See Your Agile Collaboration Traps In honor of the impending Create Your Successful Agile Project book release, I decided to send you a four-part series about agile traps. Yes, one for each piece of the subtitle. This one is the collaboration trap. Here are three common collaboration traps: Your team is a component team. (The […]
Do you struggle with your agile approach? Sometimes, iterations don’t work for teams. Sometimes, flow doesn’t work. Sometimes, you need both. To celebrate the release of Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, I am writing a series of articles on Infoq. The first article, Customize Your Agile Approach: Select Your Agile Approach That Fits
Yegor Bugayenko asked me to be a guest on his podcast to talk about Hiring Geeks That Fit. I gladly accepted and the podcast is now up: Shift-M/10. We spoke about many issues in hiring: Laundry list/shopping list problem in job descriptions Starting with a “test” or a phone screen (I need to write a post
The Value of Planning I like my plans. I have several levels of plans: a year or so specifically for books and workshops, a 6-month roadmap so I stay on track or change my track, a one-month week-by-week proposed roadmap, and a weekly plan. I use a kanban board to manage my weekly plans. (See
I have a new book in beta, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. (The in beta part means that it is in copyediting, and then onto layout and print. It’s a process.) I’m so excited about this book. My three most recent Pragmatic Manager newsletters were about jelled teams: The Case For
The Manager’s Role in Creating Effective Teams, Part 3 Is it a manager’s job to search through haystacks to find people who can become part of a jelled team? Not really. If you know you have an unjeller, the manager’s job is to prevent that person from being on a team you hope will jell.
Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance. In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream:
Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches: Part 1: Creating Cross-Functional Feature Teams (Teams that can produce features on a regular basis) Part 2: Programs of Cross-Functional Feature Teams (Programs (multiple teams working together) that deliver features on a regular basis) Part 3: Agile Product
I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing. When I ask people to define what they mean by scaling agile, they talk about these possibilities: They have agile developers. They want agile testers. This is
I know of a geographically dispersed team across three continents and many time zones collaborating on a product. They work in one-week iterations and have weekly virtual meetings to collaborate in real time. They never have standups because the logistics are impossible. They have handoffs instead. They retrospect at a month-long cadence. (I might like