Agile Best Practices: SVP of Engineering Jeff Nielsen on “Release Planning”

Release Planning is a fairly common agile practice used in many software development companies. 3Pillar’s SVP of Engineering, Jeff Nielsen, explains in this video the five common misconceptions associated with release planning and how to work around them to create the best possible outcome for your company.

Transcription:

Release planning is a fairly standard agile practice where a team gets together to figure out what’s going to go into the next production release of their software and how it is they are going to build those features. I’d like to explore this important practice by talking about five common misconceptions about release planning.

The very first misconception is that the main goal of doing release planning is to produce a release plan. That’s a logical assumption but a faulty one. Instead, the value of release planning is in the activity itself—in the conversations that happen as we are grappling with these questions of what should we build and how are we going to build it. I am reminded of a quote that is attributed to Dwight D. Eisenhower where he said, “In preparing for battle, I have found that plans are useless but planning is indispensable.” And that is how I feel about release planning. It is not the artifact that pops out at the end that is the key thing but rather the activity of mutually working together to come up with that artifact—to create at least one solution to our problem that produces the value. And that is tied to misconceptions number two and number three.

Misconception #2 is that you can do release planning with just a subset of the team: get a project manager, maybe a business analyst, and a couple customer representatives and you can put the plan together. That misses the whole point of the value of being in the conversation. Sure you will get some good results and some kind of plan out of that, but half of the team will miss the benefit of these conversations. More importantly, we will miss the varying perspectives that can come when you put together business people with an understanding of the domain and the market and the customer; product people that are good at marrying technical solutions with business problems; and then engineers who are fantastic about knowing what will work, what won’t work, this costs this much, this is easy, this is hard and here’s the latest and greatest tool set we have to work with. When you can get all those people together in a conversation – a planning exercise where you are brainstorming, where you are trying to innovate—you can get some powerful things coming out of that conversation.

Misconception #3 is that release planning is just an estimation exercise. Someone has figured out what we ought to do, and we just need to translate those requirements into user stories, estimate them and we’re done. Again, that misses the point. There is a piece of release planning which involves estimation. That usually comes after we do some joint brainstorming. We do divergent thinking about the problem were trying to solve; we get a bunch of user stories, put some estimates on and we put some constraints around what we think the team’s capacity is; and then we put all those pieces together and try to answer the question of whether we have a shot at building what it is we want to build. But the estimation is just a small piece of this overall activity, which is really mutually exploring options together and jointly trying to converge on at least a good plan of attack, based on a shared understanding of what it is that we’ve set out to accomplish.

Misconception #4 is that once you have done release planning and produced a release plan, that release plan shouldn’t change much. And that’s again patently false. The Agile manifesto tells us that we value responding to change over following a plan. So the fact that our plan is going to change 30%, 40%, 50%, 70% as we go through and execute during the release doesn’t mean that our planning activity was useless. On the contrary, the foundation that is set by these release planning conversations—by learning together and developing a shared understanding of the problem space and the potential solutions – that actually puts us in a great position to be able to accommodate new learning and new understandings and new ideas as we execute the release. So don’t get too bothered by your release plan changing dramatically as you execute.

Misconception #5 is that we should only do release planning – we only need to do release planning – at the beginning of a release. Now, many teams do adopt some sort of quarterly cadence, releasing every two or three months, and they set aside a week specifically to do release planning in between those releases. But really any time we want to step away from the day-to-day (the tactical) and explore a problem together and explore potential solutions is a good time for a release planning exercise. It doesn’t need to take a whole week like you would do at the beginning of a quarter; you can do it in two or three hours in a morning. Someone brings a new feature idea and you gather this group of people together (this cross functional team), you brainstorm some stories, you talk about possibilities – pros and cons of different options—and  you then incorporate that into your overall plan of attack.

Let me leave you with one more powerful idea, which is that the main purpose of planning (or release planning in this case) is not certainty but rather confidence. What we’re trying to do with release planning is not to come up with the perfect plan that tells us exactly how long everything is going to take and assures us of what we are guaranteed to get at the end. Rather, we want to come away with this sense of confidence that we can do this—that we’ve put our best thinking into this problem, we have a good plan of attack, we see at least one way to get to the end, and we are confident that we can change and adjust and learn as we go. If you come away from a release planning session with that type of feeling, then you know you’ve done it well.