SPaMCAST 337 – Agile Release Plan, Baselining Software, Executing Communication

Listen Now

Subscribe on iTunes

In this episode of the Software Process and Measurement Cast we feature three columns!  The first is our essay on the Agile release plans.  Even after 12 years or more with Agile we are still asked what we will deliver, when a features will be delivered and how much the project will cost.  Agile release plans are a tool to answer those questions.  Our second column this week is from the Software Sensei, Kim Pries. Kim asks why is baselining so important. Kim posits that if we do not baseline, we cannot tell whether a change is negative, positive, or indifferent—we simply do NOT know. Finally Jo Ann Sweeney will complete the communication cycle in her Explaining Change column by discussing delivery with a special focus on social media.

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21^nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

QAI Quest 2015
April 20 -21 Atlanta, GA, USA
Scale Agile Testing Using the TMMi
http://www.qaiquest.org/2015/

DCG will also have a booth!

Next SPaMCast

The next Software Process and Measurement Cast will feature our interview with Stephen Parry.  Stephen is a returning interviewee.  We discussed adaptable organizations. Stephen recently wrote: “Organizations which are able to embrace and implement the principles of Lean Thinking are inevitably known for three things: vision, imagination and – most importantly of all – implicit trust in their own people.” We discussed why trust, vision and imagination have to be more than just words in a vision or mission statement to get value out of lean and Agile.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

Scaling Agile – SAFe Agile Release Planning: Program Increment Objectives

Program increment (PI) objectives are summaries.

Program increment (PI) objectives are summaries of business and technical goals at multiple levels within a program increment.  In the Scaled Agile Framework (SAFe) there are two levels of PI objectives. Team PI objectives reflect the summary of the specific business and technical goals that have been planned during release planning. Program PI Objectives are at a higher level of abstraction, reflecting the summary of the teams PI objectives to describe the overall program increment. The process of generating the PI objectives serves three primary purposes. They are to:

1. Create alignment. Teams in the ART synthesize the visions (business context, product and architecture visions) presented at the beginning of the planning event along with the prioritized backlog to generate business and technical stories which are then planned. Stories and spikes are added and planned by the team until they reach capacity. When process of planning is complete the work that has been planned is summarized into the team PI objectives. PI objectives are communication vehicles for the team to share what they are doing to those outside the team and for other teams and stakeholders (those outside the team boundary) to consume and understand. The PI objectives are a stand in for a laundry list user stories that allows all of the ART teams to compare objectives.  The comparison process helps to ensure teams are aligned so that the program increment vision can be delivered. Program PI objectives are generated by synthesizing the teams PI objectives into program PI objectives. Program PI objectives are another tool to ensure all of the teams are aligned.
2. Generate agreement of feasibility. The process of synthesizing the stories into team PI objectives and then from team PI objectives into program PI objectives is a mechanism to communicate what each team believes feasible in the program increment time frame. As team-level PI objectives are communicated and synthesized into program PI objectives, the ART has another opportunity to expose dependencies or to ensure that dependencies are understood.
3. Set Expectations. PI objectives, whether at the team or program level, are commitments to perform. PI objectives can be thought of as line in the sand based on plans generated by the teams that are committed to doing the work (rather than plans and objectives made for the teams).

The release planning process is a mechanism for teams to plan the work they are going to do in a program increment. PI objectives are a mechanism to summarize the detail that planning creates so that everyone involved in the Agile release train can agree upon what will be delivered. At the end of a program increment those involved in the increment can reflect on the objectives both at a program and team level and use what was learned to continuously improve.

 

SAFe Agile Release Planning: Event Basics

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.

2. 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.
3. 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.
4. 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.
5. 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.

 

SAFe and the Release Planning Event

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.

 

Agile Release Plan Revisited: Not An Event

Some rituals are better than others

