OLYMPUS DIGITAL CAMERA

The release planning event in the Scaled Agile Framework Enterprise (SAFe) is a two-day program-level planning event that focuses the efforts of a group of teams to pursue a common vision and mission. As we have noted, the event includes participation by everyone involved in the Agile release train (ART), participation is in-person (if humanly possible), occurs every 8 – 12 weeks and has a formal structured agenda.   The agenda has five major components:

  1. Synchronization.  This component seeks to get everyone involved in the ART on the same page in terms of:
    1. Business Context
    2. Product Vision
    3. Architectural Vision
    4. Technical Environment and Standards

Each of these subcomponents provide the team with an understanding of what they are being asked to do and the environment they are being asked to operate within. The flow begins by grounding the team the business context for the program increment (the 8 -12 weeks). Each step after the business context increased in technical detail.

  1. Draft Planning. Leveraging the context, vision, architecture and environmental standards, the teams develop a draft plan. We will explore the process in greater detail in a later essay, however this where the team breakdown the stories they will tackle during the program increment, breaks them down, exposes risks and identifies and minimizes dependencies.   Draft planning usually consumes the second half of the day. The Release Train Engineer will gather the scrum masters together periodically during the draft planning process to ensure teams are sharing dependencies and understand the direction each is heading.
  2. Management Review and Problem Solving. At the end of draft planning, any significant problems with the scope of the program increment, staffing or other resource constraints are generally apparent. After the majority of team has completed their work for the day the management team (including RTE and scrum masters) meets to share what was learned and make the decisions needed to adjust to the constraints. This is must be completed before the beginning of day two.
  3. Final Planning. The teams review the adjustments made during the during the management review the previous evening as a whole group and then break out into teams again to continue planning converting the draft plans into final(ish) plans. Plans are finalized when they are accepted by the business owners.
  4. Review, Re-planning and Acceptance. When the teams plans are finalized they are reviewed by the whole team, the risks are ROAMed, the whole team votes on acceptance (a form of peer review and acceptance), any rework is performed on the plan and finally a retrospective is performed and next steps identified.

The release planning meeting operationalizes a program increment. A program increment represents 8 – 12 week planning horizon within a larger Agile Release Train. The large scale planning event helps keep all of the teams involved in the ART synchronized. The release planning meeting might be SAFe’s special sauce.

Advertisements
Step out of the chaos!

Step out of the chaos!

Information technology projects are typically a bit chaotic due to interaction of people, the environment and the inherent complexity of software and hardware. The bigger the project, the more complex and chaotic the project becomes. Unfortunately, all products and services can’t be delivered based on the output of a single small team or even a swarm of independent small teams. Coordination and group thinking is required to deliver large projects. Scaled Agile Framework Enterprise (SAFe) addresses this coordination and planning need with a period release planning event. Release planning is one the lightning rods in the discussion of scaled Agile frameworks overall and SAFe in particular.

In SAFe, release planning is done as a large-scale event for each program increment (a period of time typically spanning 8 – 12 weeks). The goal of the of the two-day release planning event is not only to synchronize and energize everyone that is working on the project, but also to assure a coordinated approach to delivering value. A few of the critical success factors for this group planning and coordination activity are:

  1. Release planning is a formal meeting with an agenda and roles. Preparation must occur before participants begin showing up the first day of the meeting. Typically the program’s vision and linkage to the business objectives and the top priorities of the initial program/feature backlog are used as inputs into the event. The release train engineer (who facilitates the event) will need ensure that the workspace and tools the teams will use are prepared.
  2. All members of the program should participate in the release planning event. Release planning is both a planning and coordination event. In the release planning event, teams develop and coordinate their plans for the next set of sprints in an environment that actively encourages communication and sharing. Everyone involved in the program brings different skills and experiences to the table; therefore they can provide unique insights into how the program can deliver maximum value. For example, if a program based in the US was leveraging offshore developers in the Ukraine and testers in India would planning be as effective if team members in India and the Ukraine were excluded and just told the plan? How many challenges and issues would be exposed later in as functionality was delivered that could have been solved by upfront communication?
  3. Release planning events are best when done in person. Programs need to ensure that release planning events are scheduled and that budget is available. Budgets for the events should include travel both travel and logistics.   When travel is not possible, the program leadership should make every effort to make the communication as intimate as possible (in-person being the most intimate and then in descending order: video, audio, test chats and smoke signals). Remember that if it is difficult to hear and participate, participants will get bored and stop paying attention.

A classic advertisement during in 2009 Super Bowl showed a cowboys herding cats. Large projects might not be quite as chaotic as that, however if teams don’t have a clear vision or don’t understand the interactions and relationships between what they are delivering and what others are delivering chaos could ensue. The Agile release planning event in SAFe is a mechanism for solving the planning and communication conundrum.

Stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning.

Stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning.

In an Agile project, a release plan answers the “what and when”, based on organizational vision, project needs and team capabilities. The constituency of a release is usually broader than the Agile team. Classically, the interested parties would be called stakeholders. In order to develop a release plan that serves the organization, the team needs to understand the breadth of the release’s stakeholders. A potential list of stakeholders can be broken into three categories:

Obvious:

  • Agile Team
    • Scrum Master
    • Product Owner
    • Delivery Team
    • Business Users
    • Customer(s)
  • Marketing (for projects related to the products or the delivery of products)
  • Sales (for projects related to the products or the delivery of products)
  • Manufacturing (for projects related to the products or the delivery of products)

Program Level

  • Program Manager
  • Representatives from Other Agile Teams

Less obvious

  • Outside experts
  • Vendors/External Partners
  • Regulators

The majority of titles on this list are probably obvious; stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning. A release plan for an Agile project within a program should involve a wider sample from other Agile teams. In order to determine who should be involved, you need to understand the relationship between the individual projects.  Those that are less obvious are rarely included in developing a release plan, even though these stakeholders can contribute significantly to the projects requirements.

One mechanism I use to develop the list of roles to engage in Agile release planning is to begin with the project’s walking skeleton.  The walking skeleton is generated from Agile Story Mapping and can be used to identify the minimum viable product. Once you outline the initial story map and walking skeleton, review each of the functions in the skeleton and ask yourself the following questions:

  1. Who will use this function?
  2. Who will develop and test this code?
  3. If this function interfaces to other applications (software and hardware), who owns the other application?
  4. Who impacts how the function must work?

This list of names are the people that could be involved in developing a release plan. Even if all of the folks on the list can not be involved, the list will provide a starting point. When deciding who to invite, make sure you identify the thought leaders on the list and representatives from interfacing applications.

La Sagrada Familia was a minimum viable product that is still being built

La Sagrada Familia was a minimum viable product that is still being built

An Agile Story Map combines three basic types of information: stories, workflow information and priority.  With the addition of velocity (i.e. how much work can be delivered), these three pieces of information provide the basis for release planning.  Release plans generally reflect one of two basic philosophies.  In the first philosophy, a release is based on the on a fixed amount of functionality. In the second, a fixed duration is used.  Let’s apply each these strategies.

Fixed Functionality Release

The first row underneath the marketable and architectural features, which contains the highest priority user stories, is called the “walking skeleton.” The walking skeleton represents a barebones version of the product or project. It should represent the lean concept of a minimum viable product; just the essentials.  If you were building a house, having a foundation would be a high priority unit of work and part of the minimum viable product. A finished basement playroom is not as high a priority, and not be part of the initial release or part of the minimum viable product.

One successful iterative strategy is for the walking skeleton to be the initial release.  Each subsequent release (or rows in our map) would flesh out the product. The process of iterative releases elicits feedback from real users to hone the backlog, so that subsequent releases will more closely reflect the user’s needs. Using the walking skeleton as a mechanism to trigger a release is a reflection of the functionality-driven release strategy.

Fixed Functionality Exhibit A

 Walking Skeleton and Fixed Functionality Release Boundaries

While the walking skeleton concept is most closely associated with new applications, it can also be applied to enhancement projects. In this case, the walking skeleton represents the minimum amount of new or changed functionality that would be useful to the customer.

Here are the steps to build the release plan:

Who: Whole team, lead by the Product Owner

  1. Identify the highest priorities required to satisfy the minimum viable product.  This becomes the walking skeleton and the first release.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
  2. Identify the next highest priority group of work items that form a coherent set of functionality.
  3. Repeat step two until all of the functionality in the map has been accounted for.

Remember that the Agile Story Map will evolve as the team builds a greater understanding of needs and receives feedback from stakeholders. Therefore, the release plan will change.

Fixed Duration Release

In the fixed duration release strategy, the team works as hard as possible for a specific duration and then releases the product. Release planning would be accomplished by applying the team’s velocity to a sized backlog. The release plan changes as velocity and the Story Map change.

Fixed Duration Exhibit

Walking Skeleton and Fixed Duration Release Boundaries

When developing a new application, this strategy only makes sense if the whole walking skeleton is released in the first release. As before, the walking skeleton represents the minimum viable product. The team would then work the highest priority work items, the user and architecture stories, and those completed in time would be packaged and released.

The main difference in process for building a fixed-duration release plan is the fixed date and packaging the work based on capacity (velocity or productivity):

Who: Whole team, lead by the Product Owner.

  1. Identify the highest priorities required to satisfy the minimum viable product.  This becomes the walking skeleton and the first release.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
    • If the duration is more than the implementation window, either work with the Product Owner to refine the walking skeleton, add additional Agile teams or redefine the fixed duration.
  2. Identify the next highest priority group of work items that form a coherent set of functionality.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
  3. Repeat step two until all of the functionality in the map has been accounted for.

