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
I’ve been working with folks making their transition to agile. One of the hardest transitions is for the managers and technical leaders. Managers are accustomed to working in timeboxes. To them, the iteration is a timebox. But, they also are accustomed to features spanning multiple timeboxes, and that’s not OK in agile. They are accustomed
So where does all of this get us with budgets and dates? In many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost. It does matter