Agile release planning is an important tool for Agile projects and programs. It is easy to elevate release planning to a formal Agile ritual, done at a particular time and in the same way. Like a ceremony. My observations of Agile teams suggests that the ritualization of release planning (and all the other Agile techniques, for that matter) reduces the team’s ability to tailor the process or to experiment with variations that better match the dynamic nature of Agile projects. To make sure you are staying as flexible and dynamic as necessary remember the following points:

1. Release planning is iterative and incremental. Release planning is usually done during sprint planning and then over and over again as needed.  Change occurs incrementally and based on feedback gathered thought team performance and feedback from the team.
2. Release planning should be adjusted to deliver value in the fastest possible manner. The product owner and the team should continually tune the release plan to deliver value as early in the project as possible.  The minimum viable product or the walking skeleton are tools to help identify and plan for the delivery of value early.  The delivery of value helps to generate feedback, customer satisfaction and team motivation.
3. Keep it simple. Release planning does not have to be complicated. Project and program complexity and the amount of information the organization’s culture demand will drive the complexity of release plan. Make release planning only as complex as it needs to be (and even then try to simplify).
4. Experiment. Try new techniques for release planning. As far as I know, there is no perfect process for release planning in every team and organization. That means that we should be looking for process improvements at every opportunity.  Perhaps you will discover the best method ever, but even if you don’t you have every opportunity to get better and better and better.
5. Release early and often. Release as often as it makes sense. The quicker you can get feedback from functionality running in production the better. Also the early and often mantra helps the project’s stakeholders understand that the release plan is not the same empty promise that many non-Agile release plans represent.

Agile release planning is a dynamic, continuous process that will evolve incrementally based on actual performance and the shifting business landscape. Change in Agile are rarely represented by a big bang, the creation and evolution of an Agile release plan is no different.

 

Agile Release Plan Revisited: A Simple Program-Level Example

Large Agile programs, with numerous teams that each have their own cadence and need coordinated releases, add a level of complexity to planning and communicating releases. Instead of focusing on communicating how stories roll up to a release, program-level release plans typically take a higher-level view, communicating the relationships between themes, epics, teams and releases. Shifting to a big picture view allows the release plan to be concise enough to be able to communicate direction and progress.

A Moderately Simple Example

The example above is built on a release plan I helped build several years ago.  Just part of a single year of the program is shown below.  The program was comprised of three sprint teams and a program manager. Each of the teams had a different sprint cadence.  The program was planning to release code to their customer base (internal and external customers) twice during the first year and then every five months afterwards. The five month release cadence was driven by a major, outside client’s need. Each team supported a separate area within the organization and were allowed to release code outside of the program-level releases if needed. The product owners (yes, owners . . . not my favorite idea) prioritized the goals and themes based on business need and perceived value.  Epics that supported those themes were then prioritized based on value and dependencies.  Epics that were perceived to be larger (this group had sized the under stories and summed the size of the stores) drawn as thicker bars or across more sprints (meaning the epic was planned to be completed over a number of sprints).

Note that the plan shown is not complete.  I have used this format as a template several times.  The plan helps everyone understand the program is progressing. In at least one version of the program release plan we have up a “You are here” marker to show the breadth of progress that has occurred and is yet to happen. Keeping the plan as simple as possible makes communicating progress easier and also helps team understand when functions and features are planned.  The program-level release plan does not negate the need for a team-level plan that reflects the planning needed for a more tactical team-level release plan.

For a moderately complex program release plan I have found it necessary to add two other tables.  The first defines the epics related to the theme. Themes are used to describe larger sets of related functions within an application and are used to provide a focus to the team.  Epics are large user stories that are broken down into more granular user stories which can be estimated and completed in a sprint (remember INVEST). Here’s an example using the beer logo glass collection application we have described before.  A development theme might be focused on maintaining the glass collection (maintain equates to adding, changing and deleting glasses). A short description of an epic in that theme might be “add logo glasses”. Examples of the type of tables are shown below:

 

When using the program release plan to brief stakeholders, it is expeditious to have an idea where their pet function will be addressed.

