Why agility is faster

Very often I hear the expectation that agile development equates to faster development. When initial experience is gained, stakeholders often find that development time is still about the same. An often-heard statement is that “at least we did not slow down, but the quality of the results and decisions increased.” In my view, that is already a nice (first) success. However, this also often depends on the starting position: If e.g. in the past projects were started with crazy or impossible schedules, you do not have to be surprised if these “still do not work despite agility”. Another common reason is the mostly unchanged surrounding organization of the agile team, so that the effects in the overall result are only slightly visible.

In this article, I want to share my experience of why, in my opinion, agility ultimately leads to higher speed. The aspects are:

  • Transparency and iterations allow changes of direction
  • shorter throughput times by focusing on highest added value (avoiding parallel work)
  • higher performance through higher motivation
  • less waiting for experts through team responsibility and knowledge sharing in the team
  • Avoiding unnecessary activities and unnecessary documentation (minimal process)
  • less rework through a self-determined work pace (Pull) with agreed quality (DoD)
  • less waiting for management decisions by empowered teams

In the following, I will discuss each aspect individually …

Transparency and iterations allow changes of direction

One important aspect is the agile principle of “Transparency, Inspection & Adaptation”. Only if we know where we stand and where we want to go can we meaningfully change direction. Otherwise, we might very efficiently go in the wrong direction, in line with the motto “We lost direction, but we are making good progress”.

Overall, the path C in the picture above is shorter and faster than the sum of A and B, even though the actual path over the iterations is slightly longer. (Pythagoras’ greeting)

Transparency enables improvements

The same applies to improvements in how the team works. While this does not directly increase speed, it does make sure that work practices and methods are constantly improved.

Shorter throughput times by focusing

Parallel work sometimes makes sense, e.g. when waiting for deliveries. Unnecessary parallel work, however, leads to less performance, due to frequent task switching, i.e. by the resumption of previously interrupted work. Much worse is that when we stop unfinished work, we delay it. If we do this with all the work, we simply delay all added value.

In the above example, the value added (wert) is achieved only after all four subtasks have been completed. By evenly distributing the capacity across all four projects, we delay all projects fourfold!
Value creation looks different when we focus and first finish one task:

This creates the earliest possible added value. This can ideally be the release of a first simple product version to make money early (example iPhone 1) and to learn early with the market (see “Lean Startup”). It may, however, be also be a risk mitigation measure, e.g. a feasibility study.

Higher performance through higher motivation

According to Jurgen Appelo (Management 3.0), the untapped potential of demotivated employees is an opportunity to increase performance by about 50%. To sustainably increase and maintain employee motivation, three key intrinsic motivators have emerged: Autonomy, Mastery, and Purpose. (Thank’s to Dan Pink)
Autonomy is achieved through self-organized teams, i.e. teams are allowed to work independently as far as possible. Teams and individuals have a bigger impact on their own working environment.
Mastery (in the sense of being good in a thing or improving a skill, not being the master of someone). An aspect realized in the classical world through specialization. In the agile world, skill refers to many aspects: special technical abilities, but also the ability to connect different things; as well as success that results from the synergy in teamwork.
Purpose: Every individual can see the impact of the team and how this is reflected in the corporate purpose and success. For specialists in classic organizations this is much more difficult (“Everyone is just a small wheel in the big gear”).

Less waiting for specialists through team responsibility and knowledge sharing in the team

A prospos specialists: If they work for many teams, they are often unavailable when needed. This is exacerbated by absenteeism, vacations or illness – so we wait. Wouldn’t it be much better to have someone in the interdisciplinary team who may not be THE specialist, but who can also do the job. The side effect is that the knowledge of the specialist spreads and thus he is no longer so critical regarding his availability. The responsibility and the expertise is then in the team and no longer with individuals.

Avoidance of unnecessary activities and unnecessary documentation

Assuming that agile teams are self-organized, it makes sense to give them as much control over their work processes as possible. This means that processes for the entire organization should only describe an absolute minimum to ensure collaboration between teams and departments. I like to use the term “Minimum Viable Process” for that case.
This empowers teams to eliminate unnecessary activities in their working environment, and to create only the documentation and reports needed and used. In the sense of  “lean” this is eliminating waste and saves time and effort.

Less rework through a self-determined pace of work with agreed quality

If the responsibility lies within the team and not with the boss or with the specialists, the speed of work can also be determined by the team. This has many advantages: The team normally knows best who and how something should be done. By combining transparency and removed external pressure, work can be completed “well enough”. Pressure leads to the fact that the work is completed as quickly as possible and thus possibly limits the necessary care (“hot potato approach”). This results in rework, which in total requires more time and effort. The so-called Definition-of-Done in combination with the Acceptance Criteria define when a work product is “good enough”. These criteria must be followed by all team members with discipline.
In particular, if the work of others is based on the results of the team or if e.g. building prototypes, the “hot potato approach” generates huge losses in terms of time and money.

Less waiting for management decisions by empowered teams

In traditional organizations, projects and employees often wait for higher-level decisions (20% of decisions in the team, 80% in management). Even if they do not wait and work on assumptions, this often leads to huge rework. In the agile world, we counteract these effects by clearly delegating responsibility to the implementing teams with guiding principles (80% of team decisions, 20% management). This has several positive effects:

  • Short decision-making and (in most cases) better decisions.
  • Higher motivation of team members
  • Relief of the management. Managers can take care of the far-reaching decision and exceptions


If agility does not just happen at the team level and the aspects mentioned in the article are fulfilled, not only better work results will be achieved after a few iterations, but also faster.

Leave a Reply