Thinking About Servant Leadership and Agile Project Management

For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management. I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way. If you are looking to increase your servant leadership and help your project team (or program), check out the Influential Agile...

Value of Burndown and Burnup Charts

I met a team recently who was concerned about their velocity. They were always “too late” according to their manager. I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they “committed” to for each iteration. This is what their burndown chart looked like. A burndown chart measures what you have finished. If you look at their burndown, you can see there are times when not much is done. Then, near the end of the iteration, they finish more. However, they don’t finish “everything” before they run out of time. An iteration is a timebox, by definition. In this case, having to “declare victory” and assess what they were doing should have helped them. But, when this team saw the burndown, two interesting things happened. They beat themselves up for not finishing. And, when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added, not replaced. That meant they never caught up. They tried this burndown chart next, to see if they could meet their ideal. They realized they were “late,” off the ideal line from Day 2. They felt worse about themselves. They stopped doing retrospectives, which meant they had no idea why they were “late.” A burndown emphasizes what you have completed. A burndown with the “ideal” line emphasizes what you have done and what you “should” be doing. I have used story...

Creating Great Estimates as a Team

I’ve been teaching workshops these last few weeks. A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.” I have found that the smaller the work, the better the estimate. If people work as a team, they can provide more accurate estimates than they can alone. And, if they work as a team, the more likely they are to meet the estimate. The people in my workshops did not want to hear this. Many of them wanted to know how to create an estimate for “their” work, accounting for multitasking. I don’t know how to create great estimates when people assume they work alone, or if they multitask. In all of my experience, software is a team activity (especially if you want to use agile or lean). For me, creating an estimate of “my” work is irrelevant. The feature isn’t done until it’s all done. When we create solo estimates, we reinforce the idea that we work alone. We can work alone. I have discovered I have different ideas when I pair. That’s one of the reasons I ask for review, if I am not actively pairing. I have also discovered that I find problems earlier when I pair or ask for frequent review. That changes my overall estimate. Multitasking creates context switching, with built-in delays. (See Cost of Delay Due to Multitasking, Part 2 or Diving for Hidden Treasures.) I don’t know how to account for the context-switch times. For me, the context-switching time varies, and depends on how many switches...

Great Review of Predicting the Unpredictable

Ryan Ripley “highly recommends” Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. See his post: Pragmatic Agile Estimation: Predicting the Unpredictable. He says this: This is a practical book about the work of creating software and providing estimates when needed. Her estimation troubleshooting guide highlights many of the hidden issues with estimating such as: multitasking, student syndrome, using the wrong units to estimate, and trying to estimates things that are too big. — Ryan Ripley Thank you, Ryan! See Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule for more...

What Creates Trust in Your Organization?

I published my most recent newsletter, Creating Trustworthy Estimates, this past week. I also noted on Twitter that one person said his estimates created trust in his organization. (He was responding to a #noestimate post that I had retweeted.) Sometimes, estimates do create trust. They provide a comfortable feeling to many people that you have an idea of what size this beast is. That’s why I offer solutions for a gross estimate in Predicting the Unpredictable. I have nothing against gross estimates. I don’t like gross estimates (or even detailed estimates) as a way to evaluate projects in the project portfolio because estimates are guesses. Estimates are not a great way to understand and discuss the value of a project. They might be one piece of the valuation discussion, but if you use them as the only way to value a project, you are missing the value discussion you need to have. See Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio. I have not found that only estimates create trust. I have found that delivering the product  (or interim product) creates more trust. Way back, when I was a software developer, I had a difficult machine vision project. Back then, we invented as we went. We had some in-house libraries, but we had to develop new solutions for each customer. I had an estimate of 8 weeks for that project. I prototyped and tried a gazillion things. Finally, at 6 weeks, I had a working prototype. I showed it to my managers and other interested people. I finished the project and we shipped it. Many years later,...

Predicting the Unpredictable is Available

I’m happy to announce that Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule is done and available. It’s available in electronic and print formats. If you need a little help explaining your estimates or how to use estimation (even #noestimate), read this book....