Ein anderer ScrumMaster erzählte mir dann, wie er kürzlich mit einer solchen Situation umgegangen ist. Er hat den Spieß quasi umgedreht. Nachdem das Team über die Vor- und Nachteile einer bestimmten agilen Praktik (automatisierte Tests) diskutiert hatte und sich dann als Team dafür entschieden hatte, diese Praktik fortan anzuwenden, hat er sich nochmals davon überzeugen lassen, um die Entscheidung zu verstärken.

Er begab sich in die Position/Haltung des Nichtwissens und ließ sich von den Teammitgliedern erklären, warum sie nun „unbedingt“ die Praktik einführen wollen. Dabei hat er so getan, als würde er das Vorgehen selbst nicht kennen und somit auch nicht die damit verbundenen Vorteile. Mit interessiertem Nachfragen hat er das Team dazu gebracht, ihm genau zu erklären, wie diese Tests funktionieren und warum es gut ist, automatisiert zu testen. Mit neugierigem Nachfragen hat er sich vergewissert, ob die Wirklichkeit des Gegenübers mit seiner übereinstimmt bzw. hat er die innere Landkarte des Teams besser kennengelernt. Er hat nicht einfach etwas angenommen und sich mit Hypothesen aus der vorangegangenen Diskussion zufrieden gegeben, sondern über diese Intervention seine und die vom Team konstruierte Wirklichkeit miteinander abgeglichen.

Nach einiger Zeit sagte er dann: “Achso, ihr wollt also diese automatischen Tests machen!”

Geradezu erleichtert rief das Team im Chor: “JA, GENAU!!!!” (Und meinte damit: “Endlich hat er es verstanden!!!”)

Kann man sich ein schöneres Commitment für die Anwendung einer bisher nicht genutzten agilen Praktik vorstellen, die man an viele Teams nur mit Mühe und Not herantragen kann?

Leider war ich nicht dabei. Bei der nächsten Möglichkeit werde ich mich aber auch mal überzeugen lassen anstatt überzeugen zu wollen!

Related posts:

1. Die Sicherheitsfrage in der Retrospektive oder der Wert eines klaren Neins
2. Über das Schreiben: Leidenschaft | Passion | Freewriting
3. ScrumMaster vs. ScrumMasterin

Auf der Suche nach Separators (Unterbrechern zwischen den Sequenzen “Was lief gut?” und “Was kann verbessert werden?”) für eine Retro bin ich auf drei ganz einfache und doch wirkungsvolle kurze Übungen gestoßen. Sie lassen sich ohne großartige Vorbereitung und Zeitaufwand durchführen und können je nach Retro-Ziel eingesetzt werden.

Variante 1 habe ich letzte Woche ausprobiert. Nach dem anfänglichen „Wie jetzt? Wir sollen bis 3 zählen? Ist das Dein Ernst?“, stellte sich schnell Überraschung ein. Es stellte sich nämlich heraus, dass es nicht so einfach ist, wie gedacht.

Durch die Kombination von kognitiver und physischer Aktivität verbinden sich unterschiedliche Bereiche im Gehirn. Dadurch wird auch das einfache Zählen bis 3 zu einer Herausforderung!

Variante 1: 1, 2 … 3

ca. 3-5 Minuten – mindestens 2 Personen

• Jeweils 2 Personen tun sich zusammen und zählen bis 3. Dabei wechseln sich die Personen immer ab (Person 1 zählt 1, Person 2 zählt 2, Person 1 zählt 3, Person 2 zählt 1, Person 1 zählt 2 usw.).
• Nach ca. 30-40 Sekunden hin und her zählen gibt es eine neue Vorgabe: Die Zahl 1 muss jedes Mal durch z.B. ein Klatschen ersetzt werden.
• Wieder 30-40 Sekunden später wird die 2 durch hüpfen, stampfen, Füße anheben etc. ersetzt. Als Beobachter und Spielanleiter ist es lustig, die Gesichter der Zähler zu beobachten – man kann ihnen die Konzentration quasi ansehen.
• Je nach Belieben kann man weitere 30-40 Sekunden später auch die 3 durch eine Geste ersetzen. Nicken, auf den Tisch klopfen, einmal in die Runde drehen etc. Vielleicht hat auch einer der Zähler eine gute Idee.

Nachher kurz fragen, was beobachtet wurde, bzw. wie man sich bei den Änderungen der Vorgaben gefühlt hat. Evtl. kann man die Brücke zur aktuellen Situation (Veränderung im Unternehmen, Scrum im Allgemeinen) schlagen: einfache Regeln können schwer zu befolgen sein, Koordination, zeitliche Abstimmung und Synchronisation sind nicht einfach. Bei Veränderungen braucht es immer wieder eine gewisse Zeit, bis man sich auf die neuen Rahmenbedingungen und das Gegenüber eingestellt hat.

Variante 2: 33 / 42

ca. 5 Minuten – mindestens 3 Personen

• Teilnehmer stehen im Kreis und rufen nacheinander (z.B. reihum) die Zahlen von 1 bis 33 (oder eine andere beliebige Nummer – je nachdem, wie lange es dauern soll).
• Immer wenn die Zahl durch 3 teilbar ist oder eine 3 enthält, wird ANSTATT die Zahl zu rufen, gemeinsam in die Hände geklatscht (oder eine andere Geste ausgeführt).
• Wird ein Fehler gemacht, fängt man wieder bei 1 an – bis die Gruppe es zu der vorgegebenen Zahl schafft.

Hier muss man mitdenken und den anderen zuhören. Man kann nur als Team liefern!

Variante 3: Blindes Zählen

ca. 10-15 Minuten – mindestens 5 Personen

• Die Teilnehmer stehen im Kreis und schließen ihre Augen.
• Es soll laut bis 10 gezählt werden. Jede Zahl darf aber nur von einer Person und einmal genannt werden.
• Wird eine Zahl von zwei oder mehr Personen laut genannt, fängt man von vorne an.

Hier ist Kollaboration gefragt. Möglicherweise kommt das Team drauf, dass eine Person komplett alleine zählt oder sie eine bestimmte Reihenfolge festlegen.

Wo ich das gefunden habe, gibt es noch mehr :-): http://agiletrail.com/2012/03/27/8-great-short-games-for-groups/ – vielen Dank fürs Teilen! Oder versucht das Linie-Überqueren von David aus.

Viel Spaß beim Ausprobieren und Variieren!

Related posts:

1. Warum sind soziale Systeme so schwer steuerbar? Ein Erklärungsversuch.
2. Vorweihnachtsretro
3. ScrumMaster vs. ScrumMasterin

Manz/Sims (1986, S. 148ff.) sehen als Grenzverhalten einer externen Führungskraft die Kommunikation zu dem und von dem Management (1), die Funktion als Bindeglied zwischen Arbeits-Teams in Bezug auf Kommunikation (2) und Unterstützung des Produktionsflusses (3), Training unerfahrener Teammitglieder (4), das Bereitstellen von Arbeitsmaterial (5), die Ermutigung zum Übernehmen anfallender (fremder) Aufgaben (6) und die Abstimmung mit anderen Teamleitern (7).

So weit, so gut. Es findet sich also eine Menge Theorie in Scrum und eine Menge Führungstheorie selbstorganisierter Teams in der Rolle des ScrumMasters wieder. Dem gerecht zu werden, ist in der Hektik und vor allem bei der Umstellung auf Scrum nicht immer einfach. Nichtsdestotrotz sollte es immer wieder die Richtschnur sein, an der die Tätigkeiten der ScrumMaster ausgerichtet und priorisiert werden. Viel von den Bereichen ist durch den Scrum Prozess berücksichtigt – wir müssen also “nur” darauf achten, dass es richtig gelebt wird und vor allem darauf vertrauen, dass es funktioniert. Der Weg zu Selbstorganisation auf einem hohen Level ist jedoch nur durch das Commitment aller, mit Konzentration, Zeit und Inspect and Adapt möglich.

Related posts:

1. 15 Minuten sind 15 Minuten
2. Der ScrumMaster: Status, Position, Rolle
3. Scrum – eine Revolution (4)

Ich gebe zu, man könnte es als luxuriös bezeichnen, eine komplette Woche mit einem neuen Team zu verbringen, bevor der tatsächliche Sprint startet. Mittlerweile betrachte ich es aber als notwendig, vor allem wenn das Team vorher nicht zusammen und nicht mit Scrum gearbeitet hat. Vor allem aber, wenn die Teammitglieder nicht daran gewöhnt sind, zu diskutieren und sich einzubringen.

Was man eine ganze Woche lang macht?

1) Scrum Basics vermitteln

