Spotify, Google and many other companies owe their success to the way they adopted the “agile” methodology. They continuously improve their agile working method and adapt it to company growth. Especially Spotify published its agile approach and anyone interested can read about how its agile framework works. Frameworks like SCRUM, SAFE or LeSS have a really good level of maturity, they only focus on other aspects. SCRUM focusses on a single team, SAFE on an enterprise. All these frameworks are developed in a different environment.
As with any use of framework, the success of its application depends on the way it is adapted to the specific environment.
This article highlights some observations that will enable you to improve the implementation of “agile” in your company.
Weaknesses in Implementation
Of course, many mistakes can be made when implementing agile frameworks. Table 1 shows an exemplary list of frequently occurring errors without any claim to completeness.
But there are structural impediments as well:
In our economy, which is based on the division of labor, it is often the case that several companies supply parts of a product within a supply chain. The motivation for such supply chains often lies in the attempt to achieve cost transparency or to shift risks to specialized companies. If you try to squeeze the entire supply chain into an agile team, the only remaining contract form is ‘Time & Material’, since you cannot bindingly define or guarantee any product properties. However, this transfers the production risk back to the client and cost transparency is no longer a given. In well-established customer-supplier relationships, it is often the case that work contracts are retained, despite agile working methods. In this case, however, the client runs the risk of numerous change requests, which often results in significant cost increases.
To prevent such effects, the company’s boundaries must be considered when defining agile teams. Unless the client can live well with a ‘time & material’ contract and its consequences.
Another obstacle is the agile transformation of companies, which is a process and cannot be achieved via a big-bang scenario. As many agile teams repeatedly encounter non-agile teams, whose deliverables they depend on, but often are not received in the time required. This makes it almost impossible to prioritize requirements with the greatest value to the customer or the greatest risk.
Factors that Influence Agile Implementation
The degree to which these implementation weaknesses are manifested is different in every company. Let’s look at the factors affecting agile adoption:
Figure 1 shows that the implementation of agility in companies can look different depending on the various factors and their individual weighting.
An organization that has previously championed the waterfall model and placed a great deal of emphasis on formalities will define the first implementation step of an agile organization quite differently than an organization where collaborative work is already established throughout the company and employees are given much freedom for decisions-making.
Nevertheless, both can become successful agile companies, if they can successfully instill agile thinking in the workforce and management. After all, an agile company is in principle not a stable state. An agile company permanently adapts to changes in the market and optimizes itself. To ensure that this happens intrinsically, “retrospective meetings” are of particular importance. Here, critical points are brought to the table and each team changes the approach, communication, or tool.
Courageous teams will take bigger steps than, for example, teams in companies where mistakes are treated as a defect.
Agility – a Low-Hanging Fruit?
There are many well-developed agile frameworks such as SCRUM, SAFE and others. There are also enough experienced external consultants or employees available, who have already gained experience with agile procedures in other companies. One might think that switching to business agility is therefore easily achievable. But is it enough to simply introduce SCRUM and avoid the mistakes mentioned above? Will everything be fine? No!
This is because agile frameworks, while very good, only cover the process level.
A company’s business agility depends on three levels: the strategy of the business, the processes, and the IT systems.
If one of these levels is unable to keep up with the pace of the others, it slows down the entire company.
If the business strategy does not put the customer at the center of the action, the introduction of agility may lead to improvements at the process level, so that designers work better with the engineers. However, you still do not know the customer’s expectations and therefore cannot meet them. Negative examples of technological progress without benefit to the customer are, for example, the small gaps in car production or laptops that fit into envelopes. A positive example from the B2B market of a product that offers added value to the customer is the cloud solution. Here the solution is readily available, and the customer is not forced to set up his own operating unit. The customer can tangibly feel the added value from using the product.
When it comes to IT systems, we have to say goodbye to monolithic solutions, which we have grown fond of, and which are extremely mature in terms of functionality. Many teams have adapted these solutions to the extent that they, too, are able to put a release into production every month. However, this hardly shortens implementation times. Monolithic solutions have numerous dependencies and therefore a need for high test coverage. On the one hand, this ties up important resources to execute testing, or test coverage is reduced to meet the deadline. Both options carry a high risk for achieving business agility.
Converting these IT systems, however, presents many companies with major challenges. Generally, such a rebuild is expensive and oftentimes does not offer the business any new functions. The intermediate states can also lead to additional manual work for the business. To achieve business agility, however, this transformation of IT systems is necessary.
Unequivocally, the introduction of business agility is a multi-faceted program that involves notable effort and therefore requires appropriate management attention.
Agile Employees – Stable Management?
What does it look like when agile teams start their work?
Agile teams organize themselves. The iterative approach points to the fact that projects and their content cannot be clearly defined at an early stage. Due to this, some companies have concluded that middle management is no longer needed. In my opinion, this is an exaggeration of the agile idea, causing more harm than good to the company. Agile teams pursue the goal of providing an optimal product for the customer. However, companies usually don’t have just one team, so it can lead to the situation where, for example, one team only provides face-to-face customer contact, while the other only provides self-service. The company will perceive this inconsistent appearance as negative.
Self-sufficient teams, who look for their work tools on the free market constitute another example. Without management, this leads to the purchase of many different tools for the same task, thus increasing the company’s fixed costs.
So, without management, it doesn’t really work.
Management in an agile company is different from management today. An agile company carries change in its DNA: teams optimize themselves, markets change, new markets are to be developed.
In agile companies, management defines the principles and characteristics the company wants to live by or achieve. A manager should also set himself the goal of coaching his employees, emphasizing the value of soft skills. After all, collaboration requires proper interaction! Agile teams, therefore, need guidelines and frameworks to organize themselves and focus on their goal.
Even an agile company cannot do without control mechanisms to ensure compliance with these specifications.
In order to support the agility of teams, these mechanisms must, of course, be adapted to the team’s agile way of working. This aspect, too, must be solved by each company individually in a way that fits the individual situation. As the agile maturity level increases, the control mechanisms must also be adapted again and again.
Summary
When considering American tech companies, such as Google, Spotify, Facebook, etc., it is apparent that the “time-to-market” factor has becoming increasingly important when introducing new business models, because the first provider occupies most of the market – ideally, almost the entire market. Successors and imitators hardly have a chance to conquer large market segments. For companies to be the first to occupy new markets, the adoption of agile is critical.
Standardized solutions that fit every company and deliver at the same success rate everywhere do not exist.
The challenge to any agile initiative is to find one’s own solution for the specific situation at hand and to match the maturity level of the organization. And the intermediate states that are achieved as part of the process, require the appropriate management attention, because they are often fraught with shortcomings and weaknesses and must be supported by the employees. Merely the introduction of SCRUM (or other agile frameworks) to implement business agility is not sufficient, because the strategy of the business unit and the architecture of the IT systems also play an important role. The first implementation step of agile must fit the business. The rest of the journey requires well-articulated principles, a specified target state, guardrails, and meaningful governance. If you manage to move your initiative into this direction, the answer to the question posed at the beginning of this article will increasingly be:
“Yes, agile is the way to go!”
