Die fünf Prinzipien des Lean Managements als Grundlage des agilen Manifests

Um Agi­li­tät his­to­risch rich­tig ein­ord­nen zu kön­nen, muss man bis zu den Prin­zi­pi­en des Lean Manage­ments zurück­zu­ge­hen. Agi­li­tät im Sin­ne des agi­len Mani­fests von 2001 kann so als Anwen­dung der fünf Lean Prin­zi­pi­en auf Soft­ware­ent­wick­lung ver­stan­den wer­den. Der Fokus von Agi­li­tät liegt auf der schnel­len Lie­fe­rung von Kun­den­wert durch funk­tio­nie­ren­de Soft­ware. Und der opti­ma­le Fluss dafür ent­steht im inter­dis­zi­pli­nä­ren selbst­or­ga­ni­sier­ten Team, das den kom­plet­ten Wert­strom von der Idee bis zum Betrieb der Soft­ware abdeckt.

Kundenwert definieren

Lean Manage­ment beginnt immer am Ende. Ein ers­ter und sehr wich­ti­ger Schritt aller Lean Über­le­gun­gen ist es, den Wert aus Sicht des Kun­den zu erken­nen und zu defi­nie­ren. Was braucht der Kun­de wirk­lich, was schätzt er und wofür ist er am Ende bereit zu bezahlen?

Don’t find cus­to­mers for your pro­ducts, find pro­ducts for your customers.

Seth Godin

Agi­li­tät im Sin­ne des Mani­fests für agi­le Soft­ware­ent­wick­lung stellt den Kun­den­nut­zen eben­falls ins Zen­trum, nähert sich der Fra­ge nach dem rich­ti­gen Nut­zen aber empi­risch und weni­ger ana­ly­tisch als es die­ses zugrun­de lie­gen­de Lean-Prin­zip sug­ge­riert. Agi­le Ent­wick­lung heißt in kur­zen Abstän­den ein benutz­ba­res Pro­duktin­kre­ment zu lie­fern. Nicht nur, weil das auch schnel­ler einen Nut­zen erzeugt, son­dern auch und gera­de, um dadurch zu ler­nen, ob und wie gut der Kun­de damit zufrie­den ist. Agil arbei­ten­de Orga­ni­sa­tio­nen wie Ama­zon oder Spo­ti­fy pro­bie­ren stän­dig neue Ideen live an uns aus und ler­nen dadurch Schritt für Schritt was ihre Kun­den schät­zen und was nicht und wie sie ihr Pro­dukt anpas­sen und ver­bes­sern könnten. 

Wertstrom identifizieren

Aus­ge­hend vom Kun­den­wert fokus­siert die­ses zwei­te Prin­zip auf alle Pro­zes­se, Akti­vi­tä­ten und Zwi­schen­er­geb­nis­se zur Her­stel­lung des Kun­den­werts. Ziel ist es dabei, sich auf die wert­schöp­fen­den Pro­zes­se zu kon­zen­trie­ren und unnö­ti­gen Auf­wand (Muda im Japa­ni­schen, was fälsch­li­cher­wei­se oft mit Ver­schwen­dung über­setzt wur­de) zu vermeiden. 

The most dan­ge­rous kind of was­te is the was­te we do not recognize.

Shi­geo Shingo

Die­se Suche nach dem opti­ma­len Wert­strom für Soft­ware­ent­wick­lung hat die Autoren des Mani­fests im Jahr 2001 in Utah zusam­men­ge­bracht. Sie emp­fan­den die damals immer schwer­ge­wich­ti­ger wer­den­den Ent­wick­lungs­mo­del­le für Soft­ware wie bei­spiels­wei­se den Ratio­nal Uni­fied Pro­cess oder das V‑Modell als (vor­sich­tig aus­ge­drückt) nicht opti­mal gestal­te­te Wert­strö­me. Genau dar­um legt das Mani­fest so den Fokus auf funk­tio­nie­ren­de Soft­ware mehr als auf umfas­sen­de Doku­men­ta­ti­on und stellt Indi­vi­du­en und Inter­ak­tio­nen über Pro­zes­se und Werkzeuge.

Fluss optimieren

Das Fluss-Prin­zip ist es wesent­li­ches Gestal­tungs­prin­zip des Lean Manage­ments. Gemeint ist damit der kon­ti­nu­ier­li­che und geglät­te­te Ablauf der Pro­duk­ti­on ent­lang des Wert­stroms. In vie­len Fäl­len ist die­ser Fluss näm­lich durch Gren­zen in der Orga­ni­sa­ti­on unter­bro­chen, was zu loka­ler Opti­mie­rung und unnö­ti­gem Auf­wand in Form von Lagern für Zwi­schen- oder End­ergeb­nis­se führt.

Alles fließt, nichts bleibt.

Hera­klit

Die Erkennt­nis der Autoren des Mani­fests für agi­le Soft­ware­ent­wick­lung war es, dass der opti­ma­le Fluss für Soft­ware­ent­wick­lung durch ein inter­dis­zi­pli­när besetz­tes und selbst­or­ga­ni­sier­tes Team ent­steht, das über den gesam­ten Wert­strom von der Idee über die Pro­gram­mie­rung bis zum Betrieb der Soft­ware ohne Unter­bre­chun­gen und Über­ga­ben eng mit dem Kun­den zusam­men­ar­bei­tet. Agi­le Ent­wick­lung ist im Kern ein kon­ti­nu­ier­li­cher Fluss von Pro­duktin­kre­men­ten mit denen das Team Schritt für Schritt das Pro­blem­feld und den Lösungs­raum exploriert.

Pull-Prinzip umsetzen

In der Lean Manage­ment Phi­lo­so­phie wird die Pro­duk­ti­on vom Kun­den aus ange­sto­ßen. Die Pro­duk­te wer­den vom Kun­den aus gese­hen durch die Pro­duk­ti­on „gezo­gen“ (pull) und nicht mit­tels Pla­nungs­vor­ga­ben und Pro­duk­ti­ons­zie­len durch die Pro­duk­ti­on „gedrückt“ (push).

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

Taiichi Ōno

Agi­le Metho­den und Rah­men­wer­ke kön­nen ihre Ver­bin­dung zum Pull-Prin­zip gar nicht ver­leug­nen. In Scrum bei­spiels­wei­se legt der Pro­duct-Owner als Reprä­sen­tant des Kun­den fest, was als nächs­tes gebraucht wird. Das Ent­wick­lungs­team zieht sich dann in die­ser Rei­hen­fol­ge so vie­le Ele­men­te des Back­logs wie es im nächs­ten Sprint umset­zen kann. Und inner­halb des Sprints wird im Detail auf einem Kan­ban-Board gear­bei­tet, wo auch wie­der das Pull-Prin­zip gilt und neue Auf­ga­ben erst nach­ge­zo­gen wer­den wenn ande­re abge­schlos­sen sind: Start finis­hing – stop star­ting.

Kontinuierlich verbessern

Im Lean Manage­ment sind alle Mit­ar­bei­ter auf­ge­for­dert kon­ti­nu­ier­lich Abläu­fe zu hin­ter­fra­gen und an ihrer Ver­bes­se­rung zu arbei­ten. Die Logik dahin­ter ist ein­leuch­tend und eine deut­li­che Abkehr von der vor­herr­schen­den tay­lo­ris­ti­schen Denk­wei­se: Die­je­ni­gen die im Pro­zess arbei­ten und nicht ihre Mana­ger, ken­nen die Abläu­fe am bes­ten und sind folg­lich die­je­ni­gen die sie am bes­ten opti­mie­ren können.

Some­thing is wrong if workers do not look around each day, find things that are tedious or boring, and then rewri­te the pro­ce­du­res. Even last month’s manu­al should be out of date.

Taiichi Ōno

Auch die­ses Prin­zip fin­det sich im Mani­fest für agi­le Soft­ware­ent­wick­lung fast unver­än­dert wie­der. Dort heißt es in den Prin­zi­pi­en, dass das selbst­or­ga­ni­sier­te Team In regel­mä­ßi­gen Abstän­den reflek­tiert, wie es effek­ti­ver wer­den kann und sein Ver­hal­ten ent­spre­chend anpasst. Im Scrum gibt es mit der Sprint-Retro­spek­ti­ve sogar ein eige­nes Event dafür. Was klei­nen für das Team und sei­ne Arbeit gilt, trifft auf agi­le Orga­ni­sa­tio­nen auch im gro­ßen zu: Stan­dards ent­ste­hen dort emer­gent aus der Zusam­men­ar­beit und wer­den nicht mehr als Blau­pau­se zen­tral erdacht und aus­ge­rollt. Aber eigent­lich ist auch das nichts Neu­es, son­dern fin­det sich schon bei Taiichi Ōno, dem Erfin­der des Toyo­ta Produktionssystems. 

Stan­dards should not be for­ced down from abo­ve but rather set by the pro­duc­tion workers themselves.

Taiichi Ōno

Unterstützen

In mei­ne Arti­kel zu Lea­ders­hip, Agi­le und vie­lem mehr flie­ßen seit 2010 viel Arbeit und Lei­den­schaft. Mein Blog ist und bleibt frei von Wer­bung, aber Kos­ten ent­ste­hen dafür natür­lich trotz­dem. Wenn Dir mei­ne Arbeit mehr wert ist als ein Like, kannst du mich dabei unter­stüt­zen via Ko-fi.

Teile diesen Beitrag

5 Kommentare

Hal­lo Marcus,
wie­der­ein­mal eine tol­le Zusammenfassung.
Jeff Suther­land beschreibt die Geschich­te hin­ter Scrum im Buch „Scrum: The Art of Doing Twice the Work in Half the Time“ sehr schön und zeigt auch den Zusam­men­hang zum Lean Manage­ment. Beim Lean Manage­ment geht es häu­fig um die gesam­te Ket­te zum Ein­bau von vor­han­de­nen Bau­tei­len. Auf die­ser Abs­trak­ti­ons­ebe­ne geht es bei Scrum um den „Ein­bau“ von Anfor­de­run­gen. Was aus mei­ner Erfah­rung hier­bei häu­fig über­se­hen wird ist, dass Anfor­de­run­gen, die einer Defi­ni­ti­on of Rea­dy genü­gen, erst „pro­du­ziert“ wer­den müs­sen. Die­se sehr krea­ti­ve Vor­gang ist nicht Teil von Scrum und der Auf­wand wird häu­fig unter­schätzt. Ohne kla­re Anfor­de­run­gen ist aber kei­ne gute Pla­nung und schluss­end­lich auch kein Com­mit­ment möglich.

Hal­lo Kai, dan­ke für dei­nen Kom­men­tar. Ich ken­ne die Ana­lo­gie bei Jeff Suther­land und hal­te sie für gefähr­lich. Sie sug­ge­riert näm­lich eine Tren­nung zwi­schen Spe­zi­fi­ka­ti­on und Pro­duk­ti­on im Sin­ne von „Ein­bau“. Im Ide­al­fall will ich den Wert­strom zwi­schen Idee und Umset­zung nicht haben, son­dern sehe das alles beim Ent­wick­ler­team. Die Ent­wick­ler müs­sen die Sto­ries ver­ste­hen und dazu hilft es unge­mein, wenn sie selbst eng mit dem Kun­den zusam­men die­se aus­ar­bei­ten. Ich will kein Rea­dy-Team, das Sto­ries für ein Done-Team vorbereitet.

Hal­lo Mar­kus, schön gesagt. Im Mit­el­stand mit sehr begrenz­ter Per­so­nal­ka­pa­zi­tät wird ist das aber schwie­rig. Bei rein SW implem­tier­ten Ver­fah­ren stim­me ich voll und ganz zu. Im Anla­gen- und Maschi­nen­bau sieht das aber ein wenig anders aus. Klar gibt es auch Teams die inter­dis­zi­pli­när arbei­ten, aber die Arbeit ist zeit­lich sehr weit gestreckt. So fin­det das Sys­tem­sen­gi­nee­ring meist im Vor­pro­jekt noch ohne Auf­trag statt und wenn dann nach 1 Jahr oder mehr der Auf­trag kommt, dann gibt es beim Stahl­bau eigent­lich nur einen ein­zi­gen Sprint, der aber mehe­re Mona­te dau­ert. Inkre­men­te funk­tio­nie­ren hier nur sehr begrenzt. Kon­struk­ti­ons- und SW-Inge­nieu­re arbei­ten sehr stark zeit­ver­setzt, was den Team­ge­dan­ken nicht gera­de stärkt. Wäh­rend sich der Kon­struk­teur voll auf das Pro­jekt C kon­zen­triert, arbei­tet der SW-Inge­nieur noch am Pro­jekt A und hat sich mit C nur am Ran­de befasst. Eine Pro­duk­ti­ons­anlge, noch dazu mit vie­len ver­schie­de­nen Gewerk­len ist sehr schwer in Inkre­men­ten her­zu­stel­len. DA kommt dann auch einer bestimm­ten Ebe­ne doch wie­der das unge­lieb­te V‑Modell zum Ein­satz. Aber auch dort ist Agi­li­tät gefragt, denn ich habe in mei­ner Jahr­zehn­te lan­gen Pra­xis noch kei­ne Anla­ge gese­hen, die so gebaut wur­de, wie zum Zeit­punkt des Ange­bo­tes vorgesehen.

Hal­lo Mark, sehe ich genau­so. Die Zyklen sind in Hard­ware natür­lich län­ger. Was zählt ist aber die Grund­hal­tung, dass ein inter­dis­zi­pli­nä­res Team in Zyklen mit­tels Feed­back die rich­ti­ge Lösung erar­bei­tet. Fin­det sich übri­gens auch so im ers­ten Arti­kel in dem die Par­al­le­le von Scrum als Spiel­zug im Rug­by zu Pro­dukt­ent­wick­lungs­teams gezo­gen wur­de: The New New Pro­duct Deve­lo­p­ment Game Und die unter­such­ten Teams hat­ten alle einen Schwer­punkt in Hard­ware (immer­hin war das 1986!): 

FX-3500 medi­um-sized copier (intro­du­ced by Fuji-Xerox in 1978)
PC-10 per­so­nal-use copier (Canon, 1982)
City car with 1200 cc engi­ne (Hon­da, 1981)
PC 8000 per­so­nal com­pu­ter (NEC, 1979)
AE‑1 sin­gle-lens reflex came­ra (Canon, 1976)
Auto Boy, known as the Sure Shot in the United Sta­tes, lens shut­ter came­ra, (Canon, 1979)

Guter Punkt. Wie kann Agi­le im „nor­ma­len“ Leben gelebt wer­den, abseits der sepa­ra­ten, eli­tä­ren Neu­pro­jek­te in den „Coversto­ries“?

Schreibe einen Kommentar