Handling Impediments with the Task Board

My colleague Bernd Schiffer has published an interesting article about managing impediments with an Action Board (see his blog post). I think it is valid to have such an Action Board and it is definitely superior to what a lot of teams do: The ScrumMaster records impediments in a personal notepad.

But I prefer a simpler mechanism and just adding impediments to the existing Task Board which I have described here in a PDF.

Teamwork during the Daily Scrum

Do you see teamwork in your Daily Scrums? Or do you see individuals reporting their individual status and then proceed with their task or story? Then try this:

Every team member answers two questions:

  1. What did I achieve since the last Daily Scrum? (and update the taskboard)
  2. What are my impediments? (and make impediments visible at the taskboard)

Then the team updates the Sprint Burndown Chart (yes, let the team draw it on a big sheet of paper).
Now the team sees the current state of the Sprint at the taskboard and the prognosis at the Sprint Burndown Chart.
Then ask the third question in a slightly modified form: How can we as a team organize until the next Daily Scrum to create the most progress towards the Sprint Goal?

That will avoid stickyness to tasks (“I worked on the database schema and will work on it again”). Instead the team plans together who should work on what. Perhaps Henning should help Stefan with the database schema? Perhaps it would be better to stop working on the database schema for now and focus on another more important task?

Einfaches Scrum

