Three deadly traps to avoid when implementing the Scaled Agile Framework.
You have a large vision for your organisation, the problem is how do you execute upon this vision when the implementation of that vision may span disparate teams, multiple systems, divisions and even political fiefdoms. SAFe is one approach that is becoming increasingly popular to solve this problem of Agile at Scale.
Like all methodologies, Agile or not, SAFe has its critics and one of the reasons may be because if implemented without care and thought, it’s implementation can quickly start to look like a mini-waterfall implementation, reducing many of the benefits the organisation was hoping to achieve by transitioning to Agile. To avoid falling into this trap it is important to understand why this occurs.
Over the past few years I have facilitated over countless Program Increment Planning and Program Level ceremonies across diverse industries. As I assist more and more companies with introducing SAFe, I have noticed three common patterns or ‘traps’ that I have seen companies across industry fall into when implementing SAFe. These traps are by no means inevitable, but they are common and easy to slip into if not mindful.
Trap #1 : Short Waterfall Cycles
Program Increments in SAFe typically vary from 8 weeks to 12 weeks. Many companies like 12 weeks, as it aligns with their quarterly cycles (well kind-of – you have an extra 4 weeks you need to decide what to do with each year).
Given this, it is very easy to think of a Program Increment (PI) as a large sprint where all Features and Stories need full definition together with a detailed architecture or design rather than a high level PI roadmap which is emergent with more detail in earlier sprints than latter ones. It is easy to get trapped into thinking that what’s needed is a heavy upfront requirements and design effort to plan out the entire PI in advance of Program Increment Planning. The diagram below illustrates what this trap looks like :
I think it is important to remember that at Program Increment Planning the output is essentially a PI Roadmap with a series of Goals/Objectives for that Increment. The challenge for many organisations coming from a waterfall background is that they may revert to old thinking requiring detailed plans, requirements and design upfront. At this point it doesn’t matter if you have a single detailed requirements document or a collection of Features and corresponding fully elaborated series of detailed User Stories – the outcome is largely the same – one of heavy upfront requirements and design. Congratulations, you have now descended into a short waterfall cycle !
I find most organisations transitioning from a Waterfall environment fall into this trap rather than organisations that have pre-existing Scrum teams which they are bringing into a SAFe construct.
Trap #2 : Loss of Focus
One of the primary benefits of Agile is to enhance focus. For example, Agile/Scrum at the team level enhances focus through Events (such as Daily Stand-ups), Artefacts (such as User Stories), Concepts (such as a Sprint), Roles (such as a Product Owner). This approach helps both individuals and teams to focus on solving a small challenge over a short duration of time. SAFe attempts to do the same, it does this by adding an additional dimension to the above, i.e. having Events, Artefacts, Concepts, Roles at different levels within the SAFe hierarchy, so they can focus on a challenge but this time at the right level of abstraction, i.e. team, program, value stream or portfolio level.
|SAFe Constructs||Team, e.g.||Program, e.g.||Value Stream, e.g.||Portfolio, e.g.|
|Events||Sprint Planning||PI Planning||Pre- and Post PIP|
|Concepts||Iteration/Sprint||Program Increment||Program Increment||Strategic Themes|
|Roles||Product Owner||Product Manager||Solution Manager||Solution Portfolio Manager|
The above table is an example, not an exhaustive list, of how SAFe tries to enhance focus through applying Agile constructs with an additional ‘organisational tier’ dimension to solve a large problem. The SAFe requirement constructs are a classic example of this: Epic, Capability, Feature, Story, each potentially articulating the same problem to a different audience, with a different level of detail for a different outcome each contributing to achieve a specific objective.
The challenge that occurs is that without a clear understanding of these constructs and why they are there, it is easy to lose focus, and end up with a very confused picture, where Roles, Concepts, Artefacts and Events get blurred across the different levels.
Trap #3 : Feature Inflation with limited Feature Release Capability
In many organisations new to SAFe, the point of a Feature as a requirement construct is entirely misunderstood. A Feature should represent the optimal unit of releasable end-end value. Yet, frequently larger more traditional organisations are merely using features as a bucketing or classification mechanism for bunching up related user stories and / or for reporting purposes. Value is driven by creating and releasing a consumable solution ready for the user to use not through focussing on creating classification and/or reporting prowess.
So, the third trap to be wary of is Feature Inflation, where the number of features grow to an unmanageable number. In some instances they are starting to resemble User Stories in size and impact. This defeats the very point of having Features as requirement constructs in the first place. Additionally, a lack of deployment capability, be that either through a lack of multi-tiered Continuous Integration or a general lack of speed as far as release management is concerned, means that many organisations are bunching up features for deployment causing needless complexity and entirely missing the point of having a Feature in the first place. Here are some common anti-patterns I have come across :
- Features Not Released. Features are not released to the live environment or potentially releasable during the Program Increment.
- Feature Inflation. An Agile Release Train (ART) may have a large number features being brought into a Program Increment, involving huge overhead even through the ART is only able to deploy a fraction of these per PI.
- Features not Valuable. Features are not treated as constructs that deliver end-end business releasable value. Rather they are split to fit within a team rather than to deliver end-end business or user value.
- Features Batch Released. Features are bunched up because most traditional organisations don’t have multi-tiered CI or the ability to release functionality frequently. This delays the release of value reducing the benefits of moving from a Waterfall methodology to Agile.
To see how I have solved these problems in the real world, please join my free webinar : It’s not SAFe to descend into Waterfall. Here, I will talk not just about the traps, but also the solutions that I have implemented to either prevent falling into these traps or helping to get out of these traps if the organisation is already suffering from these challenges.