Interview mit Matthias Bohlen

„Kanban ist kein Vorgehensmodell, sondern ein Gewürz“
Kommentare

Matthias Bohlen, Speaker auf der diesjährigen JAX, sprach mit uns über Kundenzufriedenheit, das Classes-of-Service-Konzept, Real Options und das Wesen von Kanban.

Na klar muss alles „gestern“ fertig sein, wann denn sonst? ist eine deiner Sessions auf der JAX betitelt. Wie sagt man es dem Kunden, dass das einfach nicht geht?

Matthias Bohlen: Dass das nicht geht, sieht der Kunde ja selbst. Das braucht man ihm nicht zu sagen. Doch was soll man ihm stattdessen sagen? Wenn Du etwas ablehnst, musst Du ihm sagen, was er denn stattdessen bekommt.

Ich argumentiere meistens so: Lieber Kunde, Dein (oder unser) Team ist wie ein Motorrad mit viel PS, trotzdem ist seine Leistung begrenzt. Du kannst das Team so nutzen, dass es Dich sehr schnell an genau die Orte bringt, die für Dich geschäftlich wichtig sind. Fahre mit dem Team immer zu dem jetzt wichtigsten Feature, dann zum nächstwichtigen usw.

Was wichtig ist, entscheidest Du anhand des Wertes, den Du mit dem neuen Feature erzielen kannst und anhand der Verzögerungskosten für diejenigen Features, die Du dafür herunterpriorisieren musst. Wir machen immer die wichtigsten Features zuerst, so dass Dein Return on Investment maximal wird.

JAX 2015Die JAX (20.-24. April 2015) bildet mit der W-JAX Europas führende Konferenz-Serie für Enterprise-Technologien, agile Methoden und Software-Architekturen. Gemeinsam mit den begleitenden Business Technology Days und der BigDataCon verleiht sie IT-Professionals führender Unternehmen aller Branchen die entscheidenden Impulse für digitale Wertschöpfung und Innovation – zwei Mal im Jahr. Mehr Informationen unter http://jax.de.

Ich höre immer wieder, dass es zur Praxis gehört, einem Kunden unrealistische Leistungen zu einer unrealistischen Deadline zu versprechen – einfach deshalb, weil man sonst den Auftrag nicht bekommt. Und dann müssen Überstunden geschoben werden, um den Kunden einigermaßen zufrieden zu stellen. Wie kann man diesen Teufelskreis durchbrechen? 

Die Angst, den Auftrag nicht zu bekommen, ist zwar da, doch erlebe ich meist etwas ganz anderes: Die Dienstleister wissen nicht, was ihre Teams können. Noch besser: Die Teams wissen es selbst meist auch nicht nicht. Resultat: Sie versprechen irgendwas, von dem sie glauben, dass sie damit konkurrenzfähig sein werden. Wenn die Teams konsequent messen würden, wie viel sie können (anstatt zu schätzen, wie viel sie schaffen), und das konsequent an den eigenen Vertrieb kommunizierten, wären sie besser dran.

Außerdem empfehle ich immer der Geschäftsleitung, sie sollen doch den Vertrieb nicht nach der Zahl der Verkaufs-Abschlüsse belohnen, sondern nach Zahl und Umsatz der erfolgreich und nachhaltig abgelieferten Projekte, die sie in Zusammenarbeit mit der Entwicklung realisiert haben. Das heißt, Aufträge heranholen wie der Teufel ist gar nicht das Ziel, sondern nur so viele Aufträge, wie der Durchsatz der Teams nachhaltig hergibt. Bonus gibt’s erst, wenn die Entwicklung ein Projekt abgeschlossen hat. Lieber rauf mit den Preisen und weniger Aufträge in angemessener Qualität ausführen als viele Aufträge bekommen und mit mieser Qualität abliefern.

Es gibt dabei generell zwei unterschiedliche Fälle:

Fall a ist die Projektarbeit. Der Kunde will „n“ Features bis zu einem gewissen Termin – das ist eine Frage des Durchsatzes, mit dem das Team die Features in hoher Qualität bereitstellen kann. Kennen die Teams ihren Durchsatz, z. B. in „Actionable user stories per week“, dann können sie sagen, was für einen bestimmten Termin und bestimmte Kosten wohl für eine Storymenge geliefert werden kann. „Actionable“ heißt für mich eine Story dann, wenn sie sowohl klein genug ist als auch den genügend hohen Detaillierungsgrad (z. B. an Akzeptanz-Testcases und Beispiel-Eingabedaten) aufweist, so dass das Entwicklerteam sagt: „Die Story ist super beschrieben, die können wir sofort umsetzen.“

Fall b ist die Service-Arbeit, also z. B. Bugs fixen oder Change Requests abarbeiten. Hier kommt es nicht so sehr auf den Durchsatz an, sondern auf die Durchlaufzeit eines einzelnen Bugs oder Change Requests. Der Kunde will einen Fehler/Change schnell behoben haben. Wenn die Teams messen würden, wie das Spektrum typischer Durchlaufzeiten aussieht, könnten sie Statements abgeben wie „80% der Changes von der Art X haben wir immer in unter einer Woche geschafft, also rechnen wir damit, dass wir einen Deiner Changes, lieber Kunde, mit 80% Wahrscheinlichkeit in einer Woche bereitstellen können.“ Dafür braucht man noch ein paar Messgrößen mehr, die erkläre ich dann in meinem JAX-Vortrag und in meinem Artikel für’s Business Technology Magazin.

In deiner zweiten Session sprichst du über das Classes-of-Service-Konzept. Kannst du uns in wenigen Sätzen erklären, was man hierunter versteht?

Bei den Arbeitspaketen, die vom Kunden zum Team kommen und erledigt wieder an den Kunden zurückfließen, gibt es mehrere Stufen von Dringlichkeit. Class of service heißt, das Team reagiert unterschiedlich, wenn die hereinkommenden Aufträge unterschiedliche Dringlichkeit haben.

Beispiel: Wenn beim Kunden die Produktion steht, weil das Team einen Fehler ausgeliefert hat, dann muss das Team alles stehen und liegen lassen und sofort den Bug fixen. Solch ein Bug fällt dann in die Serviceklasse „Express“.

Das andere Extrem: Wenn der Datenbankhersteller sagt, dass in fünf Jahren der Support für Version 12 der Datenbanksoftware ausläuft, dann muss das Team nicht sofort eine Migration anstoßen – denn sie muss ja erst in fünf Jahren durch sein. Solch eine Anforderung fällt im Moment in die Serviceklasse „man müsste mal machen“.

Wenn Euer Kreditkarten-Unternehmen sagt: „Ab 1. Mai haben wir ein neues API, und Eure API-Aufrufe müssen bis dahin umgestellt sein, sonst macht Ihr nach dem 1. Mai von Eurem Webshop aus kein Geschäft mehr“, dann ist das die Serviceklasse „festes Lieferdatum“.

Dann gibt es noch die Pakete, die einfach so eins nach dem anderen erledigt werden müssen. Das ist die Serviceklasse „normal“.

Teams, die ihren Kunden mehrere Serviceklassen anbieten können, ermöglichen eine feingranulare Steuerung der Dringlichkeit und damit eine Minimierung des Risikos. Die Deutsche Post hat auch Serviceklassen. Ein Brief der Klasse „normal“ kostet 62 Cent und kommt in der Regel in einem Tag an, manchmal aber auch in zwei Tagen. Wenn Du als Postkunde willst, dass er garantiert in einem Tag ankommt, nimmt die Post dafür plötzlich ganze 9,90€ – weil sie einen Brief dieser Serviceklasse ganz anders behandeln muss, obwohl er meist auch nicht schneller ankommt als ein normaler Brief. Der Kunde entscheidet, was er will. Die Teams entscheiden, was das kostet und wie sehr sie sich dafür anstrengen. Sie managen die Tickets der verschiedenen Serviceklassen tatsächlich unterschiedlich, um die Kunden zufrieden zu stellen.

Entweder man verpasst Termine – oder man liefert nur langweilige Features aus.  Wie hilft das Classes-of-Service-Konzept dabei, nicht in eines dieser Extreme zu verfallen?

