Zweck

Synchronisation innerhalb des Dev-Teams, um das Sprintziel und somit das Release zu schaffen.

Ziel

Als Team wissen wir, was erledigt werden muss, damit die committeten Stories auf Done gesetzt werden können.

Ablauf

1. Das Dev-Team trifft sich im Halbkreis vor dem Taskboard. Der ScrumMaster steht seitlich ca. einen halben Schritt außerhalb dieses Halbkreises. Gäste stehen komplett außerhalb des Halbkreises.
2. Begrüßung durch den ScrumMaster – ein “Guten Morgen” reicht aus. Hier ist ein motiviertes Auftreten wichtig: Wenn der ScrumMaster als Coach des Teams schon keinen Bock hat, wie soll das Team dann erst Lust bekommen? Der ScrumMaster startet mit einer Begrüßung und macht auf die geplanten Termine für den Tag aufmerksam.
3. Falls jemand im Dev-Team noch keine Vorstellung hat, welche Arbeit er an diesem Tag leisten kann/ möchte/wird, sollte er sich gleich anfangs zu Wort melden, damit das restliche Team ihn für potenzielle Aufgaben in Erwägung ziehen kann.
4. Nacheinander erzählt jedes Teammitglied seinen Kollegen Folgendes:
   1. Was habe ich seit dem letzten Daily umgesetzt? (falls fertig, wird der Task von Work In Progress in Done gehängt) Falls die Aufgabe wider Erwarten innerhalb des letzten Tages nicht fertiggestellt werden konnte, erklärt das Teammitglied kurz, wodurch die Aufgabe behindert wird. Dann wird ein Punkt auf das Post-It gemacht. Ggf. wird diese Störung am Impediment Backlog, auf dem Task bzw. an der Story visualisiert.
   2. Was werde ich heute tun? Hier zieht sich das Teammitglied eine Aufgabe aus der To Do Spalte der höchstpriorisierten User Story und hängt sie in Work In Progress. Falls möglich, plant das Teammitglied gleich Pair Programming mit einem Teamkollegen bzw. Unterstützung, die er in Anspruch nehmen möchte.
   3. Was behindert mich in meiner derzeitigen Arbeit? (Visualisierung nicht vergessen…)
   4. Wo benötige ich Hilfe?
   5. Meine heutige Verfügbarkeit
   6. Das nächste Teammitglied übernimmt und beantwortet dieselben Fragen gegenüber dem restlichen Team. Dies passiert reihum, bis das Team seine Arbeit synchronisiert hat und jeder weiß, was er heute mit wem bearbeiten soll.
   7. Ist eines der Teammitglieder nicht da, übernimmt ein anwesendes Teammitglied die Punkte des abwesenden Kollegen und hängt die jeweiligen Aufgaben auf dem Taskboard für ihn um.
5. Der ScrumMaster fasst abschließend folgende Punkte zusammen:
   1. Neue Impediments, die in diesem Daily ans Tageslicht gekommen sind und um die er bzw. jemand im Team sich kümmern wird
   2. Inwieweit sind aktuelle Impediments schon gelöst bzw. ist dafür die Hilfe des Dev-Teams nötig?
   3. Neue Termine, falls ein detaillierter Abstimmungsbedarf zwischen Teammitgliedern sichtbar geworden ist
   4. Die eigene heutige Verfügbarkeit, ggf. einer Vertretung
   5. Falls der Product Owner anwesend ist: Spätestens jetzt noch fragen, ob er weitere  Anmerkungen hat
6. Das Burn-Down Chart wird von einem Teammitglied aktualisiert.

Alles was man für dieses kurze Stand-Up benötigt, sind ein ScrumMaster, ein Dev-Team, ein Taskboard und ein Burn-Down Chart. Gäste, vor allem der PO, sind immer herzlich willkommen. Die Rahmenbedingungen von max. 15 Minuten, täglich, stehend, selber Ort, selbe Zeit dürfen deshalb aber nicht außer Acht gelassen werden.

Was haltet ihr von diesem kleinen “How-To”? Wie sieht der Ablauf des Daily Scrums bei euch aus?!

Related posts:

1. Christbaumschmücken Advanced
2. Erfolgreiches Nichtwollen
3. 10 Things about ScrumMasters

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

Unsere Mission: Ein Spiel zu entwickeln, das die Fertigungsstraße der Modellfabrik als Referenz nimmt, um agiles Arbeiten deutlich zu machen.

Probieren geht über Studieren!

Doch zuvor standen wir vor einer weit größeren Herausforderung: Die Fertigung eines Lasters  durchzuspielen, und so die Logik von strikter Arbeitsteilung, Push- und Pull-Prinzipien sowie Just-inTime-Lieferung am eigenen Leib zu erleben. Es dauerte nicht lange, da war das System schon mächtig unter Druck: Drei Fertigungsstände meldeten per Kanban-Signalkarten gleichzeitig Bedarf an Steckteilen und überforderten damit den Teilebeschaffer gnadenlos. Da hatten wir ihn: Den klassichen Bottleneck. Dass nach zehn Minuten die drei bestellten Laster im Wert mehrerer hunderttausend Euro dennoch ausgeliefert werden konnten, grenzt da schon fast an ein Wunder. Die Modellfabrik war vorerst vor dem Bankrott gerettet.

