Currently, many organizations are in the process of introducing agile methods such as SCRUM outside of classic software development. However, many agile transformations are not as successful as companies would like.
The hype is unbroken
Success stories of digitization, such as Facebook, Salesforce, Google, Airbnb and Uber, which go hand in hand with agile methods, encourage imitation. From IT came business models that have shaken up many traditional industries. Airbnb has unsettled hotel chains with an application, Uber the cab industry, and Google’s applications are so broad that many industries are directly or indirectly affected by them. These new business models are based on digital applications and social networks.
There are many studies that have compared traditional and agile approaches and demonstrate the superiority of the agile approach. Many are adamant about the path taken, less so about the destination. Friedrich Nietzsche
Agile project management methods are lean
Scrum can be explained in its basic features in a few words. The Scrum Guide, the bible of Scrum, comprises just 17 pages including cover page, table of contents and acknowledgements. Despite the simplicity of the method, the introduction of agility presents companies with major challenges.
The Implementation
Successful implementation of Scrum requires teams to self-organize and regularly deliver their products to customers at short intervals, taking their feedback into account. Self-organization enables employees to contribute their respective strengths in an optimal way. The productivity of the team is not hindered by control from outside or above. Micromanagement limits the productivity of the team and leads to overload for managers. Managers are usually the limiting factor in micromanagement. The team’s performance depends on their availability and ability to deploy and monitor people appropriately. Task control is better distributed across the broad shoulders of a multi-member team. In addition to self-organization, a key success factor of Scrum is frequent feedback with the customer. The short feedback cycles ensure that the products have value for the customer.
Introducing self-organization and frequent feedback loops is challenging because you change core processes, structures and values of organizations. Let’s look at the challenges in detail below. Before embarking on an agile transformation, one should anticipate potential problems. In this list, I do not claim to list the problems completely. The problems described are mutually dependent, so the listing is artificial to a certain extent and only serves to make it easier to read. Also, the points are not ordered by severity and show a more or less arbitrary arrangement.
Motivation of employees
Employees often have reservations about changes to their organization. This can be based on a number of different fears, some of which may be justified, others unjustified. Employees fear they could lose advantages they have acquired and encounter new problems. Tasks might await them that they do not feel up to. New knowledge is demanded of them and they feel overwhelmed.
Employees may view the changes with suspicion, suspecting that they are restructuring measures whose necessity they do not recognize. If team structures also change, it becomes even more difficult to gain the acceptance of employees. Employees may lose colleagues they have grown fond of and find themselves in a new team to which they first have to get used. Employees who have to fear losing privileges they once gained are hardly likely to be won over to the change.
The acceptance of agile role models is often also made more difficult by the fact that no career model is recognizable in the agile context. In order to make the roles attractive in the long term, organizations must develop a professional career model without using classic hierarchies.
Outside of software development
For non-software teams, the uncertainty faced by employees is disproportionately greater. While in the software area many companies have successfully introduced agility and can serve as a model, in the non-software area it is unclear what a successful implementation might look like. In each case, it must be worked out how Scrum can be transferred from software development to other areas, such as marketing, sales or personnel management. We are embarking on a journey with an uncertain outcome, which is not necessarily conducive to the motivation of individual employees.
Agile transformation demands a lot from the individual employees, since the way of working, the understanding of roles and the team composition are changed.
Dealing with the “new” openness
Self-organization relies on openness. The team defines how it wants to implement the demands placed on it. Each team member contributes to the process. There is no manager who defines, assigns and monitors tasks. Instead, the team defines the tasks itself and ensures that they are completed in the right order, quality and quantity. For this to happen, the communication within the team must be right. The individual team members must be willing to openly exchange information about their activities. Everyone must know what the others are working on, where they have problems and what they have already completed. The entire team must have an overview of the status quo of the project, which was previously reserved for the controlling manager. To make activities transparent, Scrum teams use task boards. Within an agile organization, these boards can be used by every employee. In IT projects, it is also common to make work results such as software code, architectures and models available to all employees in the organization.
This openness is not common in our traditional team structures. Employees are reluctant to reveal to their colleagues what they are working on every day, where their problems lie, and what they completed yesterday. Colleagues can usually estimate quite accurately how difficult and time-consuming the respective tasks of their teammates are. There is also unspoken jockeying for tasks. Talking openly about tasks within a team is therefore not a matter of course for the time being and needs to be practiced. Things that were previously swept under the rug become transparent for everyone: It quickly becomes apparent on the task board that employees need different amounts of time for the same or similar tasks. The handling of unpopular topics is revealed. It becomes clear that the same employees are always doing annoying tasks, while others pick out the “cherry”.
This openness can cause major problems for a non-software team. If the bonus system rewards individual performance, as is common in sales, you can’t expect employees to share information openly. This would put their bonus payments at risk. In this case, the bonus systems must first be adapted and team performance must be rewarded. However, it goes without saying that even the introduction of a new bonus system can meet with considerable resistance.
Many companies want to establish agile methods like SCRUM outside of classic software development. But how does this step succeed?