2018-04-18
Fortunately for the organizations they work for, development teams are smart enough not to build the original project's design -- which is why we have Scrum and Agile. But, even with Scrum, good estimating may be the least important thing you have to do: Adopting Scrum, Kanban, or any Agile methodology means that you have to be willing to stop building your project altogether.
The project to build ENIAC began in 1943 (prior to the release of information about Colossus, ENIAC was considered the first computer ever built). ENIAC was originally designed to calculate artillery firing tables for guns used in World War II. Sadly, ENIAC didn't become operational until the year after the war ended, in 1946. Ever since, we've been hearing about how IT development projects are always late and over budget...and about how bad IT project managers are at estimating projects.
In fact, that's not true.
If project managers were simply bad at doing estimates then sometimes our estimates would be too high (we'd come in early) and sometimes too low (we'd come in late). If project managers were just bad at estimating, those mis-estimates would cancel each other out. To put it another way: while individual projects would be late or early, average project delivery times would be pretty close to project estimates.
The Developer Side
But, in fact, IT development projects (like ENIAC) always come in high: over time and over budget...often very much so. For example, McKinsey & Company reports that projects are typically 45% over on budget and 7% over on time -- though, to be fair, this is for projects in excess of $15 million.
But here's the thing: We don't build the original design. As we build out the project, we often discover that we'd be stupid to build the original design because it wouldn't work.
One solution to this problem is to to mandate more planning in the early stages of the project to try and ensure that the design is buildable. That's a grand plan. The reality, however, is that we've yet to discover a modeling technique for determining if a design is buildable that's as reliable as actually building the design. So, we continue to discover, as we implement, that the original design was dumb and we shouldn't build it.
I'm OK with that. Who wants to build something that won't work?
The User Side
The other reason that we don't build the original design is that the users don't want it. As users get to see parts of the original, they come to understand the changes it will make in their world. Not surprisingly, that knowledge changes both the users' world and what they want from the project.
In addition, as the project progresses through time, the world around the project changes. As a result, the design that made perfect sense back when the project started isn't the optimal design for today. It would be spectacularly stupid to build the original design.
So we don't.
Instead, we build something that (a) will work, (b) the users actually want, and (c) makes sense in the current world. It's not surprising, then, that the estimates for the original project (which wouldn't work, the users didn't want, and didn't make sense in the current world) turn out to be inappropriate.
The Benefits of Smarter
Essentially, then, we get smarter as we work through the project. Think about it: Wouldn't it be awful if we didn't? If we were just as stupid after we finished the project as before we started it? And, as we get smarter, we can make better estimates...and design better applications.
So we do.
Which, as we discuss in Learning Tree's Introduction to Scrum course, is what Scrum does: Each sprint gives the team (both developers and users) an opportunity to make better estimates, based on how smart we are at the end of the sprint. Sprints also provide regular points to integrate into the design what the team has learned. In other words, the team can come up with something better -- you know: Something that will work, is wanted, and makes sense.
The Management Side
Not only is this better for the application, it's also better for the organization. In the pre-Scrum world, once you got your project going, the resources for the project were locked in. The organization had no choice but to carry on funding the project, no matter what changed in the world as the project went on. Sprints help prevent resources being "locked up" indefinitely by providing regular opportunities (the end of each sprint) for the organization to assess what's best for the organization. This does require a change in thinking.
Recently, I was working with a client in New York City who were starting to move to Scrum (and its variation for maintaining existing applications, Kanban). One of the people involved said "So, I'm going to go to management and say we need roughly thirteen sprints to finish this one year project? Here's the cost but I'll let you know at the end of every sprint how much it's really going to cost?"
I responded by saying that adopting Scrum actually means something much, much worse. With Scrum, I suggested, you go to management and say,
"Here's what we're going to build next. At the end of the sprint -- about a month from now -- the team (developers and users) will deliver what we promised. We'll also tell you what we want to build next. Our estimates/costs for the next month will be pretty accurate. By 'accurate,' I mean that we'll be low on some sprints and high on some others; On average, over a bunch of sprints, we'll be very close. At the end of the sprint, management will need to decide on the best use of the organization's money: Do our recommended next sprint or spend the money on something else."
The Fallacy of Sunk Costs
The guy I was talking to said, not unreasonably, "But that's terrible! We might have invested six month's worth of work into the project and management might decide not to go onto the next sprint." If you're interested, this kind of thinking is called "the sunk cost fallacy": The idea that time/money you've spent should, somehow, control what you do next.
Here's the reality: The time/money you've spent on previous sprints is irrelevant to your future decisions. There's nothing you can do to get that time or money back. It's gone. Forget about it. If your recommended "next month" isn't the best use of the company's money, if there's something else the organization could do next that's more important or valuable than your project...then the company shouldn't automatically continue with your project. Instead, the organization should spend their money on that other thing.
And, I think, that's the way it should be.
And that's Agile.
AUTHOR: Peter Vogel
Related Training:
Project Management Training
Agile and Scrum