Mark Kilby and I have finished the first four chapters of From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver. We thought we had five finished chapters. Then we realized how much more work we had, to move from Google docs to Markdown. Sigh. We have four finished chapters 🙂 And, we know how to collaborate in
Sprints, by definition, are a timebox. You’re supposed to say, “Pencils down!” at the end of the sprint, show your work and reflect. One of the big problems with new-to-agile teams is their inability to finish work inside a sprint. Each team is unique. However, I’ve seen these causes most often: Team members multitask, so
See Your Agile Estimation Traps Agile estimation. Nothing seems to bring more fervor to an argument than by pairing the words “agile” and “estimate.” Well, controversy doesn’t bother me. Here are three estimation traps I’ve seen in agile teams: An expert signs up for their own stories, thinking it will help the team’s throughput. Your
My most recent article on projectmanagement.com is 3 Questions to Ask Before Estimating an Agile Program. In both Create Your Successful Agile Project and Agile and Lean Program Management, I talk about the reality of estimates in most settings. The question is what kind of an estimate does your project or program need? I’m not opposed to
I have a new column up on projectmanagement.com, 3 Questions to Ask Before Estimating an Agile Program. Often, management wants an estimate for the program. I suggest that before a program manager ask the teams to estimate, she learn the answers to these questions from management: How much would you like to invest in time,
See Your Agile Measurement Traps In honor of my new book, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, this is the second in a series of four trap emails, the measurement trap. Here are three common measurement traps: You/your management thinks velocity is a target or a measure of progress. Someone (often a
Back in Manage It!, I suggested that for requirements, the questions should be, “How little can we do?” and still have a great product. My argument was this: the longer the project (regardless of approach), the more risk there is. Can you reduce risk by reducing the requirements? That would allow you to release earlier
Last year, I was part of a geographically distributed team who wrote the Agile Practice Guide. Shane Hastie interviewed us during Agile 2017. His interview (which was a ton of fun!) is here: Johanna Rothman and Mike Griffiths on the Agile Alliance/PMI Agile Practice Guide. I learned a ton from that writing experience: Geographically distributed agile
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
The Case Against Stable Teams, Part 2 In The Case for Stable Teams, Part 1 , I wrote about stable teams as a way to create jelled teams. My guideline was that the longer it took for people to be useful in the team, the more you needed a stable team. Otherwise, the cost of