When I talk to project managers, or managers in general, one of their main concerns is the precision, or lack there of, in their planning. It is still common that development projects overrun their deadlines, resulting in frustration, loss of money and trust, and cause a lot of extra work in re-planning dependent activities. So many managers look to Agile for a solution to this problem.
But very few seem to realize the inherent problem in planning development work. It is not uncommon for managers of large projects to think of planning as a simple process of converting required functionality to manhours and then allocate enough people to do the hours. It seems to be working when planning other types of projects, so why shouldn’t it work for development?
Well, first, does it really work for other types of projects? Software people have always been blaimed for beeing the worst when it comes to planning; road work, house building, are always on time. Well, no, their not. At least not most of them.
What is development, really? Some people view software development as a production process: from the requirements manufacture the software. Sometimes it can be, but usually we then quickly create a tool that can do that repetetive work for us. So what’s left? Only the parts that are not repeatable. The ones that require engineering and design. That means that development work is a creative process. Or rather, it is problem solving. Constantly solving new problems is what development is. At its core it’s like solving a continuous flow of crossword puzzles. And like crossword puzzles, some things are easy, sometimes as hard as we thought. And some things, much, much harder. Did you ever give up on a crossword puzzle?
So can you tell me how long it’s going to take you to solve the Sunday crossword puzzle? Of course you can’t. You don’t know what the questions will be, what problems you will have to solve. So development work is inherently unplannable. Period.
How can we then promise anything at all about when something will be ready? Agile planning uses statistical methods to get planning to work. And statistical methods needs multiple values to work, you can’t use a single value as a basis for statistics. And you don’t do statistics by guessing, you measure. And the more data points you have, the better your statistics will be.
Doing the Sunday crosswords for a year will give you 52 datapoints, resulting in a reasonable probability in your guess for the next one. It still won’t give you any guarantees for how long the next one will take, but on average you will know. If you wanted to know the total time for the next 52, you’d have a pretty good guess.
If you do various sizes and types of crossword puzzles you could probably find some statistical correlation between the number of squares or questions in a puzzle and the time it took. This adds to you statistical samples, maybe up to a few hundred squares over a year, increasing the statistical probabillity of your future projections.
If you want to have good statistically based projections you need many actual samples, and many planned samples. And how do Agile planning help us with that?
By
- breaking down functionality into small parts
- always include everything required to keep quality
- measuring average development speed
Because development work is problem solving we need statistical support for our planning, and because we need statistical support for our planning we need many samples. The agile techniques to do that are small stories, done criteria, velocity and story points. And as many of them as we can get.