Agile scaling and the challenges that come with it

Nowadays, it is hard to imagine software development without Scrum as the agile framework. Many companies understand that changes have to be made within their own organisations if they wish to take action to accommodate the new ways in which we work. They have made it their goal to deliver products to their customers with greater efficiency through agile development, employing different frameworks depending on their size, which we would like to present here.

Scrum, which is the best-known framework, promises to pave the way to agility if used correctly. In our view, however, Scrum has become a commonly used buzzword, even though the approach and the consequences that come with it are not adequately understood. In addition, this does not even take into account that Scrum was originally conceived of as a framework that is optimally tailored to an explicit team. Nowadays, products are generally so large and complex that several teams are frequently needed, all of which can use the agile framework and the methods it offers to make sustained improvements to the products provided to customers or users.

Agile scaling is the term we use to describe the organisation of these interdisciplinary agile teams in terms of their structures, interfaces and conventions. The approach brings significant changes with it.

A number of well-described frameworks, methods and best practices are now also available for agile scaling. Determining if one of them is a good match for your organisation and the employees involved based on the given situation is often a project in and of itself. That is because agile scaling requires that agile principles be applied from top to bottom at every department, which in turn creates enormous challenges. In our experience, every system, when it comes to scaling or whether you are talking about a person, a team or an entire organisation, is unique. They each have their own needs and processes, which is why we have not yet found one method that we can recommend in all cases. We often recommend a combination of best practices and parts of established frameworks or methods from the agile world, which generate added values on their own when used in combination. Before we get started, we speak with as many people who are part of the system as possible. The primary goal is to hear the ideas and views of management, whose main focus is typically on the viability of their products.

However, we will be taking a closer look at the requirements and the challenges when it comes to agile scaling that need to be overcome to get a majority of a company’s staff on board.

Agile scaling frameworks at a glance

Jeff Sutherland, one of the creators of Scrum, recognised the challenges at organisations early on and expanded the Scrum framework to include the Scrum of Scrums. This led to the emergence of further agile frameworks and methodologies, which became established steadily over time, to provide highly customised solutions for a wide range of organisations and more precisely scale their roadmaps. They are as follows:

Scrum@Scale: The aim of the meta-level framework created by Jeff Sutherland is to scale Scrum at larger organisations. It consists of a Scrum Master Cycle and the Product Owner Cycle, for which there are predefined questions. The ‘standard’ Scrum is adapted based on the answers given to them.

Scaled Agile Framework® (SAFe®): The Scaled Agile Framework is a knowledge base that contains proven, integrated principles, practices and competencies for achieving business agility via lean, agile and DevOps. SAFe is a reliable approach to agile scaling that includes planning at various organisational levels. It uses the Agile Release Train (ART) to coordinate teams of up to 125 during the planning, development, implementation and approval phases.

Disciplined Agile (DA): Disciplined Agile is a framework developed by Scott Ambler that is mainly concerned with decision-making processes. It is based on the four principles of people first, a focus on learning, agility and hybridity. Decisions have to be made in order to achieve a clear level of quality later on. DA does not specify the outcome of the decisions. What it does do is aggregate all the decisions in a targeted way in order to effectively perform scaling.

Large-Scale Scrum (LeSS): As the name suggests, the LeSS framework developed by Craig Larman and Bas Vodde is dedicated to the basic concept of being as simple and compact as possible for application on a large scale. You could also say that LeSS simply poses the question as to what else needs to be added to Scrum to make working with multiple teams run smoothly.

The importance of agile scaling

An agile approach within an organisation is typically based on Scrum and therefore on the Agile Manifesto as well. They are built on the values of individuals and interactions, collaboration with customers, responding to change and functional products. Therefore, agile scaling as defined in SAFe works on the assumption that Scrum can be carried over to larger units consisting of five to 11 members per group.

However, in order to be able to develop products effectively and efficiently and establish them successfully and correctly in the company, agile scaling should take into account several factors. We will only touch upon these briefly at this time due the limited space available. Key terms in this context include the role of the user, the product owner, release definition, team size, specialisation, iteration length and so forth.

The question of competences

Once we have a product owner, for example, we can start thinking about the implementation teams. The product owner takes the user’s and/or technical view and applies it to the product.

If necessary, there are also architects in the company who are tasked with consolidating the technical developments within the company in a targeted manner, keeping them up to date and generating innovation. We would also be happy to include them in discussions on the competences needed for the implementation team.

In addition to architects, employees who are both experienced and interested from a professional and technical perspective can of course also contribute to discussions on the optimum composition of the team. Generally speaking, we try not to involve managers at this point, as the first step is not yet about specific individual employees.

The question of capacities

Once we have the basic competences in place, the question of capacities arises. As we know from Scrum, the potential performance of a team with much more than nine members declines rapidly. Therefore, we recommend that you consider setting up several teams. There is much less overhead for coordination between small, efficient teams than for coordination within a team that is too large.

Once we have decided to employ several teams, we need to distribute the competences between the teams in such a way that each of them is able, in the best case, to work and approve releases independently and on their own responsibility to the greatest extent possible within their sprint.

Experience shows that there are in many cases staff members with special roles within organisations. We need some of expertise they have in different teams, though we cannot have one for every team. In cases like this we recommend allowing this person to move between teams while always making the transfer of knowledge one of their tasks. In this way, the teams can tackle specific issues that are smaller and less complex on their own and at their own pace without being reliant on this employee, thus increasing their ability to work autonomously.

Composition of the teams

Once we have put the competences and capacities for the teams down on paper and the product owner has been assigned their duties, there are now a number of ways to staff the teams from the pool of employees in the organisation.

Last but not least, we recommend that you strongly consider the personality of the people you wish to assign to teams when selecting key members. At the end of the day, it is of no use to us if the expertise we need is in theory available in the team, but we cannot make use of it because interpersonal conflict gets in the way.

One popular method is self-organisation. As a general rule, the end result is generally a consensus that ensures that all the teams are satisfied with the make-up of their teams in the long term. At this point, we recommend holding a large event with the employees who are available. To set the tone, we suggest that the product owner prepare a product presentation, focusing on the added value for the potential user in order to optimally motivate employees to generate this value.

The process of assigning staff to teams can be extended or shortened depending on the number of teams that need to be set up. Colleagues in the organisation who are compassionate and understanding could be useful as a contact and a person to turn to for advice.

Which brings us to the Scrum Masters, Kanban Masters and Team Coaches (depending on the team framework). However, titles do not matter here, since the mission is always the same, namely to promote and continuously improve the effectiveness of the team. To keep it simple, we will only discuss the Scrum Master as we proceed.

Selecting a Scrum Master who would work best for the team can also be done in the workshop, since it is necessary to ensure that all team members more or less get along. If there are no trained Scrum Masters in the pool of employees yet, you will need to urgently consider building up these skills. These can be brought in from outside the company, or there may be employees in the pool who are actively looking to retrain and take on this role.

Work plan

Before a team, or in this case an entire system, can begin to work productively on tasks relating to the product, it is necessary to first define a structure for the overall system both within each team and in relation to overall coordination between the teams. This ultimately depends on the framework being used and poses a number of challenges. We will explain this in greater detail in the next blog post on this topic.

You can find more exciting topics from the adesso world in our blog posts published so far.