Agility as an antidote to unpredictability Over 20 years after the agile manifesto

1 year ago

By now, most people have heard the apparent buzzword "agile" or consider it "one of those trends of which you won't hear anything for long". In fact, agile was published in the form of the Agile Manifesto already in 2001 and therefore laid the foundation for a new approach about 20 years ago - not only to projects, but also to daily work, collaboration in teams up to complete agile enterprises. And agility is not only becoming increasingly important, it is often already part of everyday life.
Many who think they already know something about the agile approach probably associate it at first with a project management method, as an alternative to the classic waterfall method. Scrum immediately comes to mind. But agile is much more and is, by the way, not just a synonym for the Scrum framework.

Where does agility have its roots and wat exactly is behind it? Where is the added value in this approach? And why is agility more relevant than ever today, about two decades after the publication of the agile manifesto?

The origins

Until the 1980s, IT projects and especially projects in software development were often associated with failure. In quite a few cases, it turned out during the development of software or even after its completion that customer requirements and/or the surrounding conditions were changing - regardless of the planning or agreements. The classic waterfall project management method was hardly able to keep up with the constantly developing environment and especially with technological innovations. In extreme cases, software to be developed had partially lost its expected added value between project start and planned end or was already outdated before completion. Unfortunately, there were almost no alternatives to the waterfall and technological progress was still gaining up speed. How to deal with this frustrating situation?

Not surprisingly, some software developers recognized the need for change. The discussion focused on the following key points:

• The need to ensure good communication throughout the project in all directions - meaning within the team as well as towards the customer.
• The need to have small and manageable sub-projects in order to make the whole project more manageable.
• The need to respond more quickly to changing customer needs or changing environmental factors.
• The achievement of tangible results in a shorter period of time, in order to get back faster at least a part of the investment and/or to reduce the commercial risk.

However, these agile approaches did not reach a broad mass until the publication of the agile manifesto in 2001. Although agility took its start in software development, nowadays it can be found in many industries and is at least partially applicable in most areas.

„Driving at sight“

But why is agility seemingly so important right these days? Many experts agree:

"Business developments [are] becoming less and less predictable and accordingly less plannable [...]. Therefore, management and/or leadership approaches that have been successful in the past, based on detailed analysis and long-term planning, need to be rethought. First, such a dynamic environment requires a more flexible approach and faster (re)action. In the digital age, managers often have to 'juggle' with multiple options and have to 'drive on sight'." (Thorsten Petry)

"Lifelong learning and rapid response are becoming increasingly important. Willingness to change and the skills to deal with complexity and with uncertainty are the competencies where the need for action is highest." (Joachim Volpert and Volker Mayer)

"Changes [as a result of Industry 4.0 and Work 4.0] are putting pressure on companies to question themselves. Currently, this is particularly evident during the COVID 19 pandemic. In addition, it is suspected that a change in the direction of agility is needed in order to survive as a company [...]." (Stephan Fischer and André Häusling)

The expert quotes above refer to the so-called "VUCA world" in which we have arrived as a society. (The acronym VUCA stands for Volatility, Uncertainty, Complexity and Ambiguity and originally describes unpredictable conditions in conflict zones that bring with them unknown conditions).

In relation to business, VUCA describes an environment in which globalization is challenged in many cases, as processes, requirements, and procedures in cooperation with business partners and service providers have accelerated considerably due to the global interconnection of economic and trade flows, including production methods and supply chains, and have increased in complexity and, at the same time, in uncertainty and volatility. Intensive global competition, rapidly changing sales markets and changing customer requirements as well as disruptive upheavals go hand in hand with this. (after Kai-Nils Eicke and Bodo Kirf)

As already indicated in one of the quotes, many experts also agree here that an ongoing change in companies towards agility is the right solution in order to be able to survive in the VUCA world - in fact, it is virtually unavoidable.

Since change seems to be the only steady feature in life, the VUCA world is already being questioned. In the current, more chaotic world, BANI offers itself as a suitable successor. We will address the BANI model in a separate post.

In the IT project environment, it is evident that an agile approach leads to successful project completion much more frequently than the classic waterfall approach. This is also clearly proven by the CHAOS study or CHAOS Report of the Standish Group, which has been published regularly since 2014 and deals with the success and failure drivers in IT projects:

So, it can be said that agile projects are twice as likely to be successful and less than half as likely to fail as waterfall projects. The figures from the latest CHAOS Report from 2020 confirm this, as the values have not changed much:

The best approach?

But, to avoid any misunderstanding, what has been said so far should not be taken in a way that there is a bad approach and a better approach in general. If there is the question of what is the best approach, the answer, as with so many things in life, is: "It depends." Of course, each approach has its advantages and none is free of disadvantages. This can be contrasted with reference to project management in the following table:

