Achieving Business Agility at Small to Mid-Scale (online book)
For mid to large sized organizations, the Planning Event has become to “scale” what the Daily Scrum is to Scrum. Whether or not you are doing SAFe®, the Planning Event is often a great way to increase collaboration while coordinating the work of your teams. This article is geared to those people who have adopted the SAFe Program Increment (PI) Planning Event, either while doing SAFe or using another approach.
Planning is everything, even in Agile
Eisenhower famously said, “plans are worthless but planning is everything.”
The purpose of planning in Agile is not to create a plan to stick with it. It is to increase collaboration, to discover dependencies, to create a baseline for working together and provide some degree of predictability to stakeholders.
Planning events can be improved by shifting from the plan itself (which is worthless) to increasing collaboration and dependency management. On reflection, it is easy to see if there was no need for collaboration and dependency management there actually wouldn’t be need for the event itself – teams could just plan on their own.
The advantages of the Planning Event lie more in collaboration and dependency management than in the actual plan that results from the planning. This reflects the fact that if there weren’t dependencies between the teams, the event wouldn’t even be necessary. Some of the benefits of the Planning Event.
Aligning around value realization
Before the Planning Event, it should already be clear what needs to be created for release and realization. If Product Managers are required to do this clarification during the event, it is a symptom of improper preparation. They do this by defining a sequenced list of Minimum Business Increments (MBIs).
In a nutshell, an MBI is the smallest increment of value that can be released that has realizable value. The notion of “release for realization” is critical for a plan that is focused just on releasing will not necessarily capture all of what is necessary in order for customers to realize the value of what was released. Far too often, items ancillary to technology are forgotten.
The focus should be on building MBIs as quickly as possible within the event.This results in a deliverable value graph that is constant and linear rather than looking like a “hockey stick” where value is realized at the end. To explore this a bit more,
Whether they are released or not is a business decision. But doing so lowers the risk of having nothing to release at the end of the program increment. You will be able to deliver value even if things don’t go according to plan.
When capacity is limited and conflicts arise between the MBIs, teams can decide which MBI to support based on the overall understanding the impact to overall Cost of Delay of their decisions.
Elements of an effective Planning Event
Planning Events don’t just happen. Here is what is required for an effective event.
Events should take place over two days even if only a half day is used each day. The reason for this is that it gives time for people to reflect on what happened and is needed. The subconscious mind will prompt new ideas overnight.
The following sections give more detail.
Preparing for the Planning Event
Proper preparation is crucial for an effective Planning Event. As said before, Product Managers must be clear about what needs to be created for release and realization and must have created a sequenced list of MBIs. The prioritization and sequencing should be based on WSJF on the MBIs. The items for the backlog should be appropriate for the amount of time of the PI the planning is for.
In addition, before the event, teams should have been able to identify most of their dependencies their work has on other teams.
Clearly dependency management is essential for an effective event. If there weren’t dependencies teams could just plan and deliver on their own. There are different types of dependencies, however.
These are dependencies where one feature or story won’t even work without another. For example, updating a customer record requires that somewhere a customer record can be created.
These are dependencies where the system will function, but where a business rule in one part of the system requires functionality in another. For example, a new type of client may be added but the controlling software is never given the functionality to take advantage of it even though it will run.
Dependencies outside of technology
These dependencies are often overlooked and a key reason MBIs are useful. These would include any marketing, shared services or DevOps requirements. The difference between releasable and realizable are often of these type. Releasing something without being able to support it or having marketing be aware of it cause clear challenges to realizing value.
If there is not the capacity to complete an MBI because of limited capacity, it should be considered whether to do another MBI that can be done before it.
Making agreements regarding dependencies
When a dependency is identified, it is important that an agreement be made about when it will be met. In some companies one team just tells another they need it and by when. But notice that’s not an agreement. That’s a mere request disguised as a demand. If later the team finishing the dependent story can’t get it done in time they will often just say they can’t do it. However, if it is made clear before the event that when one team needs another team to get something done, then both teams must agree to the date at which it will be done.
Having a visualization tool to help during your planning event that allows for deferring commitment can often be useful for shared services teams that several teams are depending upon. Such a tool can also help with avoiding having the program backboard becoming a bottleneck. Such a tool should be designed for events of this type so that entering information into them is easier than putting it up on the program board.
This is actual output from Net Objectives Program Board Builder tool that automatically builds the program board with little effort. Bold red borders indicates the backlog item is involved in an uncommitted dependency. The lines are different colors and style to create easy visibility on what connects to what (the difference don’t represent anything. Note that manual boards can be built by just adding a sticker when an unagreed to dependency is present.
Running the event
How the event is run often depends upon the how the work being done relates to the teams. In very large companies, it may be that work for an MBI is spread amongst several teams. But in many companies whose technology is less than 1000 people, teams are already product oriented. In these cases, a team is often responsible for most of an MBI, where the event is being used to just manage the few stories each MBI may have dependencies on with other teams. In this case, each team can be responsible for their own commitments – the MBIs they are committing to as well as the stories that others are dependent upon.
The event is best run over two days, even if it can be squeezed into one day. This provides a little reflection time which is very valuable.
At the end of the event
A little time should be left at the end of an event to see if moving any stories around can shorten cycle time. Very often in an event certain stories are started earlier than they need to. A reflection of the program board can often reveal significant improvements here.
If your organization’s work is mostly organized around teams that build their own MBIs and only need other teams for a few dependencies, the event can be run remotely with a good planning tool. These are not the same as tools such as AgileCraft, Computer Associates, LeanKit, etc., which are about managing work during the program increment itself. A planning tool needs to be designed so that using it is easier than using a board. If you have a way of doing this, then teams can connect with each other in the following way:
This enables teams to work on their own stories while communicating with other teams that they are dependent upon or who depend on them.
Variations on Planning Events
Although the program increment planning event originated with SAFe you don’t have to do it as prescribed in SAFe. Sometimes a one-off planning event to get dependencies mapped out and then going to a flow model is best. Sometimes doing planning events every month is best. These two are often the cases for mid-scale organizations. Planning events should be done as frequently as possible as doing so enables
Summary: Achieving scale
Regardless of the approach you are taking, Planning Events should include the following:
A challenge with SAFe is that Planning Events are not guided by MBIs. There is more focus on when features are to be completed than on the possibility for the customer to realize value. This results in features that have bigger scope than is needed; too often, considerations about the “minimum scope required” only surface when it looks like we may not complete the work in time. By creating visibility of the MBIs and when they can be released, everyone can work together on getting value to customers or the business and not merely building functionality.
For companies with fewer than a thousand people in their technology group, the planning event integrated with good Agile Product Management can often be a better choice than a full implementation of SAFe or even SAFe Essentials.