The goal of program-level release planning is to help the teams, product owner(s) and the organization to conceptualize the flow of how functionality will be delivered and then to communicate the plan.  As with any other Agile tool, a program release plan will evolve as everyone involved in the gathers project level experience and knowledge.

 

Agile Release Plan Revisited: Simple Examples

A simple Agile release plan

Agile release plans are powerful tools to communicate direction to the organization AND the team.  There is a natural tendency to think that power and complexity are directly related. In other words, a powerful tool must be complex and require a significant level of effort to develop and maintain however Agile release plans can be simple and easy to deploy. The complexity of a release plan is driven by two major factors: the complexity of the project and the level of process fluff required by the organization.

An Agile release plan for a single team can be as simple as a sheet of paper with sprints marked off.  The team would then list the stories in the appropriate.  In the case above, the team did not develop a release plan until just before the second iteration.  They used a simple process of matching a sized (with story points) and prioritized (value) backlog to iterations based on their velocity (the average amount of work they were completing per iteration).  The release plan was taped to the wall in their team room so it was available to the team every morning during stand up. Note that at the end of iteration one the team realized that story number 29 was an epic and broke it down for completion in the next iteration. The release plan that the team used was very simple, but it served as a planning platform for the team and as a tool to communicate their approach for delivering value. The long-term usability of this very simple model could be improved by writing the stories on sticky notes rather than on the paper so that changes to the  plan would not require crossing stories out or rewriting the plan as changes occur.

I observed a more complex approach to Agile release planning that addressed a two team, two release project.  The project was funded for six sprints. The product owner anticipated releasing functionality twice during the project. Both teams were responsible for delivering architectural stories and functional stories in a coordinated fashion. The stories for the project were drawn for a larger application backlog that both teams used.  The following picture is a representation of the solution the team used (they actually used brown butcher paper, painters tape, sticky notes and yarn).

The two teams opted for a simple graphical approach. The plan was placed on the wall of their team room where the entire team could see the chart. As the teams kicked off, they held a joint meeting with their product owner and built the initial plan.  The first plan was viewed as even more notional than normal, as neither of the teams had established their velocity. The plan was to be updated as part of the sprint planning process. An interesting touch that this team used was the inclusion of dependencies between stories, which were marked by yarn. These teams were still working on developing independent user stories, which is sometimes difficult.

There are lots of ways to generate an Agile release plan. The complexity of the project and the process needs of the organization will guide how teams address and communicate release plans. Agile release plans do not have to be the outputs of highly complex tools, represented by highly polished charts to communicate direction. Simplicity in release plans makes it easy for the team to create, maintain and use Agile release plans.

 

Agile Release Plan Revisited: Portfolios, Programs, Projects

 

Climbing flight is a project, climbing them all is a program.

Release planning generally focuses on the process needed to deliver functionality from projects. Projects are a central fixture of business, so it is easy to overlook program and portfolio release. Release planning for portfolios, programs and projects each has similarities and differences.

Project Level Release Plans: The project release plan describes what the team plans to deliver and when they intend to deliver.  These are a reflection of the team’s capability (reflected in the team’s velocity) and the product owner’s prioritization and strategy. An individual project’s release plan is very focused on the team’s ecosystem and generally has more a tactical orientation.  Project release plans are typically very granular, showing individual stories.

Program-Level Release Plans: Program release plans have to reflect a significantly larger number of moving parts than an individual project. The Project Management Institute (PMI) defines a program as a group of related projects, subprojects and program activities. Programs, because of their breadth, have more dependencies between projects and subprojects and will require more coordination, which impact both technical and business components. For example, earlier in my career I participated in a number of bank merger projects. Those projects were classic programs that included account conversions, application changes, signage/branding changes and business process changes. A change in the plan for one component could potentially cause a change in all of the rest of them. Also after a point the cutover date was nearly impossible to change. Developing a program release plan reflecting the needs and worries of a wide range of product owners is more than just assembling a view of all of the project release plans. Typically program-level release plans are less granular than project release plans showing the delivery of features and epics (collections of stories).

Portfolio-Level Release Plans: Portfolio management exists to help organizations maximize the impact of IT or project budget. In a perfect world, the portfolio of IT projects would be driven by the organization’s strategy and anticipated business value. Projects that are critical to business strategy and deliver the highest value would be prioritized, and then magically there would be capacity within the organization to tackle the project/program in the prioritized order. That magic is reflected in portfolio release plan. Portfolio release plans use inputs that include the organization’s strategy, estimates of business value and budgetary cost, the projected capacity AND technical capabilities to generate a plan that forecasts the evolution of the overall organization. A typical portfolio release plan will be at a high level showing product, programs and projects.

All three release plans are related. Project release plans influence program release plans and program release plans influence portfolio release plans. However, each release plan is not simply an aggregation from one level to the next. Project-level release plans are the most granular and are generally a reflection of the product owner’s needs and team performance.  Program-level release plans require negotiating the needs of multiple product owners, recognition of potential dependencies and reflect the performance of multiple teams. Portfolio release plans must integrate and balance organization level needs, capacities, capabilities and even politics. All three are important and having one does not lead linearly to the next.

 

Agile Release Plan Revisited: Tactical or Strategic?

For these wild dogs stalking their prey, the release plan is actually a catch plan.

In my essay Agile Release Plan: Strategic or Tactical?, I indicated that the release plan impacts the strategic direction and alignment of the business though the evolution of the organization’s software. I think that it would have been equally fair to suggest that the release plan is guided by the organization’s strategic plans. This describes a classic feedback loop. The organization’s plans guide capability development and capability affects the evolution of plans.  A release plan serves both tactical and strategic masters.

Tactically, the release plan dynamically answers the questions of what will be delivered in a release and/or when the release will be delivered. This helps the organization understand the value the team is delivering whether the team releases on a standard schedule or infrequently.  The plan is not only valuable as a communication vehicle, but it is also useful inside the team as a planning mechanism to help team maximize the value they can deliver.  The release plan allows the team (including the product owner) to layout the stories so focus the release’s impact.  An example of a tailored release plan: I recently observed a project that impacted three departments (one application was used by three departments).  A release plan was created with four separate releases. The product owner and the team clustered the functionality in each release so that it would primarily impact only a specific department in each release. Three release focused at the departmental work and a fourth was to be clean-up release.  The product owner want minimize the number of times each department needed to be retrained. The release plan was used both to plan and communicate the approach. the idea was to minimize the potential retraining in each department.

On a strategic level, the release plan provides a product owner with a tool to understand (and communicate) what the project has and is going to deliver to support their organization’s investment plan.  This is true whether the project impacts a product for an end customer or changes the software needed to support internal processes. As a Christopher Vedete recently put it: the release plan answers the “what’s the investment getting me?” Since the product owner owns the release plan, the cycle needs to match the strategic needs of the business. For example, if an organization was developing cloud software for personnel income tax processing, the organization would need to make the final release in conjunction with tax season. The release planning makes visible as much as is known about each release and then incorporates and shares that knowledge as new information is discovered. The release plan communicates direction and purpose.

The Agile release planning process steps away for the single sprint focus that Agile tends to have on a day-to-day basis and creates a wider view of the path the project is taking to meet its goal.  Short-term projects that run for a few sprints and then release and are done will not have to spend significant time developing and maintaining a release plan. However even a small project should spend some time to reflect on a path forward. Release planning for programs (a group of related projects) and for larger projects will invariably require more coordination as the need is greater because size is often directly related to strategic importance. Software projects that have strategic importance will always need an answer to the questions: 1) what are we delivering and 2) when are we delivering, so the organization can evaluate the impact those answers will have on the larger strategic plan.

 

Agile Release Plan Revisited: Who to Involve 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.