First the Problem, Then the Solution!

Much to my wife’s chagrin, I’m not much of a?do-it-yourselfer. Nevertheless, tools fascinate me. Beautifully lined up in incredible variety, they tout their undeniable usefulness in the hardware store. And occasionally, they tempt me to buy them just in case I?might need them someday. This case never happens, or when it does, I?have long forgotten about the tool (my wife also claims that I?can avoid this by keeping the tool storeroom tidy, but that’s another?story).

The situation is similar with various agile frameworks such as the Scaled Agile Framework (SAFe), LeSS, Nexus, or the Spotify model. You won’t find these at the hardware store, but every consulting firm has them on offer. And here, too, customers are enticed to buy a?model with its tools and practices. However, this is often more of a?preventive and theoretically motivated purchase, just as I?do at the hardware store. One has not understood all the problems these models provide solutions for, but they look convenient and valuable.

All these frameworks contain helpful solutions, but they have to fit the organization’s problems. These problems, however, must first and foremost be understood and present in practical everyday life. That’s why my advice for the agile transformation is: to think big, start small, and learn quickly. If you start small, for example, with one or two Scrum teams, and then gradually expand the activities, you will inevitably come across these problems and understand the solutions that the various frameworks provide for?them.

First on this journey typically comes the problem of coordinating the work of multiple teams on the same product. The somewhat traditional solution is to break down the product hierarchically into components, on each of which a?dedicated team works. Coordination in this setting is often up to the product owner, who must ensure a?consistent result for each sprint. As a?result, the product owner quickly becomes a?bottleneck missing out on his actual work on the future of the product and with the stakeholders.

A similarly severe problem is that, globally, these teams do not always work on the things that are most important to the product for workload reasons. Work is not always evenly distributed across all components of the product. So the team for the user management component will be working on things that are not a?priority because, at the moment, the focus should be on reworking the store component. Unfortunately, the user management team can’t help because it’s a?different component.

So-called feature teams address precisely this problem. Their scope is not limited to one product component, but they can implement a?feature across?all?components end-to-end. These teams also have to coordinate, but joint sprint planning and a?regular scrum of scrums during the sprint are usually sufficient. However, this model requires a?higher maturity of the teams, which of course, need to know more about the entire product to make adjustments. This higher degree of ownership, concerning the product as a whole and not just one component, leads to a?higher degree of self-organization and relieves the product owner of coordinative?tasks.

Even with this elementary form of scaling, i.e., multiple teams working on a?single product, it is crucial how we divide the work. Suppose you choose the traditional breakdown into components and encounter a “Program Increment Planning” (PI?Planning) in the SAFe toolbox. In that case, you solve the problem of managing dependencies on the surface, but you don’t get to the root of the problem.

If several products in a?portfolio work agile, the question of coordination and joint alignment arises again, but now at a?higher, strategic level. Here objectives and key results, for instance, could give the products a?shared strategic direction without restricting their autonomy too much. SAFe provides answers to this at the portfolio level, and to a?certain extent, the tribes in the Spotify model are also a?solution. Many roads lead to Rome. However, it is crucial to look for the solution starting from a?practically occurring problem and not precautionary or out of theoretical fascination for the methodology on colorful slides.

Finally, when many teams are working in an agile manner across several products, the question of common standards for the operations of the products, the architecture, Continuous Integration / Continuous Deployment, or security, to name only the obvious ones, is pressing. The primary organizational structure is rightfully the product hierarchy: The employees should feel that they belong primarily to their product and the value creation for the customer (ideally in a?feature team because otherwise, they think they belong primarily to the component). In this sense, specialist silos in the organization for these cross-cutting aspects are not a?good solution. Here come into play communities of practice or guilds, depending on the preferred framework. Their task is always the same: to build up, professionalize and also standardize joint expertise (IT?operations, security, architecture, etc.) across several product?teams.

I could continue this list of typical problems and the solutions offered in agile frameworks. However, my point is not to exhaust the topic or create a?meta-model of agile frameworks. All frameworks contain reasonable solutions. Like there are good tools in the hardware store. But to use them successfully, you must have the right problem and understand it correctly. In addition, all solutions also have side effects and interactions, and sometimes these solutions also need specific prerequisites for successful application.

It is no longer sufficient to have one person learning for the organization, a?Ford or a?Sloan or a?Watson or a?Gates. […] The organizations that will truly excel in the future will be the organizations that discover how to tap people’s […] capacity to learn at all levels in an organization.

Peter Senge, The Fifth Discipline

The obsession with simply selecting a?proven model and rolling it out will, therefore, not be rewarded with success but has the potential to burn the chosen agile framework and the concept of agility in general. It seems more sensible to me to explore the problem space of scaled agile step by step and then, after understanding the problem thoroughly, look for adequate solutions in the known frameworks and beyond. Crucial to this is a?fearless learning culture and the fundamental agile practice of continuous improvement that originates from lean management, such as retrospectives in Scrum. With such a?sustainable foundation, it is unnecessary to find the?best?framework to start with; a?good beginning is enough, as long as there is consistent shared learning.