Agile Planning Land Mines

The agile manifesto and its specific implementation in Scrum have revolutionized software development. In its original form, it prescribed the practice of basically two loops, cycles, or increments. The one that we most frequently think of is the sprint. Typically a two week period in which a team seeks to deliver another working unit or increment of a product. But there is also another cycle that we don’t typically think of and that is the day.

Just as there are special ceremonies that attend the sprint, a retrospective looking backwards and a planning meeting looking forward, so in the daily scrum, there is communication among the team about what was accomplished in the previous day and organization about what will be attempted to be finished in the day that lies ahead. So even though each of these loops has its own characteristics, they are not radically different.

This is even demonstrated in the classical diagram of the scrum process. I heard someone describe this diagram as the “snail with a tumor on its back” and I’ve had it in my head ever since. If you’re not sure what I’m talking about just do a google image search for “scrum development” and you will see it everywhere. It shows a large loop representing the sprint and a smaller loop on top of that representing the daily scrum.

Many die-hard adherents of the original scrum guide believe that this is all that is required to do good iterative software development and that any planning that extends past the sprint is blasphemy and, at best, a reintroduction of the waterfall development methodology. And yet the desire and demand for longer-term planning repeatedly rears its head under the terms of release planning, sprint zeros, and product road mapping.

I believe there is a great secret here for us to discover because I don’t believe that the desire for these longer-term plans is unjustified nor do I believe they are anathema following the strict strictures and values enshrined in Agile and the Scrum process. Let’s look at each of these specific flavors of longer-term planning and see where each fails and then examine what a truly faithful pattern of long term planning might look like within the scrum process.

Firstly we have release planning. This presupposes that a release is larger than a sprint which, on the bare face of it already militates against scrums requirement that the conclusion of a sprint should be a potentially shippable product increment. That means if we are being real with our language, that every single sprint should produce a releasable release. What’s more, the advances in continuous delivery (CD) have made it possible and desirable to deliver functional features multiple times within a sprint. It has reached a point where it is a bragging point to say that one’s team pushes to production multiple times a day. So we see that CD has kind-of made obsolete defining longer-term planning efforts as release planning.

Secondly, we have the infamous Sprint Zero. This is defined as a period of time that the scrum team uses to set up a project and plan the larger initiative related to what they are trying to build. While its name is very different, the desire behind it is not fundamentally different from release planning. It certainly can’t just be planning for the next sprint because that would just be sprint planning and it’s also not just the first sprint of a new team because the teams that practice it do it on a recurring basis. The unfortunate part about this practice, and the area in which it is most routinely attacked is that it violates the principles of what a sprint is supposed to deliver. A sprint is supposed to produce a working product increment and a sprite zero makes no attempt to do so. It is to its creator's credit that they did do their best to introduce this longer-term planning that everyone wants in the terms already being employed by the scrum framework. They repurposed the sprint increment and just defined this sprint as a special case. Another unfortunate side effect of this is that long term planning does not typically require an entire sprint to do so not only do we have a sprint without the required properties of a sprint but it’s also not even the length of a sprint so now we find ourselves just using terms to fit things in.

Lastly, we have Product Roadmapping. Unhampered by any desire to abide by existing scrum practices, this kind of long term planning is typically done without any of the development team’s involvement and sees itself has happened completely outside of the existing scrum loops. It’s kind of seen as a byproduct of a team's product owner working with other existing business stakeholders to produce a long term vision that will be either delivered to the team in a big reveal or either metered out to them in the form or backlog items. The difficulty with this is that it is not possible to get estimates of any of this work without the team. So there is no road map. There may be a list of desired features but there can be no roadmap without estimations and no one can estimate the work but the team.

So to conclude the quandary in which we find ourselves if releases are obsolete in release planning and “sprint zeros” are no sprints and all and a misuse of the sprint term, and product roadmaps give us no real roadmap, where do we go?

In future posts, I’d like to describe a practice of long term planning that subscribes to the strict principles of the iterative method, does not bastardize any of the established existing scrum artifacts and activities and, further, expands upon the philosophy and fundamental mechanics of scrum.

I believe that, as we dive into this subject with greater care, you will not only be confident and empowered to do longer-term planning in a truly agile way but that your understanding and appreciation of the existing scrum practices will be revolutionized as well.