Ripping the Planning Out of Agile

Recently I was following some twitter feed about #NoEstimates. I’m no expert, but it seems to be a conversation about the fundamental value, or lack of value, that planning provides to teams. What they seem to be arguing is that planning represents a lot of wasted effort that would be better spent elsewhere.

Fundamentally I would have to agree. I’ve wasted a tremendous amount of time arguing about story points, burning down hours, and calculating person days – all for what seems like very little benefit.

What I would rather do is spend more time talking about the problem we are trying to solve. I really value a deep understanding of the system and the changes that we intend to make to it. If I have that much, then I’m well situated to deliver fast enough that nobody’s going to give me much grief about not having estimates. That’s my theory anyway. The sooner you can deliver working software, the sooner people will shut up about estimates.

But often we never do talk about the problem at anything other than a very superficial level. We spend most of our time trying to size the effort according to some artificial schema that has nothing to do with the work or any real empirical evidence at all.

So what if there were no plan? What if we took Scrum and did everything but the planning? You show up Monday morning and you have no idea what you are going to work on. The team sits down with the customer and talks about their most pressing need. They work out what they need to build, make important design decisions, and coordinate among themselves. At no point are there any hours, or points, or days. What would happen to the cadence of the sprint if we removed the planning? Basically, we would have our daily standup, and then we would review our accomplishments at the end of the sprint and look for ways to improve.

That sounds pretty good actually. Like anything else, I’m sure it has pros and cons:

Pros: Save time and energy otherwise wasted on estimation, and use that time instead for important problem solving work.

Cons: Stakeholders really like estimates. It’s like crack. They start to shake and twitch if you take their estimates away. Not many will even let you talk about it.

It might be worth a try sometime. It would certainly make an interesting experiment for a sprint or two. What if the sprint were focused entirely on the improvement cycle instead?

Post Mortem Magazine

Years ago I used to read a magazine called Game Development (at least I think that was it). I’ve never worked in game development myself, but I found it fascinating to take a little peek into the world of the game development teams. They were always working on some cutting edge game engine technology that enabled “the next generation of jaw dropping graphics” and some form of ridiculously enhanced gaming experience. At the time it seemed to me like the game developers were very much the real deal – the applications I wrote were childish by comparison. The level of performance optimization they engaged in was astronomical compared to anything I dealt with. The geometry they used to describe the 3D worlds they created was a language all it’s own. It looked like all the cool kids were in gaming.

There was a regular article in the magazine called something clever like “Post Mortem”. Every month they would publish a post mortem written by a project manager or team that had just released a new game. These were not happy-go-lucky-aren’t-we-cool reports. No, these were unflinching, unsparing critiques of all that happened on the project. There was drama, daunting challenges, and total train wrecks. This stuff was riveting!

I used to think to myself, “Everybody should be doing this!” I was already working on agile projects at the time. I was dutifully doing a team retrospective every 2 weeks, but I never got the nerve to publish one. I probably should have, but I didn’t think at the time that our stuff would be all that interesting (in hindsight I have had my fair share of project train wrecks). Nobody else published post mortems either. This gaming magazine was the only place I’ve seen them widely published.

It would be interesting to have a magazine composed of just project post mortems and retrospectives. In a very real way it would be a collection of experimental results. Some of those experiments would be successes and many would be failures, and each and every one of them would be useful.

Of course who would read such a publication? Project Management geeks? Scrum Masters? And what would we advertise in this little catalog of triumphs and disasters? Anti-depressants? Liquor? Well, all kidding aside, I really do think it would be useful. Of course nobody makes magazines anymore. It would have to be a blog or something. Not a bad idea really. Hmmm…