Dies ist die Übersetzung des Blog-Artikels „Simple Scrum“ von Tobias Mayer in der Version vom 01.01.2010 (http://agileanarchy.wordpress.com/2009/09/20/simple-scrum/).

Die Übersetzung habe ich (Stefan Roock, stefan.roock@it-agile.de) vorgenommen. Ich habe mich entschieden. an einigen Stellen leicht vom Original abzuweichen mit der Absicht, einen Sachverhalt einfacher zu erklären.

Ich denke an Scrum als etwas fast unfassbar Einfaches, das häufig unnötig verkompliziert wird. Es ist diese Verkomplizierung, die so viele Missverständnisse verursacht und zu schlechten Anwendungen von Scrum führt. Die folgende Beschreibung von Scrum hat das Ziel, Scrums Geist der Einfachheit einzufangen.

Scrum ist ein Framework, um die Art und Weise zu verbessern, in der Menschen arbeiten, oder wie auf der Scrum Alliance-Website definiert „ein team-basiertes Framework zur Entwicklung komplexer Systeme und Produkte“. Scrum benutzt einen iterativen Prozess in dem die Iterationen (aka Sprints) so kurz wie sinnvoll möglich gehalten werden. Die Sprints erzeugen einen gleichmäßigen Rhythmus der durch Planung, Durchführung und Reflektion pulsiert. Diese strikten, rhythmischen Time-Boxen von Scrum fördern auf frappierende Weise organisatorische Dysfunktionen zu Tage.

Scrum definiert drei Rollen (Scrum Master, Product Owner und Team), erfordert eine priorisierte Menge von Zielen, ein Commitment für jeden Sprint und eine einfache Art, Fortschritt zu messen. Scrum benutzt Zeremonien mit Timeboxen, um zu planen und auf täglicher sowie Sprint-Basis zu inspizieren und zu adaptieren.

Das „Was“ (das Ziel) und das „Wie“ (der Weg) werden klar unterschieden. Scrum erfordert klaren Fokus, Commitment und vollständige Transparenz auf allen Ebenen; es hebt auf bestimmte menschenzentrierte Werte ab, einschließlich (aber nicht eingeschränkt auf) Vertrauen, Integrität, Mut und Respekt.

Rollen
Der ScrumMaster ist eine dienende Führungskraft (Servant Leader) für das Team und ein Change Agent in der Organisation. Der Product Owner ist die Hauptstimme des Kunden, etabliert eine fesselnde Vision und benutzt einen Prozess kontinuierlicher Priorisierung, um die Vision umzusetzen. Das Team ist eine selbstorganisierte, cross-funktionale, bevollmächtigte Gruppe, die die Vision in das Produkt oder den Service umsetzt.

Artefakte
Ein Backlog (Auftragsbestand) aus Anforderungen oder Zielen ist immer vorhanden. Es enthält zu jeder Zeit all die Dinge, von denen wir möchten, das das Produkt oder der Service sie enthalten. Es ist eine lebendige Liste, kontinuierlich im Fluss und trotzdem jederzeit nach Priorität geordnet, die sich über die Zeit ändern wird. Die Einträge des Backlogs fokussieren auf das „Was“. Das Sprint-Commitment ist eine Untermenge des Backlogs, manchmal herunter gebrochen auf Arbeitsaufgaben (Tasks), die das „Wie“ beschreiben. Scrum fordert einfache Metriken, z.B. die verbleibende Restarbeit oder gelieferter Geschäftswert. Diese Metriken sollten verwendet werden, um die Wirklichkeit zu erfassen – nicht, um Erfolg oder Misserfolg zu festzustellen. Nur Metriken der Wirklichkeit können wir vertrauen, dass sie dem Team keinen Anreiz für Quick-Fix-Verhalten geben.

Zeremonien
Das Team und der Product Owner treffen sich vor dem Start jeden Sprints, um die Arbeit zu planen. Das Team committet sich auf priorisierte Arbeitspakete, die „wohldefinierte Ergebnisse“ (das Ziel) haben und es wird von ihm erwartet, dass es das fertige Produkt gemäß diesen Kriterien am Sprintende liefert. Wie das Team seine Arbeit erledigt (der Weg) ist allein ihm überlassen. Jeden Arbeitstag treffen sich die Teammitglieder an einem visuellen Board (z.B. Taskboard), um sich abzustimmen und Hilfe einzufordern und anzubieten. Am Ende jedes Sprints begutachten Stakeholder und Konsumenten die abgeschlossene Arbeit und machen Vorschläge für Anpassungen. Nach dem Review reflektieren die Teammitglieder über ihren Prozess, suchen nach Verbesserungsmöglichkeiten und committen sich auf Veränderungen ihrer Arbeitsweise. Jeder Sprint produziert ein verbessertes Produkt oder einen verbesserten Service und – sogar noch besser – ein glücklicheres Team.

Das ist mehr oder weniger die Beschreibung von Scrum, die seit der Veröffentlichung des ersten Scrum-Buchs 2003 existiert. Ich habe sie aus dem Software-Kontext herausgelöst, einige Begriffe fallen gelassen, um auf die grundlegenden Prinzipien zu fokussieren und versucht, sie auf ihre Essenz zu kondensieren. Ich habe nichts hinzugefügt oder weggelassen.

Envisioning done right

When you start a new product development you have to do something before the first Sprint: shaping a product vision, creating an initial product backlog, forming the team etc. There are a lot of names for these activities: envisioning, ideation, customer discovery, pre game etc. Envisioning seems to be the most common name.

While I think that Envisioning is often necessary I am often shocked when I see what companies do during „Envisioning“:

  • The Envisioning lasts weeks or months when hours or days would have been sufficient.
  • Comprehensive fine grained product backlogs are created.
  • Detailed designs are created.
  • etc.

That is not Envisioning. That are the early phases of a waterfall project. Therefore some people consider the Envisioning an anti pattern in Scrum.

Before I join these people I want to try to explain better what Envisioning should be and what not.

During Envisioning I value

  • learning important things over designing things
  • having business and technical people in the Envisioning team over having only the Product Owner doing the Envisioning
  • Product Owner and Team listening to and working together with real customers and users over giving research orders to marketing
  • checking assumptions about the market, customers, users over dealing with corporate stage gate processes
  • checking technical assumptions with prototypes over having long design discussions within the team
  • sketching things on flip charts over creating power point slides
While few of the things on the right side have value, I value the things on the left side more during envisioning.

Commitment and the Comfort Zone

There are issues with the commitment concept in Scrum. Even Ken Schwaber is thinking about replacing „Commitment“ with „Forecast“. While I have seen some of the described problems I think the potential of the commitment concept outweights it’s flaws. Here is a story that illustrates one powerful aspect of commitments:

At it-agile we created a Scrum team to restructure some aspects of our software development unit. For the first Sprint the Sprint Goal made it necessary to interview customers. So far so good.

But when I was at the site of a coaching client with potential interview partners it wasn’t that easy. I had a full email inbox and it was hard to get in touch with the potential interview partners. It would have been much more comfortable to postpone the interviews. And if I hadn’t committed to the Sprint Goal I would have postponed the interviews. But the commitment made me focus on what really mattered and it pulled me out of my comfort zone and do the interviews. And in the end it was the right thing to do. Learning something about customers was much more valuable than reading emails.

In this story my commitment to the Sprint Goal made me leave my comfort zone.

This is just one of the possible positive aspects of the commitment concept done right. Others include building trust, having an additional feedback mechanism, create focus etc.

Buchtipp: „Die Kraft von Scrum“

Ein Buch, in dem ein windsurfender Scrum-Coach aus Norddeutschland mit Namen Stefan vorkommt, muss einfach ein großartiges Buch sein 🙂 Die „Kraft von Scrum“ ist demnach großartig. Das Buch ist eine Scrum-Einführung nicht nur für Manager, verpackt in romanartige Geschichte, in der besagter Scrum-Coach Stefan einem angeschlagenen Software-Unternehmen durch die Einführung von Scrum den Weg aus der Krise weist.

In der Geschichte werden alle Elemente von Scrum am praktischen Beispiel eingeführt, so dass der Leser einen guten Eindruck davon gewinnt, was Scrum ist. Die Geschichte drumherum hat trotz windsurfendem Scrum-Coach keinen großen Inhalt. Sie ist halt Mittel zu dem Zweck, Scrum zu erklären und dafür ist sie vollkommen in Ordnung.

Das kleinformatige 150-seitige Buch lässt sich schnell durchlesen. An der im Vorwort genannten Lesezeit von 2-3 Stunden bin ich aber kläglich gescheitert. Naja, vielleicht habe ich einfach noch nicht die Qualitäten, um Manager zu werden…

Obwohl Scrum für mich nichts Neues mehr ist, hatte ich dennoch Spaß an der Lektüre und empfehle das Buch gerne weiter. Vielleicht ist es ja das passende Geschenk für den eigenen Chef? Für meinen Chef allerdings nicht; er hat das Buch schließlich ins Deutsche übersetzt und die Lokalisierung vorgenommen. In diesem Zuge wurde aus dem Scrum-Coach auch der windsurfende Stefan, warum auch immer 🙂

Direkt bei Amazon kaufen: „Die Kraft von Scrum: Inspiration zur revolutionärsten Projektmanagement-Methode“

To Tool or Not to Tool

A recurring question in my coaching engagements and training classes is about tools for Scrum (Product Backlog, Sprint Backlog, Taskboard, Burndown Charts). My recommendation is always the same: try index cards, pens, post it’s, card walls etc. My collegues at it-agile do the same.
Sometimes have the impression that we are very dogmatic when it comes to tools. I don’t think that I or my collegues are dogmatic. We simply base our recommendations on our experiences. Over the last 10 years we tried a lot of different tools and we have seen even more tools at our clients and the experience so far was always the same: for agile teams physical tools like index cards worked better than software tools.

But why work physical tools better than software tools?

Software tools are used with another focus than physical tools. Software tools are used for managing (e.g. for managing the Sprint Backlog). Physical tools facilitate communication and cooperation. When somebody moves an index card at a card wall, the other team members can see that directly and step into a discussion. When somebody changes the status of a ticket in an issue tracker nobody notices immediately and starting a discussion is unlikely.

And facilitating communication is more important than easy management?

This question is easy to answer with a look at the agile manifesto: The first value statement of the agile manifesto reads „Individuals and interactions over processes and tools“. And principle number six says: „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“

Yes, communication and cooperation is king.

So whatever tool is used communication and cooperation should be the goal, not management. And I think that this goal is easier to achieve with physical tools than with software tools. But in the end the decision is up to the team.

Things to try

  • The team should at least try physical tools for one Sprint to make an informed decision.
  • As ScrumMaster shield the team from existing tools and do the mapping from the physical tool to the software tool during the trial period.

Buch „Agile Entwicklungspraktiken mit Scrum“

Im Mai wird das Buch „Agile Entwicklungspraktiken mit Scrum“ im dpunkt-Verlag erscheinen. Roman Pichler und ich sind die Herausgeber. Wir wollten ein deutschsprachiges Buch herausgeben, in dem die in Scrum gängigen Entwicklungspraktiken nach dem aktuellen Stand der Technik beschrieben sind. Dazu haben wir namhafte Coaches angesprochen und sie gebeten, jeweils ein Kapitel beizusteuern. Wir selbst haben ebenfalls das eine oder andere Kapitel beigesteuert und versucht, für einen einheitlichen Stil des Buches zu sorgen, so dass sich eine möglichst durchgängige Leseerfahrung ergibt. Ich hoffe, das ist uns gelungen 🙂

Die Autorenliste umfasst Alex Bepple, Jens Coldewey, Jutta Eckstein, Peter Friese, Andreas Havenstein, Johannes Link, Martin Lippert, Bernd Schiffer und Henning Wolf. Die Themen des Buches umfassen die Architekturvision und den inkrementellen Entwurf, Continuous Integration, Testgetriebene Entwicklung, Refactoring mit und ohne Refactoring-Browser, automatisierte Akzeptanztests, Pair Programming, Collective Ownership, Coding-Dojos und Code-Katas, Modellgetriebene Entwicklung und Entwicklungspraktiken bei verteilter Entwicklung.

Es ist seit langem bekannt, dass in größeren Scrum-Projekten kein Weg daran vorbei geht, dass das Team passende Entwicklungspraktiken auswählt. Die Entscheidung, welche Techniken eingesetzt werden, obliegt in Scrum dem Team. Aus unserer Sicht sollte das Team aber die in Frage kommenden Techniken kennen und beherrschen, um eine qualifizierte Entscheidung treffen zu können. Wir hoffen, das unser Buch einen Beitrag dazu leistet.

Wer sich bereits intensiv mit eXtreme Programming auseinandergesetzt hat, dem wird vieles bekannt vorkommen. Wir hoffen, aber auch diesen Lesern einen Mehrwert bieten zu können, indem das Buch den aktuellen Stand der Technik beschreibt.

„Agile Entwicklungspraktiken mit Scrum“ bei Amazon bestellen!

Anforderungen sind keine Bedürfnisse

Bei der Arbeit mit Product Ownern finde ich es stets wichtig, dass es eine Produktvision gibt. Diese sollte neben anderem die Kundenbedürfnisse enthalten sowie die Key-Features des Systems. Laut Wikipedia ist ein Bedürfnis „[…] das Verlangen oder der Wunsch, einem empfundenen oder tatsächlichen Mangel Abhilfe zu schaffen.“ Ein Feature „[…] ist die Fähigkeit eines Produktes oder einer Komponente, eine bestimmte Funktion oder Gruppe von Funktionen zu erfüllen.“

Bedürfnisse und Features auseinander zu halten fällt vielen Product Ownern sehr schwer. Heraus kommen dann Formulierungen, in denen Bedürfnisse und Key-Features identisch sind – nur leicht anders formuliert. Beispiel: „Menschen, die andere Menschen anrufen wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.“

Wenn man vor der Frage steht, ob etwas wirklich ein Bedürfnis ist, hilft die Maslowsche Bedürfnispyramide. Sie hat diese Stufen (von unten nach oben):

  1. Physiologische Bedürfnisse: Atmung, Schlaf, Nahrung, Wärme, Gesundheit, Wohnraum, Kleidung, Sexualität, Bewegung
  2. Sicherheit: Recht und Ordnung, Schutz vor Gefahren, festes Einkommen, Absicherung, Unterkunft
  3. Soziale Bedürfnisse: Familie, Freundeskreis, Partnerschaft, Liebe, Intimität, Kommunikation
  4. Anerkennungsbedürfnisse: Höhere Wertschätzung durch Status, Respekt, Anerkennung (Auszeichnungen, Lob), Wohlstand, Geld, Einfluss, private und berufliche Erfolge, mentale und körperliche Stärke
  5. Selbstverwirklichung: Individualität, Talententfaltung, Perfektion, Erleuchtung, Selbstverbesserung

Jetzt müssen wir uns lediglich die Frage stellen, auf welche Stufe unser „Bedürfnis“ fällt. Wo würde man das vermeintliche Bedürfnis „telefonieren“ verorten? Genau! Es passt da nicht rein. Man kann telefonieren, um in Kontakt mit seiner Familie oder seinen Freunden zu bleiben. Dann wäre genau das das Bedürfnis und wir könnten z.B. schreiben: „Menschen, die im sozialen Kontakt mit ihrer Familie bleiben wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.“