Scaling Agile Your Way: SAFe vs. MAXOS (Part 2 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 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:

1.  Teams
2.  Customers/Users
3.  Agile Methods and Environments
4.  Product/Solution
5.  Complexity
6.  Value Chain (see Tables 1 through 4 of Part 1 of this blog series)

Each scaling agile parameter can assume one or more values from a range of values.  This comprehensive (but by no means, complete or exhaustive) list of 25 scaling agile parameters suggests that the agile scaling space is complex and rich with many choices.  Each organization or 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, in Part 1, I also clarified that “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 radically different from MAXOS.  In this part of the series, I will compare and contrast SAFe vs. MAXOS in some depth.

Briefly, here are the key highlights of SAFe.  Details can be found at Scaled Agile Framework:

• SAFe requires a “Portfolio, Program and Teams” hierarchy for a large-scale agile project.
• Each team must be a cross-functional Scrum team and may follow many XP practices.
• Epics at portfolio levels are managed as a Lean/Kanban flow.  Epics are broken down into features that can be completed in a single release cycle at the program level; each feature is broken down into stories that can be completed in a single sprint at the team level.
• All teams in a release train of a program must follow the same lock-step sprint cadence (typically two weeks).
• Release train planning requires all team members (typically up to 150) from all teams in a program to hold two-day-long release planning meetings in person, which entails a substantial effort and complex logistics.
• Release cycles are typically eight to 12 weeks long.
• Software is developed on sprint cadence, and released on demand (but cannot be released faster than the sprint cadence).
• Considerable time and effort is spent in various ceremonies:  sprint planning, sprint review and sprint retrospectives, release train planning across multiple teams, release review and release retrospectives, etc.

Briefly, here are the highlights of MAXOS.  Details can be found in Andy Singleton’s Agile 2014 presentation.

• MAXOS is the scaling approach for “Continuous Agile.”  Continuous Agile combines Kanban Agile task management with continuous delivery code management. 
• MAXOS requires a number of (almost) independent service teams.
• Services have well-defined APIs, are loosely coupled, and have minimal dependencies among them.
• Each team operates with Lean flow.  Applications are rapidly composed of a group or a network of services.
• Each team is developer-centric (not cross-functional) and highly empowered.
• Code is continually integrated in a single code base across all teams.
• Code is continually tested with automated tests (unit, acceptance, regression, etc.) by firing off as many virtual machines as needed in a cloud-based environment.
• Any dependency issues across teams are immediately resolved via rapid team-to-team communication.  For rapid team-to-team or member-to-member communication, tool support is essential. VersionOne provides excellent communication and collaboration among team members.
• The typical ratio of developers to testers tends to be 10:1, as teams are developer-centric and developers do most automated testing.   There are no separate QA teams.  QA testers are called as needed for their expertise by developer-centric teams.
• Each empowered, developer-centric team decides when to release its code (not decided by QA testers or product managers!).  MAXOS claims that this policy rationally aligns the interests of developers with consequences of their release decision; poorly written, poorly reviewed, or inadequately tested code may mean “no weekends” or “No Friday evening beer” for developers!
• All features or stories have switches (togglers) that the product owner (called story owner) decides to turn on (unblock) or turn off (block) based on the market needs.
• Code released in production is extensively supported by automated user feedback collection, measurements and analysis that result in actionable reports for product management.
• Automated feedback from production environment is also used directly by developers to immediately fix problems.
• Meeting time is minimized by “automating away” management meetings, and removing or reducing other Scrum ceremonies.  For example, sprint and release retrospectives are replaced by periodic “Happiness Surveys” and taking actions based on those surveys.

Because of these fundamental differences between SAFe and MAXOS, they represent radically different approaches to scaling agile. The contrast between SAFe and MAXOS is breathtaking, and its implications are worth understanding.  Tables 5-10 present the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

These six tables (Tables 5-10 below) follow a specific color legend described below:

Are your agile projects closer to the SAFe Sweet Spot or the MAXOS Sweet Spot? 

Or are your projects closer to the SAFe Challenge Zone or the MAXOS Challenge Zone?  Or are you in a situation where neither SAFe nor MAXOS will serve you unique agile scaling needs? If you are exploring the use of LeSS or DAD framework, I would encourage you to use the list of 25 scaling agile parameters to identify the Sweet Spot, Challenge Zone and Unfit Zone for LeSS or DAD (as I have done in Tables 5-10 for SAFe and MAXOS). Then determine if your projects are closer to the Sweet Spot or Challenge Zone of LeSS or DAD.

Related posts:

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

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

Part 4: Scaling Agile Your Way – How to develop and implement your custom approach