Large-Scale Scrum : SAFe Is Not Safe
This is my second article about Large-Scale Scrum or LeSS. Let me start by making it clear that I am not saying that other approaches can’t or won’t work, but I firmly believe in a principles based approach. Principles that focus on the on-going delivery of business value through the focus on the sustainability for the humans as well as the product. Principles that support the concepts of building quality in and the belief in increasing business viability through increased productivity rather than cost reduction.
SAFe is used by many organizations to manage software development and IT projects. For many organizations, the implementation of Scrum at the team level creates significant coordination and visibility issues. Because Scrum does not overtly deal with the issues of large scale scrum, organizations reach for traditional management techniques. The familiarity of these techniques makes them easy to fall back on. SAFe, while professing to be Agile, is in fact more of a traditional approach to muti-team development. One of the core concepts of SAFe is the Release Train. Here are four aspects of the SAFe Release Train and how LeSS handles these issues.
The Release Train documentation describes the role of Release Train Engineer. This role is described as the Chief ScrumMaster. The ScrumMaster is a facilitator, a servant leader. Adding the word “Chief” to the tem indicates a hierarchy and vertical responsibility. Scrum is flat. The team is responsible for how the product gets built and the Product Owner is responsible for what gets built. The role of Chief ScrumMaster sounds like the team and Product Owner are responsible to the Release Train Engineer. The train must leave the station on time, these items must be built by the team or you will answer to the Release Train Engineer. The forceful pulling of the teams by the train, with a Release Train Engineer, just does not seem to support the principles. In SAFe the schedule is more important than quality or the team. The product needs to be guided by user and business needs.
The Release Train documentation says that the Business Owners have the ultimate responsibility for outcomes. My question is, if the Business Owners are responsible, how can the Product Owner be responsible for what is developed and the team for how it gets developed? The Business Owner(s) might be the actual Product Owner, but with this role being called out separately, that is not likely the case. That means that the Business Owner is setting product goals for the Product Owner. Who is the team to assume is the authority for what gets built? At the very least, a multiple level product owner system is going to be confusing, especially if the relationship between the Business Owner and Product Owner is not clear. LeSS, for up to 8 Scrum Teams, has a single Product Owner who is the sole authority for what gets built. In LeSS Huge, where there are more than 8 teams, there is a Product Owner with a team of two or more Area Product Owners. The Product Owner is responsible for the product as a whole, and the Area Product Owners take responsibility for a functional area of the product. The Product Owner manages the Product Backlog so that each Sprint delivers a single increment of complete product with each Area contributing to that goal. If the Business Owner is responsible for outcomes, how do they balance the cost, quality and scope relationship? Many business owners, who are not developers, operate as if quality is controlled by a big dimmer switch and it is their’s to turn up or down. They believe that they can tune quality up or down to get more or less work done as required. The reality is that poor quality is the primary drag on the delivery of business value. Teams that deliver higher than average quality pursue quality. The Lean principle is to build quality in. If the Business Owner is responsible for outcomes, they are going to assign work to the teams and team members with deadlines. Rule #1 becomes build the product, quality takes a back seat. The Business Owner is truly responsible for the poor outcomes.
The Release Train contains a System Team who is responsible for Integration. What happened to continuous integration? Many teams deal with dependencies with the sequencing of the work in working periods where the provider components are built before the consumer components. That means that the provider component teams have to clearly understand the needs of the consumer components, before those teams begin their work. The Product Owner in LeSS manages the implementation of the Product Backlog with all teams Feature Teams focused on a single, comprehensive, integrated increment of product per Sprint rather than trying to link component teams in a chain of sequential dependencies in a train of Sprints.
The UX and System Architecture Teams build the Architectural Runway. Firstly, the switch in metaphor leaves me wondering how trains will fly. However, on second thought my impression that the intention is to have the UX and System Architecture Teams create the interface, user experience and architectural aspects of the solution before the other component teams can work on their parts of the solution. While these components are special in that they interact with all the other components in the system, neither UI nor Architecture deliver any true business value. The UI and the Architecture are not the product and the product must lead. The implementation of a solution that satisfies user need is the proper indicator of UI and Architecture. In LeSS, as in any truly Agile process, the best designs and architectures emerge from a business value driven, feature focused set of teams. Trying to define and build UI and Architecture before the emergent unfolding of the needs of the user not only delays the start of build real value delivering features, it will be wrong and likely lead to system viscosity and brittleness. The rework required to mitigate these errors is expensive and further delays the delivery of business value.
In summary, the Release Train, ruled by the Release Train Engineer with component teams that follow the chain of dependencies as defined by the UX and Architecture teams with an Integration team trying to bring it all together before the train gets to the next station on time. Borrowing Ralph Nader’s reference to the Corvair, SAFe is unsafe at any speed. SAFe is a brute force process with very little chance of delivering solutions that will be delivered on time and be able to adapt to change in the future.
However, all of these problems are hidden under the illusion of agility that SAFe presents. LeSS is Scrum. LeSS is based on self organizing feature teams where the responsibility for what gets built is defined by a business person and the teams are responsible for how the solution is built and the quality. Rule #1 of LeSS is “Don’t do it!”, but if your solution can’t be built by a small number of teams, SAFe will most likely create a train wreck while LeSS provides the opportunity to deliver more business value faster.