AGILE RELEASEPLANNING

Atos Syntel

2

This eBook discusses how an Agile release planning event can be coordinated for a team or a group of teams. It explains the whole process, which consists of two stages: the release plan process and the release plan event. Best practices of how to go about a successful release plan have also been mentioned.

CONTENTS

AGILE IMPLEMENTATION CHALLENGES ...............................................................................3

THE SOLUTION – AGILE RELEASE PLAN. ............................................................................3

TWO STAGE PROCESS ...........................................................................................................3

• STAGE 1: THE RELEASE PLAN PROCESS ................................................................3

• PREREQUISITES ....................................................................................................3

• WHO PARTICIPATES .............................................................................................3

• THE PROCESS .......................................................................................................4

• THE OUTCOME ......................................................................................................4

• STAGE 2: THE RELEASE PLAN EVENT .......................................................................5

• WHO PARTICIPATES .............................................................................................5

• PREREQUISITES ....................................................................................................5

• ORGANIZING ..........................................................................................................5

• THE EVENT .............................................................................................................5

• STEP 1 - THE DEPENDENCY EXCHANGE ................................................5

• STEP 2 - THE BREAKOUT SESSION .........................................................5

• STEP 3 - THE COMMITMENT CEREMONY

• THE OUTCOMEE ................................................................................................. 6

HELPING FACILITATE / BEST PRACTICES ........................................................................... 6

ACCOMMODATING ONSITE AND OFFSHORE TEAMS ...................................................... 6

• THE RELEASE PLANNING PROCESS ........................................................................ 6

• THE RELEASE PLANNING EVENT............................................................................... 6

CONCLUSION ........................................................................................................................... 7

A HOW TO GUIDE

3

Agile Implementation Challenges One of the key measures of success of an Agile implementation is working software. But when you scale a project at an organizational level, it creates its own set of unique challenges. What does one do when for a software or a product to work, may need several teams to simultaneously develop and complete their individual components that then connect as a seamless process?

The Solution – Agile Release PlanOne of the most popular solutions is using an Agile release plan – where we define a release as a planned meeting point for all the dependent pieces to come together and complete the release.

Hence an Agile release can be defined as a logical time-boxed duration (also called a release window) which consists of:

• A logical increment of a product which will be movedto production

• If it is a large scale implementation, an interim goalconsisting of a predefined number of modules

• A subset of requirements

• If nothing else can be logically segregated, a windownot less than a 32-week sprint

Two Stage Process Depending on the role one plays Agile release planning can be divided into two stages:

Stage 1: The Release Plan Process - results in a plan for the dependent teams to operate till the release is complete.

Stage 2: The Release Plan Event - where the dependent teams interact and finalize the plan shaped by the above process.

Stage 1: The Release Plan ProcessThe release plan process is the act of defining and shaping the backlog into finalized versions. The finalized versions consist of the priorities and goals the teams need to work on, subsequent to the release plan event for the duration of the release window.

Prerequisites

Before we get into the details of what a release plan or a release planning session entails, there are certain elements that need to be in place to realize the benefits of a release plan:

• There needs to be clarity (published) on the vision/objectives of the program or project.

• The objectives need to be clearly segregated inorder of priority and sorted into buckets which are MustHave, Should Have, Could Have, and Would Like to Have(MoSCoW).

• There should be a fairly reasonable understanding of thecapacities and velocities of the teams participating.

• The participant teams should be working onsynchronized sprints.

Who Participates

Agile was intended to be a collaborative approach to software development, and as such, it is only natural for as many people as necessary to be involved in the release planning process as there are stakeholders. For the purpose of planning, there should be representatives from each of the groups involved

AGILE RELEASE PLANNING

4

in the project at the very least if it is not possible to involve everyone. This necessitates representatives from development, quality assurance, support, management, PMO, and the customer. At the very least, the product owner, Scrum master, dev lead, QA lead, and the customer representative should be in the required audience. During the process of planning the release, more number of people leads to a more comprehensive plan. To facilitate the process between large audiences, a RACI matrix may be published which lists out:

• The person responsible for the deliverable

• The person accountable for the deliverable

• The person who contributes

• The person who needs to be informed

The Process

The process of Agile release planning begins with the product owner defining the set of priorities for the duration of the release window. Once these priorities (Epics) are listed out and have buy-in from all the stakeholders participating in the process, the next step is for the team to determine the dependencies it has on external sources to complete these Epics. The next step is to determine the latest sprints by when the dependencies need to be resolved to achieve the objectives the team has set for itself. This is followed by a slotting exercise where the team breaks the Epics down into stories workable in sprints and slots the stories into the sprints making up the release window. The first couple of sprints are completely filled with the latter sprints having some bandwidth to accommodate change and unpredictability. Then it takes a couple of weeks for the release plan process to work itself through. The entire process is represented in the following diagram:

The Outcome

At the end of the release planning process and prior to get-ting into the release plan event, each participating team/group should have certain things clearly organized:

• A list of stories, actionable in one sprint, should beclearly laid out. The list should be groomed and sized indecreasing order of priority to fill up at least 70% ofthe backlog for the release window.

• A list of dependencies (Gets) for external teams, storieswritten for the Gets, and the timelines by which the Getsare required.

• All broken down stories slotted into sprints whichcomprise the release window taking into account thetimelines by which the Gets will be fulfilled.

• A commitment from the team(s) that all identified storieswill be complete in the sprints and all dependencies willbe ironed out.

• A buy-in from the stakeholders stating that the identifiedstories are acceptable for the teams to work on.

AGILE RELEASE PLANNING

Raodmap Item 1Raodmap Item 2Raodmap Item 3Raodmap Item 4..........................................................................................Raodmap Item n

Epic 1

Sprint 1

Roadmap broken into Epics Epics broken into storiesand slotted into sprints

Sprint 2

Epic 2

Epic 3

Epic n

...................................................

...................................................

...................................................

5

Stage 2: The Release Plan EventThe release plan event is the culmination of the release plan process and is the point where all interdependent teams get together to iron out dependencies and affirm commitments to each other.

The plans finalized at the end of the release plan event decide the stories the teams will be working on for the duration of the release window.

Who Participates

The release plan event is generally supposed to be a half day to a day-long event. Since the meeting involves a lot of stakeholders engaged for an extended period of time, it is advisable to make it as non-disruptive as possible. Therefore, only stakeholders who have a say in decision making are recommended to attend. The typical audience for a release plan from each group/team would consist of the product owner, the program manager, the Scrum master, the dev manager, the QA manager, the architects, and the PMO. Development teams may attend the meeting but they should be sure that the meeting would be productive for them.

Prerequisites

Before getting into the release plan event, it is beneficial to ensure that every participating team has undergone the release plan process and are clear about the objectives and the remaining capacities of their teams. The only unknown things will be the delivery dates from the other teams for their Gets, and the Gives they need to provide to the other teams. An unprepared team will not be able to get the expected benefit from the event.

Organizing

For such a large scale event, arrangements need to be made

early and made well for the event to be a success. One should arrange for a large meeting room capable of seating 50 - 100 people with breakout rooms for the teams to brainstorm. Audio and video conferencing should be available for teams/participants who join from remote locations. Plenty of whiteboards and stickers should be provided to facilitate brainstorming. Food and refreshments should also be provided.

The Event

The event is typically broken down into three equally distributed steps:

STEP 1 - THE DEPENDENCY EXCHANGE: During this stage, each team reaches out to the other teams they are dependent on and shares their Gets. The team which is going to work on the dependency utilizes this time to talk about Gets and clarify any doubts. The Get becomes a Give for the team resolving the dependency.

For instance, if Team A needs a module from Team B, it will be a Get for Team A and a Give for Team B. Once all the Gives and Gets have been exchanged, the event can move to Step 2.

STEP 2 – THE BREAKOUT SESSION: At this point, each team walks into breakout sessions and goes through the Gives they have received from the other teams and slots them into the remaining 30% capacity that they have not planned for. Depending on the timelines requested for by the team dependent on the Give, stories may be moved around to accommodate the timelines. Ideally, the attempt should be to work on the Give stories in the first few sprints since there is dependent work in the release window following them. Once all the Gives have been slotted and stories rearranged, the teams get back together to move to Step 3.

AGILE RELEASE PLANNING

6

STEP 3 - THE COMMITMENT CEREMONY: At this point, each team informs the other teams about the time they will take to complete the Gives their team needs to deliver and if there are changes to the timelines. The team then publishes its plans for the release window and makes a commitment towards their deliverables for the release. This process is repeated by each constituent team until all dependencies are slotted and everyone agrees to the timelines. At this point, the release plan event can be closed.

The Outcome

At the end of the release plan event, each team should have clearly articulated and published:

• A list of stories that the team is going to be working onin the sprints comprising the release window.

• A list of the Gives they need to provide to the otherteams and the sprints they will need to complete them.

• A clear idea as to when they receive their Gets from theother teams.

• A commitment from all the teams towards thecompletion of the work identified.

• Buy-in from the leadership on the published releaseplan for all teams.

Helping Facilitate / Best PracticesFacilitating a release plan event can be a time consuming and demanding task. One may find some of the following points helpful while trying to coordinate an event of this magnitude:

• It is advisable to have a team rather than an individualfacilitate because of the sheer volume of theparticipants.

• One of the ways of setting the team up is via volunteerswho want to participate. Alternatively, organizers may bechosen from the participant body based on rotation.

• Assigning owners for each of the deliverables goes along way in clarifying responsibilities and removesambiguity from the process about who owns a particulartask. A RACI matrix can be published outlining this task.

• To facilitate the release plan process, kits can bedistributed which contain the RACI matrix, templates,guidelines, and checklists of deliverables which clearlyset the expectations for the teams.

• Allow enough time for the teams to iterate through therelease planning process. Grooming and slottingstories for an entire team for 4 - 5 sprints can easilytake a month.

• For the event, start planning a month or two before toget enough time to arrange for the logistics and preparethe participant list and travel needs if any.

• The event can be coordinated by a central team thatdrives the audience and a central coordinator whoguides the teams through the different stages.

• Presence of Agile champions and coaches in the eventand during the process helps the teams navigatethrough the Agile ceremonies required to attain thedesired outcomes.

• Conducting a release plan retrospective (i.e. aretrospective for the release plan event andprocess alone) helps identify improvementsto the process and can be used as a valuable feedbacktool from the participants to improve the releaseplanning process.

• A simple survey can be used to gather feedback fromthe participants. A more detailed retrospective meetingcan be held with representatives from all the involvedbodies – product, technology, PMO, and the organizingcommittee.

• Conducting dry runs of the event with just the help ofpresenters streamline the process in front of a largeraudience.

• A definition of done needs to be set so that everyoneunderstands what it means when a team says they aredone with release planning.

• It helps if there is a published calendar of the differentrelease plans scheduled for the year and thetimelines for the interim release plan deliverables sopeople are not scrambling to organize at the last minute.

• If the event is of a longer duration, it can also be usedas a team building session by incorporating teamgames and contests which not only help provide abreak to the participants but also liven the atmosphereand strengthen the bonding between the teams.

Accommodating Onsite and Offshore TeamsTeams based out of different locations pose a separate set of challenges altogether. Concessions need to be given to teams that cannot be geographically together. We will examine these scenarios with respect to different perspectives, processes, and events.

The Release Planning ProcessThis part is relatively easier to accommodate since a majority of the stakeholders within a team would be collocated. Since grooming is a time consuming task, if any of the stakeholders are geographically separate, it would make sense to schedule multiple meetings over a span of a few weeks during a time suitable for the various geographies to groom the stories. In-depth details can be fleshed out by the teams locally. The presence of shareable whiteboards and collaboration tools go a long way in facilitating the process of planning.

The Release Planning EventScheduling a large scale event across geographies is a challenging task since it is very difficult for a large group to interact over distances in a many to many setting. The easiest way to accommodate geographically disparate groups is to cut short the meeting while minimizing the loss to the outcome. One way of doing this is by ensuring different mechanisms for exchanges of dependencies between teams. This can be done by either scheduling collaboration one offs or working sessions at different locations. The entire body can be brought together during a shortened release plan event at a convenient time for all locations to reiterate the commitments and ensure everyone has the same information and takeaways.

AGILE RELEASE PLANNING

7

AGILE RELEASE PLANNING

ConclusionThe release planning process is the engine that runs the Agile release train, where teams coordinate to release a major shippable increment for a large scale product or engagement. The above described process is just a guideline and there is no right way or wrong way to go about the release plan. The expected outcomes, however, are necessary to be arrived at to ensure that the entire organization/group coordinates its efforts.

Practically speaking, Release planning is both an art and a science. By using experience, incorporating best practices, as well as soliciting and working on the feedback from the participants, the release planning process and the event become invaluable tools for planning and coordinating efforts. The tools also help in large scale development initiatives across an organization or a group.

Atos Syntel’s Agile Capability

Atos Syntel has been into Agile delivery and consulting for the last 10 years. Based on experience and increasing demands from clients, Atos Syntel has proactively established a dedicated Agile Change the Business (CTB) task force. Our Agile talent pool comprises of 50+ Agile coaches, 700+ Agile certified professionals, and 14000+ Agile practitioners working across different verticals throughout the globe. As part of Agile service capabilities, Atos Syntel primarily offers:

• End-to-end software products/services development using appropriate Agile methods like SCRUM, TDD, FDD, andSCRUMBAN (Co-located or Distributed Agile)

• Atos Syntel Proprietary Offshore Agile Model (G-Agile) to develop software products or services in a cost effective way

• Agile transformation partnerships

• Agile readiness and maturity assessment consulting

• Agile delivery assurance consulting

• Scaled Agile implementation and associated consulting