Man braucht nicht vor lauter Termindruck nur noch langweilige Features abzuarbeiten. Termine kann man gut halten, wenn man eine Hierarchie von Serviceklassen bildet, so dass „Express“ wichtiger ist als „Festes Lieferdatum“, das wiederum wichtiger als „normal“, das wiederum wichtiger als „man müsste mal machen“. Dann kann ein Team trotzdem richtig interessante, etwas risikoreichere Features ausliefern, weil sie sich nicht ständig verrückt machen und alles als superdringend auffassen.

Sprecht einfach mal mit dem Kunden und fragt ihn, wo die Termine herkommen, die er nennt. Wenn am Termin wirklich etwas Entscheidendes passiert (z. B. keine Kreditkarten mehr abrechenbar sein werden), dann ist das ein echter Termin. Doch wenn am 1.7. auch nichts anderes geschieht als am 30.6., dann ist der 30.6. kein echter, sondern ein Wunschtermin. Das Team sollte entsprechend unterschiedlich reagieren.

Das Classes-of-Service-Konzept macht die Kommunikation zum Kunden hin total ehrlich. Das Teamverhalten wird für den Kunden viel besser einschätzbar, und das Team macht sich nicht mehr wegen jedes Arbeitspakets verrückt.

Was hat es mit dem Begriff „Real Options“ auf sich?

Real Options sind Optionen in der Realität, nicht am Finanzmarkt. Sie haben jedoch ebenfalls einen Wert und ein Verfallsdatum.

Beispiel: Ein Team hat ein Performanceproblem, für das es zwei Lösungen gibt: Die eine dauert vier Wochen in der Umsetzung, die andere sechs. Die Vier-Wochen-Option hat aber ein paar Nachteile in Bezug auf die Verständlichkeit des Codes. Wir sind z.B. noch sieben Wochen vor Termin, das Team hat also noch beide Optionen zur Verfügung. Sie können sich noch eine Woche Zeit lassen, um zu entscheiden. Falls sich das Team jedoch nach drei Wochen immer noch nicht entschieden hat, was sie umsetzen wollen, ist die Sechs-Wochen-Option schon abgelaufen, und das Team kann nur noch die Vier-Wochen-Option wählen, um den Termin zu halten. Sofortige Entscheidung bei sieben Wochen vor Termin hätte aber auch nichts gebracht! Das Team hätte eine Woche verschenkt, in der sie vielleicht noch mehr hätten lernen können, um eine dritte, noch bessere Möglichkeit zu finden.

Wenn man Real Options konsequent anwendet, kann man den Wert, der für den Kunden geschaffen wird, steigern und wiederum viel Hektik und Risiko aus der Entwicklung nehmen. Im Prinzip ist auch jede User Story im Backlog solche eine Real Option, die erst dann zum Commitment wird, wenn das Team sie anfängt, umzusetzen. Bis dahin darf der Product Owner sie noch wieder absagen. Die Story verliert aber z. B. ihren Wert, wenn sich das Marktfenster des Kunden schließt, also muss der Product Owner aufpassen und die Story als Option rechtzeitig „ziehen“.

Warum ausgerechnet Kanban? Welche Vorteile bietet Kanban im Vergleich zu anderen Vorgehensmodellen?

Kanban ist selbst kein Vorgehensmodell, sondern ein „Gewürz“ für Vorgehensmodelle. Du gibst es als Zutat hinzu, und das Vorgehen, das die Teams ohnehin haben, schmeckt plötzlich wesentlich besser! Warum?

Beispiel: Nehmen wir an, Ihr macht zur Zeit einen etwas unreifen Scrum-Prozess, weil Euer Team noch neu ist. Euer Burndown-Chart verläuft nach Sprint-Beginn zunächst waagrecht, weil das Team mehrere Stories aus dem Sprint Backlog auf einmal angreift und parallel bearbeitet. In der Mitte des Sprints merkt der Product Owner, dass das nicht klappt, und nimmt Stories aus dem Sprint heraus. Das Burndown Chart geht schlagartig nach unten. Wenig befriedigend für alle, weil schlecht planbar.

Jetzt gebt Ihr Kanban als Gewürz hinzu. Ihr visualisiert auf dem Scrum-Board mehrere Spalten, die den Schritten im Entwicklungsprozess entsprechen, z. B. Verstehen, Akzeptanztests entwickeln, Code entwickeln, Akzeptanztests durchführen, in Produktion nehmen, done. Für jede Spalte setzt Ihr ein Work in Progress (WIP) Limit, das Euch sagt, wie viele Stories Ihr in dieser Spalte maximal gleichzeitig angreifen wollt (z. B. 1 bis 2). Wenn zu viele Stories in einer Spalte landen, macht Ihr zuerst eine alte Story, die schon weit rechts auf dem Board hängt, fertig und zieht erst dann die neue Story, die weiter links hängt, nach. Klemmt’s z.B. im Akzeptanz-Test, dann helfen alle mit, zuerst den Test einer alten Story fertig zu bekommen, bevor Ihr neue Stories nachzieht.

Ergebnis: Der Burndown wird deutlich glatter und näher an der Ideallinie verlaufen, weil Kanban Euch dazu bringt, weniger auf einmal zu machen und Euren ansonsten völlig unveränderten Scrum-Prozess besser zu leben. Euer Product Owner wird besser planen können und das Team wird weniger Stress haben. Alles andere (z. B. die Sprints und die Meetings) könnt Ihr erst mal komplett so lassen.

Später, wenn sich herausstellt, dass Ihr gute und reproduzierbare Geschwindigkeit durch Scrum+Kanban=Scrumban habt, könnt Ihr als Nächstes die Schätzerei im Sprint Planning weglassen und so viele kleine Stories in den Sprint ziehen, wie in die erste limitierte Spalte des Boards passen, mehr nicht. Später, wenn Ihr noch schlauer seid und bei jedem Anschlag ans WIP-Limit sofort die Ursache herausfindet und behebt, könnt Ihr Euch die Hälfte der langweiligen Retrospektiven einsparen, weil Ihr die Lernerfahrung immer sofort mitten im Sprint macht und nicht bis zur Retro wartet. Noch später zieht Ihr vielleicht mitten im Sprint einfach ohne Planning weitere Stories nach und schafft die erste Hälfte des Sprint Planning Meetings ab.

Entsprechend für andere Prozesse (z. B. das V-Modell oder einen Marketingprozess oder eine Hochzeit oder was auch immer), die Ihr ebenfalls mit Kanban würzen könnt, um aus einem Stop and Go einen flüssigen Verkehr zu machen. Kanban selbst ist kein Prozess und kein Vorgehensmodell, sondern ein Gewürz, das solltet Ihr wissen. Also ergeben Aussagen wie „wir wechseln von Scrum zu Kanban“ keinen Sinn, sondern z. B. höchstens „wir wechseln von Scrum zu Continuous Flow, Sofort-Retros und 14-tägige Reviews“.

Meine Kunden kriegen immer große Augen, wenn ich von sowas erzähle.

Noch Fragen? Einfach auf meine Membership-Site http://treffpunkt.mbohlen.de gehen, kostenlosen Zugang holen und Fragen ins User Forum schreiben. Ich kümmer‘ mich drum.

Mit seinen Coaching-Programmen und Trainings hilft Matthias Bohlen Führungskräften und Teams, die in der Entwicklung von Produkten tätig sind, dabei, profitable Produkte zur Tür hinaus zu bekommen, ohne dabei den Verstand zu verlieren: Start-Ups und Produktmanager erarbeiten mit Matthias, wie deren neues Produkt aussehen soll, damit es für Kunden unwiderstehlich wird. Kleine und mittlere Unternehmen wollen von ihm wissen, wie sie effizienter und zuverlässiger entwickeln können, z. B. mit Kanban. Unternehmen mit reifen Produkten nutzen Matthias‘ Talent als Softwarearchitekt und Mitglied des iSAQB, um mit seiner Hilfe ihre Produkte wieder wartbar und robust zu bekommen. Alle möchten bei Matthias Soft Skills lernen wie z.B. Präsentieren, Moderieren, Designmeetings leiten, Entscheidungen herbeiführen und Konflikte bei der Arbeit ausräumen. Teammitglieder, die mit Matthias schon gearbeitet haben, nennen ihn den „Team- und Managementflüsterer“. Matthias Bohlen hat eine einzigartige Weise, komplizierte Dinge einfach zu erklären und in kleinen Schritten umsetzbar zu machen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -