In Part 1 of this four-part series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives. Each agile project developing a product or a solution has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management 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 (see Tables 1-4 of Part 1 of this blog series). Each scaling agile parameter can assume one or more values from a range of values. Each organization or a large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique. However, “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise). Systems thinking is important for Scaling Agile Your Way.
In Part 1, I 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. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth. SAFe and MAXOS represent radically different approaches to scaling agile. 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.
Today, I will focus on the Sweet Spot, Challenge Zone and Unfit zone for SAFe and MAXOS:
- Indicates a good match between a scaling agile framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
- Implementation becomes easier, more efficient and effective
- Indicates a challenging match between a framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
- Requires more implementation effort compared to the Sweet Spot
- Indicates a poor match between a framework and a scaling agile parameter with a specific choice or range of choices for the parameter
- Poor match could happen for one of two reasons: (1) the parameter value chosen is not applicable, or (2) the parameter value chosen will not work well
Figure 1 illustrates the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presents similar information for MAXOS. These are organized by the six scaling aspects mentioned above. You will see four arrows in each Figure showing our recommendation for taking your large-scale agile projects closer to the Sweet Spot over a period of time. I urge you to carefully review all of the information presented in Figures 1 and 2. There is a lot of information, and it will take time to fully understand. You may find it helpful to discuss with other agilists within your company.
From the information in Figures 1 and 2, it is clear that SAFe and MAXOS offer mostly distinct Sweet Spots, Challenge Zones and Unfit Zones, although occasionally there may be some overlap. For example:
- As shown in Figure 1, cross-functional, self-organized teams with co-located or close-by time zoned team members working under low to moderate governance structure offer a Sweet Spot for SAFe. But in Figure 2, self-organized, developer-centric (not cross-functional) teams of co-located members with minimal governance overhead offer a Sweet Spot for MAXOS.
- In Figure 1, emerging user needs that must be discovered with sustained effort represent a Challenge Zone for SAFe; in Figure 2, the same scaling agile parameter value offers a Sweet Spot for MAXOS.
- In Figure 1, low to moderate product modularity represents a Challenge Zone for SAFe, while Figure 2 shows that low modularity (tight integration of all code) creates an Unfit Zone for MAXOS. On the other hand, a high degree of modularity in the product/solution architecture represents a Sweet Spot for both SAFe and MAXOS.
- In Figure 2, heavy and rigid governance, or heavy/life-critical regulatory regime represent an Unfit Zone for MAXOS. But in Figure 1, the same scaling parameter values offer a Challenge Zone for SAFe.
- In both of these, we see that, “Tightly coupled hardware product with embedded software and services (ex. appliances, cars, medical devices, smartphones, wearable computers, military gear, industrial equipment)” represent an Unfit Zone for both SAFe as well as MAXOS.
Get As Close to the Sweet Spot As Possible
If you decide to use SAFe in your enterprise (at least for some programs and portfolios), ideally you should try to get as close to the SAFe Sweet Spot as possible. I have similar advice if you decide to use MAXOS (get as close to the MAXOS Sweet Spot as possible). It is quite possible that your entire enterprise is not close to the Sweet Spot when you are just beginning your scaling agile transformation effort. In that situation, I suggest starting with a scaling agile pilot program of 5 to 10 teams; after their initial education on SAFe (or MAXOS) is over, have this pilot program start as close to the Sweet Spot as possible. This may require changes in some of your historical processes and practices, and development of SAFe (or MAXOS) with clear understanding and support for from your senior management.
For example, a pilot for SAFe may need to choose a relatively moderate domain complexity project, fairly modular architecture to minimize inter-team dependencies, co-located team members for most teams, a good deal of test automation and continuous integration (with prior training), a set of strong servant-leader ScrumMasters for each team, low to moderate governance overhead, low to moderate regulatory compliance regime, low to moderate impact of defects, etc. See the Sweet Spot for SAFe in Figure 1. If the pilot program teams are not close to the Sweet Spot yet, senior management will need to help them get there as the starting point for the pilot to make the scaling agile journey less painful. With the experience of one release cycle underway, more pilot programs can be started close to the Sweet Spot; in fact, while the first pilot is going on, one to four more pilot programs can be identified and necessary effort expended to bring them close to the Sweet Spot as a starting point for their upcoming SAFe (or MAXOS) pilots.
Dealing With the Unfit Zone
The other extreme of the Sweet Spot is, of course, the Unfit Zone. If a pilot team finds themselves in the Unfit Zone for at least one scaling agile aspect, the pilot will very likely fail. For example, if a SAFe pilot program must use contributions from the open source community, or a MAXOS pilot program must operate under a rigid or heavy governance structure, or work under a life-critical regulatory regime, it will most likely fail. Senior management must either take action to remove the issues creating the Unfit Zone, or select a different pilot program that does not find put the pilot in the Unfit Zone for any of the six scaling aspects.
Your Journey to the Sweet Spot is Your Tailored Journey
Your transition of your pilot program to the SAFe (or MAXOS) Sweet Spot will be your own customized plan and journey tailored to your situation. You need to consider where these pilot teams are now, the gap between their current status and the Sweet Spot, and the effort and time needed to bring them closer to the Sweet Spot. This effort will be dependent on each team’s situation, and is a very important aspect of “Scaling Agile Your Way.” How do you take a pilot program close to the Sweet Spot is going to be your own unique journey and cannot be copied from a recipe book. If a pilot program or a specific team within that program cannot reach the Sweet spot across all six scaling aspects, maybe it will come close to the Sweet Spot for four out of six scaling aspects, and stay in the Challenge Zone for the remaining two. When a pilot program is in the Challenge Zone with respect a scaling aspect, it does not mean that the pilot program cannot start or proceed; but it does mean that you need to be prepared to spend more effort and overcome difficult challenges if you are going to operate in the Challenge Zone.
For example, if a pilot program has one or more teams with their members in different locations with widely different time zones, the SAFe Release Train Planning (two-day event required by SAFe) may involve a lot of complicated logistics and travel time/expenses for remote people, for which senior management support might be hard to come by (after all, “this is a pilot” is likely to be the argument). If the pilot needs to operate under a traditional, hierarchical and rigid structure, it may create many organization impediments, complicating the challenges for the pilot program.
As shown in both Figures 1 and 2, your transition plan is to move as close to the Sweet Spot (the inner most rectangle area) as possible from the directions of Unfit Zone and Challenge Zone. This is illustrated by four broad arrows pointing toward the innermost rectangle in Figure 1 for SAFe and in Figure 2 for MAXOS. 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 culprit is likely one of 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 its understanding and commitment to the success of scaling agile.
2. Rooted in the market and business environment of your organization. These reasons cannot be removed by senior management (if you want to stay in the business). You will need to replace or augment the scaling agile framework practices with your own custom practices and retain the practices from the framework that are still applicable.
Table 11 below captures the Unfit Zone and Challenge Zone in its two rows, and the above two classes of reasons in its two columns. The cells in this table illustrate specific examples of an action plan.
Table 11: Reasons and Actions for Unfit and Challenge Zonewith Examples
The transition from Unfit or Challenge Zone to Sweet Spot will require planned, disciplined and concerted effort — and a good understanding and true commitment from your senior management. This journey will be 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 still have few areas in the Challenge Zone.
Customization Needs and Opportunities for Implementing Your Scaling Agile Framework
In addition to your unique and tailored journey toward the Sweet Spot of your scaling agile framework, a very important aspect of Scaling Agile Your Way is that each team, program or portfolio may need to implement key aspects of its framework in unique and customized ways. It seems that the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be used to implement a variety of process modules of SAFe in customized ways. Customization needs and opportunities for the MAXOS framework will come mostly in the context of implementing its advanced engineering practices of code contribution, automated testing, continuous integration, feature switches, continuous delivery, and making use of cloud computing facilities, etc. I will elaborate on this topic in Part 4 of this series.
Are you about to start your scaling agile journey? If so, do you have one or few pilot programs consisting of 5 to 10 teams in mind? How do you feel getting them started closer to the Sweet Spot of SAFe, MAXOS or any other framework of your choice (such as LeSS or DAD)? Have you run into the Unfit Zone for any scaling aspects?
Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly
Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS
Part 4: Scaling Agile Your Way: How to develop and implement your custom approach