Ein Team und seine Verträge

Presentation 30'

Abstract

Worum es in dieser Session geht:

Eine sehr wichtige Eigenschaft von Kanban ist "mache Prozessrichtlinien explizit". Das schließt auch wohldefinierte Schnittstellen zu den Partnern stromaufwärts (z.B. Fachbereich, Helpdesk) und stromabwärts (z.B. Betrieb) mit ein. Kanban versucht, diese Schnittstellen auf einem sehr abstrakten Niveau zu definieren, weil Kanban ein Ansatz für Change Management ist und sich mit mehreren möglichen Projektmanagement-Ansätzen integrieren möchte, ohne Annahmen über sie zu machen.

Aus der Softwareentwicklung wissen wir, dass es gut ist, das Verhalten einer Schnittstelle als eine Form von Vertrag zwischen Client und Service zu definieren, indem man Beispiel-Szenarios, Zusicherungen, Deliberate Discovery, Behavior Driven Development, TDD, Design by Contract usw. benutzt. Kann man das auch auf die Prozessrichtlinien in Kanban anwenden?

In dieser Session würde ich gerne Fragen wie diese ansprechen:

• Woher wissen die Business-Leute (Fachbereich, Management, usw.), was das Team als Leistung anbietet - insbesondere, wenn sie es erst seit kurzer Zeit kennen oder wenn das Team neu gegründet wurde?

• Woher weiß das Team, was es kann? Sind sich die Leute der eigenen Fähigkeiten bewusst und sind sie entschlossen, diese anzubieten?

• Lassen sich die im Vertrag beschriebenen Leistungen auch quantitativ fassen? Welche Messgrößen sind wichtig und welche tragen nur zur Konfusion bei?

Was Sie erwartet und was Sie lernen können:

Ich hinterfrage in einem kurzen Folienvortrag die Erwartungen an ein Team, die man in der Literatur oder im Netz findet. Ich frage auch, ob Teams typischerweise bereit sind, über ihre Schnittstellen nachzudenken und schlage vor, dass ein Denken in Verträgen helfen kann, über einen längeren Zeitraum hinweg die Leistungen immer weiter zu verbessern.

Sowohl die Business-Leute als auch das Team haben etwas davon:

• Die Business-Leute wissen woran sie sind und entwickeln Vertrauen in das Team.

• Das Team bekommt eine klare Vorstellung von dem, was es anbieten will und kann Ehrgeiz und Stolz entwickeln, indem es seine Leistungen immer weiter verbessert.

• Das Team wird sich bewusst, dass es nicht allein ist, sondern von weiteren Verträgen abhängig (z.B. von Domänenexperten oder vom Betrieb).

• Team und "Drumherum" können lernen, sich als System zu verstehen, in dem alle gemeinsam für den Erfolg verantwortlich sind.

Beispiele für das, was kommt:

Am Anfang führe ich Behavior Driven Development in 2 Minuten ein. Dann benutze ich daraus die Standard-Form GEGEBEN/WENN/DANN, um interessante Szenarios aus den Verträgen zu besprechen:

GEGEBEN ein Team mit nicht-leerer Queue (Anforderungswarteschlange)

WENN Team-Mitglied ein Ticket auf "in Arbeit" zieht

DANN startet ticket.cycleTime

GEGEBEN ein Ticket in Arbeit

WENN Team das Ticket auf "done" zieht

DANN stoppt ticket.cycleTime

Das war trivial. Was ist aber mit diesem hier:

GEGEBEN ein Ticket, das gerade abgeschlossen wurde

WENN Team eine Cycle-Time berichtet, die größer ist als im SLA vereinbart

DANN // was machen wir da?

Oder dies hier:

GEGEBEN die Queue (Anforderungswarteschlange) eines Teams sei voll

WENN Business-Leute noch ein weiteres Ticket der Klasse "festes Lieferdatum" hinzufügen möchten

DANN Team schlägt vor, anderes Ticket der Klasse "nicht fassbar" loszuwerden

DANN Business-Leute entfernen nicht fassbares Ticket aus der Queue // tatsächlich???

DANN Business-Leute fügen Ticket mit festem Lieferdatum zur Queue hinzu // tatsächlich???

Und so weiter. Durch diese (und noch kritischere und interessantere) Szenarios können wir die Prozessrichtlinien, die in Benutzung sind, untersuchen. Business und Team versuchen gemeinsam, den Prozess für alle Partner, die am Wertstrom leben, immer besser "bewohnbar" zu machen.

Speaker

Matthias Bohlen

\ No newline at end of file