RISIKOMANAGEMENT MIT KANBAN: RISIKEN SICHTBAR MACHEN UND IM TEAM ANGEHEN Quellen erkennen, denen man die nahelie- genden Unsicherheiten zuordnen kann: ■ der Markt ■ die Nachfrage ■ die Fähigkeiten der Entwicklungsorga- nisation Mit Kanban (vgl. [And10]) versucht man, diese Unsicherheitsquellen als Informations- quellen zu betrachten, aus denen man Risikoprofile ableitet. Ein Risikoprofil ist wie ein Steckbrief, der beschreibt, wie „gefähr- lich“ etwas ist, an dem man arbeitet. Jedes Stück Arbeit, das mit Kanban verfolgt wird, untersucht man daraufhin, zu welchem Risikoprofil es gehört. Mit Hilfe dieses Wissens stellen die Entwicklungsteams ihr Verhalten ein und managen damit das Risiko. Doch eins nach dem anderen. Zunächst sollen die drei Quellen der Unsicherheit näher untersucht werden, später sehen wir, wie Kanban dabei helfen kann, die Risiken daraus zu managen. Den Markt verstehen Bevor man ein IT-Vorhaben startet und sich bemüht, es richtig zu machen, sollte man sich fragen, ob man das richtige Vorhaben startet und welcher Art das gestartete Vorhaben eigentlich ist. In wohlbekannten Märkten (z. B. wenn man als Dienstleister das x-te Mal für Banken, Versicherungen oder Telekom- Unternehmen entwickelt) kann sich die Entwicklungsorganisation darauf konzen- trieren, aus dem Geld des Kunden für die- sen ein Maximum an Geschäftswert her- auszuholen. Die Priorisierung der zu entwickelnden Features kann danach erfol- gen, wie viel Wert für den Kunden entsteht, wenn man dieses Feature entwickelt. Bei Risikomanagement ist wichtig – das weiß jeder, der in einem IT-Vorhaben gearbeitet hat. Doch so manche Risikoliste veraltet einsam auf der Festplatte eines Servers, ohne dass ein Mitglied der Entwicklungsorganisation hineinschaut. Mit Kanban kann das anders werden. Risiken sind nicht mehr getrennt von der Arbeit, sondern werden als Bestandteil der Arbeit gesehen und verfolgt. Entwicklungsteams und Management teilen sich diese Aufgabe – die Entwickler haben die Informationen, die Manager geben Entscheidungsrichtlinien. Gemeinsam können Risiken so schneller berücksichtigt und behandelt werden. mehr zum thema: www.mbohlen.de 34 35 logische Innovation, Zusammenspiel der Akteure mit dem System usw. In Management-Frameworks – wie z. B. COBIT, Risk IT und VAL IT – werden die Themen „IT-Governance“, „IT-Risiko- management“, „Compliance“ und „IT- Sicherheit“ immer mehr als eine Einheit gesehen (vgl. [Isa12]). Risikomanagement wird sehr breit angelegt, um möglichst alle Risiken eines IT-Vorhabens strukturiert zu erfassen und zu bewerten sowie Steu- erungsmaßnahmen herbeizuführen und diese wiederum zu bewerten. Ich möchte bewusst nicht so weit gehen, alle Risiken eines Vorhabens managen zu wollen. Lange Risikolisten – eingeteilt in mehr als zehn Kategorien, jeweils mit Eintrittswahrscheinlichkeit und Auswir- kung, abgelegt in einem Tabellenkalkula- tionswerkzeug, weit weg vom Entwick- lungsgeschehen – darin steckt nach meiner Meinung bereits wieder ein Risiko: zu viel Gepäck mit sich herumzuschleppen und den Überblick zu verlieren. In diesem Artikel schlage ich stattdessen eine Methode vor, mit der sich Manager und Teams die Tätigkeit des Risiko- managements teilen – und zwar fokussiert auf die Risiken, die direkt mit den Arbeits- paketen zusammenhängen, die zur Entwicklung der Software führen. Risiken, die außerhalb der Arbeitspakete liegen (z. B. Image-Schaden für das laufende Vorhaben, weil jemand Gerüchte darüber verbreitet), sollte man anders managen als mit dem hier vorgeschlagenen Vorgehen. Risikoprofile Grenzen wir also zunächst ab, für welche Arten von Risiken diese Methodik beson- ders gut geeignet ist. Betrachtet man Risiken systematisch, lassen sich drei große Zum Begriff „Risiko“ gibt es ein paar schö- ne Definitionen, die Tom de Marco und Tim Lister in ihrem Klassiker „Bären- tango“ (vgl. [Mar03]) aufgeführt haben. Risiko ist demnach: ■ Ein mögliches künftiges Ereignis, das zu unerwünschten Folgen führt. ■ Die unerwünschten Folgen selbst. Oder gleich noch eine schöne, zirkuläre Definition, die sich ebenfalls in [Mar03] findet: ■ Ein Risiko ist ein Problem, das erst noch auftreten muss. ■ Ein Problem ist ein Risiko, das bereits aufgetreten ist. Das COSO-Framework für unternehmens- weites Risikomanagement (vgl. [Cos04]) definiert Risiko wie folgt: ■ Risiko ist die Wahrscheinlichkeit, dass ein Ereignis eintritt, das die Erreichung von Zielen negativ beeinflusst. In IT-Vorhaben stecken viele Quellen der Unsicherheit. Diese müssen betrachtet und in das Management des Vorhabens mit ein- bezogen werden, damit man unterwegs die Ziele des Vorhabens nicht unversehens gefährdet. Die Unsicherheit kann aus den verschie- densten Richtungen kommen. Tom De Marco und Timothy R. Lister nennen in [Mar03] eine Auswahl, die keinen Anspruch auf Vollständigkeit erhebt: Anforderungen, politische Machtspiele, Teamfähigkeiten, Zulieferer, Veränderungen in der Umgebung, Größe und Skalierung, Management- fähigkeiten, Stakeholder-Interessen, techno- schwerpunkt Matthias Bohlen ([email protected]) ist unabhängiger Coach für effektive Produktentwicklung. Teams und Manager arbeiten mit seiner Hilfe bewusster, flüssiger und effektiver. Er ist Mitglied des OBJEKTspektrum-Redaktions- teams. der autor
Transcript
RISIKOMANAGEMENT
MIT KANBAN:
RISIKEN SICHTBAR MACHEN
UND IM TEAM ANGEHEN
Quellen erkennen, denen man die nahelie-genden Unsicherheiten zuordnen kann:
■ der Markt■ die Nachfrage ■ die Fähigkeiten der Entwicklungs orga -
ni sation
Mit Kanban (vgl. [And10]) versucht man,diese Unsicherheitsquellen als Informa tions -quellen zu betrachten, aus denen manRisikoprofile ableitet. Ein Risikoprofil ist wieein Steckbrief, der beschreibt, wie „gefähr-lich“ etwas ist, an dem man arbeitet. JedesStück Arbeit, das mit Kanban verfolgt wird,untersucht man daraufhin, zu welchemRisikoprofil es gehört. Mit Hilfe diesesWissens stellen die Entwicklungs teams ihrVerhalten ein und managen damit das Risiko.
Doch eins nach dem anderen. Zunächstsollen die drei Quellen der Unsicherheitnäher untersucht werden, später sehen wir,wie Kanban dabei helfen kann, die Risikendaraus zu managen.
Den Markt verstehen
Bevor man ein IT-Vorhaben startet und sichbemüht, es richtig zu machen, sollte mansich fragen, ob man das richtige Vorhabenstartet und welcher Art das gestarteteVorhaben eigentlich ist.
In wohlbekannten Märkten (z. B. wennman als Dienstleister das x-te Mal fürBanken, Versicherungen oder Telekom-Unternehmen entwickelt) kann sich dieEntwicklungsorganisation darauf konzen-trieren, aus dem Geld des Kunden für die-sen ein Maximum an Geschäftswert her-auszuholen. Die Priorisierung der zuentwickelnden Features kann danach erfol-gen, wie viel Wert für den Kunden entsteht,wenn man dieses Feature entwickelt. Bei
Risikomanagement ist wichtig – das weiß jeder, der in einem IT-Vorhaben gearbeitet hat. Dochso manche Risikoliste veraltet einsam auf der Festplatte eines Servers, ohne dass ein Mitgliedder Entwicklungsorganisation hineinschaut. Mit Kanban kann das anders werden. Risiken sindnicht mehr getrennt von der Arbeit, sondern werden als Bestandteil der Arbeit gesehen undverfolgt. Entwicklungsteams und Management teilen sich diese Aufgabe – die Entwickler habendie Informationen, die Manager geben Entscheidungsrichtlinien. Gemeinsam können Risiken soschneller berücksichtigt und behandelt werden.
m e h r z u m t h e m a :www.mbohlen.de
34 35
logische Innovation, Zu sam men spiel derAkteure mit dem Sys tem usw.
In Management-Frameworks – wie z. B.COBIT, Risk IT und VAL IT – werden dieThemen „IT-Governance“, „IT-Risiko -manage ment“, „Compliance“ und „IT-Sicherheit“ immer mehr als eine Einheitgesehen (vgl. [Isa12]). Risikomanagementwird sehr breit angelegt, um möglichst alleRisiken eines IT-Vorhabens strukturiert zuerfassen und zu bewerten sowie Steu -erungs maßnahmen herbeizuführen unddiese wiederum zu bewerten.
Ich möchte bewusst nicht so weit gehen,alle Risiken eines Vorhabens managen zuwollen. Lange Risikolisten – eingeteilt inmehr als zehn Kategorien, jeweils mitEintrittswahrscheinlichkeit und Auswir -kung, abgelegt in einem Tabellenkal kula -tionswerkzeug, weit weg vom Entwick -lungs geschehen – darin steckt nach meinerMeinung bereits wieder ein Risiko: zu vielGepäck mit sich herumzuschleppen undden Überblick zu verlieren.
In diesem Artikel schlage ich stattdesseneine Methode vor, mit der sich Managerund Teams die Tätigkeit des Risiko -managements teilen – und zwar fokussiertauf die Risiken, die direkt mit den Arbeits -paketen zusammenhängen, die zurEntwicklung der Software führen. Risiken,die außerhalb der Arbeitspakete liegen(z. B. Image-Schaden für das laufendeVorhaben, weil jemand Gerüchte darüberverbreitet), sollte man anders managen alsmit dem hier vorgeschlagenen Vorgehen.
Risikoprofile
Grenzen wir also zunächst ab, für welcheArten von Risiken diese Methodik beson -ders gut geeignet ist. Betrachtet manRisiken systematisch, lassen sich drei große
Zum Begriff „Risiko“ gibt es ein paar schö-ne Definitionen, die Tom de Marco undTim Lister in ihrem Klassiker „Bären -tango“ (vgl. [Mar03]) aufgeführt haben.Risiko ist demnach:
■ Ein mögliches künftiges Ereignis, daszu unerwünschten Folgen führt.
■ Die unerwünschten Folgen selbst.
Oder gleich noch eine schöne, zirkuläreDefinition, die sich ebenfalls in [Mar03]findet:
■ Ein Risiko ist ein Problem, das erstnoch auftreten muss.
■ Ein Problem ist ein Risiko, das bereitsaufgetreten ist.
Das COSO-Framework für unternehmens-weites Risikomanagement (vgl. [Cos04])definiert Risiko wie folgt:
■ Risiko ist die Wahrscheinlichkeit, dassein Ereignis eintritt, das die Erreichungvon Zielen negativ beeinflusst.
In IT-Vorhaben stecken viele Quellen derUnsicherheit. Diese müssen betrachtet undin das Management des Vorhabens mit ein-bezogen werden, damit man unterwegs dieZiele des Vorhabens nicht unversehensgefährdet.
Die Unsicherheit kann aus den verschie-densten Richtungen kommen. Tom DeMarco und Timothy R. Lister nennen in[Mar03] eine Auswahl, die keinen Anspruchauf Vollständigkeit erhebt: Anfor derungen,politische Machtspiele, Teamfähigkeiten,Zulieferer, Veränderun gen in der Umgebung,Größe und Ska lierung, Management -fähigkeiten, Stakehol der-In teressen, techno-
mit seiner Hilfe bewusster, flüssiger und effektiver.
Er ist Mitglied des OBJEKTspektrum-Redaktions -
teams.
der au tor
2/2012
wohlbekannten Vorhaben ist das eine vali-des Vorgehen und wird z. B. von einigenagilen Prozessen auch so vorgeschlagen.
In strategischen Vorhaben jedoch würdedieses Vorgehen nicht funktionieren. Beidiesen kann der Ge schäfts wert nicht vonvornherein bestimmt werden. Diese Vor -haben sind besonderen Risiken ausgesetzt.Man unterscheidet insbesondere die folgen-den beiden:
■ Marktrisiko: Werden sich überhauptgenug Kunden finden, die das neueProdukt einsetzen und bezahlen?
■ Erfindungsrisiko: Wird das neue Pro duktüberhaupt jemals richtig funktionieren?
Zwei Beispiele: Zunächst betrachten wirdie kostspielige Entwicklung eines neuenKrebsmedikaments. Wenn das Medika -ment wirkt und weniger Nebenwirkungenhat als die existierenden Medikamente,wäre der Markt sicherlich riesig und dasMarktrisiko gering. Das Erfindungsrisikoist jedoch groß, denn es ist vorher nichtklar, wie der menschliche Organismus aufdie neue Substanz reagieren wird.
Anders ist es bei der Entwicklung einerneuen Website wie Groupon (vgl. [Gro11]).Vor der Entwicklung von Groupon warnicht klar, ob Menschen soviel Lust aufRabatte haben, dass sie Groupon häufigbenutzen würden. Das Erfindungsrisikovon Grou pon war jedoch vergleichsweisegering, denn wie man soziale Websitesbaut, weiß man schon länger.
Bei einer Software wie Groupon müssenSie zunächst das Marktrisiko testen. EricRies beschreibt in [Rie11], wie die Gründervon Groupon zunächst ihre Dienstleistungvon Hand erbrachten, ohne dafür Softwarezu schreiben. Das Ziel war es zunächst, zulernen, ob Kunden Groupons mögen unddafür bezahlen würden – was (wie sich her-ausstellte) auch der Fall war. Danach erstentwickelten sie die Software, als sie dasMarktrisiko als beherrschbar ansahen.
Wenn Sie erkennen, dass Ihr Vorhabenein signifikantes Erfindungsrisiko birgt,entwickeln Sie frühe Prototypen, um dieschwierigen Detailaspekte der Lösung zuverstehen. Wenn Sie sich sicher sind, dassauch diese Details funktionieren, könnenSie das Vorhaben starten wie geplant.
Die Nachfrage verstehen
Das Business stellt Nachfragen an die Ent -wicklungsorganisation: „Entwickelt unsbitte dies oder jenes Merkmal für dasProdukt“. In diesen Merkmalen steckt einAkzeptanzrisiko: Wie begeistert wird dasBusiness überhaupt sein, wenn wir diesesMerkmal fertig haben?
Noriaki Kano untersuchte an der Uni -versität Tokio Kundenanforderungen undfand heraus, dass die Kundenzufriedenheitnicht unbedingt damit zusammenhängenmuss, wie gut man ein Merkmal ausprägt.Das nach ihm benannte Kano-Modellunterscheidet fünf Ebenen der Merkmal -qualität, von denen drei im Hin blick auf
das Risikomanagement beson ders interes-sant sind (siehe Abbildung 1):
■ Basismerkmale: Diese sind so grundle-gend und selbstverständlich, dass derKunde sie einfach erwartet und ihrVorhandensein seine Zufriedenheit nichtsteigert. Beispiel: Eine Login-Maske beieiner Web-Anwendung mag notwendigsein – besondere Kunden zu friedenheitwird ihr Vorhandensein nicht erzeugen.
■ Leistungsmerkmale: Diese fallen demKunden auf und steigern seine Zufrie -denheit, je besser sie erfüllt sind.Beispiel: Die Exportformate bei einemBildbearbeitungsprogramm – je mehrFormate das Programm exportierenkann (TIFF, JPEG, PNG usw.), destozufriedener wird der Kunde sein.
■ Begeisterungsmerkmale: Das sind solche,die Nutzen stiften, mit derenVorhandensein der Kunde aber nichtgerechnet hat. Sie verschaffen einenVorteil gegenüber dem Wettbewerb, weilsie den Kunden wirklich begeistern.Beispiel: Besonders ausgefeilte Bedien -konzepte bei heutigen Smart phones,Tablet-Computern oder noch witzigerenGadgets wie der hochwerfbarenPanorama-Ball-Kamera (vgl. [Pfe11]).
Das Akzeptanzrisiko in einem Produkt -merkmal sollte man als Entwicklungs -organisation im Blick behalten und sich jenach Kano-Ebene unterschiedlich verhalten.Bei der Entwicklung eines Basis merkmalssollte das Team nicht mehr Energie investie-ren als nötig – der Kunde wird überschüssigeQualität einer Login-Maske nicht schätzen,sondern ignorieren. In ein Leistungsmerkmalwird man die normale Menge an Energieinvestieren, um eine gute Realisierung sicher-zustellen. Bei Begeisterungsmerkmalen wirdman Extra-Energie investieren, indem manz. B. einerseits einen User-Experience-Ex per -ten hinzuzieht und andererseits die Mengeder automatisierten Akzeptanztests vergrö-ßert, damit das Merkmal auch besonderssicher funktioniert. Das Letzte, was Sie wol-len, ist ein schlecht implementiertes Be -geisterungs merkmal, denn dabei wäre dasRisiko der Nicht-Akzeptanz am höchsten.
Untersuchen Sie die Eigenschaften vonProduktmerkmalen systematisch, danngewinnen Sie Erkenntnisse, die Ihnen beider späteren Risikoeinschätzung der Merk -male helfen können:
schwerpunk t
Abb. 1: Kano-Modell für Kundenzufriedenheit.
dem neuen Merkmal bereits Geld verdie-nen könnte, wenn Sie es denn geliefert hät-ten. Je länger es sich hinauszögert, destomehr Geld entgeht dem Kunden (sieheAbbildung 2). Die Kosten der Verzögerungsteigen linear mit der Zeit – solcheMerkmale bezeichnet man in Kanban alsStandardarbeit.
Im Gegensatz dazu betrachten Sie einenkritischen Fehler: Beim Kunden steht dieProduktion, er kann nicht weiterarbeiten,die Kosten sind bereits ab jetzt sehr hoch(siehe Abbildung 3). Sie müssen ihm sehrschnell einen Bug-Fix liefern, den er ein-spielt, um den Fehler zu beheben. Solch einMerkmal bezeichnet man in Kanban alsExpress-Arbeit.
Stellen Sie sich vor, der Kunde hat eineVerbindung zu einem Kreditkarten-Abrech -nungsunternehmen, das ab 1. Mai eine neueSchnittstelle anbietet, die vom Kun den ein-zuhalten ist. Die alte Schnittstelle gibt es nachdem 1. Mai nicht mehr. Für diesen Kundenmüssen Sie die Software ändern, um die neueSchnittstelle aufzurufen. Was würde passie-ren, wenn Sie erst nach dem 1. Mai liefernkönnten? Ihr Kunde würde schlagartig keinGeld mehr via Kreditkarte einnehmen, waseinen Anstieg der Verzö gerungskosten abdem Stich tag zur Folge hätte (sieheAbbildung 4). Was würde passieren, wennSie die Änderung deutlich vor dem Stichtagliefern? Nichts, denn Ihr Kunde kann sienicht einsetzen. Solch ein Merkmal bezeich-net man in Kanban als Arbeit mit festemLieferdatum.
Noch ein letztes Beispiel: Ihr Datenbank-Hersteller sagt, dass er für die Version derDatenbanksoftware, die Sie für Ihr Produktbenutzen, keinen Support mehr leistet unddiese Version nur noch fünf Jahre lang lie-fern wird. In diesem Fall bringt sofortigesHandeln keinen Vorteil, doch wenn Sie fünfJahre lang gar nicht handeln, werden Sie inSchwierigkeiten kommen. Die Verzö -gerungs kosten nehmen einen vagen Verlauf(siehe Abbildung 5), sie steigen lange Zeitnur leicht an, doch eines Tages deutlichstärker. Merkmale mit diesem Kosten -verlauf nennt man in Kanban „vage“ (inder englischen Kanban-Literatur intangi-ble).
Was wäre, wenn Sie für jedes Merkmalwüssten, in welches dieser vier Beispiele esgehört? Und wenn Sie außerdem ihreFähigkeiten bezüglich Zykluszeit, Durch -satz und Bestand an unfertiger Arbeit ken-nen würden? Sie könnten dem Kundensagen: Wir liefern Express-Arbeit sofort,solche mit festem Lieferdatum zu dem
36 37
ergebnissen gefüllt sind, werden konse-quent beobachtet und bekämpft.
Lohnt sich für Sie als Entwick lungs -organisation die ganze Mühe, um die eige-nen Fähigkeiten zu verstehen und immerweiter zu optimieren? Die Mühe ist aufjeden Fall dann vergeblich, wenn Sie demKunden im nächsten Schritt eine Deadlinefür alle Features anbieten. Durch dieErkenntnis Ihrer Fähigkeiten haben Sie vie-le Optionen offen, die Sie mit Hilfe einesDeadline-Versprechens („Liefertermin istder 30.6. für das ganze Projekt“) schlagar-tig schließen. Sie nutzen damit dieMöglichkeiten, die Sie haben, nicht aus undholen sich ein neues Risiko herein: dasRisiko der zu späten Lieferung.
Vom Standpunkt des Risikomanage -ments aus ist das unklug. Machen SieUnterschiede und liefern Sie nur dieMerkmale auf Termin, die wirklich hoheVerzögerungskosten haben. Sagen SieIhrem Kunden, was Sie bieten können, under wird begeistert sein. Sagen Sie ihm, dassSie dringende Merkmale sofort bereitstel-len können, sofern nicht alles dringend ist.Geben Sie dem Kunden Optionen, die Werthaben, und verschaffen Sie sich selbstRaum zum Manövrieren, damit Sie dieseOptionen auch einlösen können.
Hierzu ein paar Beispiele: Betrachten Siedie (Opportunitäts-)Kosten der Verzö -gerung, wenn Sie ein Merkmal zu spät anihren Kunden ausliefern. In der Mehrzahlaller Fälle bedeutet das, dass Ihr Kunde mit
■ Geschäftswert: Wie viel Wert stiftet die-ses Merkmal für den Kunden?
■ Entwicklungskosten: Wie viel Geld müs-sen wir für die Entwicklung ausgeben?
■ Kosten einer Verzögerung: Was kostetes, wenn dieses Merkmal zu spät gelie-fert wird?
■ Wettbewerbskategorie/Akzeptanzrisiko:Handelt es sich um ein differenzieren-des Merkmal? Wird der Kunde esschätzen?
■ Unsicherheit/Lernaufwand: Wird derKunde das Merkmal sofort verstehenund benutzen?
■ Kundenklasse (z. B. A-Kunde, B-Kun de,C-Kunde): Von welcher Art von Kundekommt die Anforderung? Wird er ohneProbleme dafür bezahlen wollen?
■ Geldquelle (z. B. Sponsor-Name beimehreren Sponsoren): Welcher derSponsoren des Vorhabens bezahlt fürdas Merkmal?
■ Zulieferer-Aktivitäten notwendig: Be -nö tigen wir die Zuarbeit von anderen(z. B. von einem Grafikbüro)?
Die Fähigkeit verstehen
Eine reife Entwicklungsorganisation ist sichüber ihre Fähigkeiten im Klaren – sowohlwas die Nachfrage, als auch was ihr eigenesAngebot betrifft. Bei der Behand lung derNachfrage benötigt sie Fähig keiten in denBereichen Anforderungs klärung, Werter -mitt lung, Rentabi litäts rechnung und Pro -dukt gestaltung (um nur einige zu nennen).Zum Bereitstellen eines für die Kundeninteressanten Angebots muss die Organi -sation Merkmale entwickeln können sowiekontinuierliches Deployment und (noch bes-ser) kontinuierliche Lieferung beherrschen.Fähigkeiten zur beschleunigten Lieferungund zur Lieferung auf Termin sind etwas fürFortgeschrittene. Prototyping, Vorab-Freigabe zum Testen und Feedback einsam-meln sowie Fehleranalyse und -behebungrunden die Fähigkeiten ab, die die Ent -wicklungsorganisation für den Kundeninteressant machen.
Sehr reife Organisationen kennen ihreFähigkeiten nicht nur qualitativ, sondernauch quantitativ. Sie messen die durch-schnittliche Zykluszeit, die ein Merkmalbraucht, bis es release-fähig entwickelt ist.Der Durchsatz an fertigen Merkmalen, dendie Organisation erbringen kann, wirdebenfalls gemessen und ist allen bekannt.Der Bestand an unfertiger Arbeit (Work-in-Progress) wird rigoros und diszipliniert aufein Minimum begrenzt. Warteschlangen,die mit Nachfrage oder gar mit Zwischen -
Datum und alles andere danach mitbestimmter Wahrscheinlichkeit für eineZykluszeit. Ihr Kunde wäre begeistert.
Erkenntnis zwischendurch
Lassen Sie uns an dieser Stelle kurz inne-halten und fragen wir uns, was das mitRisikomanagement zu tun hat. Es gehtnämlich um die Risiken der Gleichbe hand -lung:
■ Wenn wir alle Märkte gleich behan-deln, riskieren wir, in wohlbekanntenMärkten zu teuer zu sein und in risiko-reichen Märkten zu scheitern.
■ Wenn wir alle Merkmale gleich behan-deln, riskieren wir, uns für Basis merk -male zu sehr anzustrengen und für ech-te Begeisterungsmerkmale zu wenig zutun.
■ Wenn wir alles als dringend betrachten,riskieren wir, uns für Standardarbeit zusehr anzustrengen und Express- oderTerminsachen nicht rechtzeitig liefernzu können.
Markt, Merkmale und Dringlichkeit bzw.Fähigkeit liefern Informationen, die zusam-men ein Risikoprofil der Arbeit ergeben. Esist nun Zeit, sich darüber klar zu werden,dass nicht jede Arbeit gleich ist, sonderndass unterschiedliche Risikoprofile auchunterschiedliche Reaktionen der Entwick -lungsteams verlangen, sprich: Dem Kunden
gegenüber bieten Sie eine andere Art vonService, je nachdem, wie viel Risiko in demsteckt, was er verlangt.
Teilen Sie also das, was Sie tun, inKlassen ein und versprechen Sie demKunden pro Klasse eine bestimmte Service -qualität, nicht mehr eine pauschal einheitli-che. Diese Klassen nennt man in KanbanServiceklassen.
Serviceklassen
Beispiel: Verlangen Sie vom Kunden mehrGeld für eine Expresslieferung oder für eineLieferung zu einem festem Termin. Sie glau-ben, das können Sie mit Ihrem Kundennicht machen? Nehmen Sie sich ein Beispielan der Deutschen Post. Sie berechnet füreinen normalen Brief, der in der Regelinnerhalb eines Tages ankommt, nur 0,55Euro. Kommt er nicht innerhalb einesTages an, dann fast immer innerhalb vonzwei Tagen. Für einen Expressbrief, derinnerhalb von einem Tag ankommen muss,berechnet die Post 18 Mal so viel, nämlich9,90 Euro. Dieser Brief ist dann sogarschon bis 2.500 Euro versichert – Sie mer-ken, das ist einfach eine ganz andereService klasse als der normale Brief.
Was wäre also, wenn Sie zu IhremKunden sagen könnten: „Normale Pro -dukt merkmale können wir mit 85 %Wahrscheinlichkeit innerhalb von 20 Tagenliefern und verlangen dafür X Euro. FürProduktmerkmale, die wir in genau 20Tagen mit 100 % Wahrscheinlichkeit lie-fern müssen, verlangen wir 18*X Euro.“Ihr Kunde hätte die Möglichkeit zu ent-scheiden, ob er wirklich diese hohe Service -qualität benötigt, und würde wahrschein-lich nur noch wenige Merkmale fordern,die so dringend sind. Stattdessen würde erauf die 85%-ige Wahrscheinlichkeit einerStandardlieferung vertrauen (sofern Sieihm Grund dazu geben und ihn nicht regel-
mäßig im Regen stehen lassen) und vielGeld dabei sparen.
Serviceklassen sind wie Eimer mit einemNamen und mit definierten Eigenschaften.Tabelle 1 zeigt einige Beispiele für solcheServiceklassen, die auf Basis des bisherGesagten definiert wurden.
Visualisierung in Kanban
In der Kanban-Methodik visualisiert man sei-ne Arbeit als Karten auf einer Kanban-Tafel.Die Tafel ist in Spalten eingeteilt, die für dieverschiedenen Arbeitsschritte stehen, die jedesMerkmal durchlaufen muss, bis es release-fähig ist. Die Karten befinden sich in einerSpalte, wenn sich das zugehörige Merkmalgerade in diesem Arbeits schritt befindet.
Für die verschiedenen Serviceklassen ver-wendet man farbige Karten, z. B. weiß fürExpress, lila für Termin, gelb für Normalund grün für Schlupf. Sie können nun mitKanban die Kapazität auf die Service -klassen verteilen, indem Sie festlegen, dass
20. – 21. März 2012, KölnDie Teilnehmer lernen in diesem Seminar, wie man ein Kanban-System für die eigene Firma entwirft und möglichst erfolgreich einführt.
sich von einer bestimmten Farbe nur einebestimmte Anzahl von Karten im Systembefinden darf (siehe Abbildung 6). Damitverteilen Sie Ihr Risiko. Express-Lieferun -gen könnten das Entwicklungs team durch-einanderbringen, deshalb legen Sie fest,dass immer nur 5 % aller Karten auf demBrett Expresskarten sein dürfen. Lieferun -gen mit festem Termin sind auch risikobe-haftet, deshalb legen Sie fest, dass nur 20 %aller Karten lila sein (also einen festenTermin haben) dürfen. Den Löwenanteilbilden die normalen, gelben Karten mit 50%. Die grünen (Klasse „Schlupf“) bildendie langfristig wichtigen Dinge, die abereine kurzfristiges taktisches Manövrieren(sprich: Vernachlässigen) er lauben. Dafürkönnen Sie z. B. 30 % reservieren.Aufmerksame Leser werden be merkthaben, dass die Summe mehr als 100 %ergibt. Warum wohl?
Damit ist ein erstes Risikomanagementdurch Kapazitätsaufteilung gegeben. Doches geht noch mehr.
Das Teamverhalten ausrichten
Vereinbaren Sie teamintern, wie mit denKarten aus den unterschiedlichen Service -klassen umzugehen ist. Das Team richtetsein Verhalten daran aus, zu welcherServiceklasse eine Karte gehört. Ein paarBeispiele:
■ Express-Karten sind nur für Notfällereserviert (Produktion steht). Sie sprin-gen an den Anfang einer jeden Warte -schlange und durchbrechen die Work-
schwerpunk t
in-Progress-Grenzen. Leute hören mitdem auf, woran sie gerade arbeiten,und schwärmen aus, um diese Kartedurchzubringen.
■ Höchst-unsicher-Karten sind Markt -risiken oder technischen Risiken ausge-setzt. Die Maxime lautet: Wenig Auf -wand investieren, erst einmal im Markttesten, dann zu voller Blüte ausbauenund dem Kunden oder Produkt -manager sagen, dass Zeit- und Kosten -schätzungen höchst unsicher sind.
■ Hochwertig-Karten benötigen Extra-Bemühungen für User-Experience,brauchen mehr automatisierte Tests
und vielleicht extra manuelle, explora-tive Tests – hier lohnt sich ein großesEngagement.
■ Schlupf-Karten sind das Kanonenfutter,das Express- oder Terminarbeit über-haupt erst ermöglicht. Beispiele:Datenbank-Upgrades, Verbesserungdes Build-Systems, Paar-Program -mierung in COBOL für Java-Leute usw.Karten aus der Klasse „Schlupf“ wer-den durch Karten aus höheren Ser -viceklassen verdrängt, sind aber trotz-dem langfristig wichtig.
Die Vorteile von Serviceklassen sind ein-deutig. Die Entwicklung wird sich an derNachfrage des Business ausrichten, wenndieses sorgfältig mit den Klassen umgeht.Die Erwartungen an die Zeitplanung wer-den realistischer, da nicht mehr eine pau-schale Zeitplantreue versprochen wird.Und schließlich ermöglicht die Einteilungin Serviceklassen eine risikoorientierte Be -trachtung des Backlogs für Ihr Produkt.
Risikoorientierte Sicht
Teilen Sie die Merkmale, die zu entwickelnsind, anhand des Risikoprofils in Service -klassen ein. Stellen Sie dann risikoorientier-te Fragen:
■ Was ist, wenn wir zu viele „Höchst-unsicher“-Features im Backlog haben?Das wird wahrscheinlich unsere Plänedurcheinander bringen.
■ Was ist, wenn wir gar keine „Höchst-unsicher“-Features haben? Dann wer-
Abb. 6: Kanban-Tafel mit Serviceklassen.
Abb. 7: Teamermächtigung durch Richtlinien.
2/2012
den wir ein Produkt entwickeln, das fürden Kunden möglicherweise uninteres-sant ist.
■ Was ist die beste Mischung von Fea -tures aus den Klassen „Basis“, „Nor -mal“ und „Hochwertig“?
■ Können wir Merkmale mit hohemRisiko amortisieren, indem wir sie inkleinere Merkmale zerteilen, die wirdann Stück für Stück angehen?
■ Sollten wir eine „Sensationsversion“mit zehn neuen Merkmalen herausbrin-gen oder lieber drei neue Produkt -versionen nacheinander mit je drei bisvier neuen Merkmalen?
■ Können wir ein ausbalanciertes Releasemit einem „Höchst-unsicher“-Merk -mal und mehreren gut verstandenenStandardmerkmalen herausbringen?
■ Wie ist die langfristige Auswirkung,wenn wir zu viele Express-Merkmalehaben?
Selbstorganisation und
Ermächtigung
Mit Hilfe solcher Fragen lassen sich zwi-schen Management und Teams Richtlinienabsprechen (siehe Abbildung 7). ExpliziteRichtlinien machen es möglich, dass TeamsVerantwortung für das Risikomanagementübernehmen. Nicht nur die Projektleitungist jetzt mehr gefragt, sondern Manage -ment und Teams vereinbaren ein Verhalten,das dann in der freien Wildbahn des Alltagsklar beschreibt, wie zu reagieren ist. DasTeam hat im Alltag alle Daten, die esbraucht, um zu entscheiden. Die Richtlinieagiert dabei als Filter, der zu den richtigenEntscheidungen führt, ohne dass erst einManager gefragt werden muss, der ohne-
hin womöglich gerade auf dem Weg nachAlaska ist. Die ganze Organisation gewinntdadurch an Agilität.
Fazit
In diesem Artikel habe ich die folgendenSchritte vorgeschlagen:
1. Informationen über den Zielmarkt, dieNachfrage und die Fähigkeit der Ent -wicklungsorganisation gewinnen. Dasnennt man ein Risikoprofil.
2. Diese Informationen nutzen, um festzu-stellen, in welche Serviceklasse ein zuentwickelndes Merkmal gehört.
3. Im Alltag die Kapazität der Entwick -lungsteams auf die Serviceklassen ver-teilen, dadurch das Gesamtrisiko sen-ken und Platz zum Manövrierenschaffen.
4. Das Teamverhalten am Risiko ausrich-ten, und zwar mit Hilfe expliziterRicht linien für den Umgang mit denkanbans jeder einzelnen Serviceklasse.
Wenn Sie jetzt noch die Partner derEntwicklungsteams (also z. B. Business undBetrieb) mit in die Erarbeitung derRichtlinien einbeziehen, haben Sie wirklicheine schlagkräftige Organisation. ImErnstfall brauchen die Richtlinien nicht mehrdiskutiert zu werden, weil sie bereits allseitsakzeptiertes Allgemeingut sind. Sie werdenfeststellen, dass Ihre Organisation an Reifegewinnt, wenn Sie Risiken derart professio-nell managen und sich von den Teams dabeihelfen lassen. Mein Tipp: Nehmen Sie sichfür den Anfang einen Coach, der mit Ihnengemeinsam dieses System initialisiert – dasvereinfacht vieles. ■
schwerpunk t
Literatur & Links
[And10] D.J. Anderson, Kanban, Blue Hole Press 2010
[Cos04] Committee of Sponsoring Organizations of the Treadway Commission (COSO), Enterprise
