Using a Scaled Agile Framework for Big Agile Projects
It is not uncommon to hear about software project failures., but it's the large-scale project failures that really capture our attention—especially when the problems not only affect a company but the company's customers as well. The recent software glitches and errors that hit the Royal Bank of Scotland and Knight Capital Group damaged both organizations’ reputations and resulted in multimillion dollar losses.
Some of the problems plaguing large-scale projects include communication and coordination errors at multiple levels as well as technology integration and infrastructure issues. Several thought leaders have made attempts in the past to alleviate the impact of these problems on the customers. Craig Larman’s recent book Scaling Lean and Agile Development is a good example. However, no one has been able to identify a silver bullet to address the issues. I doubt there is one.
Recently I came across the idea of a Scaled Agile Framework (SAFe), created by Dean Leffingwell, which is another attempt to help steer large-scale agile projects in the right direction. Synchronization of multiple touch points and early integration testing form the two key ingredients in large-scale projects, and SAFe suggest ways to solve many issues that may arise during these stages.
This screen shot provides an overview of SAFe.
Figure 1. Overview of SAFe
Copyright 2012, Leffingwell LLC. Reproduced with permission
When you see the diagram for the first time, it might look very complex. However, it carries some simple concepts in it. Leffingwell has divided the entire framework into three broad levels: portfolio, program, and team.
Each level has been tagged with clear-cut roles, responsibilities, and artefacts to be delivered. SAFe reuses not only the Scrum framework but also the Feature Driven Development framework in some ways. This reuse ensures that the learning curve is minimal when it comes to understanding the framework.
Even though Scrum popularized the concept of Potentially Shippable Increments (PSI), many teams ignore it. They still continue delivering islands of partially-built products in each iteration. However, SAFe enforces the good behavior of implementing PSIs through the Agile Release Train (ART).
The ART carries all the features to deliver a PSI, just like a train carrying a cargo. At the end of each PSI, you should be able to test the application end-to-end with limited features. This concept forces the release managers, portfolio managers, architects, and developers to think about integration right from the first Iteration.
I would like to set the expectation that you need to do a lot of careful planning before embracing this framework. One of the expectations while implementing PSIs is a commitment from different Scrum teams to deliver end to end testable features at the end of each PSI. A team not completing a certain feature could push others to wait. You should not wait until the end of PSI to do integration testing but do Continuous Integration (CI) from day one. However, many legacy and packaged applications don’t support CI, which makes testing complicated within PSI boundaries.
With so many roles and processes involved, many agilists believe that this could end up becoming another Capability Maturity Model.
