www.spamcast.net

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 21nd. 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.

Advertisements
Program increment (PI) objectives are summaries.

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.

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.

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.

Some rituals are better than others

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.

Untitled3Large 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:

 Untitled4

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.

A simple Agile release plan

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).

Untitled2

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.