This is the final part of my set of articles about Scaled Agile. At the end of the last article I'd promised to describe the Planning Event.
The Planning Event is where all the teams get together. The purpose is to "define and design system that best fulfills the shared vision". That's a mouthful to unpack!
This is like a combined sprint planning and review meeting - but for everyone. It gets its own two-week 'iteration' in the SAFe model of which around two days the end is the meeting itself.
For the development teams, this is a few days grace to consider the bigger picture. To look at process improvements, experiments, training and catch up. For the Product Owners and Scrum Masters, there is a lot of work to prepare for the planning event.
- The Product owners and Product Manager have to agree their high-level priorities. They have to prepare any new stories or epics.
- The System Architecture team need to define their priorities. They need to document any refactoring or system improvements.
- The Release Train Engineer needs to document any changes to the development process.
- The development teams also get together with their Product Owner to review their own backlog of existing stories.
At the Planning Event, each team gets the chance to plan their own part of that picture. They set an achievable target for the next Program Increment. They work through with all their colleagues where the dependencies and risks are.
At the end of the two days, everyone should leave with a good feeling that the objectives are clear and each team feel that they have a plan they can achieve and feel confident in. At least for the next 2-3 months.
A lot rests on how well the event is facilitated. Often it is the release train engineer who takes on the responsibility of facilitating the event. There are three main things that have to come together for the event to work.
Organisational readiness
- Is planning scope and content understood?
- is there responsible agreement on priorities for business owners?
- do we have agile teams ready to do work?
- do we know who the scrum masters and product owners are and do they understand their roles?
Facility readiness
- Is the venue large enough for all to attend
- Is all the technical and communication support needed available
- Are distributed communications available for members of the teams that can't attend in person? This includes all the channels for audio, video, and presentations
Content readiness
This includes preparing :
- the executive briefing on the current organizational situation
- the product solution briefing on what the top 10 priorities are, and the vision for the product.
- the architecture briefing covering the system architecture, new enablers, and non-functional requirements.
A typical pattern for the even itself describe by Dean Leffingwell and Richard Knaster in Scaled Agile Distilled is something like:
Day One opens with the presentation of the business context.
The facilitator outlines the objectives of the Planning Event. They then describe any working agreements and logistics.
The Business Owners then give an 'Executive Briefing'. They set out the business context and business priorities for the next three months. This may include market analysis, about how the customers' needs have changed. It could also be any planned organizational changes or other corporate plans.
Next, the Product Manager outlines the Product Solution. The current vision for the product. The product management objectives for the next iteration and further into the future.
Concluding this part is the Architecture Presentation. What is the current architectural vision? Are there any changes to development practice? Is there any new common infrastructure? Are there any large scale refactors, or structural changes that teams need to be aware of.
The rest of the first day is for the team breakouts. Each team drafts their initial plans. They work with their Product Owner on the Program level stories. The aim is to split them into stories that they could tackle in an increment.
Once the team has a backlog they prioritize the stories and lay out their plan. Each of the stories represented by a single card or post-it on a sheet. 1 sheet for each iteration in the Program Increment. These sheets are displayed around the room. Dependencies are shown by linking cards together.
Throughout this process, the program level team circulate round the development teams. This allows them to clarify any queries about the program level stories. Members of the development teams also circulate. Since everyone's work is visible. people have the chance to identify overlaps or dependencies.
Once the teams have their backlog and their plans drafted each team has 5-10 minutes to present. They outline their plans highlighting any risks or remaining questions or concerns.
The day finishes with a review meeting. The point of this is to give the business owners and programme team the chance to make decisions based on:
- What did we just learn?
- What do we need to adjust - do we change the vision, the scope or sources?
- Where are the bottlenecks?
- what needs to be descoped from the Program Increment?
Day 2 starts with a presentation of what has changed. Given this revised scope, the teams breakout and adjust their plans and objectives. At the end of the replanning once again teams present their plans, focusing on any program risks.
Once the teams have presented their revised plans, everyone votes on how confident they are. Is this a plan that everyone can commit to. If confidence is low planning is repeated until everyone has a high degree of confidence. The teams then commit to making the plan happen.
This sounds like it could be a dry and corporate sort of business. It doesn't, however, have to be like that.
The link below is to one of the most entertaining videos I've found about the whole subject of SAFe. I hope that our planning increment in a couple of weeks is half as much fun as Lars Roost & Henrik Kniberg make it sound.
Top comments (0)