In order to understand agility from a historical perspective, it is important to go back to the principles of lean management. Agility in the sense of the Agile Manifesto from 2001 can thereby be seen as the application of the five principles of Lean to software development. The focus of agility is on the rapid delivery of customer value through working software. And the optimal flow for this comes from an interdisciplinary and self-organizing team that covers the complete value stream from the idea to operating the software.
Lean management always starts at the end. A first and very important step of lean thinking is to recognize and define value from the customer’s point of view. What does the customer really need, what does he value and what is he willing to pay for ultimately?
Don’t find customers for your products, find products for your customers.Seth Godin
Agility in the sense of the Manifesto for Agile Software Development likewise focuses on customer value, but approaches the question of the proper value empirically and less analytically than this underlying lean principle suggests. Agile development means delivering a usable product increment at short intervals. Not only because it generates value sooner, but also and especially in order to learn whether and how well the customer is satisfied with it. Agile organizations like Amazon or Spotify are constantly trying out new ideas live on us, learning step by step what their customers value and what they do not value and how their products can be adapted and improved.
Map the Value Stream
Starting from the customer value, this second principle focuses on all processes, activities and intermediate results to produce this customer value. The aim is to focus on value-adding processes and avoid unnecessary effort (muda in Japanese, which has often been mistakenly translated as waste).
The most dangerous kind of waste is the waste we do not recognize.Shigeo Shingo
Their search for the optimal value stream for software development brought together the authors of the Agile Manifesto in Utah back in 2001. They felt that the increasingly heavy-weighted development models for software, such as the Rational Unified Process or the V‑Model, were (to put it mildly) not optimally designed value streams. This is precisely why the manifesto focuses more on working software than on comprehensive documentation and puts individuals and interactions above processes and tools.
Flow is the essential design principle of Lean Management. This refers to the continuous and smooth flow of production along the value stream. In many cases, this flow is interrupted by organizational boundaries, which leads to local optimization and unnecessary effort in the form of inventories for intermediate or final results.
All things flow, nothing abides.Heraclitus
The authors of the Manifesto for Agile Software Development recognized that the optimal flow for software development is created by an interdisciplinary and self-organizing team that works closely with the customer throughout the entire value stream, from the idea through programming to the operation of the software without interruptions or handovers. Agile development is essentially a continuous flow of product increments with which the team explores the problem area and the solution space step by step.
In the Lean Management philosophy, production is triggered by the customer. The products are “pulled” from the customer’s point of view through production and not “pushed” through production by means of planning production targets.
The more inventory a company has, the less likely they will have what they need.Taiichi Ōno
Agile methods and frameworks cannot deny their connection to this pull principle. In Scrum, for example, the product owner as the customer’s representative determines what is needed next. The development team then pulls as many elements of the backlog as they can implement in the next sprint in this particular sequence. And within the sprint, work is handled in detail on a Kanban board, where the pull principle applies again and new tasks are only started when others have been completed: Start finishing — stop starting.
In Lean Management, all employees are encouraged to continuously question processes and work on their improvement. The logic behind this is obvious and a clear departure from the predominant taylorist way of thinking: Those who work in the process and not their managers know the processes best and are therefore the ones who can optimize them best.
Something is wrong if workers do not look around each day, find things that are tedious or boring, and then rewrite the procedures. Even last month’s manual should be out of date.Taiichi Ōno
This principle also is to be found almost unchanged in the Manifesto for Agile Software Development: The self-organizing team reflects at regular intervals on how it can become more effective and adapts its behavior accordingly. In Scrum, there is even a separate event for this with the Sprint Retrospective. What is true for the small team and its work is also true for agile organizations on a large scale: standards emerge from daily cooperation and are no longer centrally defined and rolled out as a blueprint. But that’s nothing new either; Taiichi Ōno, the inventor of the Toyota Production System, already called exactly for this.
Standards should not be forced down from above but rather set by the production workers themselves.Taiichi Ōno
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?