Is Agility always the answer?

implementation of agile frameworks and methods such as Scrum or Kanban, but also the basic understanding and corporate culture. But how can a company that has worked successfully with stable processes in the past build a bridge to agility?

The most important principle here is that projects are different and unique. For this reason, we classify development projects into four different classes. Two basic questions are used to classify them: Is agility necessary in the project?

Do the product and the environment of the development project make an agile approach absolutely necessary? The answer to this question is influenced by the complexity and degree of innovation of the product. Furthermore, the necessity of agility differs in the type of product, for example the software or hardware portion or the degree of customer involvement. The complexity of the development project itself, i.e. team sizes, the current phase of the project, external partners or the stability of the processes also provide information.

The second question for classifying a project is: Is agility feasible? Here, the focus is on the organization’s environment and its enablers of agility. What competencies do the organization’s employees possess? Does the management level see itself as a servant leader? What personnel capacities does the project have? In addition, there are evaluations of the organizational structure and culture: Is a culture of error practiced? How do the communication channels work in this project?

Does the organization have experience in agile collaboration? Through these two central questions, many development projects can be placed into one of the following four classifications: Classic – we also call this type the “Dolphin”, Selective Agile – the “Cheetah”, Agile Practitioners – the “Nandu”, Full Agile – the “Swift”. Why we name these types this way?

Does the organization have experience in agile collaboration? Through these two central questions, many development projects can be placed into one of the following four classifications: Classic – we also call this type the “Dolphin”, Selective Agile – the “Cheetah”, Agile Practitioners – the “Nandu”, Full Agile – the “Swift”. Why we name these types this way?

THE DOLPHIN
Dolphins learn continuously and have an excellent memory. Even after twenty years, they recognize their companions by their individual name whistle. Dolphins are “always on”, one half of the brain is always awake. They live in large groups (“dolphin schools”).

Other characteristics: Dolphins are masters of orientation, characterized by their loyal and social nature and a strong bond with leadership.

THE CHEETAH
When hunting, the cheetah can reach speeds of over 90 km/h and with these sprints is the most efficient single hunter in the animal kingdom. It uses its power specifically and always with pinpoint accuracy for critical phases.

The cheetah also has the ability to move through its territory agile and responsive.

THE NANDU
The nandu is one of the fastest animals in the world. Nandus live with their conspecifics in smaller groups, but occasionally join herds of other animal species (e.g. antelopes or zebras). In theory, they do not need to drink; their fluid requirements can be met almost exclusively through food. These characteristics make it an equally fast and flexible, as well as a vigilant and persistent animal.

THE SWIFT
About 10 months of the year the swift spends non-stop in the air, flying even while sleeping and feeding. The birds fly in groups from Europe to southern Africa. In doing so, they adapt their route to the corresponding weather conditions in order to find as much food as possible along the way and, if possible, to be exposed to heavy rain for only a short time. In the large groups, it becomes clear that the swift is a team player. Always focused and adaptable, it covers long distances with great endurance.

The cheetah and the nandu are the answer to a fundamental problem: In many projects, two worlds – the classic world and the agile world – have to be combined.

Classic approaches and Agile approaches – like fire and ice?

In project environments where classical and agile approaches meet and have to work hand in hand as much as possible, the difficulty of synchronizing between agile deliverables in time with sprints with a classical milestone plan arises.So the synchronization points of these two parties have to be found out and actively managed. One variation: the waterfall team “dictates” through the planned milestones and the agile team delivers “into” this dictated plan. The alternative: ideally, it becomes possible to create a common cadence between these teams. If it is not possible for the classically working team to achieve the duration of a sprint in their work, then it may still make sense to agree on a higher-level, common cadence, possibly many times the cadence of the agile team (e.g., 2 weeks cadence SW team and 4 weeks HW team).

Another problem: In hybrid or selective teams, their members are usually only proportionally employed in the project. The 100% dedication to this development project is therefore missing. In this case, it can be helpful to define a core team that is 100 percent fully employed in this project and to grow proportional team members around this core team. However, expectation management should be adjusted in projects like these. A team where not all members are 100 percent engaged will not be able to deliver the same results.

If a mode is reached where a co-existence of classical work and agile work within the same development project is managed through appropriate synchronization points, successful results can definitely be achieved with this composition! The two ways of working should therefore be understood less as opposites than as different approaches to different problems, which in common can also be a means for specific problems.

Are we on the road to Agility?

Due to the developments described above, many companies are striving to evolve into a fully agile organization. However, this change is not a single lever that can be flipped from one moment to the next, but requires a long-lasting transformation that involves not only the top-down introduction of agile frameworks, but in particular bottom-up developments in the culture and self-image of the organization and its employees. So are we now on the road to agile? In the long view, yes! But, in the words of Keynes, “In the long run, we’re all dead.”

Granted, the statement may seem harsh. Nevertheless, especially in fast-moving environments like the VUCA world, the medium-term view applies more! So, in this medium-term view, in many organizations today, we are on a journey from old, proven processes to agility as a response to the VUCA world. For this reason, we recommend becoming aware of this fact, developing an individual working model for the specific deployment, and once this has been found and tested, scaling the “own framework”. In this way, a suitable procedure for the co-existence of the two streams of classic and agile work is applied, this co-existence is actively and consciously managed, and a convergence of these two approaches is achieved in the long term.

Conclusion

This blog post has shown: Often it’s not about classic or agile. It’s not about black or white, and it’s not about wanting to “introduce” agility everywhere by hook or by crook. Rather, it is about classic and agile. It is about finding individual solutions for situations in which co-existence of the two supposed countercurrents is the right approach.

Especially due to the fact that the change towards agility takes time, it is particularly important to deal with co-existence in the short or medium term. Further, it is also about not getting fundamentally stuck on agility as a solution to every problem. Do agile approaches help me at all with my problem? Are these agile approaches even applicable in my individual situation? Once a model has developed with the co-existence of classically and agilely working teams, an effect usually sets in that resembles a black hole: Classically working teams circle around the high-performing agile working teams and benefit from their results and experiences.

We as P3 support companies as a competent partner on this path of transformation with special consideration of the individuality of each organization. Because no framework and no method is an omnipotent solution for every problem. Our experience always helps us to support companies not only in becoming agile in the long run, but also in successfully steering the way there with hybrid and selective approaches.