5 Most Powerful Acronyms for Agile Coaches

AcronymsPhoto by tuchodi is licensed under CC BY-SA 2.0

Personally I love acronyms, because they serve me as mnemonic for some of the important stuff that I shouldn’t forget as an agile coach. Further they are simple to teach and made to stick. Here are my top 5 acronyms for agile coaches:

FROCC

The Scrum values can be easily remembered with the acronym “FROCC”, the misspelled frog:

Focus – we focus on a few things at a time
Respect – we respect our colleagues like we want to be respected
Openness – we express our thoughts about how we are doing
Courage – the team gives us the courage to take greater challenges
Commitment – we are committed to success

Source: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

DEEP

A well refined product backlog is “DEEP”:

Detailed appropriately – the details are added over time
Estimated – backlog items are estimated
Emergent – a product backlog changes over time
Prioritized – the most valuable items are on top

Source: https://www.mountaingoatsoftware.com/blog/make-the-product-backlog-deep

MoSCoW

When it comes to prioritizing your backlog “MoSCoW” can serve you well. Distinguish your features by:

Must have – the requirement is core and must be satisfied for success
o
Should have – the requirement is should be satisfied for success
Could have – the requirement is desirable but not necessary for success
o
Won’t have – the requirement will not be implemented

Source: http://en.wikipedia.org/wiki/MoSCoW_method

INVEST

“INVEST” in well-defined user stories. A user story must be:

Independent – the user story has no dependency to other stories
Negotiable – user stories can always be changed and rewritten
Valuable – a user story must deliver value to the end user
Estimable – you must be able to estimate the size of a user story
Small – a user story must fit into a sprint, but should be smaller
Testable – a user story must be testable

Source: User Stories Applied (Mike Cohn)

SMART

Make (iteration) goals always “SMART”:

Specific – target a specific goal
Measurable – quantify or at least suggest and indicator of progress
Achievable – be realistic
Relevant – check relevancy of the goal
Time-bound – assign a target-date

Source: http://en.wikipedia.org/wiki/SMART_criteria

Any other suggestions?

Advertisements

The Scrum Master Maturity Model

This blog post is dedicated to Angel Medinilla‘s awesome “Scrum Master Maturity Model”, which describes three levels of maturity a scrum master can reach (before Agile nirvana is reached 🙂 ):

  • The Scrum Dude: Scrum Dudes have rudimentary scrum master skills and little experience with scrum, which results into low-performing and mostly disoriented teams. Scrum Dudes are more like secretaries for their teams.
  • The Scrum Mom: Scrum Moms are solicitous and protective to their teams like a mother for her children. Teams with a Scrum Mum can be well functional, but Scrum Moms miss to challenge their teams, which often leads to stagnation.
  • The True Scrum Master: The true scrum master coaches, leads and develops high-performance teams that are able to self-reflect, learn and continuously improve. She addresses conflicts, keeps the team challenged, encouraged and motivated.

Scrum master maturity model

 

Angel’s model is of high practical value, because it gives us a visual representation of the actual scrum master role we find in the industry. In fact I have met many so-called “scrum masters” who later turned out to be Scrum Dudes or Scrum Moms, but very little who were actually true Scrum Masters. Let’s improve this! We need true Scrum Master to improve our organizations!

Source: http://www.infoq.com/presentations/hire-scrum-master

Innovieren vs Optimieren?

Unternehmen stehen vor dem ewigen Dilemma: Laufen die Geschäfte gut bleibt keine Zeit für Innovation, läuft es schlecht fehlt das Geld um in Innovation zu investieren. Was also tun? Lieber optimieren, statt innovieren!

So scheint mir jedenfalls der übliche Tenor in vielen Unternehmen zu sein. Die Grundzutat für Innovation sind bekannterweise Ideen. Wann haben wir Ideen? Genau dann wenn wir unsere Gedanken schweifen lassen können und einmal nicht im Hamsterrad des Projektgeschäftes laufen. Und da liegt das Problem. Ich behaupte in der Praxis wird vom Großteil der Unternehmen alles versucht um das Hamsterrad auf Touren zu halten – die Auslastung hoch halten. Letzlich kosten die Mitarbeiter ja eine Menge Geld und sie sollen auch etwas dafür leisten.

Ich stelle einmal folgende These in den Raum: Scrum wurde in den meisten Unternehmen eingeführt um:

  • Die Produktivität, Effektivität und Effizienz zu steigern
  • Die time-to-market zu verringern
  • Die Projektrisiken kalkulierbarer zu machen
  • Die Qualität zu erhöhen
  • Um die Mitarbeitermotivation zu erhöhen
  • Um sich einen strategischen Vorteil gegenüber der Konkurrenz zu verschaffen
  • Manchmal vielleicht auch aus Verzweiflung, hervorgerufen durch wiederholtes Scheitern.
  • etc…

Welches Unternehmen hat ernsthaft mit vorrangigen Ziel innovativer zu werden Scrum eingeführt? Ich kann mich natürlich täuschen, aber ich sehe wenig Zusammenhang zwischen innovativen Unternehmen und jenen, die Scrum verwenden. Dabei sind die Voraussetzungen für Innovation aufgrund der innovationsfreundlichen Kultur, die durch Scrum entsteht, gerade zu perfekt:

  • Flache Hierarchien
  • Stark ausgeprägte Netzwerke
  • Hohe Fehlertoleranz
  • Hohe Transparenz

Der Nährboden für Ideen wäre also bestens gegeben, doch muss man ihnen auch den Platz einräumen damit sie wachsen können. Viele werden nach kurzer Zeit wieder absterben, doch einige wenige werden gedeien und sich so gut entwickeln, dass man daraus eine reiche Ernte schlagen kann.

Platz einräumen heißt für mich:

  • Zeit für Kreativität im Arbeitsalltag vorsehen
  • Prozesse für Innovation einführen
  • Die Stelle des Innovationsmanagers besetzen

Anm.: Wenn ich Scrum als Begriff verwende, meine ich damit im weiteren Sinn agile Softwareenwticklungs-Frameworks mit vergleichbarem Mindset

Agile Planung

Seit längerem komme ich wieder dazu einen Blogpost zu schreiben. Es hat sich einiges an Posting-Material in den letzten Monaten angesammelt. Das heutige Thema ist Planung in der agilen Welt.

Kent Beck und Martin Fowler sagen dazu in “Planning Extreme Programming” folgendes:

“We plan to ensure that we are always doing the most important things left to do, to coordinate effectively with other people, and to respond quickly to unexpected events”

In der Praxis zeigt sich immer wieder wie wichtig es ist, den Spagat zwischen Planung und Agilität zu schaffen. Als Scrum Master sehe ich vor allem die Herausforderung der Sprintplanung. Auch im Sprint gilt nämlich: Spät entdeckte Planungsfehler sind teuer!

In meinen Scrum Teams teilen wir das Sprint Planning in 2 Teile:

Sprint Planning 1 (SP1)

Leitfrage: WAS soll in diesem Sprint umgesetzt werden?

Fokus: Fachlich (Business Value, Kundensicht)

Outcome:

  • Fachlich, einheitliche Sicht auf die einzelnen User Stories, die im Sprint Planning vom Product Owner vorgestellt wurden
  • Commitment des Teams, welche User Stories es im Sprint umsetzen kann

Sprint Planning 2 (SP2)

Leitfrage: WIE sollen die im Commitment enthaltenen User Stories umgesetzt werden?

Fokus: Technisch (Design, Architektur)

Outcome:

  • Technisches Design für die im Commitment enthaltenen User Stories
  • Tasks, welche alle Aufgaben zur Umsetzung der User Stories umfassen

Wie immer, sieht die Theorie einfacher aus, als die praktische Umsetzung dann tatsächlich ist. Folgende Probleme treten in der Praxis in der Sprint Planung auf:

Problem Lösungsvorschlag
Im SP1 sind noch fachliche Anforderungen des Kunden unklar. Jene User Stories, die noch unklar sind nicht in das Commitment aufnehmen. Der PO muss sich um die Klärung der Anforderungen erst kümmern. Es macht keinen Sinn diese User Stories zu beginnen!
Für das technische Design ist zu wenig Know-how im Team vorhanden. Architekten, Know-how Träger aus der Domäne zum SP2 einladen.
Im SP2 wird das Design nur oberflächlich geplant. Konkreten “Desired Outcome” für das SP2 festlegen: z.B.: UML Klassen-Diagramme, Interface-Beschreibungen, Tracer Bullets, Tasks < 8h, Codestellen gemeinsam inspizieren, Offene Fragen wenn möglich gleich im SP2 klären.
Für das technische Design ist zu wenig Know-how im Team vorhanden. Architekten, Know-how Träger aus der Domäne zum SP2 einladen.
Das SP2 verläuft unproduktiv. Jeder Entwickler moderiert für eine User Story das SP2, Pausen machen wenn keine Energie mehr vorhanden ist, Jede User Story einzeln planen.
Im SP2 wurden Tasks vergessen aufzuschreiben. Für jede User Story einen abschließenden Check machen, ob alle Tasks für die vollständige Implementierung (+ Tests) der User Story vorhanden sind.
Während der Implementierung (Sprint) herrscht Unklarheit über den Scope der einzelnen Tasks. Wording der Tasks im SP2 genau besprechen, Besser 2 speziellere Tasks statt einen generischen Task aufschreiben, Falls die übliche Taskbeschreibung nicht ausreicht um die Semantik zu klären, eine erweiterte Beschreibung hinzufügen.

User Stories richtig formulieren

In der agilen Softwareentwicklung hat sich das Arbeiten mit User Stories etabliert. Eine User Story beschreibt immer eine Kundenanforderung, den dahinter liegenden Business Case, so wie den Nutzen für den Anwender und dient als Ausgangspunkt für das Entwicklerteam, so wie für die Kommunikation mit dem Kunden, Entwicklern, Product Ownern, Auftraggebern, usw. Im optimalen Fall liegen bei der Erstellung von User Stories definierte Use Cases und Personas vor, die bei der Erstellung von User Stories als Hilfestellung dienen. Der erste Teil der User Story, die High-Level Beschreibung, beantwortet immer möglichst kurz und prägnant folgende Fragen: Wer will Was, Warum tun? (Mike Cohn, 2010) verwendet dafür folgendes Template:

Als <Benutzer / Rolle> möchte ich <ein Ziel> erreichen, damit <ein Nutzen> entsteht.

z.B.: Als Webshop-Kunde möchte ich Waren in einen virtuellen Warenkorb legen, damit ich diese zu einem späteren Zeitpunkt gesammelt betrachten kann.

Wer, Was, Warum möchte ist in dieser Form eindeutig und kompakt ausgedrückt. In der Praxis ist es daher sinnvoll sich an dieses Template zu halten um die drei W-Fragen zu beantworten. Viele Product Owner und Teams meinen jedoch eine noch bessere Variante gefunden zu haben um dies zu bewerkstelligen – meiner Erfahrung nach sind diese Abwandlungen jedoch meist entweder unvollständig in der Beantwortung der W-Fragen oder schlichtweg wesentlich länger in der Beschreibung und damit schlechter verständlich.

So weit, so einfach. Eine User Story soll aber neben der Kundenanforderung auch die notwendigen Details  für die Umsetzung enthalten. Dafür werden Akzeptanzkriterien definiert. Diese sollen Fragen über das Wie, Wann und Wohin beantworten. Sie sollen außerdem als Basis für automatisierte Testfälle dienen. Ich habe mir daher folgende Form bei der Definition von Akzeptanzkriterien angewöhnt:

  • Voraussetzung: Darin werden die notwendigen Vorbedingungen (z.B. Zustand der Software, aktueller Prozessschritt, Zustand der GUI,…) definiert.
  • Auslöser: Darin wird die Aktion (z.B. User Aktion, Eingehender Request, Triggern eines Events,…) beschrieben, die den Soll-Zustand triggert beschrieben.
  • Soll-Zustand: Beschreibt den vom Kunden gewünschten Soll-Zustand mit den notwendigen technischen Details.

Ein Akzeptanzkriterium für die oben definierte Webshop User Story könnte wie folgt aussehen:

  • Voraussetzung: Der Webshop-Kunde befindet sich auf der Produktseite XY und hat die Produktoptionen (Größe, Menge, Farbe) gewählt (siehe <Link zu Mockup 1>)
  • Auslöser: Der Webshop-Kunde klickt auf den Button “In den Warenkorb legen”
  • Soll-Zustand:
    • Der Kunde sieht den Warenkorb (siehe <Link zu Mockup 2>)
    • Das Produkt befindet sich mit den gewählten Optionen im Warenkorb (siehe <Link zu Mockup 3>)
    • Die Tabelle shopping_cart enthält die Produkte, die sich im Warenkorb befinden mit allen Optionen

In der Regel sind 5-10 Akzeptanzkriterien notwendig um das Verhalten der Software ausreichend zu beschreiben. Um den Kontext und die Details näher zu Beschreiben können Klassendiagramme, Systemarchitektur-Diagramme, Mockups, Screenshots, Sequenzdiagramme, Schnittstellendefinitionen, usw. verlinkt oder an die User Story angehängt werden. Ziel ist jedoch die User Story möglichst kompakt und übersichtlich zu halten um den Fokus zu bewahren. Im Zweifelsfall ist es besser eine große User Story in zwei kleine Stories aufzuteilen.

Quellen:

Mike Cohn (2010), Succeeding with Agile Software Development using Scrum, Addison-Wesley, Kap.13, S.239

Prof. Dr. Ikujiro Nonaka in Wien

