Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release. One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all
Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt. One of the big problems in backlog management is ranking technical debt stories. It’s even
In Part 1, we discussed the cost of delay of not shipping on time. In Part 2, we discussed the cost of delay of multitasking. In this part, we’ll discuss a cost of delay due to management indecision. Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop.
In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk. Sometimes, you don’t have short projects, so projects
I’ve been thinking about estimation these days. After the healthcare.gov site fiasco, and all the schedule games–many of which are estimation problems, I thought about why we estimate. The larger the effort, the more we need to estimate. And, the more your estimate will be wrong. The more we estimate, the more we have schedule
I read Sayonara Sony: How Industrial, MBA-Style Leadership Killed a Once Great Company, and was struck by how the company appeared to make decisions—what will make us the most money now? If you make your project portfolio decisions based on money, estimated cost, you too will have Sony’s problems. This is why cost is the
If you read my most recent post, Comparing Teams Is Not Useful: Exposing Another Management Myth and the comments, you will see that I rant about the business of normalizing story points for predicting cost or schedule for a program. That led to several comments re SAFe for programs or other frameworks or lifecycles for
Long ago, when I was a young developer at an anonymous company, one of my managers was disappointed with my progress. “I know how long the work should take. If I was doing the work, it would be done by now,” he huffed at me. “Really?” I could have stopped there. I didn’t. “If you
I’m giving a talk at Agile 2012, entitled “How Much Will This Project Cost?” It doesn’t seem to matter what life cycle your project has, someone wants you to predict the cost. The problem is, it’s the wrong question. But, that won’t stop people from asking it anyway. People want to know the cost so
I’ve been talking to people whose management cares about their velocity. “My management wants us to double our velocity.” Or, “My management wants us to do more in a sprint.” Or, “My management wants to know when we will be a hyper-performing team, so they want to know when we will get 12x velocity like