The Five Principles of Lean Management as the Basis of the Agile Manifesto

In order to under­stand agili­ty from a his­tor­i­cal per­spec­tive, it is impor­tant to go back to the prin­ci­ples of lean man­age­ment. Agili­ty in the sense of the Agile Man­i­festo from 2001 can there­by be seen as the appli­ca­tion of the five prin­ci­ples of Lean to soft­ware devel­op­ment. The focus of agili­ty is on the rapid deliv­ery of cus­tomer val­ue through work­ing soft­ware. And the opti­mal flow for this comes from an inter­dis­ci­pli­nary and self-orga­niz­ing team that cov­ers the com­plete val­ue stream from the idea to oper­at­ing the software.

Define Value

Lean man­age­ment always starts at the end. A first and very impor­tant step of lean think­ing is to rec­og­nize and define val­ue from the customer’s point of view. What does the cus­tomer real­ly need, what does he val­ue and what is he will­ing to pay for ultimately?

Don’t find cus­tomers for your prod­ucts, find prod­ucts for your customers.

Seth Godin

Agili­ty in the sense of the Man­i­festo for Agile Soft­ware Devel­op­ment like­wise focus­es on cus­tomer val­ue, but approach­es the ques­tion of the prop­er val­ue empir­i­cal­ly and less ana­lyt­i­cal­ly than this under­ly­ing lean prin­ci­ple sug­gests. Agile devel­op­ment means deliv­er­ing a usable prod­uct incre­ment at short inter­vals. Not only because it gen­er­ates val­ue soon­er, but also and espe­cial­ly in order to learn whether and how well the cus­tomer is sat­is­fied with it. Agile orga­ni­za­tions like Ama­zon or Spo­ti­fy are con­stant­ly try­ing out new ideas live on us, learn­ing step by step what their cus­tomers val­ue and what they do not val­ue and how their prod­ucts can be adapt­ed and improved. 

Map the Value Stream

Start­ing from the cus­tomer val­ue, this sec­ond prin­ci­ple focus­es on all process­es, activ­i­ties and inter­me­di­ate results to pro­duce this cus­tomer val­ue. The aim is to focus on val­ue-adding process­es and avoid unnec­es­sary effort (muda in Japan­ese, which has often been mis­tak­en­ly trans­lat­ed as waste).

The most dan­ger­ous kind of waste is the waste we do not recognize.

Shi­geo Shingo

Their search for the opti­mal val­ue stream for soft­ware devel­op­ment brought togeth­er the authors of the Agile Man­i­festo in Utah back in 2001. They felt that the increas­ing­ly heavy-weight­ed devel­op­ment mod­els for soft­ware, such as the Ratio­nal Uni­fied Process or the V‑Model, were (to put it mild­ly) not opti­mal­ly designed val­ue streams. This is pre­cise­ly why the man­i­festo focus­es more on work­ing soft­ware than on com­pre­hen­sive doc­u­men­ta­tion and puts indi­vid­u­als and inter­ac­tions above process­es and tools. 

Create Flow

Flow is the essen­tial design prin­ci­ple of Lean Man­age­ment. This refers to the con­tin­u­ous and smooth flow of pro­duc­tion along the val­ue stream. In many cas­es, this flow is inter­rupt­ed by orga­ni­za­tion­al bound­aries, which leads to local opti­miza­tion and unnec­es­sary effort in the form of inven­to­ries for inter­me­di­ate or final results.

All things flow, noth­ing abides.

Her­a­cli­tus

The authors of the Man­i­festo for Agile Soft­ware Devel­op­ment rec­og­nized that the opti­mal flow for soft­ware devel­op­ment is cre­at­ed by an inter­dis­ci­pli­nary and self-orga­niz­ing team that works close­ly with the cus­tomer through­out the entire val­ue stream, from the idea through pro­gram­ming to the oper­a­tion of the soft­ware with­out inter­rup­tions or han­dovers. Agile devel­op­ment is essen­tial­ly a con­tin­u­ous flow of prod­uct incre­ments with which the team explores the prob­lem area and the solu­tion space step by step.

Establish Pull

In the Lean Man­age­ment phi­los­o­phy, pro­duc­tion is trig­gered by the cus­tomer. The prod­ucts are “pulled” from the customer’s point of view through pro­duc­tion and not “pushed” through pro­duc­tion by means of plan­ning pro­duc­tion targets.

The more inven­to­ry a com­pa­ny has, the less like­ly they will have what they need.

Tai­ichi Ōno

Agile meth­ods and frame­works can­not deny their con­nec­tion to this pull prin­ci­ple. In Scrum, for exam­ple, the prod­uct own­er as the customer’s rep­re­sen­ta­tive deter­mines what is need­ed next. The devel­op­ment team then pulls as many ele­ments of the back­log as they can imple­ment in the next sprint in this par­tic­u­lar sequence. And with­in the sprint, work is han­dled in detail on a Kan­ban board, where the pull prin­ci­ple applies again and new tasks are only start­ed when oth­ers have been com­plet­ed: Start fin­ish­ing — stop start­ing.

Seek Perfection

In Lean Man­age­ment, all employ­ees are encour­aged to con­tin­u­ous­ly ques­tion process­es and work on their improve­ment. The log­ic behind this is obvi­ous and a clear depar­ture from the pre­dom­i­nant tay­lorist way of think­ing: Those who work in the process and not their man­agers know the process­es best and are there­fore the ones who can opti­mize them best.

Some­thing is wrong if work­ers do not look around each day, find things that are tedious or bor­ing, and then rewrite the pro­ce­dures. Even last month’s man­u­al should be out of date.

Tai­ichi Ōno

This prin­ci­ple also is to be found almost unchanged in the Man­i­festo for Agile Soft­ware Devel­op­ment: The self-orga­niz­ing team reflects at reg­u­lar inter­vals on how it can become more effec­tive and adapts its behav­ior accord­ing­ly. In Scrum, there is even a sep­a­rate event for this with the Sprint Ret­ro­spec­tive. What is true for the small team and its work is also true for agile orga­ni­za­tions on a large scale: stan­dards emerge from dai­ly coop­er­a­tion and are no longer cen­tral­ly defined and rolled out as a blue­print. But that’s noth­ing new either; Tai­ichi Ōno, the inven­tor of the Toy­ota Pro­duc­tion Sys­tem, already called exact­ly for this.

Stan­dards should not be forced down from above but rather set by the pro­duc­tion work­ers themselves.

Tai­ichi Ōno