When choosing the project management approach that tends to be more suitable, it depends therefore on the general conditions of the project. Many factors play a role here. Starting with the experience of those involved, through the time dimension to the clarity of the requirements and the solution approach. To make it more difficult, there is not only the classic waterfall and "the one" agile approach. There are about 30 methods that interpret agility differently and have different focuses at different levels of the corporate hierarchy. In addition, there are various so-called hybrid methods.
A good starting point for finding the most suitable approach is the so-called Stacey Matrix, named after the British professor of management Ralph Douglas Stacey. It illustrates the relationship between the clarity of the requirements or goals of the project, with the knowledge of the solution approach to implement these requirements:

To a certain level it can be simplified to say: the more unclear the stakeholders are about what the goal is, or exactly what the result should look like, and the more innovative the solution method is, the more reasons support the choice of an agile approach.

The world is upside down!

The consequence of the "agilization" of project management demands a fundamentally different approach. While in classic project management, there should be clear specifications as early as possible (ideally delivered by the customer) regarding the deliverable in order to be able to determine the necessary effort and the associated costs. In agile project management, the world seems to be upside down. Because the goal or result and the requirements for it are not absolutely clear at the beginning, other parameters such as the available time must first be defined.

With an agreed amount of time and/or an available budget, an effort is then made to reach a first approximation of a possible goal in a period of time which is clearly defined with the customer. (This period of time is called iteration). Once an initial solution is ready for use, feedback is requested from the stakeholders and especially from the customer. This feedback is essential. It decides how and also whether to proceed with a next iteration. This cyclical approach, including requirements analysis, design, implementation, testing, etc. - as it is also known from classic project management - is repeated until a final result satisfying the customer is achieved, or as long as the customer wishes. Therefore, the complete project process is not planned in advance, since the circumstances would not allow for it. Instead, you get many smaller complete project life cycles for individual parts (called increments) of the - at the beginning still - unknown "big picture".

This does not mean, as it is often feared, that you always start from scratch; rather, the product grows into a final product with each iteration. This approach can be illustrated as follows:

What is Agile?

But what actually is agility? The very short answer is: An attitude!
First and foremost, agile is a matter of attitude or a way of understanding the world, a "worldview" - for short: a mindset. An agile mindset supports the agile work environment. These include, for example, the following understandings:

• Collegial and trustful cooperation
• Mutual respect
  • The colleague is recognized as a human being
• Cycles of improvement and willingness to learn
• The ability to adapt to change
  • Flexibility is taken for granted
• Being proud of autonomous work done
• Focussing on the creation of value
  • Responsibility is taken and mutual trust exists

This mindset is necessary to create and support high-performing teams, which want to create added value for the customer with motivation for themselves. The focus here is on "wanting", as forcing a mindset will always create resistance in case of doubt, and it is just achieved the opposite.
Without "being agile", meaning without the right (agile) attitude, agile working does not make sense, because the agile behaviors and ways of working, meaning "doing agile", are derived from it, as illustrated here:

To make this more comprehensible, the Agile Manifesto expresses this mindset in just 4 agile values as well as 12 added agile principles.
Namely, these are the four following agile values and they can be understood as follows:

> Individuals and interactions over processes and tools

   Each human has his expertise, so why force him or her to do things a specific way and
   so limiting his or her ability to perform?

> Executable software over comprehensive documentation

   The customer wants a result at the end of the day or project, not a documentation!
   (But this does not mean that documentation should be ignored completely.)

> Customer collaboration over contract negotiation

   Why discuss contract details for hours if we are not sure that we can satisfy the customer? And customer requirements can change all the time!

> Responding to change over following a plan

   Why continue to follow the plan if it is not in line with reality anymore?

The Agile Manifesto is enhanced by 12 principles, which are not discussed in detail here, but which must be considered, and not only in relation to software development projects, if you wish to continue studying the topic of agility.

If project teams and other stakeholders have understood - better internalized - the agile mindset, consider the 4 agile values as well as 12 principles of the manifesto and implement - even better believe - them, collaboration and efficiency will improve by its own in most cases, as the typical reasons for project failure are often automatically slowed down, such as lack of transparency in the team or for the customer. This does not require the exact implementation of a complete agile approach such as Scrum. Working with an agile coach has proven to be much more helpful as a first step.

The introduction of so-called agile practices, such as a "daily standup", a regular review or providing a kanban board as an overview of the project status, whether analog or digital, often already offer great benefits for those involved and should be a step anyway before fully introducing an agile method, as indicated in the graphic before.

If you would like to know more about agility or if you see a case where an agile approach could be useful, please do not hesitate to contact us via: info@novamusHR01.com

Author: René Sittel-Wenige, Business Consultant