Why do we do the things we do?

When we can explain why we d: practice, decide to keep or change the way we do things, we should have better excuses than “that’s the way we’ve always done it” or “it is considered a best practice”. If these are the only answers we have, we’re in a bad place.

In fact, if we continue to do things without understanding why, not only will we not understand why they go wrong, we can’t do course correction in order to improve the situation.

In recent years, we’ve heard stories about “cargo cult“, people continue doing the same things that worked before, but because circumstances have changed, the practices are not useful anymore. Too many times we follow the scrum (and other methodologies’)  practices, and people continue to get surprised at the results.

So let’s explain the “why”. This will turn out to be a series, so watch out.

And let’s start with the trigger to the series.

What’s the plan?

Planning, estimation, and all ways of predicting the future, have been a hobby of mine for a while (as readers of this blog know. Check out some #NoEstimates posts.). Have you considered why we do the sprint planning that way?

A long time ago, in the days before agile, we had problems of trust. We were missing deadlines left and right (maybe that wasn’t only long ago…). We would plan for five year projects. Results were very bad for business.

The business people never understood why developers (and testers, and any part of the product development team), were delivering late. And why they delivered the “wrong” software. They wanted predictability, but never got it. The development team didn’t understand why the business people always change their mind, and then complain that the dev team never met deadlines or budget.

The blame, of course, wasn’t with either side, it was with reality. The longer a project was, more uncertainty poured in, things had to change, new unknowns became apparent, the unforeseen revealed itself. You get the picture.

Developers struggled with unplanned problems. Business people needed to adjust their requirements. Both sides try to maintain course, while dealing with uncertainty. As in many cases, the trust issues were not the core problems, merely the symptoms.

Scrum, and other agile methodologies tried to disarm the trust bomb, by cutting the main wire. In fact, it planned to harness the power of trust for the forces of good.

Introducing a sprint (a lousy word to begin with) or iteration, a short time box, does that, as long as everyone plays by the rules.

1. Within the sprint, the business people promise not to change their mind. Requirements are stable, and the team can work on them without distractions.
2. The stories are prioritized so work on them is in order of importance, visible to both the team and the “customer”.
3. The developers promise to deliver the committed stories as working software. Really working, tested, not “on my machine”.
4. The planning ceremonies brings both sides to the table, where the developers can give the business people the predictability they always wanted, at least until the end of the sprint.
5. Because the sprint is a lot shorter than a multi-year project, planning is shorter and more accurate. (Read: There’s not much we can mess up in a single sprint).
6. At the end of the sprint, in a regular cadence, the business gets to see actual progress by the team. And if they see something they don’t like, they can change their minds and do something about it in the next sprint. (Read: if they messed up the sprint, it wasn’t a big loss).

If everything works, everyone gets what they wanted: The business people get to see actual delivery, predictability of delivery cadence and visibility into the quality of the product. The developers get to work on what they understand, and not on ephemeral requirements. Their estimations are a lot more accurate, and are usually achievable. For everyone, it’s a framework that delivers consistently, effectively and in a more efficient manner than before.

And if everything works, we get a bonus: Trust between both sides rises. And with trust, we can do all kinds of stuff we were afraid to do before. With trust, we can experiment. For example, the business people can let the team suggest and implement features. The business people don’t need to spell everything for the team. They can rest assure that what they get actually works. And both sides can reduce the time spent on planning, and actually working.

Nice things to have indeed. But there’s a catch, of course. The rules have to be obeyed fully.

1. “Working software” is actually working. Tested, demo-able and ship-able.
2. No changes within the sprint.
3. Availability of knowledge (usually product answers) and visibility of status.

When any one of these things break, the framework collapses. Consistent delivery, predictability, and trust is not going to be achieved. It’s very easy to disrupt the framework. But you already know that.

Agility is not about sticking to ceremonies, and scrum is anti-agile in that sense. But, the reasons we plan like that is to achieve that trust and delivery cadence. If your teams have already achieved that, there’s not much sense in adapting scrum planning.If however you decide to do that, make sure you’re adapting it for the right reasons.

So if you’re doing it wrong, it’s fixing time.

We’ll continue with planning wrongness next time. God knows there’s plenty of it.