I’ve worked in seven different shops so far in my career, and I’ve seen at least twice that number of approaches to planning software development efforts. Some approaches worked better than others, but all failed in one or more respects.
So what is it about planning software development efforts that seems to stymie processes and organizations? Here are some things I’ve observed over a quarter of a century.
(Wow, I did not like the way that sounded…)
Deadlines, not Estimates
Business-people — managers, marketing, sales — want certainty. It is important for a business to predict when new software or features will be available. That’s the entire reason we sit down to plan out and estimate effort.
But notice the vast difference between the words certainty and estimate. The business needs deadlines, but we plan in terms of estimates. We just don’t know with any degree of certainty how long many of the things we do will take.
Now, I’ll be the first to admit that we often just don’t try very hand. We pull estimates out of any number of orifices, fling them into Microsoft Project, or a spreadsheet, or a whiteboard and that’s that. In my experience though, that isn’t typical — we generally do our conscientious best to estimate things out.
We know these are estimates. Nonetheless, they are typically interpreted as having a higher degree of certainty than they actually possess, and are thus treated as deadlines by those who need deadlines. This leads to no end of dysfunctional organizational behavior as both developers and business-people scramble to bridge the certainty gap when things fall apart.
Most methodologies and processes I’ve seen used don’t adequately address the variables that go into planning a single task.
Skills: A 10 hour task for me might be a 5 hour task for Sarah or a 30 hour task for newcomer Bill. But tasks are shuffled around between different people as if estimates are not dependent on who does the work. This is a classic misapplication of assembly-line logic.
Complexity: Related to skills, but different: some tasks are just inherently straightforward, while others are much more subtle. Performance-critical tasks often fall into the latter category.
Unknown Unknowns: Related to complexity, but different: the complications that we don’t realize we don’t know about. Plans are too often built without buffers of any sort to try and absorb new, previously-unplanned worked, such as tooling upgrades, toolkit obsolescence, etc.
When processes or methodologies fail to account for this type of variability, they inevitably oversimplify, which remorselessly leads to schedule overruns.
Revising Over Time
Everyone knows that plans only last until you get punched in the face (Mike Tyson). Everyone admits that action now is better than a perfect plan tomorrow (George Patton). Unfortunately, everyone forgets both these things as soon as a plan begins to play out (me).
Every process or methodology needs a way to track progress, reassess existing schedules, and republish them. The first two are pretty easy, but the last one is nearly impossible: once a date has been exposed to external business-people it is become death, the destroyer of worlds.
Business-people need certainty. Developers have no choice but to be uncertain. For purposes of keeping a business alive, we need to meet somewhere in the middle.
Types of Tasks
Every schedule I’ve ever scene has a mix of estimation types within its list of tasks. But most processes tend to lump every task or activity into a category of identifiable, specific items with a well-defined deliverable. However, consider the following:
- Ongoing tasks: “We have a team of four working on defect reports at all times.”; “We have two people who are on-call for support at all times.”
- Time-boxed efforts: “We’re going to research topic X, spending up to 40 hours on it.”
- Calendar-boxed efforts: “We’re going to play with this new toolkit for two weeks and see what we learn.”
- Dependent tasks: “We’ll be able to do task X after party Y completes task Z, and we have no control over Y…”
Some processes deal well with certain of these tasks. But all of them make planning more difficult, and so they are sometimes (oftentimes?) swept under the rug and dealt with outside the plan.
Hope is the thing with feathers.
— Emily Dickinson
We all like to make other people happy. (Well, maybe all of us except Scheme programmers…) We all like to be the bearer of good tidings. We are all optimistic at the start of a new project.
We are all fools.
(At least when it comes to planning software efforts…)
Honesty coupled with ruthless pessimism is our only defense against the scourge of hope.
— a book by Woody Allen
It’s a sad truth that many organizations are run in a very top-down, paternalistic, almost militant way. Schedules are handed down from on high, rather than being derived from estimates by the team. Plans are half-born things that struggle for any sense of reality or authenticity.
It’s also true that most places aren’t that bad 🙂 Still, in today’s business climate, no one would rush into risking their job by giving realistic (if not ruthlessly pessimistic) estimates where they are not welcome.
What about Agile?
I’m not picking on Agile. I like Agile methods, whichever way you interpret “Agile”. I just felt like it was necessary to discuss at least one specific methodology to lend some credence to my vast over-generalizations…
Agile does an admirable job of recognizing and (at least partially) dealing with many of these issues. Release efforts are time-boxed, and short, reducing the scope of planning activities to more predictable boundaries, thus reducing risk. It focuses on visibility of development plans to business-people to help bridge the gap between deadlines and estimates.
But agile is weird. It’s weird to business-people. It’s weird to developers. It takes getting used to since one can’t fall back on a standard Gantt chart; one must learn about “stories” and “burndown” rates and Scrum-masters. (Which frankly, sounds too much like Dungeon Masters and reinforces our hereditary, hard-earned stereotypes…)
And I’m not convinced that Agile methods scale to very large, very hard problems. Sprints are just too short. Or maybe I don’t understand the methodology well enough. That certainly doesn’t disqualify it as a methodology, but the types of problems I’ve worked on tend to fall into this category. So I have mixed feelings.
What Should I, Developer, Do?
- Don’t try to force your organization to change its methodology. This is a seriously tough row to hoe (forgive my hay-seed roots) and requires more clout than most individuals have.
- Respect the needs of business-people for certainty. They have very legitimate reasons for wanting deadlines. Work with them to find ways for them to meet their goals despite the uncertainty.
- If you can get away with it, always give estimates in terms of ranges: e.g. from 2 to 4 weeks. This is a good way to convey degrees of uncertainty in a visceral way.
- Plan buffers to handle things you don’t know about. If your organization’s planning process doesn’t explicitly support such buffers, add them into your estimates. (This is not dishonest: you are responsible for making your estimates as accurate as you can, and planning for unknowns is certainly a valid component of that.)
- Track your own performance. Careers are long. Gather information about how long projects you work on have taken. Track your initial estimate and how long something actually took; track lines of code if you find it helpful. Don’t share the data with anyone, just use it yourself to make your own estimates better.
Then cross your fingers and hope for the best…