The various dimensions and levels of scaling agile and their implications

Implementing Scrum in one or more software development teams is usually the first step towards agility that the typical company takes. Scrum as envisioned by its inventors and described in the Scrum Guide, is oriented around a single team, containing both business people and software developers, working autonomously together on a single product. It sounds simplistic and you might think that such a thing could only have been possible in small IT-product-oriented startups, enjoying the luxury of greenfield development without any legacy issues, dependencies, or scaling requirements. Actually it was not simple and a lot of empirical inspect and adapt was required by Ken and Jeff in the context of medium to large size enterprises to finally come up with the framework that was powerful, yet general and flexible enough to be used by any organization involved in highly creative, market facing, complex product development.

With good leadership and courage, such as that exhibited by Ken and Jeff back then, any company has the potential to successfully apply Scrum out of the box and allow their teams to evolve to a state of highly engaged, highly productive delivery of valuable products. But perhaps some aspects of the context they enjoyed back then did make it easier to change the organization to fit Scrum and other aspects were surely harder to change and had an influence on how Scrum itself developed. Sometimes this is fine. Things still have to make business sense. If either not doing Scrum perfectly is not your main problem (and very often organizations have development teams that are working with a slightly flawed implementation of Scrum that could be improved, but if these teams are not the bottleneck, then improving the way they do Scrum might not bring any end-to-end, bottom line results), or doing it perfectly might be more expensive (or have other downsides) than the alternative, then we have to use common sense. We have to look for alternatives. In this post I will look at some of the situations larger enterprises might face and some of the ways we might decide to cope with them.

In Scrum, one of the ideas is to work on the most valuable features first and keep going until the product is “good enough”. This is usually the point at which the incremental costs of development usually exceed the incremental value of the most valuable features still in the backlog. This could potentially happen without warning after a review meeting for example. Now a product development company has an interest in seeing this coming and can start to think about the next product that a team could work on, thereby avoiding the situation that employees are sitting around not producing value. In the case that a software development company is providing development services to a customer however, the customer might not necessarily share the risk that the service provider faces from an early end to development. To mitigate this risk the service provider might find it useful to develop a multi-product approach. This is the first level of Agile Scaling: Single-Team, Multi-Product.

It is not just service providers that may need to mitigate risk by adopting a multi-product strategy. Product companies often have to work on both the maintenance of a legacy version of some product, while developing its more modern replacement or more generally investing effort into products at different stages of the product development lifecycle as part of a departmental or organizational product portfolio risk management strategy. Interestingly enough, the two main popular, lightweight approaches to scaling agile do not support this first level of scaling. LeSS and Nexus are explicitly single-product only which excludes them from consideration from many situations. For such situations I recommend the use of Kanban which has a lot of support for a multi-product approach and is lightweight enough to be used in a single-team setting.

The second approach is the functional teams approach. This is where the teams start to compromise on being cross-functional. It is certainly not optimal from an Agile perspective, and technically not permitted with Scrum, but there may be cases where it is the sensible approach and it is certainly very common. The line between teams can usually be drawn in two places. Between Business and IT, or between a product-oriented team and one or more teams providing common services such as common UI or business logic components, web service development, database tasks, infrastructure services, or skills that the product team doesn’t need every sprint such as SAP or mainframe skills. Some of the reasons for structuring a knowledge work system this way are less valid than others. Splitting Business and IT should really be avoided. It is usually done because the organization has a historical split between the two that is culturally or socially hard to bridge. What often happens in this approach is that the market facing business team actually develops the product, often not in an agile way at all. They will have the vision, conduct market research, develop some sort of requirements or even design documentation and may even build a user-interface mockup of the product. They then hand this over to the IT team, who are supposed to then use Scrum to basically do not much more than convert the almost-finished product into source code. This is the incorrect application of Scrum. In such a case it is actually the business teams who are doing the complex, creative work and have the need for Scrum, whereas for the IT team, Scrum is an unnecessary overhead. For their more linear task, a simple ticket system would be sufficient.

The other case, where we make a split between a market-facing, product development team and service providing team, is also overused. I think it is always much better for the product team itself to do the actual work developing any potentially shareable components and then make them available to other product development teams for reuse or extension. Likewise, developing a web service or performing database related administration or development tasks are also the sort of thing most developers should be able to do themselves directly. Even if a service, schema or DB instance is shared amongst products, I believe the product teams themselves should do the work directly, and not rely on a separate team to do the work. This is essentially the Extreme Programming concept of collective ownership. The grey area might lie in the case of infrastructure development or testing environments I think the product development teams should have a high degree of freedom to e.g. provision their own virtual servers or DB instances according to their needs. When it comes to provisioning production environments, this is perhaps something that should at least be partially centralized for various economic and security related reasons. The use of separate service teams for highly specialized, seldom used tasks such as modifications to a centralized SAP or mainframe system are perhaps genuinely legitimate use cases for such an approach.

The best tool to help manage this type of scaling where multiple teams are spread across one or more value streams is once again Kanban and its bigger brother, Enterprise Services Planning.

The third type of scaling is the one that the well-known frameworks have been developed for: Multi-team. This is when several teams have to work with each other simply because that much capacity is required. At the low end we have the multi-team, single-product approach, where the work involved in developing a single product is significant enough to require several teams to develop it. Scrum-of-scrums is not a framework but is the simplest approach that can be applied at the departmental level to provide an informal level of synchronization between teams. In most cases this is sufficient, especially if the product can be broken down into areas that allow teams to work reasonably autonomously. If a more formal structure is required, then the frameworks LeSS or Nexus could be applied, perhaps at a departmental level. However I think once we have reached the size where Scrum of Scrums is insufficient, and LeSS or Nexus is required, then we are likely to have reached the scale where at least multi-product support is required, which LeSS and Nexus unfortunately do not support. More useful at the departmental, business unit or even organizational level is the heavy duty SAFe framework. This covers most of the scenarios covered in this article, multi-team, multi-product, multi-value stream, the use of service oriented teams, and also includes mechanisms for supporting portfolio and program management. It is highly geared towards the development of software products though, is highly prescriptive, and may be difficult for an organization to adopt, particularly as it requires everyone to find some new role in the structure which can be culturally difficult, and for teams that have already become used to self-organization by starting with Scrum, the introduction of SAFe may feel like a top-down, command and control style imposition. A more flexible, general approach would be to make use of Lean Kanban and Enterprise Services Planning to integrate all parts of the value stream, without a particular emphasis on software development (thus being easier for those outside of software development to accept) within a comprehensive service delivery system based on visualization, limiting the size of queues, pulling work and implementing a series of targeted “Kaizen” style improvements exactly where they bring the most value without requiring a potentially disruptive upfront reorganization.