I am a Scaled Agile Framework coach and trainer and it amuses me to sometimes see the blood drain from the faces of Agile practitioners when I say „yeah, I really like SAFe, I´ve learned a lot“ :).  The reaction comes from interpretation. The Big Picture really is Big. When I give a Leading SAFe course and ask for feedback at the end, participants often say „Wow, I never knew there was so much in it, I´m really going to need to sit down and think about this“. It´s been said that one of the best things about the framework is the Big Picture, and one of the worst things about the framework is, yes, you guessed it, the Big Picture. Its big and open to interpretation. One (false) interpretation is that in order to „do SAFe“, you need to implement the entire Big Picture, with its full collection of roles, responsibilities, meetings and metrics. But, when asked „how to start“, the answer really is“ start with what and where it makes most sense to your enterprise“. In any case, I´m not going to get bogged down in defending SAFe, or trying to justify it, what I plan to do in this and similar blogs is simply present what I´ve seen implemented „in the field“ with living-breathing-paying customers, and then you can decide what is good or not, and what might make sense in your context.

This first blog in the series relates to the Program Level. SAFe talks about four areas of an enterprise that we typically need to address if we are to be successful with Agile at scale:

• Teams
• Programs
• Portfolios
• Leadership

From the Program level, lets take a short look at the Program Increment Planning Event.

This is often referred to as the “Release Planning event”. This is misleading as we are not planning a release, we are planning an increment of our agile product development program (our aligned set of teams focused on delivering into one value stream). When we actually release is up to the business – we may have continuous delivery, release after each sprint etc. The thing to remember is “develop on (a regular) cadence, but release on demand”.  To remove confusion with one customer who felt they were being flooded with new terminology, we call this program increment a “super-sprint”. We sprint the program. This has worked well in building a common mindset.

The use of the super sprint term has proven quite useful as a tool to remind people what we are up to. We say “hey, you are all familiar with working with scrum, well what we now plan is to introduce a super sprint for the whole team-of-teams (Agile Release Train). We´ll start with a “super sprint planning” event where the chief product owner describes the “what” of what is desired over the coming super sprint (typically 5*2wk sprints). You, the teams, will then create a high level sprint-by-sprint plan for what you believe (with the information you have available during the planning event) you can achieve during the super sprint. We´ll align the “business” with the teams and create a set of high-level super-sprint objectives, then we´ll hold a vote to determine how confident we are that we can achieve these objectives during the coming 10 weeks. After working in sprints for 10 weeks, we´ll then hold an inspect & adapt event where we review what we have achieved, look at some metrics, then retrospect on some issues that arose during the super-sprint and find potential solutions to some issues that can positively impact the next super sprint. Repeat”. This is a simplified description of the core elements program level increment in SAFe. But the “sprint” analogy works in connecting the new level of planning with the familiar scrum planning cycle.

In practice we´ve had great success using the planning meeting agenda proposed by SAFe. The typical planning event is planned for two days, but we´ve also had success running this in a single day with release trains (team-of-teams) of less than 7 teams. For a detailed look at this event then come along to one of our Leading SAFe courses where we deep-dive into the program level and carry out an exercise to simulate such an event.

Typical one-day planning agenda:

Inputs for the planning event are:

• Prioritized set of features from product management. We often see a set-up with a Chief Product Owner and team Product Owners formed into a product ownership team.
• Stories (ideally estimated – a must for a one day event) for the features
• Vision and roadmap

The day runs like this:

• The business owner (often the CEO or SVP responsible for a value stream) starts with a pep-talk to set the overall mission for the business. Setting the big business context.
• The head of product (Chief Product Owner, Product Manager..) presents the vision for the upcoming planning horizon and the high level roadmap. Sets the sense-of-purpose for the team-of-teams. She/he then introduces the priortized features to to the entire team.

Prioritised feature (and stories) laid out prior to planning

• Architecture/DevOps then present Architecture and Ops topics that may impact the teams in the coming weeks. Typcally this could the CTO setting the big architecture picture („we’ve made a platform decision and this is reflected in stories, we´ll need to support the SDK, we have some new NFRs (non-functional requirements), the continuous integration flow will change etc.). Basically setting the „big picture“ for technical issues. The day to day/sprint-to-print technical design still mainly resides in the teams.
• The release train engineer (chief scrum master – agile enterprise coach – call the role whatever you like) then reminds the team what the objective of the planning is, discusses practical & logistic issues, and makes sure all roles & goals are known before the first team break-out session starts.
• Development teams then „break-out“ into their respective teams and start to plan 4 sprints based upon features and stories pulled into their team by the product owner. They leave the 5th sprint (if you are using a 5 sprint planning cadence) free to allow for planning, innovation and (yes, it´s true) a little buffer for work that either spills over from the 4 sprints or emerges from the normal sprint flow). From a LeanAgile perspective, this capacity buffer allows us to „trade uncertain earliness for certain lateness“.

• After the first break-out session, the Business Owner and product team carry out a management review so discuss what has been learned so far – and face the reality of what is likely to be achievable compared to their original wish-list. They have a chance now to make some changes to the original plan so that they can maximise the value likely to be achieved over the 10 weeks.
• After some potential planning changes resulting from the management review, teams go into a second break-out session and continue to plan the 4 sprints. There is a lot of evergy in these break-out sessions, with open communication between teams to discuss dependencies and trade-offs.
• With the end of break-out two, teams present their high-level objectives for the 10 week period, identify risks, and take some questions. If accepted (and the business owner/POs have been „doing the rounds“ during the second breakout to follow progress), then each teams objectives are collected to create the aggregated team-of-teams (release train) objectives. We now have a high level set of program objectives.
• As a group, we review the risks associated with our plans – this usually involves quite a bit of inter-team discussion
• Finally, once all objectives have been collected and accepted by the business owner, and risks have been discussed, the team take a confidence vote to indicate how confident their are that we can achieve this set of objectives in 10 weeks. The teams of teams „comittment“ at the end of the planning event is a) we are confident that, given what we know now, we can achieve these goals and, b) as soon as things change, we´ll inform product and discuss the changes to objectives.

Tips

I was  worried the first time I facilitated such an event: how will it run? will we be able to reach a plan? how can we steer such a large group of people through such an agenda? But it all went well – and has gone well ever since. The planning day/s works. But here are a couple of tips:

• Run a simulation exercise (i.e. simulating the actual planning event) with as many people as possible from the teams who will participate. This is critical in surfacing questions, setting expectations, and helping everyone understand the appropriate level of abstraction.
• Prepare the features and stories – and estimate (even if you use magic estimation so initially estimate a large number of stories. Remember CICO: crap in, crap out 🙂
• Create a clear vision for the 10 weeks (make it short and with a marketing feel – not a 30 page doc.)
• Respect your team – make sure participants know that, ultimately, planning is in their hands 
• Get trained – if you will follow a SAFe approach – get some trained people on the ground
• Continually challenge the plan – if the plan doesn´t change during the 10 week „super sprint“ – then something is probably wrong 🙂

NEXT BLOG: ok, so that´s a little about the program planning event. Next time I´ll talk about one great output of this event – the Program Board. And how we´ve been using (and adapting) this with customers.