Pitfalls and solutions for agile transformation

Agile development – a miracle cure?

More and more companies are responding to the challenges of tomorrow – to move faster and deliver added value to customers – by turning their development teams into “agile” teams. All too often, however, this does not lead to the expected success, quite the contrary: It even leads to frustration and resignations among developers.

As part of a series of articles on agile methods, we will today take a closer look at the challenges that many companies face in agile transformation.

Agile is attractive

There is much to be said for the agile approach: new features reach the customer faster, the  product quality increases and the overall efficiency of the employees improves. Logically, many companies want to achieve these advantages and therefore strive for “agile transformation”. 

Unfortunately, these desired effects only become effective if the transformation is successful. In a large part of the attempts, however, it fails. Many companies simply try to apply agile practices without having understood the underlying principles.

The most difficult part: Adapting corporate structures

Most companies that want to take advantage of the benefits of agile development are classically organized: strict hierarchies, the boundaries between departments are precisely defined and, thanks to clearly separated budgets, silo mentality prevails. Nobody would think of doing something for another department without an order and a budget, and if a project does cross departmental boundaries, it is handed over at the border – often with a considerable loss of information. In a large software project, the first problems occur at the latest during prioritization, even if all the teams involved are agile – due to customer needs, it may map and implement entire business processes in an integrated manner, but due to the underlying corporate structure alone, it is divided into three separate areas and therefore operates with three different budgets. Last but not least, it may also be based on three different product visions.

If one department alone now dares to make the change, this environment is of course poison for all agile procedures. Anyone who has ever experienced a Water-SCRUM case knows how gruelling it can be for the agile team to constantly crash against the ” bulkhead walls”.

In order to actually successfully introduce agile procedures in an established, classically positioned company, one must therefore take a difficult and often painful step: the change of corporate culture throughout the entire company. Yet which cultural aspects promise to increase the chances of success of agile transformation?

The scrum values

All those who want to switch to agile methods in their team or department should definitely take a look at the scrum values and decide whether these values have a chance of being adhered to – by management, as well as, by developers. If developers are expected to implement specifications accurately without wasting time with contradictions and discussions, then you will probably not have much success with the conversion. Constant intervention by management and complex controlling are not compatible with agile philosophies either.

An open, respectful working environment

We are in a fictitious hospital. More precisely, a neonatal intensive care unit. Here, all premature babies are observed and, if necessary, treated until it is certain that there is no longer a health risk. Especially the lungs are endangered here because this organ is the last to fully mature. A doctor and a nurse go around together to check on the newborn babies. The nurse notices that twins have not been given the usual medication to promote lung maturity. Before she can draw the doctor’s attention to this, however, she remembers that this same doctor yesterday loudly rebuked one of her colleagues. She does not know why, but perhaps it was a “stupid” question? When she finally wants to say something to the doctor after a short hesitation, he has already left the room…

Everyone has certainly been in a similar situation at some time or another. This oppressive feeling of contradicting superiors or pointing out a mistake often leads to silence. It does not always have to lead to life-threatening situations but lost opportunities can also have bitter consequences. How could the situation have ended if the nurse had felt confident that there were no negative consequences to fear?

The nurse might have helped to provide the twins with life-saving medicine. It might even have led to the introduction of a checklist or protocol to prevent such omissions in the future. Or the doctor could have explained to the nurse why this medicine is not appropriate in this particular case, and she would have learned something valuable.

This concept of “psychological safety” is widely regarded as the fundamental basis on which the pillars of agile values are built. In a future article, we will go into more detail about the consequences of the feeling of lack of safety and will also use some examples to learn about methods that have been used to successfully introduce the concept into the existing corporate culture.

Source: Amy Edmondson – The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth

Leader-leader or leader-follower?

Every person in leadership, a management or team leadership role also contributes significantly to the success of the agile transition. In the impressive success story of David Marquet (Turn the Ship Around! A True Story of Turning Followers Into Leaders), a former captain of a U.S. submarine tells how an unplanned command assignment got him into big problems because the type of submarine was different from the one Captain Marquet had been preparing for for a year. Nevertheless, the ship’s crew managed to work their way up from the derided last place of the US Navy ship performance ratings to the historic highest rating. The presented approach sounds very simple and can be summarized in a few sentences, however, its consistent implementation is not easy, as one has to act against trained behaviour patterns and instincts. Yet, if you manage to do it, it will result in a huge performance boost for the whole team. David Marquet said that his submarine was superior to all the others because in each case, even with an otherwise superior opponent, one captain had to steer 134 sailors. Only on his submarine did all 135 crew members tackle every problem together as quickly as possible.

The principle is based on the “empowerment” of the team. The team leader changes from the detailed arrangement of activities to questions that actively require the team members to think and decide for themselves, and in the final stage sometimes only to take note of the decisions and actions of the team members. Of course, in order not to fall into total chaos, a basic requirement is mandatory: the team must not only have the technical competence to solve a task but also to grasp the overall task above it. It must know the vision or the goal and coordinate with the rest of the team. In Turn the Ship Around, for example, a mechanic is given as an example of this, who – in order to be able to decide whether noisy maintenance of an engine is possible on board – must know whether a crawl speed is imminent or whether the noise is not relevant in the next few hours. Applied to software development, this means that the team must not only know the primary functionality of a newly developed feature but also have a rough overview of the entire context in which the customer is using the feature.

Fast reasoning and the influence of language

Daniel Kahneman’s Thinking, fast and slow is often referred to in literature, as in David Marquet’s new book Leadership is Language.  Kahneman introduces the concept that there are two basic thought paths in our brain: the fast one, which allows us to recall similar situations from our experiences and thus to efficiently find a solution to acutely occurring events without lengthy deliberation. On the other hand, the slow one, which includes active thinking, reasoning, analysis and planning. It is obvious that the fast path was a great success factor for the survival of the human species.

Even in the early days of the industrial revolution, the fast track was strongly emphasized: Workers were in demand for their manual work, and the step from craftsmanship to assembly line work made it possible to make workers productive even without long training. Since thinking was deliberately undesirable, productivity could be increased precisely by increasing psychological pressure (at least according to Frederick Winslow Taylor’s 1911 book, The Principles of Scientific Management).

In today’s working world, especially in the IT industry, this old way of thinking is poison: Many studies show that creativity and the ability to find solutions suffer greatly from such pressure. In Leadership is Language, special attention is given to the small changes in the choice of words that can help managers make the transition to slow thinking sustainable.

…should one dare undertake the transformation?

After this brief foray into the topics that we believe are at the heart of a successful agile approach, the question then arises: “Is it worth the effort?”

We clearly say yes – if the company is really willing to move away from the traditional, multi-layered hierarchies and strict departmental thinking. A half-hearted implementation, perhaps only in one part of the company, leads to frustration in the workforce and the departure of the most experienced employees.

However, if the agile way of thinking is lived consistently, this will not only increase employee satisfaction and the associated attractiveness on the job market but also efficiency, quality and customer satisfaction. In this way, the open-minded companies overtake those competitors who did not dare to take the step.

#Cloudflight

Need support on your way of transforming your business to agile? We offer remote workshops on agile and scrum methods.

Menu