In both strategies the organization must weigh the business value of each release against the cost of development.  If the organization can make better use of the Agile team and other project resources, the work on the project should be halted and a new project begun.

The prioritization process in of Agile Story Mapping helps to identify a minimum viable product/walking skeleton.  Once a walking skeleton is identified Agile Story Maps provide a great platform for release planning. The mapping process supports both of the popular release strategies and methods that combine the two.  The visual nature of Story Mapping helps to ensure that the team and their stakeholders understand the impact of changes to the release plan as new stories are added or priorities are changed.

Feedback loops help make planning more effective.

Feedback loops help make planning more effective.

Agile planning is layered and continuous throughout the life span of a project. The continuous nature of Agile planning provides a stream of feedback that makes making course corrections more effective. Agile release planning actively uses feedback loops from sprint/iteration planning and indirectly from daily sprint meetings.

Mike Cohn described Agile planning as an onion with strategic planning on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer of the Agile onion includes planning, and that planning reacts to the performance of the layers below.  Release planning provides sprint planning with information about the goal(s) of upcoming releases and the functionality that the product owner and stakeholders are anticipating. Sprint planning further breaks the goals and needs into tasks and activities. The team translates results into knowledge and information that is used to refine daily activities and is then used to refine the next iteration of sprint planning which in turn provides feedback to the release planning process. Each planning activity is influenced by results from next layer of activity.

Short iterations provide the ability to plan and then gather results that will either validate the plan or generate the impetus to change the plan. Feedback loops are an important part of ensuring that we continually adjust plans so that we get it right.

Release plans are not menus.

Release plans are not menus.

Developing an Agile release plan can be relatively easy. In general there are only a few moving parts. The inputs into the release planning exercise are:

  • Prioritized and Sized Backlog – The backlog represents the work to be done including bugs, features, technical items and knowledge acquisition annotated. Each item on the backlog needs to be sized using a unit such as story points, t-shirt size or function points. The backlog is prioritized by the product owner based on value, dependencies and business requirements.
  • Team Velocity or Productivity – Velocity and productivity are measures that represent how much work is normally completed in a sprint by the team or teams involved in a project.
  • Release Strategy – Two macro release strategies are often considered. The first is a time-boxed approach (fixed amount of time) or a scope-boxed (fixed amount of scope). The strategy will be used to determine what will be included in the release.

Using a simple approach for release planning, the process begins with the prioritized and sized backlog. The product owner and team walk through the backlog counting off sprints using the velocity or productivity to determine what can be done. The whole team is usually involved in the creating the release plan; however the responsibility for the plan lies with the product owner. Based on the strategy selected the release will occur when a fixed number of sprints are completed (time-boxed) or when a fixed amount of features are completed (scope-boxed). At the end of every sprint the process will need to be revisited based on the results of the sprint, work items may have been completed, not completed or new items discovered. This is a simple approach to release planning; however even more complex, scaled-up methods follow the same basic steps. In many projects I have used these basic techniques with sticky notes and brown butcher paper as tools to record the process.

 

Release plans provide a map towards a goal.

Release plans provide a map towards a goal.

Agile release planning builds on the standard Agile values and principles with a number of additional principles and concepts that are needed to underpin the planning process. There are five additional planning principles that are important for ensuring effectiveness. They are:

  1. Teams should work on only one project at a time.
    Multitasking is inherently inefficient and makes planning significantly harder.
  2. Determine the minimum viable product for each release.
    The product owner and team must understand the minimum viable product at all times
    in order to plan releases and to make trade-offs in the order that functionality is developed when changes are needed.
  3. Early feedback is critical to avoiding problems.
    Gathering feedback early and often will reduce the possibility of surprises late in the project that could cause failure or customer dissatisfaction.
  4. Make irrevocable decisions as late as is smart.
    Irrevocable decisions should be delay as long as possible so that progress and knowledge gathering can be used to validate and inform the decision process. Making irrevocable decision early before enough project learning occurs increases the risk of project failure.
  5. Understand that the release plan will change over the life of the project.
    Projects are engines of learning and discovery. Product owners will discover new needs, new solutions will present themselves, new issues, risks and problems will be discovered that will require adjustment to the release plan.

The five additional release planning principles and concepts are focused on making the processes more effective. We understand that teams are more effective when they can focus (one project at a time) and have a goal (the minimum viable product). Showing our stakeholders what we are doing helps us understand whether we are on track or not (early feedback) and we should make decisions when they have the best chance at being right (make decisions as late as is smart). Finally, we always have to remember that plans change in the face of reality.