Agile working is no longer a foreign word in the modern working world. But it is often not at all clear when and why agile working makes sense at all.

The birth of agility

Before we look at the "when", let's first take a look at the beginning of the agility movement: Agility has been around in the systems theory of organizations since the 1950s. At the beginning of the 1990s, about three waves of the agility movement started:

1. Agile Manufacturing
   In agile manufacturing, the focus was, among other things, on rapid product development, multifunctional teams and optimization of production processes. This was primarily in the area of engineering.
    
2. Agile software development
   Since the beginning of the 21st century, agility was predominantly found in software development. Especially with methods like Scrum, agility gained attention here. In the course of this, the so-called agile manifesto of software development was created. This postulated guidelines for working in an agile manner.
    
3. The agile organization
   Meanwhile, the megatrend of agility is making its way into entire organizations. Instead of focusing agility on just one area, it is much more a matter of getting the entire company on course for "agile". The agile transformation is intended to meet the challenges of the new working world.
   

Agile transformation in companies meets the challenges of the modern working world

VUCA lays the foundation for agile working

When it comes to the challenges of the modern working world, there is no getting around the term VUCA.

VUCA stands as an acronym for:

• Volatility
• Uncertainty
• Complexity
• Ambiguity

VUCA describes in one word the environmental conditions and challenges we face in today's markets. The world is constantly changing, becoming more unstable, and unpredictable changes are happening - ever more drastically and rapidly (volatility). This makes long-term planning and investment almost impossible (uncertainty).  Problems become more complex and demands on organizations are not only black and white, but also colorful (complexity and ambiguity). 

Now, of course, the question arises: What is the best way to work in such a world? And what different work models or approaches to work are there anyway? 

Classic (project) work style vs. agile work style

Prinzipiell kann man zwischen zwei Arbeitsstilen unterscheiden: Klassische Projektarbeit und agile Projektarbeit:

• Classic project work

This is a linear process model. Often the individual project phases are separated from milestones and at the beginning the result as well as costs, deadlines and personnel requirements are determined. Changes should be avoided as far as possible, as this often results in a lot of costs.

• Agile project work

In comparison, agile project work focuses on iterative-incremental work. The goal is to have a product increment completed in each iteration. In addition, agile work is based on teamwork, feedback, and continuous process improvement.

Based on the topic described above regarding dynamic environments with frequent changes in requirements (VUCA), it seems to be advantageous to work with short planning cycles in the sense of agile procedures. In contrast to this, classic project work is often attributed with employees acting and, above all, thinking in silos, i.e., separately from one another. This is what agile project work aims to break down.

With agile project work, you are well positioned for the "VUCA world".

Even though it may seem difficult to apply agile working to every project or task, in agile project work there are various frameworks that can help. In addition, it makes sense to differentiate according to the task type in order to check which approach fits best. not every agile method fits every task. However, blanket distinctions along the lines of "but agile makes no sense for us in production" miss the point.

Differentiation of the type of task

Statements such as: "Agile working is easier to implement in the IT sector. After all, a new version can be created at any time." Nevertheless, you often have to take a closer look. It helps to distinguish between different types of tasks:

1. Control tasks
   Control tasks are tasks that occur with high repetition rate and sameness.
   
2. Project work
   Project work describes tasks in project development that do not occur with high frequency and are rather heterogeneous.

In general, there are different requirements for tasks. An agile format is not suitable for all of them. For example, agile work does not initially make sense for regular tasks. However, the Scrum framework, for example, is suitable for project work. For larger project scopes, in which several units must be brought under one hat, there are, for example, agile scaling frameworks such as SAFe or LeSS.

Complex vs. complicated tasks

Eine weitere Unterteilung, die hilft herauszufinden welche Vorgehensweise wann sinnvoll ist, ist die Unterscheidung zwischen komplizierten und komplexen Aufgaben:

• Complicated tasks can be solved with knowledge. For example, unknown variables, but which can be calculated, also count as complicated tasks. Complicated tasks can be planned and controlled because they can be solved with sufficient time and practice. Thus, complicated tasks are suitable for a classical approach.
• Something is always complex when many unknown variables or tasks with changing influencing variables come together. The development of completely new solutions (software, process, etc.) is more complex. Requirements can change again quickly in the course of development and the project plan that was once drawn up becomes outdated again. This is where an agile approach is suitable.

Before the start of the project, an intensive analysis makes sense in order to choose the right process model.

Which approach is right for you?

It is crucial that processes and methods are effective and successful when the process model fits the initial situation. Before the start of the project, it is therefore important that you deal with which requirements exist and with which knowledge and under which conditions solutions can be developed. The respective mindset of the company and the employees should also be considered and plays a major role. Finally, the mindset has a great influence on the way of working. We are happy to help you find the right way for you.

Conclusion

Both classic and agile approaches have their peculiarities and advantages. If requirements, resources and times are known and sufficiently defined, classic project management methods can lead to the desired result. However, if the requirements for a project are characterized by frequent changes, short planning horizons and a high proportion of research, the advantages of agile methods clearly outweigh them.