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­dukt­in­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­dukt­in­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.

Tai­i­chi Ō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 start­ing.

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 bor­ing, and then rewri­te the pro­ce­du­res. Even last mon­th’s manu­al should be out of date.

Tai­i­chi Ō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 Tai­i­chi Ōno, dem Erfin­der des Toyo­ta Produktionssystems. 

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

Tai­i­chi Ōno

Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

5 Kommentare

Hal­lo Marcus,
wie­der­ein­mal eine tol­le Zusammenfassung.
Jeff Sut­her­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 Sut­her­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 copi­er (intro­du­ced by Fuji-Xerox in 1978)
PC-10 per­so­nal-use copi­er (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