Create an Environment of Delivery One of the nice things about agile and lean approaches is that they focus on delivering value. I’m a huge fan of delivering value. The larger and longer your project or program, the more delivering value is important. That’s because your organization is investing in your project or program. They […]
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
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,
If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas. You have a couple of preconditions: The teams get to done on features often. I like small stories that the team can finish in a day or so. The teams continuously integrate their features. Frequent features
I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective. There is a problem with commitments and the need for
For years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under. Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.) This is a Gaussian (normal) distribution.
As I write the program management book, I am struck by how difficult it is to estimate large chunks of work. In Predicting the Unpredictable and Manage It!, I recommend several approaches to estimation, each of which includes showing that there is no one absolute date for a project or a program. What can you do?
I read the Business Week opening remarks, How Optimism Strengthens Economies. See this quote at the end: the group of people who turn out to be most accurate about predicting how long it will take to complete tasks—and how likely they are to succeed—are the clinically depressed. Optimists underestimate how difficult it will be to succeed.
I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow. Here are times when you might consider moving from iteration to flow: The Product Owner wants to change the order of features in
If you read my Three Alternatives to Making Smaller Stories, you noticed one thing. In each of these examples, the problem was in the teams’ ability to show progress and create interim steps. But, what about when you have a “wicked” problem, when you don’t know if you can create the answer? If you are