Aber zurück zur Mission. Wir hatten knappe sechs Stunden, um unser agiles Spiel vom Reißbrett auf zu entwerfen. Wir teilten uns initial in vier Gruppen auf. Der Vormittag bestand aus zwei Brainstorming-Sessions, an dessen Ende 16 Spielideen standen. Leicht entmutigt gingen wir in die Mittagspause: Wie sollte aus so vielen Ideen ein praktikables Konzept werden?

Dass wir am Ende doch noch die Kurve kriegten, verdanken wir einer Erkenntnis, die wir unseren Kunden gegenüber oft genug wiederholen: Probieren geht über Studieren! Als wir zur fortgeschrittenen Stunde dann endlich zum Spielen kamen und die Reaktionen von Teilnehmern und Beobachtern in Echtzeit sehen konnten, stieg das Vertrauen in das eigene Konzept sprunghaft an. Jetzt ging es noch um das Feintuning und die Optimierung.

Die drei Spiele, die es bis zum Schluss geschafft haben, könnten kaum verschiedener sein. Das eine Spiel heißt “Handicap” und setzt auf “blinde” und “einarmige” Teilnehmer, die nur über Kooperation einen Laster erfolgreich bauen können. Das zweite Spiel ist eine Abwandlung des Ball Point Games, in dem die Teilnehmer in Iterationen mit variabler Taktung und klarer Arbeitsteilung ausprobieren müssen, wie sie möglichst viele Laster zusammenschrauben. Das dritte Spiel schließlich setzt auf die Unterschiede zwischen Einzelgänger und Team: Lasse vier verschiedene Produkte von jeweils vier Personen alleine bauen – und mach dann das Gleiche in einem Team.

Zugegeben: Die Phase des friendly test haben unsere Spiele noch nicht überwunden. Aber Professor Komus hat seine Studenten – und wir haben unsere Scrum-Teams. Ihr dürft also auf den nächsten Beitrag gespannt sein, in dem wir Euch erzählen, wie die Spiele bei unseren ersten Probanden angekommen sind. Beim nächsten Besuch Anfang April bringen wir übrigens noch etwas mit: Wir geben dort ein ScrumMaster Advanced-Training, um den Studenten die Rolle des ScrumMasters näher zu bringen. Denn was heute noch gespielt wird, kann morgen schon berufliche Selbstverständlichkeit werden.

Related posts:

1. Fussball EM und 3 Sprints | Scrum ist überall !
2. Website | Der Wandel wird sichtbar, Notizen inklusive
3. Die Sicherheitsfrage in der Retrospektive oder der Wert eines klaren Neins

Wenn wir zu unseren Kunden gehen, dann immer mit der Absicht, etwas zu verändern. Wir implementieren Scrum, was einhergeht mit einer Veränderung der Rollen, Prozesse und Werte der Zusammenarbeit. Und wir möchten am liebsten, dass alle Mitarbeiter freudig aufspringen und rufen: „JA! Wir wollen uns verändern!“ Stattdessen jedoch sind viele Mitarbeiter erst einmal verhalten: „Ja, die agile Idee ist klasse und wir haben schon viel von Scrum gehört und gelesen, aber ich bin mal gespannt, wie ihr das hier machen wollt.“

Und dann starten wir mit ersten Trainings und damit, die ersten Teams auf Scrum umzustellen. Das bedeutet für die Mitarbeiter viel Veränderung: Die Teams werden neu gemischt, Mitarbeiter bekommen andere Rollen, wir implementieren Regelmeetings, alles wird transparent gemacht und wir sprechen plötzlich offen mit allen über Hindernisse in der Organisation. Uffz! So anstrengend haben sich die Mitarbeiter die Umstellung gar nicht vorgestellt. Plötzlich spürt man in den Teams den Gedanken: „Och, eigentlich war es doch immer ganz gemütlich hier. Können wir nicht wieder zurück?“ Dann bekommen die Consultants eine anstrengende Aufgabe, nämlich die angestoßene Veränderung konsequent weiter aufrecht zu erhalten. Die Veränderungen müssen im Verhalten der Mitarbeiter und den Prozessen im Unternehmen verankert werden.

Nicht zu früh abweichen!

Aber das Zurückrudern meinen die Mitarbeiter nicht böse – für diese Reaktion gibt es eine rein biologische Erklärung. Professor Gerhard Roth, Neurobiologe an der Universität Bremen sagt: „Für unser Gehirn gibt es kaum etwas schwierigeres, als Gewohnheiten abzulegen.“ Wir haben uns bereits an Verhaltensweisen gewöhnt und können sie automatisch anwenden. Das ist gut so, denn wir müssen selektieren, worüber wir uns Gedanken machen, sonst läuft unser Arbeitsspeicher im Gehirn voll.

Barack Obama trägt nur blaue und graue Anzüge. Warum? Er sagt: „Ich will mich nicht entscheiden, was ich anziehe oder esse, weil ich zu viele andere Entscheidungen treffen muss.“ Gewohnheiten und Routinen sind wichtig, um uns Luft zu verschaffen und sie geben uns Sicherheit. „Das Gehirn versucht unentwegt, so viele Handlungen wie möglich in Routinen zu verwandeln,“ sagt Professor Roth. Und daran arbeiten wir mit der Einführung unseres Scrum-Flows: eine neue Sicherheit und Routine herzustellen. Ja, ich weiß, das dauert ein paar Sprints, aber es funktioniert! Dazu müssen Mitarbeiter und Consultants großes Durchhaltevermögen beweisen und konsequent zusammenarbeiten.

Viele Teilnehmer in Trainings fragen mich: „Was ist der größte Fehler, den man bei der Einführung von Scrum machen kann?“ Und meine Antwort darauf ist: „Das zu frühe Abweichen vom Scrum-Flow und den Scrum-Grundlagen. Oder den vermeintlich nervenden Consultant zu früh nach Hause zu schicken.“ Mindestens die ersten drei Sprints sollten wirklich nach Lehrbuch umgesetzt werden. Da muss man sich durchbeißen, und konsequent sein. Das ist hart, aber danach wird der Scrum-Flow zur Routine und wir können uns stärker auf andere Dinge konzentrieren, wie z.B. Teamentwicklung oder Steigerung des Levels of Done. Jetzt beginnt also die Kür der Veränderung und damit der eigentlich spannende Teil. Daher lautet mein Rat zu Anfang: „Haltet durch! Land ist in Sicht“

Angelehnt an den Artikel “So besiegen Sie schlechte Gewohnheiten!” (Elke Hartmann-Wolff) im  Focus 02/13 vom 07.01.2013

Related posts:

1. Education Paradigms & Softskills
2. Scrum – Eine Revolution (3)
3. Das letzte Wort hat unser Hirn

The sequel to Does distance cancel out the efficiency of internationally distributed Teams?

Stephanie G.: Internationally dispersed Teams sound pretty exhausting. Are you telling me that you‘re no fans?

Hélène V.: I think that I can speak for everyone present that putting together internationally distributed or dispersed Teams – although dispersed is even worse – are not what we would advise managers to do. Yes, Scrum can be applied in such situations – but a lot of the fun and simplicity are taken out of the process. It is a challenge, which – of course – we are all willing to take on, but if a manager would ask me for my opinion, I would certainly advise the setting up of co-located Scrum Teams. (nodding all around)

Bernd K.: If I were a manager and I had to choose between training people on-site or investing in skilled staff abroad, I would certainly take the ones that are on-site.

Deborah W.: I second Bernd. But one has to admit that the wonderful thing about agile methods and Scrum is that they offer great practices, such as Pair Programming, for transferring and building up the skills of one‘s employees. However, this really depends on the product, the people, the necessary skills, as well as the available time and budget.

Kristina K.: Time‘s the word. If we‘re talking about a project where certain skills will only be necessary for a few months, it would probably be smarter to buy this kind of know-how. If we‘re talking about three years, then I would go for the more sustainable option of ensuring that the skills are available on-site.

Ina K.: In the case of three months, I would also aim at having the people with the necessary qualifications and competence flown in and sit together with the rest of the Team. After all, there will always be a small percentage of Team achievement that cannot be reached due to it being distributed.

Hélène V.: I second that. As a manager, it is important to figure out how to motivate the naturally distributed Team members to spend the necessary time together in one location. If one takes your case for example, Stephanie, one could have offered the German and Indian Team members a salary for 12 months and the challenge for the entire Team to complete the product within one year. The Team spends that time together in the third location Vietnam and if they finish the product earlier, then the 12-month salary is still paid, but the Team members can return home early. This is just an example – it’s up to the managers to think about ways to motivate their Team members to get together in one location and maximise their productivity.

Stephanie G.: I like that idea. But it again points to the general opinion that you would all strongly recommend to avoid creating distributed Teams?!

Christof B.: As Hélène has already said,  if we were given the choice as managers, we would try to keep the Team in one place. There are, however, a few scenarios that I could live with. Firstly, the ScrumMaster would have to sit with the Dev.Team. If the Product Owner is not able to do so, he will simply have to start travelling more frequently in order to build up a good relationship. He would furthermore have to offer a dedicated hour per day (at least), where he is strictly available to the Team for answering any questions and give information or feedback. The other important thing to watch out for when splitting a Team is that it should be equally divided. It is super difficult when there are six persons sitting on one end of the telephone receiver, and only one or two on the other.

Stephanie G.: Thank you. So to sum up your statements, we may advise managers to

• avoid distributed or dispersed Teams
• motivate Team members to travel frequently or move to the other location(s)
• build up Team members‘ competences sustainably by using agile methods
• make sure to split the Team evenly, if the dividing up cannot be avoided.

Related posts:

1. Does distance cancel out the efficiency of internationally distributed Teams?
2. Sprint Planning with geographically dispersed teams located in different timezones
3. How internationally distributed Teams can improve their Sprint Review

