Scaling Agile Your Way: How to Develop and Implement Your Custom Approach (Part 4 of 4)

In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.  In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:  Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (Tables 1-4 of Part 1).   I also presented a brief overview of various popular agile and lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.

Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS.  SAFe and MAXOS represent radically different approaches to scaling agile. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

In Part 3, I presented the Sweet Spots, Challenge Zones and Unfit zones for SAFe and MAXOS. Figure 1 in Part 3 illustrated the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presented similar information for MAXOS.  The Sweet spot indicates a good match between a scaling agile framework and all scaling agile parameters; consequently the implementation becomes easier, more efficient and effective.  The Challenge Zone indicates a challenging match between a framework and one or more scaling agile parameters, and requires more implementation effort compared to the Sweet Spot.  The Unfit Zone indicates a very poor (almost unworkable) match between a framework and one or more scaling agile parameters.

In Part 3, I explained why it is a good idea to get as close as possible to the sweet spot of your chosen scaling agile framework; it increases the likelihood that your pilot large-scale agile project will have fewer difficulties in succeeding. If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The root cause is likely to be one of these two things:

1.  Internal to your own organization (its history, culture, current practices, etc.).  This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate their understanding and commitment to the success of scaling agile.

2.  Arising from the market and business environment of your organization.  These pressures cannot be removed by senior management (if you want to stay in the business).  You will need to replace or augment some of the scaling agile framework practices with your own custom practices, while retaining the practices from the framework that are still applicable.

The journey from Unfit or Challenge Zone to Sweet Spot is uniquely yours, and cannot be copied from a cookbook.  Over time, you will find that you are moving closer and closer to the Sweet Spot, but may still have a few areas in the Challenge Zone to address.

In this final part of my series, I explain a very important challenge for Scaling Agile Your Way.  It requires each team, program or portfolio to implement one or more key aspects of the chosen framework (whether the key aspect is in the Sweet Spot or Challenge Zone) in unique and customized ways.  I explain how the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be applied to SAFe to make it less prescriptive, “modularize” SAFe, and allow customized implementation of those modules.

The Scrum at Scale framework provides a general language for talking about how to scale Scrum.  At its roots, Scrum is an object-oriented framework.  Each role, artifact and ceremony is defined by the teams’ objectives, participants, inputs and outputs.  Core Scrum allows for many different ways to achieve objectives within given input/output constraints. Modularity allows organizations to establish and improve agile practices incrementally by focusing on one independent module at a time.  Scrum at Scale aspires to develop a “pattern library” of successful approaches that can be used in different contexts; this pattern library is being developed based on a crowd-sourcing approach.

Tables 12-16 in this post (see below) present 10 modules of the Scrum at Scale framework:

1.  Team-Level Scrum Process
2.  Strategic Vision
3.  Backlog Prioritization
4.  Backlog Decomposition and Refinement
5.  Release Planning
6.  Release Management
7.  Feedback
8.  Continuous Improvement and Impediment Removal
9.  Cross-Team Coordination
10. Metrics and Transparency

As the Scrum framework is object-oriented, each of these 10 modules has a set of well-defined goals, inputs and outputs.  It is up to each entity (team or business unit or organization) to implement each module in a way that best suits its own needs and constraints, so long as it produces the desired goals and outputs from a given set of inputs.  The details of implementing each module should be left to each entity, as the implementation details are expected to be different.  Each of Tables 12-16 presents two modules and explains how object-oriented implementation of each module is applicable to SAFe.

SAFe is characterized by its critics as too prescriptive; some of this critique may be fair while other is not.  Critics allege that because SAFe is (overly) prescriptive, it may not work well in many situations.  This prescriptive orientation (real or perceived) of SAFe can be reduced considerably by taking a strong, object-oriented approach in modularizing and implementing SAFe.  Instead of prescribing or specifying how different goals or ceremonies of SAFe should be implemented, why not follow the object-oriented approach of Scrum at Scale framework while implementing SAFe — where each module’s goals, outputs and inputs are emphasized while leaving the implementation details to each entity (team or program or portfolio)?  Of course, constraints arising from inter-team or inter-program coordination and synchronization must be met; even those constraints should be specified in terms of their goals — not by prescribing their implementation details (think of “object-oriented” constraints). 

Table 12:  Modules 1 and 2 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table 13:  Modules 3 and 4 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table 14:  Modules 5 and 6 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table 15: Modules 7 and 8 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table 16: Modules 9 and 10 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Customization needs and opportunities for the MAXOS framework

These will arise mostly in the context of implementing its advanced engineering practices of:

• Code contribution
• Automated testing
• Continuous integration
• Feature switches
• Continuous delivery
• Collecting and analyzing automated user feedback
• Making use of cloud computing facilities on a massive scale, etc.

There are open-source and some commercial products available for automated testing, continuous integration and using cloud computing facilities for software development, testing and deployment.  I will not elaborate on MAXOS customization here.

How may an object-oriented implementation of SAFe (applying Scrum at Scale meta-framework guidelines, as explained in this part) suit your organization’s needs and constraints better than following SAFe “by the book?”  Besides the aspects of customization covered in Tables 12-16, are there any other aspects that come to your mind?

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS

Part 3: Scaling Agile Your Way:  Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS