Der agile Knoten - alle aufgelöst? Mit Kommunikation von Kopitzke® gelöst

Das große, Ganze

Ist dieses „große Ganze“ dem Management noch diffus oder unklar, ist die Auswahl einer (einzigen oder bestimmten) Methode obsolet. Also heisst es, erst mal Hausaufgaben machen, die Puzzleteile (für eine strategische Ausrichtung) richtig zusammen setzen, die Bereiche zu identifizieren, wo eine Change mit agilen Methoden nicht nur sinnvoll, sonder auch angeraten ist und dann erst (aus dem Methodenkoffer) die geeigneten Tools identifizieren, die zukünfig verwendet werden sollen. Wichtig ist, so wie in dem Bild dargestellt, dem Bereich „Kultur, Werte“ besondere Aufmerksamkeit zuteil werden zu lassen.

Werte basieren auf Überzeugungen und Glauben. Ein Glaube kann nur durch einen besseren ersetzt werden. Das heisst: Die Arbeit mit Werten ist hoch kommunikativ, interaktiv (auch) impulsiv und Sie werden nicht jeden, gemäß dem Gesetz der großen Zahl und der gauss’schen Normalverteilung, erreichen können. Statistische (und auch evolutionäre) Wahrheit ist, dass genau die in der Normalverteilung alle Befindlichen den Change auch begleiten werden – mehr oder weniger – die anderen nicht.

Ein Quickview zu …

Kanban:

Kanban kommt. Neben Fertigern, ja, auch Software- Entwicklern (in bestimmten Bereichen) und Agenturen nutzen Scrum und Kanban für unterschiedliche Projekte und Teams. Scrum passt nicht immer – und im Gegensatz zu Scrum handelt es sich bei Kanban (frei übersetzt: Karte, Aufkleber, Etikett) um einen methodischen Ansatz, der einen kontinuierlichen Arbeitsfluss (Flow) absichert. Basis dafür sind 2 Dinge: ein Board, dessen physikalische Größe definiert ist und somit die Menge der zu bewegenden Karten begrenzt. Die Karten auf dem Board visualisieren alle Aufgaben und Abläufe (also auch die Probleme, die diese behindern) – also eine Karte je Item, das ist eine Vorraussetzung! Das Board ist in Zeilen und Spalten (Lanes) aufgeteilt.

Ein Kanban-Board: Die Karte wandert …

Scrum:

Die Rolle mit Methode. Ein Scrum-Projekt beginnt damit, dass der Product Owner (Rolle) das Product Backlog (initial) herstellt. Auf Papier oder elektronisch mit geeigneten Tools. Dieses ist eine priorisierte Aufgabenliste für das Team. Der Product Owner hat die Funktion inne, die am nähesten am Kunden / Auftraggeber ist und sich mit diesem austauscht. Die Aufgaben bestehen aus einer Menge von (granulierten, gut beschriebenen – und hier passieren leider viele kommunikative Fehler) Teilaufgaben, die in einem Sprint (ein Iterationszyklus), also einem fest definierten Zeitraum (2-4 Wochen) abgearbeitet werden. Während der Planung – dem Sprint ‚-Planning‘ oder ‚-Grooming‘ – greift sich das Team die (Teil-) Aufgaben aus dem Product Backlog heraus, die es in der vorgegebenen Zeit realistisch umsetzen kann.

Dabei werden Aufgaben und ToDos, die vollständig beschrieben und definiert sind, priorisiert – sofern diese von Kunden / Auftraggeber und dem Product Owner (PO) ebenfalls derart eingestuft werden. Das Team entscheidet gemeinsam, wie es dabei vorgeht (Team Commitment – was selten nutzbringend funktioniert). Eine weitere Rolle (Funktion) ist der Scrum Master (SM), der sich um das Team, die Menschen und technische als auch soziale Impediments kümmert. Der Product Owner (PO) ist primär für den Erfolg des Projekts und den ‚Return on Invest‘ verantwortlich.

Der Scrum Master sorgt dafür, dass alle den Prozess verstehen und einhalten. Die hohe Kunst ist, die Methode zu ‚leben‘. Der SM stellt sicher, dass das Team ungestört arbeitet. Störungen am Prozess und am Ergebnis werden vom SM beseitigt oder aktiv (aus-) getrieben, bis diese beseitigt sind. Das Ergebnis eines jeden Sprints ist ein Projekt- oder Produkt- Inkrement (im Idealfall etwas, was gezeigt werden kann und auch funktioniert – bitte keine PPT.), dessen Qualität einen Review-Prozess erfolgreich bestanden hat und somit an den Kunden ausgeliefert werden kann.

Eine Retrospektive im Anschluss beleuchtet den abgelaufenen Sprint, wobei Qualität auf 2 Ebenen geprüft wird: Aus Sicht den Kunden und in Bezug auf den Scrum-Prozess: Wie geht es dem Team (immer derzeit)? Funktionieren die Werkzeuge? Im nächsten Sprint wählt das Team die nächsten, hoch priorisierten Aufgaben aus dem Product Backlog, die der Project Owner als besonders relevant definiert hat – und der nächste Sprint beginnt. So ‚könnte‘ es sein …

Scrum BUT:

Typische ScrumButs: Unternehmen führen (oft mit Euphorie und auch daran geknüpfte Erwartungen) Scrum ein und erzielte direkt erste Erfolge. Die ersten Retrospektiven zeigten schnell, dass sich die Prozesse und die Ergebnisse mit Scrum stetig verbessern lassen – nur auf prozessualer Ebene. An dieser Stelle ist jedoch Vorsicht geboten: Wer Scrum einführt, für den ist die Versuchung schnell gegeben und auch oftmals groß, direkt eigene Modifikationen an Scrum vorzunehmen (ScrumButs ) und wichtige Elemente wegzurationalisieren. Der Part mit den Tickets in JIRA z.B. ist hipp, die Parts, wo es an das Eingemachte (der Entwickler des Teams oder Werten) geht, ist ‚hopp‘ erledigt – ohne Tiefgang oder gar ‚flop‘, weil niemand sich wirklich im Sinn der Sache öffnen will.

Also wird es einfach weggelassen, ohne genau zu reflektieren, warum das Framework Scrum so ist, wie es ist. Die wirklichen Auswirkungen zeigen sich dann später und dann auch vehement. Die für den Erfolg existenzielle Bedeutung aller Elemente wurden (noch) nicht komplett verstanden. Typische Beispiele für so einen ScrumBut sind, die einem Sprachmuster folgen: ‚Wir nutzen Scrum, aber wir …

  • verzichten auf den Scrum Master, …
    • da das Team zu klein ist.
    • weil der ja keinen Nutzwert hat (nicht testet oder programmiert)
  • brauchen das aufwändige Schätzen des Aufwands einzelner Aufgaben nicht.
  • verlängern die Sprints, bis wir das Ziel erreichen.
  • kommen ohne die (lästigen) Retrospektiven aus.
  • brauchen keine Definition of Done – Die Entwickler wissen (schon), wann sie fertig sind.
  • kriegen das mit den Störungen der übergeordnete Projektleiter mit Sonderaufgaben, die da nicht reinpassen, schon hin.

Es gibt noch mehr Gründe, warum ein Team nicht das komplette Potential aus Scrum heraus holen kann. Es ist an einem Punkt angekommen, an dem es glaubt (aha, aber nicht weiss), Scrum funktioniert weder für das Team noch bzw. das Projekt und muss modifiziert werden. Das ist ein Trugschluss, auch wenn ScrumBut seine Existenzberechtigung hat. Aber bitte nur dann, wenn das Team und der Scrum Master eine genaue Reflektion und eine gezielte Entscheidung dafür getroffen hat, die dann auf fundierten, stichhaltigen Gründen basiert. Keine Zeit oder nur zu aufwändig (ein sehr beliebtes ausweichen) gehören nicht dazu, weil diese Vorwände auf Störungen, die weitaus tiefer liegen oder größer sind, hinweisen. In diversen Settings kommen ScrumButs dann zum Tragen, wenn man sich mit der Basis, den agilen Grundsätzen nicht recht anfreunden möchte (oder will, das ist die gefährlichere Form – dann liegen die wirklichen Impediments viel tiefer).

Sedimentierung:

Besonders anfällig scheinen vor allen Dingen Unternehmen zu sein, in denen die Strukturen und internen Abläufe über Zeiträume gewachsen sind, die bei der Einführung von Scrum mindestens angepasst, wenn nicht sogar über Bord geworfen werden müssten. Ich nenne das „Sedimentierung“ in fortgeschrittenen Stadium. An dieser Stelle greift ein natürlicher Widerstandsreflex: Der der liebgewonnenen Gewohnheiten bis hin zur Abgabe von Macht und Einfluss. Der eine oder andere behauptet, dass man bestimmte Dinge nicht ändern könne – hören Sie dann mal genau auf die Begründungen. Um einer längeren Diskussion oder gar Auseinandersetzung aus dem Weg zu gehen, passt man kurzerhand das neue System an alte Gewohnheiten an und höhlt es damit aus. Das ist ein agiler Trugschluß.


©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend