The predictability of a team is subject to the predictability of the work.
Duration of a task depends on three things primarily:
Phrasing the ability of a team to estimate accurately as "maturity" is unhelpful. The opposite is more likely. You give more mature and skillful teams more interesting work, which is inherently less predictable.
Duration of a task depends on three things primarily:
- Raw effort -- fairly predictable, measurable, repeatable -- easy stuff.
- Risk -- chance we might break something and have rework or damage; VERY hard to predict in advance of efforts, extremely hard to detect without significant effort in automated testing AND exploratory testing. This can bring us late delays that cannot be ignored.
- Uncertainty -- the amount and difficulty of the learning we will do, along with the chance that we may hit dead ends and have to start over. Cursedly hard to predict even order of magnitude.
Interesting and Uninteresting Work
Work that is mostly raw typing effort is uninteresting. Nothing is learned there, nothing is innovated, nothing taxes or stretches the workers. It is a rare situation in software work because developers have a tendency to automate any uninteresting work. Not only does it save them a lot of time and tedium, but automating that work becomes interesting.
Work that involves risk and uncertainty is interesting work. It requires active minds and research and study. Nearly all software work is interesting work.
When you ask developers what they want to do, they will almost always tell you that they want to do interesting work. They want to take on hard problems and work them to completion, preferably with a minimum of distraction since risk and uncertainty will require their full attention.
Developers will also talk about safety to innovate and try things that might fail. Again, these are natural parts of doing interesting work.
Maturity?
There is an unhelpful belief that a mature team will estimate more accurately than an immature team, and therefore the teams that fail to estimate with precision are considered to be "immature" or even to be composed of "immature people."
Phrasing the ability of a team to estimate accurately as "maturity" is unhelpful. The opposite is more likely. You give more mature and skillful teams more interesting work, which is inherently less predictable.
A less mature team will likely be given less complex and risky work, which tends to be a bit more consistently predictable.
Consistency?
Organizations often expect teams to have consistent velocity and consistency in their SAY:DO ratio regarding estimates. That plays well with the idea of developers (coders, testers, ops, etc) as unskilled laborers in a simple or possibly complicated system.
If the work is interesting the velocities and estimates will have a higher natural variance.
I'll take a few numbers I pulled out of a hat to explain (not prove) this idea:
Perhaps among less interesting jobs, a small task may take between 1/2 a day and 3 days (on the order of 2 days, +/- a bit). A large task may take 6 to 10 days (8 days +/- 2 days).
Among teams where there is more learning and risk, the variance in task completion times may be greater than the maximum time in a team doing less interesting work. In teams doing more interesting work a small task may take between 1/4 a day and 5 days, and a large task may take between 2 days and 20 days (11 days +/- 9).
We should respect this as a natural variation.
A mature manager recognizes that every estimate is a span with a confidence percentage. It's just not likely that any interesting work will have a knowable end date.
I'll take a few numbers I pulled out of a hat to explain (not prove) this idea:
Perhaps among less interesting jobs, a small task may take between 1/2 a day and 3 days (on the order of 2 days, +/- a bit). A large task may take 6 to 10 days (8 days +/- 2 days).
Among teams where there is more learning and risk, the variance in task completion times may be greater than the maximum time in a team doing less interesting work. In teams doing more interesting work a small task may take between 1/4 a day and 5 days, and a large task may take between 2 days and 20 days (11 days +/- 9).
We should respect this as a natural variation.
A mature manager recognizes that every estimate is a span with a confidence percentage. It's just not likely that any interesting work will have a knowable end date.
But, We Need Accurate Estimates!
You probably do. It is possible, even likely, that you've built a system of work around the idea of accurate estimates. That is why the system (plans, schedules, assignments) is always operating in failure mode, and you lose sleep thinking about cascading schedule failures.
Do you need to need accurate estimates? Maybe you do. In that case, don't take on interesting work. Do only predictable things that have been done many times before, in a tried-and-true technology, for customers you understand very well. Don't complain about a lack of modernization, automation, innovation, or what-have-you. Keep it dull. You will probably lose some developers who like interesting work, but maybe you'll maintain a staff base of people who like trading n-hours-per-week for a paycheck, and those are the predictable ones anyway.
The bigger a task is, the more interesting it becomes. Slice the work down into very tiny, relatively dull pieces and you can reduce the variation in any given band of estimates.
But maybe you don't really need accurate estimates. Maybe you can learn to either do your work as an ongoing evolution of a software product using fixed staff and flexible scope. Maybe you can use story mapping and exception mapping and other story-splitting techniques to manage risk. Maybe you can have developers learn TDD and BDD and automated testing along with manual testing and coding. Maybe you can provide scheduled room for experimentation and dead-end mitigation.
Possibly you don't need estimates at all but haven't considered what a different system it would have to be in order to stop relying on estimates. That's a topic for another day, but maybe you could do a bit of research into other ways of working.
If you are going to do interesting work, though, you can't insist on accurate estimates. You'll have to tune your process to allow for risks other than date-and-content risks by adding slack, testing, and support.
Either way, you probably want to make sure you invest in refactoring, so simple things don't become risky and thereby unpredictable.
If you are going to do interesting work, though, you can't insist on accurate estimates. You'll have to tune your process to allow for risks other than date-and-content risks by adding slack, testing, and support.
Either way, you probably want to make sure you invest in refactoring, so simple things don't become risky and thereby unpredictable.
Your code should always be as easily workable as easily-fixable as possible. That still counts.
The Inevitable
If the work is unpredictable, as evidenced by our history of estimation problems, perhaps the lesson is that inaccurate estimates are not a problem caused by immaturity or insufficient motivation.If estimates have always been inaccurate, we have to accept that estimation error is (to us) inevitable.
If organizations all across the industry are also bemoaning poor estimates, then it's the problem with estimation is probably not just our company or our team, or the maturity of our developers.
Why not treat estimation error as normal and inevitable, and learn to cope with it while we look for some better way of planning our work?
It's how we've survived storms and market trends and other unpredictable elements for centuries; we accept it and allow for it.
If one or two "bad" estimates (ie estimates that turn out to not match actuals) will ruin a business plan and bad estimates are inevitable, then the business plan is fragile.
If we can't have better estimates, we'll need more robust plans.
No comments:
Post a Comment