By Nathan Donaldson
Tags: Agile
At the end of my last blog post on SAFe – Scaled Agile Framework – The Team Level – I said that I would devote an entire post to the Release Planning session as this was one of the key meetings in SAFe. This post covers the following points:
When we kick-off an Agile project, the very first thing we will do is some form of collaborative, deliberate discovery workshop to determine the initial set of User Stories that will be worked on by the team(s). As part of this workshop we will often encourage the Product Owner to prioritise the stories into releases (the number of releases depends on the size of the project), as a way to determine what holds most value to the business and what needs to be worked on first. XP (eXtreme Programming) actually names this collaborative workshop “Release Planning”, as does SAFe.
The key thing to understand with Release Planning and the resulting Release Plan is that the further it looks into the future, the more volatile it’s predictions become.
SAFe understands this and suggests that teams only draw up a Release Plan for the next 3 months of work. In SAFe 3 months of work is known as Potentially Shippable Increment or PSI (covered in my previous post), So although the Product Management team will probably have a Roadmap looking ahead up to 3 PSI (9 months) ahead, the teams will only have a very clear picture of the current PSI (3 months). The feature content of each subsequent PSI will get less clear the further away it is.
This approach is very similar to Rolling Wave Planning project management where work is planned in time periods called “Waves”. Rolling Wave Planning is used on projects where progressive elaboration – iterative development – is required, usually as a result of tight timeframes and the necessity to re-priortise the scope of the work accordingly in order to meet schedule milestones. Sounds like Agile, right?
The Product Management team of one of our key clients has used Rolling Wave Planning very successfully to plan the work for one of our Scrum teams for past 5 years, a total of 135 Sprints. They plan in 3 month Waves, starting off each year with a 1 year, 4 wave, Roadmap.
SAFe literature calls this session Release Planning, but this meeting isn’t necessarily about determining what will be in the next actual release of software to our users. Instead it determines what the teams will be working to deliver for their next PSI (Potentially Shippable Increment). Granted, for some finishing a PSI will coincide with actually releasing the product, but for others they may choose to release off the PSI cadence, at times determined by the Release Management team. This is something that Dean Leffingwell refers to as “Develop on cadence. Deliver on demand”. Whichever way your organisation works, what the teams will be determining in their Release Planning meeting is what they will be designing, building and testing in the next 3 months, or 5 – 6 sprints.
In some of the SAFe literature I notice that they refer to the release as the PSI/Release, for me that really clarifies it.
Anyway, onwards and upwards, let’s look at the Release Planning meeting.
The PSI/Release Planning meeting precedes that start of work on the first/next PSI. So, if the project is just about to kick off, the meeting will take place before the start of the first Sprint. If the project is already underway and are about to complete their PSI then this happens during the HIP sprint (Hardening/Innovation/Planning).
The Release Planning meeting is attended by all members of the program. The aim of the Release Planning is the following:
An example agenda looks something like this:
The primary objective of the first day is for each of the teams to take ownership of one or more features from the Program vision and create a Release Plan for the team. They do this by taking the feature(s) they’ve selected, and with the involvement of their Product Owner, break them down into stories to which they will give rough estimates. Each team will then map the stories into Sprints for the PSI, create a risk sheet (using colour coded post-it notes) and try to resolve any inter-team dependencies by verbally negotiating with the other teams. The final and most important output is a set of SMART objectives that the team will be working to for the coming PSI. The Product Owner will work with the team and other members of the Product Management team to assign business value to each objective so that the team is able to priortise accordingly.
Once the individual teams Release Plans start to take shape, they will start to add what they know to the overall PSI “Program Plan”. This highlights the new features (blue post-its), feature inputs (yellow post-it notes), anticipated delivery dates and any other relevant milestones (orange post-its). Most importantly it visually represents any dependencies the teams may have across their product with pieces of string to link the dependent items. These dependencies will no doubt be high on the identified risk sheets of the relevant teams.
This activity takes up most of the afternoon of the first day and is co-ordinated using a Scrum of Scrums approach, i.e. each team will send a team member to the hourly Scrum of Scrum meeting so that they can co-ordinate their Release Planning activity and determine if they are on schedule.
Once the PSI “Program Plan” has taken shape and/or the timebox expires, the Draft Plan Review will take place. This again is a tightly timeboxed meeting where the teams will present the highlights of their draft plans to all members of the Program.
This feeds into the final meeting of day 1, the Management Review & Problem Solving session, where the Program Management team meet to discuss any challenges presented by the draft Release Plan. The intent of this meeting is to resolve those challenges by negotiating scope and potentially resourcing.
At the start of day 2, the Program Management team present their suggested planning adjustments and the teams breakout to adjust their plans accordingly. Once the team has re-determined their objectives for the PSI, the business owners will make any adjustments to the business value for each objective if necessary.
During the Final Plan Review, the teams will present their plans to the entire group. At the end of each team’s timebox they will present their list of risks and impediments, but note, they don’t try to resolve them at this stage. If the plan is acceptable to the business owners, the team brings their PSI objective and program risk sheets forward to aggregate with the other teams.
Once all teams have presented their plans and the full set of objectives and risks is presented is assembled at the front of the room, the group work together to “ROAM” the program risks. The ROAM acronym stands for the following: Resolved, Owned, Accepted, Mitigated.
One by one the risks will be assessed, discussed openly and categorised into one of the above groups.
After the risk assessment activity is complete, the team will take a confidence vote, usually in the format of a fist-to-five vote. Closed fist demonstrating zero confidence, up to 5 fingers which demonstrates complete confidence. If the level of confidence is low, the plans will need to be reworked and any necessary adjustments made. Once the teams’ confidence is high, the plan can go forward.
The final step is for the group to carry out a Planning Retrospective to capture what went well, what didn’t go well and what could be done better for the next Release Planning session.
The outcome of 2 days of collaborative workshopping is a Release Plan for the PSI. This will, just as with XP, get refined and re-prioritised once more detail becomes available as work on the PSI progresses.
The Board Agile talk show Episode 8 — Scaled Agile Framework (SAFe)
