Friday, March 4, 2011

Ignoring long-term planning and estimating

I got on the agile bandwagon fairly late considering people are now celebrating the 10-year anniversary of the agile manifesto. But it's been a good 2 years now and I feel like it's a good time to sum up some of my experiences. And I'll start by writing something about estimating that's recently been on my mind a lot.

I get the impression that a large part of what people use to sell Scrum to managers is the ability to get better estimates and more reliable long-term planning. That tracking velocity and assigning storypoints to your features somehow enables you to determine what exactly you can release half a year from now. I don't think that's entirely honest. You still have no way to reliably predict accidental complexity; and team fluctuation, shifting priorities and delays in external processes that you depend on will still leave you guessing when you'll have that big new release ready.

The constant feedback obviously helps to at least be able to react to some of these obstacles. A looming deadline works wonders to get stakeholders to prioritize the features they want implemented. But I think all of this is looking at agile development from an old-fashioned angle, that is likely to be more frustrating than necessary.

Those big releases and big new major versions of your products just don't make all that much sense if you're not actually burning your software to disks to be put onto shelves. If you have a new little feature that will help your customers have a better experience using your product why wait to release it? If that feature actually doesn't help your customers, why wait to find out about it?

If you're a long-term agilante (agilista? agilero?), that is probably pretty obvious. But personally, I don't think I really grasped the power of that until recently. Really taking the idea of short iterations with incremental changes to its conclusion is not something I've seen much of in the time I've been developing software. You may read about some of the big poster-child internet companies working that way and increasingly, little start-ups seem to have a lot of success with it. But once companies get to a certain size they seem surprisingly eager to hold back on actually releasing their software.

And, with that said, I have decided that I do not care about estimating any more. I do care about the people on the team, I care about splitting items up into fine-grained tasks [edit: 'features' is probably the better word]. I might even care about tracking time spent on tasks to get feedback on whether we've become stuck on something. I care and take pride in the quality of the code we deliver. I care about people using that software and the feedback they can give. I don't care about dates in the future that may as well be arbitrary.

I conveniently ignore any kind of marketing needs or grand c0mpany strategy. Because, really, why shouldn't I? If we can consistently release new features in a short timeframe and the quality is good, why shouldn't the company strategy adapt to this rather than the other way around?

This idea is fairly fresh in my mind and I'm really looking forward to seeing what it develops into. I'm pretty sure I've missed a few things. And I'm curious what other people think about this...

And to aptly prove the motto of this blog, Naresh Jain wrote about this two ears ago. Well worth reading.