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.

Access this video on both Vimeo and YouTube.

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.

Jeff Nielsen

Jeff Nielsen

SVP of Engineering

Jeff Nielsen is 3Pillar’s SVP of Engineering. In this role, he oversees the delivery of technology services to all 3Pillar clients. Jeff is responsible for all development processes in the company and manages numerous global client-based engineering teams.

Prior to 3Pillar, Jeff was the CTO and SVP of Delivery at the Santeon Group, where he ran their global software development initiatives and their agile coaching practice. At Santeon he provided executive-level coaching to federal agencies and Fortune 100 commercial clients making large-scale transitions to agile. As Head of Engineering at TrapWire for three years, he oversaw more than 50 production releases of the company’s flagship SaaS product. Jeff was also Vice President/Chief Scientist at Digital Focus, pioneering their use of agile methods in early 2001. Jeff has worked with a number of organizations – from startups to multibillion-dollar firms – over the course of more than a decade to help them improve their software development processes.

Jeff holds M.S. and M.A.Ed. degrees in Computer Science and Instructional Technology from Virginia Tech and a Bachelors in Music from BYU.

Leave a Reply

Related Posts

Tarun Kumar at the Component Driven Development Using React.... On June 29th, Tarun Kumar spoke at Component Driven Development Using React.js at 3Pillar Global's office in Noida, India. Component Driven Developmen...
Interviews from Industry Summit 2017 – with Guest Host... On this special double episode of The Innovation Engine, the 3Pillar team interviews many of the speakers who took the stage at Industry Summit 2017. ...
Ravish Tiwari at the Component Driven Development Using Reac... On June 29th, Ravish Tiwari spoke at Component Driven Development Using React.js at 3Pillar Global's office in Noida, India. Component Driven Developm...
Raj Kumar Bharti at the Component Driven Development Using R... On June 29th, Raj Kumar Bharti spoke at Component Driven Development Using React.js at 3Pillar Global's office in Noida, India. Component Driven Dev...
Selecting The Minimum Viable Toolset for Product Managers This summer I was attending a machine learning conference and during a break, found myself deep in conversation with fellow product managers. As typic...

SUBSCRIBE TODAY


Sign up today to receive our monthly product development tips newsletter.