This step was the one that concerned me the most to publish. It just feels so strange to point this out as a step in the process, but after much consideration, I have decided that it is truly needed. One problem that many teams in larger enterprise organizations face is that they build and build but never seem to release! Even if we know the customer will just not buy the product unless we get this one feature in.. Or the next, or the next... Does this sound familiar? It is truly critical that we select a date for the release and put a stake in the ground. Come hades, high water, earthquake, or tsunami, we will deliver on that date! It may not be perfect, or have every feature. It may not be everything to everybody, but it will be well built, well tested, and released to the customer. The quickest sure way to go out of business is to let all of the competition speed past you one release
at a time. If you are not releasing, you are NOT succeeding!
In other words, set the date. Make it big, bold, and highly visible. Do not live on false hope. Do not make promises that you cannot keep. Most of all, deliver consistently on time and on schedule. Your customers will appreciate knowing they can count on a consistent good release. Trying to be
everything to everyone quickly hurls you into the category where failure prevails. When done properly, this also makes executives very happy. They truly want to see something consistently for the money they spend. They like to see new deliverables and they truly enjoy the confidence a consistently releasing team has.
Speaking of teams, this is also the greatest way to increase team morale. Give them a goal, make a way for them to achieve the goal, watch the team grow! The team thrives in an environment where things are no longer impossible to achieve and the more difficult things become that much
easier. Only you can make this possible!
Establishing a solid release plan may be the most critical of all steps in this process. Most organizations position Release Planning as optional or do not bother to research the importance of placing emphasis on the release planning process. Many disregard the process all together as too much up front planning for an agile team. This could not be further from the truth. The Agile Release plan has recently been officially recognized as part of the scrum process and has long been regarded as critical in all other Agile frameworks.
Teams and product owners alike need this time to assess the state of the backlog and need the time to review backlog item candidates that could become part of the next release prior to iteration planning. When performed correctly, Rapid Release Planning affords the team and product owner the chance to compare thoughts regarding complexity, priority, and importance to the end consumer.
Release Planning also gives teams the chance to have a preliminary technical review of the work coming in the next release. One team recently expressed the importance of release planning to me in very simple terms. Although this is not locked backlog or frozen scope, the preview allows for the team to feel a greater sense of ownership of the release. Looking to the team for technical throughput also prevents work from reaching an iteration without a proper review.
To the executive, release planning means knowing information much sooner that allows for logical decision making. Whether it is a build vs. buy decision, or where to place additional new hire dollars, even though things may change, this foundational review affords management the chance to have a sneak peek into the future of the product.
In other words, having a consistent delivery cycle is one of the VERY important keys to Agile success.