Letzte Woche hatte ich die Gelegenheit Prof. Dr. Ikujiro Nonaka bei einem Gastvortrag “The Wise Leader” an der Wirtschaftsuniversität in Wien live zu erleben. Nonaka zählt zweifellos zu den wichtigsten Wissenschaftern des Wissensmanagements – dementsprechend groß waren meine Erwartungen und meine Vorfreude. Neben mir waren hunderte Interessierte im Audi Max der WU versammelt und lauschten gespannt einem charismatischen Nonaka.

Der Vortrag war für meinen Geschmack sehr philosophisch angehaucht. Nonaka sprach viel über Visionen, Weisheit, Strategie, Innovationen und Werte, die Manager vermitteln und gestalten müssen. Vor allem sprach er über Phronesis, was er als elementaren Baustein auf den Weg zu einem “Wise Leader” sieht.

Nonaka griff auf Definition von Aristotiles zurück, der Phronesis wie folgt definierte:

“Phronesis is a virtuous habit of making decisions and taking actions that serve the common good.”

Weiters sprach (Nonaka, 2011) über sechs Fähigkeiten, die “Wise Leader” erlernen müssen um Phronesis im Unternehmen zu gestalten:

  1. Die Fähigkeit das Gute zu beurteilen
  2. Die Fähigkeit Räume (jap.: “ba”) zu gestalten
  3. Die Fähigkeit das Essenzielle zu erfassen
  4. Die Fähigkeit das Essenzielle zu kommunizieren
  5. Die Fähigkeit politischen Einfluss zu üben
  6. Die Fähigkeit Phronesis bei Anderen zu fördern

Ich möchte nun auf die sechs Punkte einzeln eingehen.

Die Fähigkeit das Gute zu beurteilen
Neben den Fähigkeiten zu Wirtschaften und zu Führen ist die Zielsetzung für “Wise Leader” moralisch und ethisch korrekt zu handeln. Werte zu vermitteln und Prinzipien zu verfolgen spielt für sie daher eine zentrale Rolle. Der Betrachtungshorizont des “Wise Leaders” geht weit über den des kapitalistisch denkenden Managers hinaus, da dieser die Frage des gesellschaftlichem Nutzens seines handelns stellt.

Die Fähigkeit Räume (jap.: “ba”) zu gestalten
Phronetische Führer gestalten Räume, in welchen ein gemeinsamer Kontext geteilt wird. Dieser gemeinsame Kontext ist die Basis für neues Wissen.

Die Fähigkeit das Essenzielle zu erfassen
Damit beschreibt Nonaka die Fähigkeit sich ständig ändernder Situationen richtig und schnell anzupassen und die richtigen Maßnahmen zu ergreifen.

Die Fähigkeit das Essenzielle zu kommunizieren
Um Andere mit Ideen und Visionen anstecken zu können, müssen Diese klar und deutlich kommuniziert werden. Der phronetische Führer beherrscht die Kommunikation des Essenziellen.

Die Fähigkeit Einfluss zu üben
Damit meint Nonaka die Fähigkeit Menschen zusammen zu bringen und sie zum Handeln anzuspornen, deren Bemühungen und Wissen zur Synthese verschmelzen zu lassen um ein gemeinsames Ziel zu verfolgen.

Die Fähigkeit Phronesis bei Anderen zu fördern
Der Phronetische Führer muss ein System schaffen, in dem Phronesis zwischen den Individuen weitergegeben wird um eine dynamische Organisation zu erreichen, die auf verändernde Bedingungen flexibel und kreativ reagieren kann.

Als Beispiele für phronetische Führer nannte Nonaka Steve Jobs und Soichiro Honda, die seiner Meinung nach die sechs Fähigkeiten des phronetischen Führens besaßen.

Nonaka betonte auch am Beispiel von Apple, dass Unternehmen “Erlebnisse” (Multimedia-Erlebnis) statt “Dinge” (iPod) verkaufen müssen, da sich erst aus dem Erlebnis ein Wert für den Kunden ergibt.

Ganz besonders spitzte ich natürlich meine Ohren, als (Nonaka, 1986) auf Scrum zu sprechen kam. Auch mit Scrum beschreibt er ein Framework, basierend auf Werten, Praktiken und Ritualen um das individuelle Wissen im Produktentwicklungsprozess besser zu verteilen, zu nutzen und produktiver zu werden und legte damit den Grundstein des heute bekannten Scrum in der agilen Softwareentwicklung.

Quellen:

Nonaka (2011), The Wise Leader, Im: Harvard Business Review, May 2011

Nonaka (1986), The New New Product Development Game, Im: Harvard Business Review, January-February 1986