NBA02: Rollen in Kanban? SDM und SRM

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines Agilenteams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt auf der Praxis daher auch der Name NoBullshit Agile. In der letzten Folge habe ich über das Thema das große Ganze gesprochen. Dies ist die Folge 2 und es geht heute um zwei Rollen in Kanban, den SDM und den SRM. Vielleicht kennt ihr das auch. Ich frage mich tatsächlich manchmal, wer bin ich eigentlich? Also was bin ich? Bin ich Projektleiter? Bin ich Account Manager? Bin ich Teamleiter? Und wenn ich ganz ehrlich bin, irgendwie bin ich keins davon und irgendwie bin ich auch alles. Wir machen halt und das ist der Fokus für heute auch Kanban und wenn man sich den Kanban Guide von der Kanban University mal anschaut, dann sind da tatsächlich keine Rollen definiert. Link zum Kanban Guide findest du übrigens in den Show Notes. Das ist beim Scrum und ich habe früher relativ lange Scrum gemacht, auch ein bisschen anders. Wenn man sich den Scrum Guide anguckt, da gibt es ganz klar definierte Rollen. Da gibt es das Dev Team, da gibt es den Scrum Master, da gibt es den PO und die sind tatsächlich relativ gut definiert, was Aufgaben Bereiche anbelangt. Kanban macht das relativ bewusst. Schlussendlich geht Kanban tatsächlich von einem selbst organisierten Team aus und das macht auch total Sinn. Aber es gibt Übergangsphasen von Teams und deswegen hat sich auch in Kanban ein bisschen ein Rollenverständnis entwickelt. Es gibt tatsächlich zwei Rollen, die von Unternehmen die Kanban machen immer wieder benutzt werden. Das ist einmal der Service Delivery Manager, SDM und einmal der Service Request Manager, der SRM. Das Ganze hat mal angefangen, tatsächlich als Microsoft Kanban gemacht hat, 2005 und die haben sich diese Rollen überlegt. Wir fangen mal mit dem SDM, dem Service Delivery Manager an. Der wird oft auch als Flowmaster oder Flow Manager bezeichnet und es zeigt schon ein bisschen, was die Idee dahinter ist. Man könnte ein Gefühl dafür bekommen, für die die Scrum kennen. Der SDM könnte so ein bisschen was wie ein Scrum Master sein. Das ist nicht richtig und nicht falsch. Es geht darum, dem Team zu helfen, eben den Flow im Delivery zu managen. Service Delivery Manager. Also, der SDM hilft dem Team seine Arbeit richtig zu machen, indem er zum Beispiel sich darauf konzentriert, die Liefergeschwindigkeit zu erhöhen, die Kosten zu senken und die Redaktionzeit auf Marktnachfrage zu verkürzen. Also, der SDM hat eine unterstützende Rolle im Team. Er hilft dem Team den Flow zu managen, um das ein bisschen anfassbarer zu machen. Vielleicht eine kleine Aufzählungsliste. Also, in Kanban geht es ja vor allen Dingen um kontinuierliche Verbesserung. Und da hilft der SDM, dass das Team diesen kontinuierlichen Verbesserungsprozess gestalten kann. Er oder sie guckt auf das Kanban-Bord, stellt sicher, dass keine Aufgaben blockiert sind, guckt dabei auch darauf, ob Regeln zum Beispiel explizit gemacht sind und ob Regeln eingehalten werden. Er oder sie kann Kanban-Besprechung durchführen. Also, es gibt ja auch in Kanban die Möglichkeit oder ich sage mal sogar die Notwendigkeit, sich abzustimmen. Deswegen ist so was wie ein Kanban-Meeting, ein Kanban-Daily sehr verbreitet und da hilft der SDM eben. Er oder sie ist auch sicherlich dafür zuständig mit Task-Ohnern zu sprechen, wenn sich bestimmte Tas verzögern. Also, normalerweise, das sind wir wieder bei der Selbstorganisation, würde ja das Team selber darauf kommen, wenn sie das dritte Mal im Daily über den Task sprechen, dass es da anscheinend irgendwie nicht weiter geht. Der SDM hilft dem Team da halt und der SDM passt ein bisschen darauf auf, dass die Regeln eingehalten werden. Er ist ein Facilitator, das ist ein schwieriges Wort, aber wie gesagt, er unterstützt halt das Team bei ihren Tätigkeiten. Die zweite Rolle, die es gibt, der Service Request Manager, ist im Prinzip der Counterpart. Also, wenn wir uns mal so ein Kanban-Bord angucken und den Flow angucken, dann haben wir, ich sage einmal, die rechte Seite, das was ich gerade beschrieben habe. Eine rechten Seite findet die Entwicklung statt, die Entwicklung des Testings, die Lieferung des Inkrements oder die Lieferung von Aufgaben im Kanbansystem. Und was ich mit linker Seite meine, ist die Vorbereitung all der Arbeit. Also Anfragen vom Kunden, die reinkommen, die analysiert und untersucht werden müssen. Da geht es sicherlich auch um Angebote, aber es geht auch um die Requirementanalyse. Was möchte der Kunde, die Beratung des Kunden an dieser Stelle, das ist so in meinem Schaubild, was ich hier vor mir habe, die linke Seite. Man könnte das vereinfachen und sagen, linke Seite ist das Backlock, vielleicht habt ihr das noch ein bisschen feiner unterteilt. Und rechte Seite ist der Umsetzungspart. Und wie gesagt, für die rechte Seite gibt es den Service Delivery Manager und auf der linken Seite gibt es den Service Request Manager. Der Service Request Manager ist jetzt eben derjenige, der, ich sage mal, die Kundenseite betrachtet. Das ist kein Product Owner. Also ich habe hier so mir das Schlagwort hingeschrieben, no hero product owner, finde ich eigentlich ganz passend. Es ist Kunden orientiert. Ich sammel und ich priorisiere zusammen mit dem Kunden seine Anforderungen, bringe die so weit, dass sie ready for development sind, um sie dann eben an das Team übergeben zu können. Sprich, wir haben diese Übergabepunkt, dem Commitment Punkt zwischen Stories und Anforderungen, die ready for development sind und dann eben die Abgabe ans Team für die Umsetzung. Diese Rolle ist tatsächlich nicht so verbreitet in der Praxis, wie die des SDM, des Service Delivery Managers, weil die Service Request Manager Rolle oft schon besetzt ist. Also oft genug gibt es eben Product Manager oder Kundenbetreuer, Account Manager oder Projekt Manager, die eigentlich schon diese Rolle übernehmen. Ich, das war so eine meiner Eingangsfragen, finde sie passt super gut zu dem, was ich mache. So verstehe ich mich auch. Ich bin halt der andere Teil der Unterstützung des Teams und versuche, die Aufgaben so weit vorzubereiten zusammen mit dem Kunden, dass hinten das rauskommt, was der Kunde sich auch vorstellt, inklusive dem, was das Team noch an Ideen dazu hat. Abschließend vielleicht noch alle Literatur, alle Links dazu, findest du in den Show Notes. Ich denke einfach, solche Rollen sind eine gute Hilfe und eine gute Unterstützung in Phasen, wo das Team eben noch nicht vollständig selbst organisiert ist. Die vollständige Selbstorganisation eines Teams, da komme ich sicherlich auch noch mal in der Folge drauf. Ja, und damit denke ich, dass wir heute schon durch sind. Wenn du Feedback hast, dann gerne unter anderem als Mail an nobs@gmail.com. Alternativ findest du mich auch auf Mastodon unter nobullshit@podcast.social. Hab eine tolle Woche und bis zum nächsten Mal. Bye. [Musik] [Musik]