It must have been the morning to challenge planning efforts, as GeePawHill did here. I was answering a post that had gotten around to discussing budgeting and planning for interruptions to fix legacy apps while teams are building new stuff.
When all of the sudden, I blurted this out:
Kanban is simple, in theory. Simply do one feature or bug fix all the way to being released. AKA focus. But there is a lot of things that have to be working well, for example: the cost of testing has to be low so that it doesn’t cost a fortune in treasure or time to get in that new feature or bug fix. (Expensive testing often leads to bundling a bunch of stuff into a given release and widening the time window, and introducing parallel development techniques.)
And, regarding budgeting in to prepare for the unknown maintenance efforts… That’s but one way to handle things. Another way is simply let the people who care about getting things done participate in setting your priorities. If you were given 10 things to do in a month, and halfway through you get an 11th thing to do. You probably don’t need to budget for that unknown. You simply ask for help deciding which of the original 10 should get axed to make room for the new “emergency” item.
Like it or not, you are all in it together, it is a zero sum game. If you fix the resources, fix the schedule, the amount of work that gets done has to give when new work is injected. Deal with it in an honest manner.
Hard to describe in words… and had to know your exact context… but what you are facing is probably more of an organizational issue than anything else.
All we software folks do for a living is produce features and fix bugs to keep paying customers happy. Just keep trying to improve your team’s efficiencies and squeeze out wasteful practices.
When you are producing software as an internal organization, you can sometimes be brave and forgo lots of planning stuff. If you have the priorities set, and if you have a delivery schedule, and if you understand your costs of releasing, you can make a pretty simple and smooth process. I’ve done it many times in companies formerly steeped in waterfall fantasy land. Why waste all sorts of time making estimates if you don’t have to?
The answers to these questions can help you decide how much ceremony your processes need:
- Does it matter if the team does 5 things in an iteration or does 10?
- Does it matter if they estimated 10, but only wound up being able to do 5?
- Or, if they bid 5 and found they could do more and gobbled up 10, is that a problem?
- Is it more important to hit a date with at least some features?
- Or, is it more important to produce specific features as fast as you can, even if you miss the date?
- Does the team need to be accurate on their estimates? How accurate and why?
Many times, we fall into traps of wanting to manage software process as if it were a brick-making factory. Unless you live or die by doing software as a fixed-bid project, you can often really get simple and make software really fun in your organization by doing less ceremonial planning crap!
Pingback: Tweets that mention Plan & Estimate, Only if You Must « Technical Debt -- Topsy.com
And even if you have to plan you can choose to go with coarse-grained but pretty accurate estimates which you can get quickly (there are a few assumptions here though) instead of putting a lot of effort to get something very specific which is completely wrong.
And the funny thing is you’re right – we keep saying how much we suck at estimation but at the same time we often enforce estimation even if there’s no need to estimate precisely at all and we can go with very rough gut feeling instead.
Pawel, I’m with you on the coarse-grained approach. I like to choose Seasons. And hopefully, don’t get asked which year.