Jeder hat über den Flurfunk oder die Unternehmenskommunikation im Rahmen der Einführung von Scrum bestimmte Buzzwords mitbekommen. Manche haben sich selbst eine Vorstellung gemacht, andere nachgelesen und wieder andere können mit den Begriffen nichts anfangen. Also, in Kürze – einen Tag – Rollen, Meetings, Artefakte. So legt man zumindest gleich zu Beginn die Grundlage für ein gemeinsames Verständnis – und eine gemeinsame Sprache verbindet zusätzlich.

2) Das Team kennenlernen

Ob ScrumMaster, Product Owner oder Teammitglied: Jeder ist neu im Team. Daher sollte man sich die Zeit nehmen, sich über die gewöhnliche Vorstellungsrunde mit Namen und Abteilungskürzel kennenzulernen. Ich bereite zwar eine Art Story Map vor, lasse dann aber die Teammitglieder durch Punkte entscheiden, was sie machen wollen, um sich, Scrum, die Hintergründe und den organisatorischen Rahmen kennenzulernen.

3) Vision und Backlog

Sich (als ScrumMaster) Zeit nehmen, den Product Owner gründlich auszufragen: Was ist das Produkt? Wer die Nutzer? Und welchen Nutzen wollen wir für sie bereitstellen? Kann man eine Vision erarbeiten oder fehlt es dafür an etwas?

Oft wundert man sich, dass es ein Team gibt und man vermeintlich starten kann, aber noch gar nicht richtig klar ist, was gemacht werden soll. Wenn man Glück hat, ist es für eine “strategische Runde” noch nicht zu spät, bevor die Verwirrung das ganze Team erfasst. Im besten Fall kann der PO nochmal drüber schlafen und nochmal weiterentwickeln, schärfen oder verwerfen, bevor er das Ergebnis zum ersten Mal mit dem Team diskutiert.

Vor allem einen nicht fertige Vision, ein mageres Backlog und die gemeinsame Erarbeitung der Personas mit dem Team laden zum Teilen der Meinungen ein. Durchstreichen erwünscht – und das ist “analog” einfacher als in einer ppt. Gemeinsam geschriebene User Stories, selbst wenn man nachher nicht alle braucht, machen deutlich, wie schwierig oft der Nutzenaspekt ist. Vor allem wenn man den Kunden bereits kennt und in der Regel einfach abarbeitet.

Gebt den Teammitgliedern etwas Zeit, wenn sie nicht gleich zu Beginn eifrig diskutieren. Oft sind sie es nicht gewöhnt, gefragt und gehört zu werden.

4) Infrastruktur und Wissen

Einen Raum beziehen, Rechner neu aufstellen, ein Taskboard bauen, weitere benötigte Infrastruktur- und Testumgebungen identifizieren, ggf. eine Schulung zu für das Team wichtigen Inhalten organisieren.

5) Definition of Done

Was ist selbstverständlich? Was wäre gut, wenn man es tun würde? Und was würden wir gerne tun, haben aber nicht die Mittel? Arbeitsweisen und Begriffsverwendungen variieren oft schon, wenn man die Seite des Flurs wechselt, ganz zu schweigen von Abteilungen. Das Sammeln der Antworten auf die Fragen oben ist für mich eine Herangehensweise, dem Team die Möglichkeiten und weniger die Doku-Regeln hinter der DoD zu vermitteln. Außerdem füllt sich das Impediment Backlog fast wie von selbst und das Team gibt bereits vor dem ersten Planning ein Commitment ab – und sei es nur um zu versuchen, die selbst gesteckten hohe Qualitätsziele zu erreichen.

First Things First – sich Zeit für die strategische Planung nehmen, bevor man in der Taktik der neuen Situation versinkt. Es lohnt sich und ist genauso ein Bestandteil von Scrum wie die Sprints.

Related posts:

1. Die drei weiteren Rollen in Scrum
2. Schätzen vs. Planen?
3. Vom Los- und in die Freiheit lassen

Nun ist es aber doch dringend, man könne die Systemdoku doch auch machen, nachdem die Abnahme vom PO erfolgt sei. Sie wäre ja schließlich sowieso nur von Entwicklern für Entwickler, den PO würde das nicht interessieren und er würde es auch nicht lesen. Vielleicht würde er noch Fehler finden oder Anpassungen haben wollen und dann müsse man die doch dringender machen als die Systemdoku. Ein Implementierungs-Task sei schließlich wichtiger als ein Doku Task …

Die Biegbarkeit der DoD

Ich diskutierte lange mit dem Teammitglied über Sinn und Unsinn der DoD. Als dann das Argument fiel “Dann müssen wir eben die DoD anpassen, da steht sowieso zu viel drin! Und du hast gesagt, dass das Team die DoD festlegt, stimmts?”, mischte sich ein weiteres Teammitglied ein. Zuerst stimmte er in den Chor der DoD-Kürzung ein, doch bei ernsthafter Betrachtung stellte er fest: “Naja, der faule Entwicklerteil in mir sagt, dass wir etwas streichen sollten, aber der vernünftige sagt, dass wir es sonst nur wieder aufschieben. Dann wird es so wie in den alten Projekten: Die Doku machen wir, wenn wir noch Aufwand übrig haben! Und dann hat man natürlich keinen Aufwand übrig!”

Im Nachgang, als ich von dem Erlebnis erzählte, wurde mir klar, dass Scrum wahrscheinlich einfach eine Methode ist, mit der sich Menschen selbst überlisten. In einem guten Moment schreibt man alles auf, was sinnvoll ist und committet sich schnell dazu, bevor man es sich wieder anders überlegt. Später fragt man sich an der einen oder anderen Stelle, warum genau man sich auf so etwas eingelassen hat. Hätte man nicht gleich sehen können, wie unrealistisch das ist bzw. wie viel Disziplin nötig ist, um das dauerhaft einzuhalten? Immerhin würden mir heute tausend Gründe einfallen, warum etwas anderes viiieel wichtiger ist als Doku, nochmaliges komplettes Testen nach einer minimalen Änderung, Testautomatisierung etc.

Pilotprojekten wird oft ein großer Vertrauensvorschuss gewährt. Man hebelt die “normalen” Prozesse aus und vertraut, dass das Team mit seinem eigenen Anspruch eine hohe Qualität liefert. Das ist gut und richtig. Oft jedoch holen einen alte Verhaltensweisen wie Featuredruck oder das Ziel der Performance-Steigerung schnell ein. Die Teammitglieder sind gewohnt an der Qualität zu sparen, wenn es knapp wird, kurzfristige vermeintliche Erfolge über z.B. die Wartbarkeit zu stellen. Im Einzelfall scheint es daher manchmal kleinkariert, auf den Regeln zu beharren. In dieser Situation sollte man sich schleunigst daran erinnern, dass man sich aus gutem Grunde selbst ausgetrickst hat.

Related posts:

1. Commitment des Product Owners
2. Fussball EM und 3 Sprints | Scrum ist überall !
3. Warum wir eigentlich alle Freelancer sind

• „How does one lead others who are supposed to lead themselves?“ (vgl. Stewart/Manz, 1995, S. 750.) oder
• „If self-managing teams are truly self-managing, then why should an external leader be required?“ (Manz /Sims , 1987, S. 106)

Solche Fragen tauchen nicht nur in Scrum auf, sondern begleiten die Forschung und Praxis selbstorganisierter Teams seit jeher. Schon 1986 versuchten sich Manz/Sims in ihrem Artikel “Leading Self-managed Groups: a Concept  Analysis of a Paradox” an einer integrativen Perspektive zur Führungsrolle in selbstorganisierten Teams. Dabei fassen sie auf Grundlage der sozio-technischen Systemtheorie und der sozial-kognitiven Lerntheorie das im Folgenden beschriebene Führungsverhalten zusammen. Da mir beim Lesen und Zusammenstellen vieles doch sehr bekannt vorkam, werde ich einfach die entsprechende Scrum-Sicht der Dinge ergänzen. In diesem Blog die gruppeninternen Aufgaben (direkt auf die Gruppe bezogen) und beim nächsten Mal die Aufgaben/Verhalten an der Grenze von der Gruppe zur Organisation.

Obwohl es in der Darstellung nicht explizit benannt wird, betrachten Manz/Sims (1986, S. 147) externes Führungsverhalten. Vielleicht hilft die Aufstellung dem einen oder anderen bei der Argumentation, warum wirklich ein ScrumMaster pro Team bzw. nur ein Team pro ScrumMaster drin ist!

Ich finde es immer wieder faszinierend, wie viel in der ScrumMaster Rolle untergebracht ist und wie oft die Organisationen dennoch an ihrer Berechtigung zweifeln. Ein guter ScrumMaster zu sein ist verdammt schwer und mit Sicherheit kann man all diese Punkte nicht von der ersten Stunde an abdecken. Aber wenn man gleich nach einer eventuellen ersten Schonfrist neben dem einen Team noch ein oder zwei weitere aufgebrummt bekommt, nimmt man sich (die Organisation sich selbst) die Möglichkeit zu lernen, zu wachsen und den Nährboden für richtig gute ScrumMaster !!!