Immer wieder kommt die Frage auf, wie viele Scrum-Teams ein guter ScrumMaster führen kann. Soll er nur ein Team haben? Kann er nicht zwei oder vielleicht sogar drei haben, wenn diese schon erfahren genug sind? Ich bin der Ansicht, dass Menschen, egal wie talentiert oder wie gut sie organisiert sind, immer nur eine Sache machen können, wenn sie diese fokussiert und mit Hingabe erledigen wollen. Ein Scrum-Team zu führen ist komplex und fordert dem jeweiligen ScrumMaster alles ab. Meine Empfehlung lautet daher: ein ScrumMaster, ein Scrum-Team.

2 – zwei Rollen auf einmal können nicht funktionieren.

Was für die Führung eines ScrumTeams zutrifft, das zählt für die Erfüllung der Rolle als ScrumMaster nicht minder. So dogmatisch es für viele immer wieder klingen mag, so sinnvoll und (erfahrungsgemäß) realistisch ist es: Ein ScrumMaster sollte seiner Verantwortung als ScrumMaster nachkommen und nicht mehr! Ein ScrumMaster sollte ebensowenig als Entwickler, wie in Zweitfunktion als Product Owner agieren: Interessenkonflikte und Überforderung sind quasi vorprogrammiert. Meine Empfehlung lautet daher: gute ScrumMaster wissen, dass sie nicht zwei Rollen belegen können.

3 – drei Verantwortungen, drei Hüte.

In einigen Punkten gehen bor!sgloger consulting und die Scrum Alliance nicht immer konform. Aber in der Three-Hats-Challenge des ScrumMasters herrscht Einigkeit: „A good ScrumMaster will be a process facilitator, a servant leader to the team and a change agent within the organization.“ (3) Diese drei Hüte erfordern von einem ScrumMaster, drei Verantwortungen im Fokus zu behalten, um ein Scrum-Team produktiv(er) zu machen:  Scrum (Prozess) einführen, das Scrum-Team schützen (nach innen und außen) und Hindernisse (Impediments) beseitigen. Die Three-Hats-Challenge unterstreicht das, was die Zahlen eins und zwei zum Ausdruck bringen. ScrumMaster sein ist ein Fulltime-Job.

4 – Scrum heißt ganz oder gar nicht – vier Prinzipien als Kompass des Handelns.

Der ScrumMaster will „vier Prinzipien immer und immer wieder zur Anwendung bringen“ (Gloger, 2011, S. 23), weil diese Argumente enthalten, die es braucht, um Scrum mit Erfolg in einer Organisation zum Einsatz zu bringen: Selbstorganisation, das Pull-Prinzip und damit die Kontrolle von Input, Timebox und damit die Vorgaben von Grenzen (Rahmen) sowie Nutzbare Business-Funktionalität als Ergebnis jeder Iteration (Sprint). Boris Gloger (2011, S. 23) vertritt die klare Auffassung: Ist eines der Prinzipien verletzt, dann ist es kein Scrum!

5 – der ScrumMaster und die fünf Werte von Scrum.

Werte sind immer ein Fundament und ihre Intention ist es, nach ihnen zu streben. Es geht weniger darum, sie zu perfektionieren, als vielmehr sie als Fixstern, wie als Lichtstrahl in einem Leuchtturm, also als Orientierung anzuerkennen und „just do them now, as best you can. Good stuff happens immediately regardless of where and when you start.“ (4) Scrum kennt derer fünf Werte, die die Grundlage des Handelns bilden. Sie lauten: Respekt, Offenheit, Fokus, Commitment, Courage.

6 – drei plus drei ist gleich sechs.

Der Erfolg von Scrum, des De-Facto-Standards in der Softwareentwicklung, ergibt sich unter anderem durch seinen Rahmen (Framework). Eine Rahmenbedingung stellen die sechs Rollen, die der Scrum-Prozess vorsieht: drei funktionale Rollen (= das ScrumTeam), nämlich Product Owner, ScrumMaster und Entwicklungsteam, drei organisationale Rollen, nämlich Manager, Customer und Enduser.

7 – Mike Cohns Eigenschaften eines guten ScrumMasters plus eine von mir.

Mike Cohn nennt sechs „Eigenschaften eines guten ScrumMasters“ (1), durch die sich die seines Erachtens „besten ScrumMaster auszeichneten“ (1): Verantwortungsbewusstsein, Bescheidenheit, Förderung der Zusammenarbeit, Engagement, Einfluss und Wissen (vgl. Cohn, 2010, S. 146ff). Es ist eine großartige Zusammenstellung. Mir fehlt noch eine siebte Eigenschaft, eine, die in der heutigen Kommunikation von und mit Menschen oftmals vergessen wird beziehungsweise viel zu kurz kommt – nicht zuletzt, weil wir Menschen verlernt haben, uns diese Eigenschaft zu nutze zu machen: das Schweigen.

8 – bei acht ist Schluss.

Die Zahl 8 steht für mich wie Felsen, wenn ein ScrumMaster ein Estimation Meeting leitet. Wenn die Teammitglieder die vom Product Owner priorisierten Userstories schätzen, dann steht für mich fest, dass ein guter ScrumMaster nur die vom Entwicklungsteam geschätzten Userstories ins Sprint Planning 1 zulässt, die kleiner gleich 8 Storypoints (entsprechend der Cohn`schen Reihe = unreine Fibonacci-Skala) geschätzt wurden (besser wäre natürlich, wenn sie einen noch kleineren Funktionsumfang haben). Sind sie größer und in der Priorität des POs so hoch, dass sie im nächsten Sprint geliefert werden, dann sollte der ScrumMaster darauf achten, dass der PO diese Stories noch mal schneidet oder dass sie zu einem weiteren Anlass für eine Konversation VOR dem SP 1 werden.

9 – mehr als neun bedeutet immer weniger.

Ein Scrum-Team sollte aus nicht mehr als neun Teammitgliedern bestehen. Amazon spricht vom so genannten „Zwei-Pizza-Team“ (Cohn, 2010, S. 208). Das bedeutet, dass ein Team so klein sein sollte, damit eine Bestellung von zwei Pizzas kein Tohuwabohu wird, sondern leicht von der Hand geht. Vorteile kleiner Teams sind u.a. weniger Zeit für Koordination und Kooperation, weniger soziales Faulenzen, weniger Gefahr der Spezialisierung einzelner, höhere Produktivität, etc.

10 – Robin Hood, mein Held als ich zehn war.

Boris Gloger vergleicht die Rolle eines erfolgreichen ScrumMasters mit der Romanfigur Robin Hood (vgl. Gloger, 2011, S. 24ff.). Als ich zehn Jahre alt war, war Robin Hood auch mein Held: Erol Flynn, unerschrockener Widerstandskämpfer gegen den bösen König John und den Sheriff von Nottingham. Der ScrumMaster hat stets die Rolle des Veränderers. Er ist Vorreiter und geht dorthin, wo es weh tun kann oder wo er anderen (z.B. Management) weh tun muss. Er stellt Fragen, die sich sonst keiner zu stellen traut. Er sucht und findet Lösungen, wo andere an Problemen, Stillstand und Routinen gescheitert sind. Er gibt seinem Team Hoffnung, hält ihm den Rücken frei und weitet die Kultur von „Scrum“ auf die Organisation aus. Die besondere Herausforderung hierbei ist, dass der ScrumMaster ohne Autorität führt. Seine Rolle und die damit verbundene Verantwortung ist es, die ihm erlaubt, sein Handeln darauf auszurichten, den bösen Mächten des Stillstands die Stirn zu bieten und dafür zu sorgen, dass der Prozess in den (Scrum-)Flow kommt.

Literatur

(1) Cohn, M. (2010). Agile Softwareentwicklung. Mit Scrum zum Erfolg. Addison-Wesley

(2) Gloger, B. (2011). Scrum. Produkte zuverlässig und schnell entwickeln. Hanser

(3) http://www.scrumalliance.org/courses/20093867-certified-scrummaster

(4) http://newtechusa.net/agile/scrum-values/

Related posts:

1. Fussball EM und 3 Sprints | Scrum ist überall !
2. Die drei weiteren Rollen in Scrum
3. Der ScrumMaster ist eine Versicherung (Mike Beedle)

Lieber Achim,

bevor du mit Scrum anfängst, möchtest Du von mir wissen, was Scrum denn eigentlich ist. Ich könnte jetzt einfach loslegen und schulbuchmäßig von den Rollen, den Meetings und den Artefakten erzählen.

Viel lieber möchte ich dir sagen, was Scrum nicht ist: Es ist keine paragraphenlastige Methode für das Management von Projekten. Dazu ist Scrum nämlich viel zu leichtfüßig. Du kannst jederzeit und mit wenig Aufwand ein laufendes Projekt auf Scrum umstellen. Alles, was du dazu brauchst, ist:

1. Ein fünf- bis neunköpfiges Team, das irgendein Produkt (weiter-)entwickelt.
2. Jemand, der Verantwortung für die Gestaltung des Produktes übernimmt (das ist der Product Owner).
3. Eine Person, die sich darum kümmert, dass Scrum gemacht wird (das ist der ScrumMaster).

Außerdem brauchst Du einen Team-Raum, Flipcharts, eine Moderationswand und viele Moderationsmarker (die trocknen nämlich schnell aus). Schon kannst Du loslegen.

Du hast immer noch keinen Plan? Das ist normal. Ich stand neulich kurz vor dem ersten Sprint mit einem neu geformten Team, das Hardware und Software für ein neues Produkt im Automobilbereich entwickelt. Alle fragten sich, was das Team denn im ersten, zweiwöchigen Sprint machen sollte.

Der Product Owner hatte die gewünschten Produkteigenschaften aufgeschrieben. Aber diese waren noch viel zu grob, um die Arbeitsgrundlage für zwei Wochen zu stellen. Also fragten wir das Team, was es für die nächsten zwei Wochen vorhabe – und was davon es nach diesen zwei Wochen fertig vorstellen könne.

Im Gespräch zwischen Team und Product Owner wurde schnell deutlich, worauf es ankam: Priorisieren und definieren. Zwei Entwickler arbeiteten an einem Produktfeature, das aus Sicht des Product Owners weniger wichtig war. Also wurde es zurückgestellt. Der Rest des Teams arbeitete gut und zuverlässig vor sich hin, aber eben nur vor sich hin. Die Frage, was denn in zwei Wochen tatsächlich fertig vorstellbar sein könnte, führte zu einer Zielklärung. Vierzehn Tage später hatten wir ein wunderbares allererstes Review, in dem das Team ein Handshake zwischen zwei Geräten sowie ein fertiges Schaltbild für das neue Produkt vorstellte.

Scrum ist kein Wunderland. Ja, die ersten Erfolge zeigen sich sehr schnell. Ja, die Arbeitweise ist komplett verschieden und viel, viel besser – weg von Dokumentenstapeln, Abteilungen und Sitzungen, hin zu Kommunikation, Kommunikation und Kommunikation. Gerade das macht die Umstellung im großen Stil dann auch so schwierig. Ein einzelnes Team fällt wenig auf. Es kann noch mehr oder weniger unbefangen vor sich hin scrummen.

Spätestens dann, wenn die gesamte Entwicklung auf Scrum umgestellt wird, stellen sich die Fragen nach alter und neuer Welt. Was macht ein Projektleiter, was macht ein Produktmanager in Scrum? Wie sehen Zielvereinbarungen für Team-Mitglieder aus? Und wie schaffen wir es, Teams tatsächlich den Rücken freizuhalten, so dass sie ihre Zeit und Konzentration einem Produkt widmen können? Hier ist das Management in der Verantwortung, die Arbeitswelt neu zu denken (siehe Helenes Blog zum Transition Team).

Lieber Achim, ich möchte diesen Brief gerne mit einer Metapher beenden. Spielst du Schach? Dann weißt Du, wie leicht das Spiel zu lernen ist. Selbst ein Kind kann die Regeln schnell verinnerlichen und zuverlässig anwenden. Du hast auch sehr schnell Spaß bei der Sache – der Gegner darf nur nicht allzu gut sein. Mit der Zeit merkst du, dass viel Raum nach oben ist. Dass du mit bestimmten Kombinationen sehr schnell sehr viel besser werden kannst. Hier helfen die Ratschläge, Tipps und Tricks von erfahrenen Freunden, die schon etwas länger im Geschäft sind.

Und wenn du dann erstmal soweit bist, dass keiner Dich mehr so leicht schlägt – dann fängt der lange Weg zum Gipfel erst an. Und ja, auch das sollte Spaß machen, weil es um die Kunst der kontinuierlichen Verbesserung geht. Was im Schach der Sieg gegen einen Meister ist – das ist in Scrum ein stolzes Team, das ein richtig geiles Produkt aus der Hand gibt.

Related posts:

1. Commitment des Product Owners
2. Warum wir eigentlich alle Freelancer sind
3. Scrum Rollen: Das Team

Viele der Grenzen, die uns umgeben, erkennen wir nicht so deutlich, wie ein Alpinist in einem Inferno von Wind, Kälte und Schnee. Nur die Natur zeigt uns treu und beharrlich, was wir nicht beherrschen. Meist erkennen wir erst nach dem Start, geschäftlich wie privat, was das Wichtigste auf unserer Reise sein wird. Ein Plan hilft, denn die Planung selbst war wertvoll. Ab jetzt heißt es: Erfahrungen machen und sich den Gegebenheiten anpassen, denn man weiß nicht, was als nächstes aus dem Nichts auftaucht. Ein Plan ist die letzte Schätzung, bevor es auf die Reise geht.

In der agilen Produktentwicklung akzeptieren wir unsere Grenzen. Wir gehen davon aus, dass wir vor dem Start nicht alles wissen, nicht alles planen können und akzeptieren, dass es auf unserem Weg zum Produkt stürmisch zugehen kann. Wir gehen auf eine Expedition. Sehen die Route durch die Wand, zum Gipfel hin aus der Entfernung unscharf vor unseren Augen und doch kennen wir das Ziel. Meter für Meter steigen wir hinauf, immer den nächsten Tritt, den nächsten Griff suchend. Jeder Abschnitt des Berges stellt eigene, neue Anforderungen an uns. Schrittweise verfeinern wir somit unsere Vision. Durch das Beschreiten des Weges beginnen wir zu verstehen – Etappe für Etappe mehr. Es wird greifbar, den Gipfel im Kopf, gehen wir die nächsten Meter an, soweit wir voraussehen können.

Stefan Glowacz schreibt: “Der limitierende Faktor im Himalaya ist bekanntlich die Höhe der Berge, in Patagonien sind es die unberechenbaren und gefürchteten Stürme. Rein statistisch gesehen stehen dem Kletterer nur zwei bis drei Schönwettertage [...] zur Verfügung, [...]“. In beiden Fällen ist die Zeit der begrenzende Faktor für die Expedition. Das ist in der Produktentwicklung nicht anders. Auch hier ist die Zeit knapp und zusätzlich ist es riskant, zu viel zu planen. Grund hierfür sind wie auch am Fels die externen Bedingungen, die sich stetig ändern. Neue Bedingungen stellen neue Anforderungen an uns, auf die wir uns einstellen müssen. Gerade das führt in der Produktentwicklung dazu, dass man keine Zeit an Anforderungen verlieren sollte, die sich ändern werden. Zu Beginn alle Anforderungen gleich zu behandeln ist verschwenderisch. Daher steigen wir mit einer soliden und grundlegenden Planung auf und haben die richtigen Fähigkeiten im Rucksack. Mit Disziplin und mentaler Stärke reagieren wir auf sich ändernde Bedingungen und haben auch den Mut, eine Expedition abzubrechen. Frei nach dem Motto: “Ein sehr guter Bergsteiger kommt wieder nach Hause.”

Was bringt uns in der Produktentwicklung sicher nach Hause?

Ein fernes Ziel haben, lässt uns die Route selbst wählen, jedoch die Richtung steht und wir richten uns daran aus. Nicht am Start alles im Detail planen, denn auf der Strecke werden wir wertvolle Entdeckungen und Erfahrungen machen, die wir vorher nicht erahnen konnten. Nicht alle Anforderungen gleich behandeln, sondern die wichtigen zuerst und den Rest hinten anstellen. Das vermeidet Verschwendung. Nicht zu viele Themen ins Backlog packen, denn ein zu großer Rucksack kann nicht weit getragen werden. Ein zu großes Backlogs zeigt nur, dass ein Team überlastet mit der geplanten Arbeit ist. In diesem Sinne: sicher starten und sicher ans Ziel kommen.

Related posts:

1. Starte nur dann ein IT-Projekt, wenn du dir den Verlust auch leisten kannst
2. Hellseherei – oder die Planung des Unplanbaren
3. Scrum und Festpreis

„Die französische Kolonialherrschaft in Hanoi verabschiedete ein Gesetz: Für jede tote Ratte, die man ablieferte, gab es Geld. Damit wollte man der Rattenplage Herr werden. Das Gesetz führte dazu, dass Ratten gezüchtet wurden.“ (Rolf Dobelli)

Diese Geschichte erzähle ich gerne, wenn ich in Diskussionen über die Belohnung der Teams pro gefixten Bug gerate. Die einen sind dafür, die anderen dagegen. Manche meinen, dass Zero-Bug-Policy die einzige zulässige Möglichkeit ist. Es gibt jedoch keine eindeutig „richtige“ Antwort, denn Ausgangssituationen unterscheiden sich. Belohnungen pro gefixtem Bug könnten sinnvoll sein, wenn z.Bsp. ein Team anfängt, auf einer Plattform zu entwickeln, aber zuerst die Altlasten und frühere Verschulden aufräumen muss. Entstehen die Bugs jedoch in eigener „Produktion“ so deuten diese auf Optimierungspotentiale innerhalb der eigenen Entwicklung. In solchen Fällen sollte man „Ursachenforschung“ betreiben, Problembereiche identifizieren und Lösungsvorschläge erarbeiten. Eine „Belohnung“ pro gefixtem Bug, bzw. die Aufnahme in die KPI´s (je mehr gefixt desto besser) könnte in solchen Fällen am Ziel knapp vorbeischießen (siehe Beispiel oben). Bei der Frage, ob ein Team eine zusätzliche Vergütung pro gefixtem Bug kriegen sollte, ist daher die Antwort „Je nachdem“ angebracht. Zuerst sollte man sich mit der aktuellen Situation auseinandersetzen – in jenem Unternehmen, in jenem Team. Man braucht einen „second glance“.

Velocity

Vergleicht man zum Beispiel die Durchschnittsgehälter in verschiedenen Ländern, ohne dabei die Preise der Länder zu betrachten, könnte man zu falschen Schlüssen kommen. Die saloppe Betrachtung der in der Schweiz eingesetzten EUR 100,- liefert einen anderen Output, als der Einsatz der gleichen grünen Coupüre in Griechenland oder Deutschland.

Ähnliche Überlegungen könnte man beim Vergleich der Velocity zwischen Teams anstellen. Angenommen, Mitgliederanzahl und Sprintlänge der zu vergleichenden Teams sind gleich, diese Teams arbeiten an unterschiedlichen Features, befinden sich in unterschiedlichen Stadien der Produktentwicklung – die noch dazu eine unterschiedliche Komplexität in der eingesetzten Technik aufweist – und nicht zuletzt bestehen sie aus unterschiedlichen Menschen mit einzigartigen Erfahrungen. Also können geleistete 100 Storypoints von Team A eine andere Aussage haben, als geleistete 100 Storypoints von Team B. Ob ein Team performt oder nicht, kann man erst nach einer Auseinandersetzung mit der aktuellen Situation sagen. There is a need for a  „second glance“.

Der Vergleich der Velocity innerhalb des Teams über einen Zeitraum ist auf jeden Fall zu empfehlen, darf jedoch nicht überbewertet werden. Ein Team könnte die Stories einfach mit höheren Werten, ausgedrückt in Storypoints, schätzen – dabei aber eine konstante Anzahl der Features liefern. Umgekehrt könnte ein Team User Stories niedriger schätzen, da Erfahrungswerte gesammelt wurden, Domainwissen vorhanden ist, etc. Die alleinige Betrachtung der Velocity-Entwicklung liefert außerdem keine Informationen über eventuell erhöhte Qualität, wenn ein Team zum Beispiel Altlasten aufgeräumt, Bugs gefixt hat, etc. Es empfielt sich, wie schon oben erwähnt, die Auseinandersetzung mit der aktuellen Situation samt dem „zweiten Blick“ auf die Situation.

Die Metrik alleine ist bloß ein Zahl. Aus dem Zusammenhang gerissen und losgelöst interpretiert, könnte sie zu falschen Ergebnissen führen. Sogar die einfachsten Metriken, wie die Lufttemperatur, müssen als unterschiedlich wahrgenommen werden, wenn man eine weitere Metrik – Luftfeuchtigkeit in Betracht zieht: -10°C bei hoher Luftfeuchtigkeit werden kälter empfunden als -10°C bei einer niedrigeren Luftfeuchtigkeit. Und nimmt man auch noch die Windstärke dazu… Ein komplexes System einer Produktentwicklung – bestehend aus Menschen, Methoden, Maschinen, Materialen und der Umwelt – bedarf unbedingt einer Auseinandersetzung mit der gegebenen Situation. Die Interpretation der Zahl, immer wieder aufs Neue, soll die Ursache für die Veränderung bringen.

Literaturtipp
Ralf Dobelli: “Die Kunst des klaren Denkens”

Related posts:

1. Vom Los- und in die Freiheit lassen
2. Der ScrumMaster als Dienstleister
3. TED | Vorträge | Deborah Gordon: Wie wissen Ameisen, was sie tun sollen? (Video)

Was bedeutet so eine Verurteilung nun an sich? Prinzipiell eines: Es ändert sich das Anreizsystem (zumindest in Italien), das Grundlage für wissenschaftliche Aussagen in Bezug auf Katastrophen ist. Auf den Punkt gebracht zweierlei: Zum einen wird sich weiterhin keiner für falsche Vorhersagen ohne Schadensfall interessieren. Wenn ich also heute die nächste Finanzkrise vorhersage, werde ich zwar ein paar Schulterklopfer bekommen, wenn meine Vorhersage eintrifft – es wird aber niemanden interessieren, wenn meine Vorhersage nicht eintrifft. Zum anderen bekomme ich als Wissenschaftler in Italien juristische Probleme, wenn ich etwas nicht vorhersage und dann ein Schadensfall eintritt – wie aktuell passiert.

Was für Anreize bringt so eine Art der Verurteilung mit sich? Ich kann mir genau zwei Fälle vorstellen:

1. Italienische Wissenschaftler werden sich in Zukunft hüten, Aussagen bzgl. Katastrophen zu treffen.
2. Italienische Wissenschaftler werden in Zukunft eher negativere Aussagen zu Katastrophen und ihrem Schadenspotential treffen.

In beiden Fällen verlieren wir die authentische und aufrichtige Einschätzung von Experten zu einem Thema.

Software-Orakel – gang und gäbe

Was mich direkt zur Software-Entwicklung bringt. Hier finden wir ein ähnliches Szenario: Das Schätzen von Anforderungen, Projekten, Komponenten – grob gesagt Dingen, die schwer zu schätzen sind und deren Eintreten in der Zukunft liegt. Leider gelangen wir in der klassischen Software-Entwicklung bzw. auch in Festpreisprojekten immer wieder an den Punkt, an dem Schätzungen zu barer Münze werden. Schätzungen werden zu Vertragsbestandteilen und werden als verbindlich betrachtet. Aus einem “nach besten Wissen und Gewissen” wird die “Unterschrift in roter Tinte”. Ein schwieriger Sachverhalt, wenn man bedenkt, dass selbst ein Plan nichts anderes als eine Schätzung des Ablaufs in der Zukunft darstellt.

Wie sieht die übliche Reaktion eines Software-Entwicklungsteams aus, wenn es zu einer Schätzung kommt? Meiner Erfahrung nach treffen wir hier meistens auf Punkt 1: Keiner will schätzen – am liebsten würden alle aus dem Raum rennen, denn alle haben sich schon die Finger verbrannt. Ja, es gilt Abstand zu gewinnen und so schnell wie möglich rauszukommen aus dieser Bedrängnis. Klappt Schritt 1 nicht, dann gilt es Schritt 2 anzuwenden: Wir schätzen so, dass wir möglichst hoch in unseren Aufwänden sind – wir zeichnen dunkle Bilder, frei nach folgendem Schema:

Team: “Hier sind unsere Schätzungen.”

Projektleiter: “Uff, das geht ja gar nicht, ich halbiere die mal!”

Team: “Okay!”

Projektleiter: “Okay? Ich hoffe ihr habt vorher die Aufwände verdoppelt?”

Okay, der letzte Punkt ist meist nicht die Realität. Die Teams schätzen ehrlich nach bestem Wissen und Gewissen. Nur leider vergessen sie immer wieder etwas. Das liegt mitunter daran, dass wir immer nur die Best-Case-Szenarien abschätzen können, da unser Gehirn leider nicht viel mehr hergibt. Nichtsdestotrotz, in der klassischen Software-Entwicklung setzen wir die gleichen Anreize. Wir bestrafen Experten dafür, dass sie etwas beurteilen, was schwer bis gar nicht zu beurteilen ist. Wir bestrafen Mut und Offenheit und belohnen Weichmacher, Schönredner, Angstmacher und Schwarzseher.

Related posts:

1. Schätzen vs. Planen?
2. Dr. Scrum – antwortet
3. Agile Estimation | Grundlagen