From start-ups to large corporations, agile procedural models have become an established feature in software and product development. The reason for this is that classic phase and milestone-based project management methods are reaching their limits in software and product development. Large corporations in particular which, just like start-ups, have to bring products to market within considerably shorter cycles, are struggling with laborious and formal processes. The need to transform their (IT) organization into an agile system poses a particular challenge for them.
How do companies react to this challenge? By setting up accelerators, innovation labs, agile islands or garages in which highly-qualified and motivated members of staff can apply agile procedures such as design thinking in the field of innovation and Scrum, Kanban or other iterative approaches in software and product development in an excellent environment. However, when it comes to implementing complicated products or projects involving teams of often several hundred developers, designers, testers or UX specialists, large traditional organizations with small team-focused implementation approaches are reaching their limits. That is why many companies are now looking for approaches and frameworks for scaling methods that work effectively on a team level. Agile thinking and action – quick decentralized decisions, continuous customer feedback, uncomplicated governance – are the foundation of these approaches. These, however, are diametrically opposed to the classic management image, a stumbling block at which companies fail time and time again. Companies try to create supposed security in more complex projects using elaborate control mechanisms and guidelines.
Overview of the most important agile scaling approaches
The range of agile scaling approaches for companies consists of a few established models. The most important agile frameworks on the market are:
• Scaled Agile Frameworks (SAFe) for the agile scaling of extensive organizational structures
• Enterprise Scrums from the Scrum Alliance – organization-wide scrum procedural approaches
• Nexus by Scrum.org for up to nine Scrum teams which form such a Nexus and a team of product owners and other integration roles
• Large-scale Scrum (LeSS) for coordinating several Scrum teams
Using agile scaling approaches properly
Selecting the right agile scaling approach is one thing, using these adequately and appropriately is another. From the perspective of Q_PERIOR, agile software and product development with up to three Scrum teams can be effectively mapped with two-part sprint planning. The procedure would then appear as follows:
• Sprint planning 1: Cross-team
• Sprint planning 2: each team combined with scrum of scrums as with a LeSS. Nexus uses this two-part sprint planning too.
Where more than three teams are involved, the Scaled Agile Framework (SAFe) is the most holistic organizational model for scrum teams. This is developed on the basis of the SAFe set-up, which binds the team level with a coordinating and synchronizing program level. All roles from the scrum team as well as planning, feedback and review principles are scaled on this next highest overall product level.
The program level installs the following roles: Chief scrum master, chief product owner, system architects, permanent specialist requester, feedback giver and decision-maker. This program level therefore works, like the teams, with an overall product backlog. It estimates and prioritizes – on program level, features instead of user stories – and develops the product roadmap on a continual basis. Sprint scaling takes the form of SAFe, in contrast to other frameworks, providing for a joint scheduling of all teams in an agile program organization (referred to as an agile release train). The joint scheduling takes place every five sprints (approx. 10-12 weeks). This planning horizon can often be very well mapped in larger organizations and harmonized on the next highest portfolio level with quarterly portfolio prioritization.
The scaling options for agile approaches have their limits too
An agile organization created using a SAFe means a certain restriction in creativity and implementation for individual scrum teams in relation to technology, architecture and development. There’s no denying this aspect, often put forward as a key criticism. But, essentially, this is the exact degree of governance and coordination that large product development organizations require. In essence, it comes down to making decisions and organizing labor wholly in line with agile values and principles and understanding and establishing this “agile release train” as an agile team consisting of several small agile teams. Represented schematically, a SAFe-oriented agile organization thus represents the binding force around scrum teams, closing any gaps left open by the scrum guide and often trying to find “self-made” solutions for companies.
Figure 2: Generic Q_PERIOR version of a SAFe adaption in a customer organization
Joint scheduling of all teams, no non-transparent decisions and quick feedback right up to the top of the organization ensure the shortest possible development cycles even when it comes to complex products or system implementations. It prevents outdated requirements in specifications from extended preliminary studies and the “hidden assumptions” that are often discovered too late in classic management set-ups. One key characteristic specific to SAFe is the description of value streams which are budgeted on portfolio level. The agile organization is formed across sectors and beyond existing organizational silos with a view to uniting the entire value creation process organizationally. This represents a significant paradigm change, ensuring the necessary agility on the scaling level above the scrum team, which is almost always the decisive factor in failed agile transformations. SAFe no longer talks about projects, but assigns topics on portfolio level to these fixed agile organizational parts (agile release trains). The result is that many overheads and time which would otherwise be necessary for project pre-planning, applications and formalism are saved and the productivity gains impact directly on value creation. In more and more companies we are seeing agile scaling succeed where methods, roles and frameworks are not dogmatically prescribed, but rather the development of an agile organization in line with a realistic transformation roadmap. Another factor critical to success is the intensive involvement and accompaniment of all those involved as well as a management set-up that itself lives by agile principles and creates corresponding framework conditions. Only then can an agile organization be successfully established on eye-level with the scrum teams.
Q_PERIOR has in-depth experience of agile transformation projects – whether using SAFe or other approaches. This experience permanently feeds into our transformation approach. Our SAFe team of certified agile transformation experts supervise the ongoing development of all frameworks and would be happy to be of assistance to you in your transformation project.