Quellen

Manz, C. &  Sims, H.  (1986): Leading Self-managed Groups: a Conceptual Analysis of a Paradox, Economic and Industrial Democracy Vol. 7, S. 141-164.

Gloger, B. (2012): Scrum Checklist.

Related posts:

1. Selbstorganisation in Scrum: stets gefordert – selten klar!
2. Der ScrumMaster – Wirklich ein Weichei?
3. 5 min on Scrum | Es gibt noch viel zu tun

When working with geographically dispersed teams (where the members of one team are spread across different locations), the team members and I find it rather difficult to keep focused on the phone during the entire Sprint Planning 1 and 2. Even more so when considering the different time zones. As one part of the team comes in right after lunch, the other part is nearly on their way home, while the third part is starving for lunch. In this situation, the retrospectives showed that the quality of the Sprint Planning 2 and the common understanding of the design ideas should be improved. Additionally, I (as ScrumMaster) wished to improve the team members’ communication and their participation within both Sprint Plannings. For reasons of seniority, experience and cultural differences, it was always the same few members who participated in the discussions.

Noticing a possibility for killing two birds with one stone, I changed the set-up of the Sprint Plannings - despite some team members complaining about long planning sessions and that Scrum was creating too much overhead ;-). So I changed the Sprint Plannings in such a way that they would not be held within one day, but split into two different days, using the morning in Europe for the three hours overlap of working time. That gave us the opportunity to use two full hours for the Sprint Planning 1 and 2 on each day.

Furthermore, to increase the participation of the team members, I asked all members working in the same location to hold their own smaller version of a Sprint Planning 2 on the day or morning before the session with the whole team. By doing so, I automatically created some competition amongst the dispersed team to come up with the „best“ solutions and share them with the others. This was particularly interesting, as I had not split the pulled stories for the Sprint Planning 2, but instead asked every location to put forward a design for every story. Now that we had three different solutions on the table in the Sprint Planning 2, the team was able to discuss which one would be preferred or which combination of the different design solutions made the most sense. Since all members had participated in the design of a solution, their involvement and the variety of possibilities for implementation clearly increased. At the same time, the meetings were not as long and stiff anymore.

Plus: The additional time now available after the Sprint Planning 2 or before the Sprint Planning 1 could now be used for working through the feedback from the review, continuing on the development of technical topics, or even refactoring ;-)

What advice do you have for working with geographically dispersed teams?

See also the interview series by Stephanie Gasche about internationally distributed Scrum-Teams.

Related posts:

1. Pre-SP2 Design Sessions or How to use your Time during a Sprint Change
2. How internationally distributed Teams can improve their Sprint Planning 2
3. Does distance cancel out the efficiency of internationally distributed Teams?

Scrum ist dabei ein Gesamtkonstrukt, das uns hilft, diese herausfordernden Ziele zu erreichen. Cherrypicking ist dabei zwar wie in allen anderen Bereichen nett, wird aber nicht die vollumfängliche Verbesserung bringen, die man sich wünscht – leider oft mit dem Fazit, dass Scrum versagt hat. Der Umgang mit Bugs ist da nur ein Beispiel von vielen.

Daher hier – ganz in der gewohnten Scrum-Manier – ein paar ganz einfache Regeln!

Bugs

Bugs werden sofort gefixt!

1. Bugs sollten innerhalb von 24 Stunden gefixt sein! Ja, dafür muss im Zweifel ein bereits angefangener Task unterbrochen werden. Solange der Fehler nicht behoben ist, kann die Story nicht abgeschlossen werden. Das Gleiche gilt für Broken Builds, fehlgeschlagene Tests etc.
2. Häufiger Einwand: Was ist mit Bugs, bei denen das Fixing länger dauert? Zumindest innerhalb der ersten 24 Stunden anfangen und sich dann fragen, was im Vorfeld schiefgelaufen ist.

Ein Bug ist ein Bug ist ein Bug – und damit ein FEHLER!

1. Wir liefern fehlerfreie Software am Ende des Sprints!
2. Keine Klassifizierungen in major oder minor oder high, medium low (notwendig). Ist es ein Bug, dann siehe Regel 1. Ist es eine neue Funktionalität –> ins Backlog priorisieren! Es werden keine Bugs zurück ins Backlog geschoben und für spätere Sprints “aufgehoben”!
3. Häufiger Einwand: Nur Laien behaupten, dass es fehlerfreie Software gibt.
   • Mag sein, dass das Laien behaupten. Allerdings schließt das nicht aus, dass es das oberste, immer, ständig, absolut angestrebte Ziel ist, das es zu erreichen gilt. Und das sollte doch auch der Anspruch eines Teammitgliedes in einem Entwicklungsteams sein, oder? Lasst uns gute Arbeit machen und nicht Zeit mit Ausreden verschwenden!

Create a bug lane!

1. Fügt über der Taksboard-Lane für die erste Story eine Bug Lane ein. Nehmt für Bugs eine andere Post-it-Farbe (Rot bietet sich an).
2. Häufiger Einwand: Macht es nicht mehr Sinn, die Bugs den Stories zuzuordnen?
   • Die Arbeit in Scrum ist prioritätenbezogen: Was oben steht, wird zuerst bearbeitet. Außerdem sollte sowieso nur die oberste Story in progress sein, so dass die Zuordnung sowieso stimmt.

Das Team bekommt einmal so viel Zeit wie es braucht, um es richtig zu machen!

• Unter Berücksichtigung des Level und der Definition of Done kann das Team so viele Stories pullen, wie es glaubt fehlerfrei liefern zu können. Ist die Freiheit berücksichtigt, kann jedoch auch verlangt werden, dass fehlerfrei geliefert wird und man nicht zusätzlich zu so viel Zeit wie man braucht noch mehr Zeit braucht!

Calls / Hotfixes / Change Requests

Manche Teams, die auf Scrum umstellen, haben bereits produktive Systeme zu betreuen – sei es in Form von Maintenance, Calls, Hotfixes, vom Kunden entdeckte Bugs oder auch Change Requests. Dabei stellt sich immer wieder die Frage, wie man mit solchen Änderungen am besten umgeht.

Calls haben sich über Jahre angesammelt, der Überblick ist verloren gegangen? Der Call Stack kann nicht mehr abgearbeitet werden, sondern nimmt mit jedem Sprint zu?

1. Alle Calls löschen!
2. Mit der Einführung von Scrum sollten alle Calls gelöscht werden. Ab diesem Zeitpunkt werden alle neuen Calls konsequent sofort behoben (siehe Beschreibung oben). Dauert das Beheben, Ändern oder Hinzufügen von Funktionalität zu lange, muss das System neu geschrieben werden.

Kunden bezahlen einen fixen Betrag zur Wartung der Software und erwarten daher sofortige Änderungen!

1. Der PO entscheidet über Priorisierung und Funktionalität!
2. In diesem Fall muss oft zuerst genau definiert werden, was unter Maintenance fällt und in welchem Zeitraum diese abgearbeitet werden müssen (sofern es vertraglich festgelegt ist). Oft versucht der Kunde, neue Funktionalität und Change Requests als Maintenance einzubringen. Hier muss der PO die notwendigen Abgrenzungen und Entscheidungen treffen. Auf jeden Fall sollte Transparenz darüber geschaffen werden, wie viele Ressourcen und wie viel Zeit durch die Maintenance-Zahlungen des Kunden zur Verfügung stehen würden. Danach kann sich die Zeit richten, die das Team pro Sprint für Maintenance-Aufgaben nutzen kann (z.B. immer an den ersten oder letzten zwei Tagen eines Sprints). Hier sollte aber wieder darauf geachtet werden, dass es eine Teamleistung ist und diese timeboxed abläuft.

Der Kunde meldet Fehler im Live-System, die seine Arbeitsfähigkeit beeinträchtigen und verlangt sofortiges Hotfixing!

1. Für den Fehler entschuldigen und sofort beheben!
2. Halten sich diese Hotfixes im Rahmen, können sie vom Team im laufenden Sprint bearbeitet werden. Umgang wie mit neu entdeckten Fehlern (siehe oben). Nimmt das Hotfixing die gesamte Zeit in Anspruch, sollte eine grundlegende Überarbeitung angestoßen werden.

Es gibt eine überschaubare Menge an Bugs, diese können jedoch nicht in einem Sprint abgearbeitet werden. Das Team, das die Bugs fixen muss, ist nicht für die Produktion der Fehler verantwortlich.

1. Mit dem Product Owner ein Bug-Burn-Down vereinbaren!
2. Wie viele offene Defects gibt es und bis wann will man sie gelöst haben? Beispiel: 100 Bugs in 10 Sprints -> 10 Bugs pro Sprint werden gefixt. In der restlichen Zeit wird Funktionalität entwickelt. So schafft man einen Übergang zu einer fehlerfreien Software und bestraft das Scrum-Team nicht damit, ausschließlich die Fehler der anderen beheben zu müssen.

Um diesen Umgang mit Fehlern zu ermöglichen und Fehler möglichst früh zu erkennen, gehört daher das nötige Handwerkzeug zur Basisausrüstung eines Entwicklungsteams:

• Continuous Integration
• Den eigenen Code in der eigenen Entwicklungsumgebung fehlerfrei laufen lassen
• Absichern des Codes durch automatisierte Unit-Tests
• Systematische Integration des unit-getesteten Codes in die Teamumgebung und Systemintegrationsumgebung – sofortige Behebung von entstehenden Fehlern

Erst hier ist die Entwicklungsphase abgeschlossen. Erst dann bekommt der (interne oder externe) Kunde die Software.

• Laufen des Codes auf der User Acceptance Test Umgebung

Und immer dran denken: weniger diskutieren, mehr fixen 

Related posts:

1. Bug Fixing
2. Definition “Done” | Was ist “potential shippable code”?
3. Agile Estimation | Grundlagen

Fragt doch mal euer Team, ob es die Kreise für die Retro nicht etwas erweitern will. Mit wem wird eng zusammengearbeitet? Wen könnte man zu einer etwas größeren Rückschau einladen? Wen möchte man  besser kennenlernen? Vielleicht wäre es ausnahmsweise auch mal an der Zeit, den ScrumMaster zur Retro einzuladen? Bestimmt auch für das PO- oder SM-Team mal eine schöne Abwechslung.

Zugegeben, es braucht etwas Vorbereitungszeit, aber es lohnt sich bestimmt.

Timeline – 24 Zeiteinheiten bis Weihnachten

Gemalte oder echte Weihnachts-Socken, Kärtchen, Geschenke, Zweige, Candy Canes etc. mit den Zahlen von 1 bis 24 beschriften und der Reihe nach im Raum aufhängen. Je nachdem, wie lange der betrachtete Zeitraum ausfallen soll, steht jede Zahl für einen bestimmten Zeitraum (z.B. eine Woche – halbes Jahr Rückschau, zwei Wochen – Jahresrückschau, zwei Tage – die letzten Sprints). Das Team sammelt Fakten und hängt sie an den entsprechenden Platz.

Was lief gut – Licht und Schmuck am Baum

(eine genauere Beschreibung mit Bildern findet ihr hier http://borisgloger.com/2011/12/16/christbaumschmucken-advanced/)

Einen großen Weihnachtsbaum auf ca. 4 Flip-Charts malen (je nach Größe des Teams). Namen der Teammitglieder einmal unter den Baum auf Päckchen und einmal von oben nach unten am Baum auf Socken schreiben und so mit den Namen eine Matrix aufbauen.

Für jedes Teammitglied leuchtet eine Kerze in dem jeweiligen Feld der Matrix, an dem sich seine Namen treffen. Jedes Teammitglied schreibt nun auf, was für ihn oder sie z.B. ein erleuchtender Moment war, was ihn/sie am meisten motiviert, was für Ihn/sie in diesem Jahr besonders gut gelaufen ist in Bezug auf die Arbeit / Scrum Einführung / neues Team etc.

Weihnachtsbaumkugeln
Der Schmuck ist Symbol für gute Zusammenarbeit mit den Kollegen. Wieder wird die Matrix genutzt und jeder klebt für die Kollegen eine Kugel mit Beschriftung an den Baum, als Antwort auf z.B. die Fragen: 

• Was habe ich an Deiner Arbeit geschätzt?
• Was waren besonders tolle Momente der Zusammenarbeit?
• Wann war ich beeindruckt von Dir?
• Was sollten die anderen von Dir wissen?
• …
  

Break / Separator
Jeder bringt seine Lieblingsweihnachtssüßigkeit mit, teilt mit den anderen und erklärt, warum er genau das so gerne zu Weihnachten isst. Oder vielleicht möchte jemand lustige Weihnachtspannen zum Besten geben? Ein kleines (!!!) Tischfeuerwerk sorgt bestimmt auch für den nötigen Break zwischen den beiden Teilen.

Was kann verbessert werden – Feuerwerk guter Vorsätze für das nächste Jahr

Das Team gestaltet das Feuerwerk des nächsten Jahres (an einer Metaplanwand oder einer mit Papier beklebten Tapete). Wie sieht das Gesamtbild aus? Welche Soundeffekte gibt es? Welche Farben? Was wird heller als dieses Jahr? Was lassen wir weg? Was nehmen wir neu dazu? Womit wollen wir experimentieren? Welche Kompetenzen brauchen wir dafür in unseren Feuerwerksexperten-Team? Wer soll das Feuerwerk sehen?

In diesem Sinne: Lasst die letzte Retro im Jahr zu einer schönen Rückschau, einem prachtvoll geschmückten Festbaum und einem aufregenden Ausblick auf das neue Jahr werden.

Related posts:

1. Christbaumschmücken Advanced
2. Die Sicherheitsfrage in der Retrospektive oder der Wert eines klaren Neins
3. Ein Projektbericht – Die eigene Website

Das theoretische Framework für Self-Leadership findet sich in der Kontroll-Theorie (Carver & Scheier, 1982). Die Erweiterung auf das Team Level steht unter den Grundannahmen der Arbeitsdesign-Theorien, Job-Charakteristika-Theorien (Hackman & Oldham, 1976) und der sozio-technischen Systemtheorie (Cummings, 1978).

Mir gefällt an dieser Darstellung von Steward/Courtright/Manz, dass sie auf einfache Art und Weise die wohl wesentlichen Aspekte zusammenfasst und darüber hinaus einfach auf die Scrum-Terminologie übertragbar ist. Interessant finde ich außerdem die Einstufung nach dem möglichen und ausgeübten Einfluss der Teams sowie der Abhängigkeit von Anreizen (die es hier im Sinne von Impulse, Motivation, Stimulus, Anreiz zu verstehen gilt).

Nimmt man das klassische Projektmanagement, wird sowohl das WAS, WIE und WARUM vorgegeben. Der Teamgedanke und Vorteil kann sich somit meiner Meinung nach nur bedingt entfalten. Die ausschließliche Abhängigkeit von extrinischen ,Anreizen‘ zeigt außerdem, dass das Team ohne externes Management wohl kaum handlungsfähig ist.

Betrachtet man dann die Entwicklungsteams (nicht Scrum-Teams) in Scrum, kommt man zum Self-Management. Sie können selbst entscheiden, WIE sie das Geforderte umsetzen. Außerdem sind sie nicht ausschließlich von extrinsischen Anreizen (Vision, priorisiertes Backlog, Constraints) abhängig, sondern können innerhalb dieses Rahmens intrinsische ,Anreize‘ entwickeln und verfolgen.

Self-Leadership trifft meiner Meinung nach auf gut eingespielte Scrum-Teams zu, die gemeinsam mit Product Owner und Scrum Master sowohl auf das WAS, das WIE und das WARUM Einfluss haben. Ganz unabhängig von extrinsischen ,Anreizen‘ sind sie jedoch nicht, da das Unternehmen z.B. mit dem Produktportfolio bestimmte und notwendige Vorgaben macht..

Wie bei allen abstrakten Definitionen und Kategorien, gilt es jedoch auch hier wieder darauf zu achten, in welchem Detailgrad die Entscheidungen getroffen werden können. Dieser sollte zu jedem Zeitpunkt dem Reife- und Kompetenzgrad des Teams angemessen sein und die Abnahme von Verantwortung durch externes Management sollte nicht so weit gehen, dass es zu einer Schonhaltung des Teams führt.

Und genau das ist wohl die Schwierigkeit (die auch durch diese Definition nicht aufgelöst wird).

Neugierig auf Lösungsansätze? Ich auch. Teilt eure und/oder lest weiter unsere Blogs.

Quellen:

Hackman, J. R. (1986): The psychology of self-management in organizations. In M. S. Pollack & R. O. Perloff (Eds.), Psychology and work: Productivity change and employment, S. 85-136. Washington, DC: American Psychological Association. 

Hackman, J. R., & Oldham, G. R. (1976): Motivation through the design of work: Test of a theory. Organizational Behavior and Human Decision Processes, Vol. 16, S.  250-279. 

Lawler, E. E. (1986): High involvement management. San Francisco, CA: Jossey-Bass.

Manz, C. C., & Sims, H. P., Jr. (1991): SuperLeadership: Beyond the myth of heroic leadership. Organizational Dynamics, Vol. 19, S.  17. 

Stewart, G.L., Courtright S.H. &  Manz, C. C. (2011): Self-Leadership: A Multilevel Review, Journal of Management,Vol. 37, S.  185-195.  

Walton, R. E. (1985): From control to commitment in the workplace. Harvard Business Review, Vol. 63, S.  77-84.  

Related posts:

1. Agile and Organizational Structures
2. Strategische Ebene
3. Taktische Ebene