High Moon Studios und Scrum

... heute auf dem Blog von Jeff Sutherland gefunden - High Moon Studios gibt einen Einblick in deren Scrum Prozess.

Wie plant man einen Release?

Beim agilen Vorgehen geht man davon aus, dass nach jedem Sprint funktionierende und brauchbare Features bereit stehen, die in Betrieb genommen werden können. Wann macht man einen Release?

Die Arbeit für ein Scrum Projekt wird im Product Backlog manifestiert. Hier steht, was am Ende geliefert werden soll, zum Zeitpunkt "heute".

Product Backlog
Das Product Backlog definiert das Fernziel, das Ende der Reise. Es hat teilweise einen visionären Charakter. Alle Aufgaben auf dem Weg werden in Form von User Stories festgehalten. Ordnet man jeder User Story im Product Backlog einen Business Value zu, erhält man eine Kennzahl, die den betriebswirschaftlichen Nutzen wiederspiegelt. Ebenso wichtig sind die Wünsche und Erwartungen der eigentlichen Endbenutzer. Er /sie wird entscheiden, ob die Software brauchbar ist und man damit arbeiten kann oder nicht. Nur wenn sich für Product Owner und Endbenutzer einen Win-Win Situation einstellt, kann man von einem Erfolg sprechen. Um die Wünsche und Erwartungen der Endbenutzer herauszufinden, gibt es mehrere Möglichkeiten, die hier nicht näher beschrieben werden sollen.

Priorisierung
Mit Hilfe des Business Value und der Gewichtung der Endbenutzer kann man die User Stories im Product Backlog priorisieren - die Basis für viele Sprint Backlogs. Das Product Backlog gibt dem Product Owner die Möglichkeit, die Priorisierung der User Stories zu ändern, hinzuzufügen, zu löschen, den Business Value neu zu bewerten, User Stories zusammenzufassen oder zu spitten - Changes are welcome.

Sprint Backlog
Der Product Owner präsentiert vor jedem Sprint im Planning Meeting seine Wünsche und beantwortet damit die Frage, welche User Stories aus dem Product Backlog im kommenden Sprint bearbeitet werden sollen. Das Team ordnet jeder User Story einen Aufwand (Effort) zu und nimmt die Arbeit an, die machbar ist. Man definiert gemeinsam das Sprint Backlog für den kommenden Sprint. Aufgrund von Erfahrungswerten kann man in etwa abschätzen, wie viele User Stories in einem Sprint vom Team abgearbeitet werden können. Das Sprint Backlog ist für die Dauer des Sprints eingefroren.

Releaseplanung
Während alle User Stories im Product Backlog quasi das Fernziel beschreiben, werden in den Sprints einzelne Etappen geplant und umgesetzt. Nach wievielen Sprints ist man nun so weit, das man einen ersten Release machen kann? Die Antwort gibt wiederum der Endbenutzer! Prof. Noriaki Kano hat in den 80-iger Jahren ein Model entwickelt, mit dem man Kundenbedürfnisse kategorisiert und gewichtet - bis heute ein wichtiges Instrument in der Produktentwicklung - Kano Model. Kennt man die Basic, Performance und Exciter kann man ein Paket schnüren, um mit Release One in Produktion zu gehen.

Was haben Hühner und Schweine mit Scrum zu tun?

There is an old joke in which a chicken and a pig are talking and the chicken says, "Let's start a restaurant." The pig replies, "Good idea, but what should we call it?" "How about 'Ham and Eggs'" says the chicken. "No thanks," says the pig, "I'd be committed, you'd only be involved." Mountain Goat Software

Genau so wurde mir im August 2006 die Rollenverteilung bei Scum von Peter Stevens erklärt - "Du bist ein Schwein". Was hier im Witz salopp daher kommt wird bei Scrum sehr Ernst genommen. Scurm gibt denen einen speziellen Status, die committed sind. So ist es in vielen Scrum Teams z.B. nur "Schweinen" erlaubt während dem Daily Scrum zu sprechen ...

Scrum unterscheidet zwischen den Beteiligten und Involvierten - Hühner und Schweine.

Schweine sind committed Team Mitglieder. Sie arbeiten selbstorganisiert und selbstregulierent. Alle Interessensvertreter, die nicht zum Team gehören, sind Hühner. Sie können das Team nur über das Product Backlog steuern, bzw. beeinflussen. Der Product Owner ist die Person, die Visionen, Interessen und Ideen von Hühnern aufbereitet, entscheidet was aufgenommen wird und was nicht und diese letztendlich dem Team in Auftrag gibt.

Wie sieht ein Scrum Team aus? Das ist ein einem weiteren Post das Thema ...

Kostenberechnung bei Scrum

Budget und Kosten - Auch wenn man agiles Vorgehen einsetzt, stellen sich diese beiden Kandidaten zur Diskussion.

Wie berechnet man die Kosten für einen Sprint?

Auf einen meiner letzten Posts gab es einen Kommentar von Nils. Wir haben die Konversation (leider) per Email weiter geführt. Er schreibt an einer Diplomarbeit und wollte unter anderem eine Antwort auf die folgende Frage:

"Hi, sachmal weißst du wie die Kostenabrechnung bei Scrumprojekten funktioniert? wird diese je Sprint errechnet.."

Die Antwort:

"... cost is defined by the number of developers assigned to the project and the duration of the Sprint. Sum for your team (Availability * Duration * Daily Rate) = Cost. Actually it's a cost ceiling. Under Scrum, there's not much overtime, so the there is an upper limit on the costs defined by the time. " Peter Stevens

The early adopter

Vor ca. 1. 1/2 Jahren habe ich zum ersten Mal von SCRUM gehört. Nach anfänglicher Skepsis schlug das Stimmungs- barometer bald in die entgegengesetzte Richtung aus. Peter Stevens, der uns die agile Vorgehensweise vorstellte, meinte schon bald: "Well, Johnny you are a early adopter!".

Man steht nicht morgens auf und denkt, Ok! - Ab heute arbeite ich nach Scrum. Woher auch, noch nie zuvor gehört. Trotzdem war Scrum eines morgens nach einem kritischem Projektmeeting vor ca. 1 1/2 Jahren plötzlich in meinem Arbeitsleben angekommen- unwiderruflich. Peter Stevens hat seinerzeit ein Projekt in Schieflage übernommen und mit völliger Überzeugung in der agilen Vorgehens- weise die einzige Hoffnung gesehen, das Projekt zu retten und eine langfristig erfolgreiche Kundenbeziehung aufzubauen: "Wir werden unser Vorgehen in diesem Projekt ändern. Ab heute arbeiten wir nach Scrum - (mit erhobenem Finger) ...nicht zu verwechseln mit Scum!"

Wenig später wurde das gesamte Team auf agile "umgestellt" und nach wenigen Sprints hatte man das Projekt wieder unter Kontrolle und das Vertrauen des Kunden zurückgewonnen. Nach nunmehr 22 Sprints und aktuell im 5. Release ist das Projekt stabiler und erfolgreicher als je zuvor.

Peter hat nun begonnen die Erfahrungen aus dieser Zeit in seinem Blog zu dokumentieren - Sprint Zero.

Danke Peter, es macht Spass das zu lesen! Ist es doch, als war es erst gestern ...

Scrum Vorstellung - Ein neues Projekt mit Scrum

Ich möchte mit diesem Beitrag auf die vielen Fragen eingehen, die man zweifelos gestellt bekommt, wenn man einem Team die "neue" Arbeitsweise vorstellt.

Unser Ziel soll es sein, das Team für agiles Arbeiten nach Scrum zu gewinnen! Drum, sage nicht, was Scrum nicht ist! Sage, was Du über Scrum sagen wirst, sag es und wiederhole, was Du gesagt hast.

Und das ist, was wir sagen wollen:

• Was ist Scrum? Wo kommt es her? (geschichtl. Hintergrund)
  
• Nach welchen Werten und Prinzipien wird vorgegangen?
• Was hat es mit dem agilen Manifesto aufsich?
• Was charakterisiert ein agiles Team?
  
• Wie wird der Kunde eingebunden?
  
• Wie sieht das "Team" aus?
  
• Wie geht man mit Widerstand um?
• Wie kann der Projektfortschritt gemessen werden?
  
• Welche Tools kommen zum Einsatz?

Da sind die Fragen, für die man ein Antwort haben sollte, BEVOR man ein Team diese Arbeiteweise vorstellt. Da viele potenzielle Teammitglieder in der Welt der klassischen Projektmethoden zu hause sind, bietet sich an die bekannten Vorgehensmodelle mit Scrum zu vergleichen und die offensichtlichen Vorteile werden schnell klar - der Aha Effekt kommt meist von selbst.

Es hat sich als hilfreich erwiesen, nach ein paar einleitenden Sätzen in das Thema einen Workshop zu machen, am besten mit Rollenspielen, für:

• Planning
• Estimation
• Retrospective
• Daily Scrum

Bevor man ein Team mit dem Thema konfrontiert, sollte man sich grundsätzlich selbst ein paar Fragen stellen:

• Wie wird mein Team auf eine neue Methode reagieren?
• Wie sieht es mit den Rahmenbedingungen im Unternehmen aus? Kann man das Team isoliert arbeiten lassen? Wird agil vom Management unterstützt?
  
• Wer wird Scrum Master? Soll das Team wählen oder das Management bestimmen?
• Hat man bereits negative Erfahrungen mit agilem Arbeiten? Warum negativ?
• Kann man Teammitglieder längerfristig an ein Projekt binden? Sind alle benötigten Kompetenzen verfügbar (cross-functional teams)?
• Wie möchte man dem Team die Hemmungen und anfänglichen Irretationen nehmen?
• Ist man selbst überzeugt vom agilen Arbeiten? Kann man andere mit der Euphorie anstecken?

So, und wie könnte das alle aussehen? Mein Kollege Peter Stevens/namics hat dazu ein Video aufgezeichnet.

Was ist ein Sprint?

Scrum ist ein agiler Prozess zur Softwareentwicklung. Scrum definiert einen Prozess als eine Serie von 2-4 Wochen langen Iterationen - Sprint genannt.

Scrum ist ideal für Projekte bei denen Anforderungen schnell ändern oder häufig neue Anforderungen auftauchen. Die Arbeit, die in einem Scrum Projekt zu leisten ist, wird in einem Product Backlog aufgelistet.

Zu Beginn eines Sprints priorisiert der Product Owner das Product Backlog und das Scrum Team wählt die Aufgaben, die im kommenden Sprint gelösen werden können. Diese Aufgaben werden in das Sprint Backlog übernommen.

Jeden Tag im Sprint gibt es einen Daily Scrum, der dem Team hilft auf Kurs zu bleiben ...

The Daily Scrum

Bei einem Scrum Projekt gibt während des Sprints ein kurzes tägliches Meeting - der Daily Scrum. Dieses Meeting wird immer am selben Ort und zur selben Zeit geführt, meistens morgens. Der Daily Scrum dient dazu, dass Team auf den heutigen Tag zu fokussieren.

An einem Daily Scrum können "alle" Projektbeteiligten teilnehmen, z.B. Stakeholders, Analysten, Product Owner oder ein Vertreter aus dem Management - allderings bleibt nur den "committed" Mitgliedern das Recht vorbehalten zu sprechen. Das macht den Daily Scrum zu einer idealen Basis, um Informationen und Status auszutauschen. Wenn jemand wissen möchte, wie es um ein Projekt steht, ist der Besuch der Daily Scrums eine gute Idee.

Der Daily Scrum ist nicht die Bühne, um Problem zu lösen oder offen Punkte zu klären, dies wird anschliessend in kleineren Gruppen (offline) gelöst. Während des Daily Scrum beantworted jedes "committed" Teammitglied folgende 3 Fragen:

1. Was habe ich gestern gemacht?
2. Was werde ich heute machen?
3. Was für Hinderhisse habe ich?

Durch den täglichen Rückblick jedes Teammitgliedes erhält das Team einen sehr guten Feedback darüber, was bereits geleistet wurde und wieviel Arbeit noch zu erledigen verbleibt.

Sobald ein Hinderniss auftaucht ist der Scrum Master angehalten, dieses Hinderniss aus dem Weg zu räumen. Wenn der Scrum Master das Hinderniss nicht selbst aus dem Weg räumen kann (z.B. technische Problem), muss er sicherstellen, dass er jemanden findet, der das Problem lösen kann - meist innerhalb des Teams.

iterativ versus agil

Iterativ ist nicht gleich agil! In vielen Gesprächen, Artikeln und Erfahrungsaustauschen stelle ich immer wieder fest, dass iteratives Vorgehen und agiles Vorgehen gleichgesetzt werden. Dem ist nicht so, zumindest in aller Regel!

Beim Interativen arbeiten nähert man sich in Iterationen dem Gesamtziel, aber sequenziell. Pro Iteration werden geplante Milestones abgearbeitet.

Ein anderes, oft verbreitetes Vorgehen ist der iterative Wasserfall. Oft ist das die erste Ausbaustufe, wenn man vom klassischen Vorgehen auf agiles Vorgehen "umstellt". Das Team abeitet im gewohnten, sequenziellen Modus, aber pro Iteration. Mit diesem Vorgehen erreicht man zwar, dass man pro Iteration funktionstüchtige Artefakte liefern kann, jedoch ist das Ende einer Iteration meist sehr un-planbar und oft geprägt von Refactoring und ordentlich Zeitdruck im Team. Erst beim Test stellt sich heraus, ob alles so funktioniert, wie geplant.

Wahres agiles Arbeiten bedeutet, dass man alle Aufgaben parallel in einer Iteration abarbeitet (siehe c) - Analayse, Design , Programmierung und Testing passiert parallel, quasi Hand in Hand. Es findet stetige Kommunikation zwischen allen Teammitgliedern statt.

Scrum Breakfast in Zürich February 6, 2008

The February and March Scrum Breakfasts will be held under the sign of experience reports.

In February, Marcello Leonardi, Scrummaster des namics-Projekts White Label Classifieds will present his experiences with this project. WLC -- known in the market at "Publisherconnect" – is the basis for many classified advertsing market places. Some of the more prominent examples include NZZexecutive.ch, Publicjobs.ch, osthome.ch, pilote.ch hand many others. Marcello has been a member of the development team since over 1 year and took over the scrummaster Roll about 6 months ago. He will talk about the project, both from the perspective of a developer and from that of the Scrummaster.

Topics:

* WLC Project Overview
* Introducing Scrum into the WLC Project
* Current State of the development of WLC 5.0
* Leasons Learned

Datum: 6. Februar 2008 (immer den 1. Mittwoch des Monats)
Zeit: Einlass 8.00 bis 10.00, Vortrag 8.35 bis ca. 9.00

Date: 6.2.2007 (always the first Wednesday of the Month)
Time: Doors open at 8.00am, conclusion 10.00am.
The talk starts at 8.35 (so that you can come by train at 8.30 and still be on time).
Location: namics ag, Konradstrasse 12, CH-8005 Zürich

The talk will be held in German.

Attendance is free and namics is sponsoring the coffee, gipfeli (croissants) and orange juice. To register, just send me a private message or better register on xing: https://www.xing.com/app/events?op=detail;id=171305

*SHIFT_resources - das Spiel mit den offenen Karten

*SHIFT_resources - so oder so ähnlich würde der Claim auf den Werbeplakat von Nissan aussehen, wenn ...

Erfahrungsgemäss ist mit der Einführung von agilem Vergehen á la Scrum das Offenlegen der Resourcen am Projekt ein zweiseitiges Schwert, weil ...

Der Product Owner trifft pro Iteration bei der Planung und Vorführung, wahlweise auch bei der Retrospective, auf das gesamte Team. Damit ist eines sofort ersichtlich - Resource-Shifting beim Software Anbieter - Pluspunkt!

Den Minuspunkt gibts beim Software Anbieter - der muss sich sehr wohl überlegen, ob und wie oft er Resourcen auf dem Projekt wechselt. Auch ein Resource-Sharing wird schnell ersichtlich, denn bei der Planung wird das Team dem Rechnung tragen, wenn 1, 2 oder 3 Entwickler nur 80% am Projekt arbeiten.

Zusammenfassend kann man sagen: wer ein Projekt nach SCRUM abwickelt, spielt bezüglich Resourcen mit offenen Karten - man muss!

Scrum Einführung - leider erfolglos

Gestern war für mich kein sehr erfolgreicher Tag, denn ich konnte ein Projekt-Team nicht davon überzeugen, agile zu arbeiten ...

Es geht um eine Webapplikation, die entwickelt werden soll. Der Funktionsumfang ist klar, Zeit und Budget auch. Das Projekt dazu wurde im Oktober 07 gestartet, Entwicklungsbeginn war Anfang Dezember. Das Projekt soll Ende Februar 08 abgeleistet sein. Ich arbeite seit Entwicklungsbeginn an diesem Projekt. Vorgehen: Wasserfall!

Projektteam (fix):

• 2 Software Engineers
• ein Projektleiter und einen Kunden-Projektleiter

sporadisch (auf Abruf):

• bis zu 3 Publisher
• ein Designer
• ein Flash-Spezialist

Alle Teammitglieder arbeiten an diversen anderen Projekten, sind also nicht 100% auf diesem Projekt.

Man weiss per heute bereits, dass dieses Projekt nicht in Zeit und Budget realisiert werden kann. Darum wurde die Entwickel-Crew gestern um 2 Software Engineers aufgestockt, d.h. +50%. Man geht davon aus, dass man damit nur halt so lang brauchen wird, so die Annahme.

Ich habe die Gelegenheit genutzt, um dem Team SCRUM vorzustellen. Ziel sollte es sein, dem Team zu vermitteln, dass man durch SCRUM das Risiko eines Misserfolgs minimieren kann, indem man regelmässig in definierten Intervallen lauffähige Funktionen entwickelt und dem Kunden zeigt. Damit stellt man einen engen und nachhaltlichen Kontakt zum Kunden her, schafft Vertrauen und fördert die Kommunikation und gibt dem Kunden die Chance, früh auf neue Bedürfnisse zu reagieren, neu Ideen einzubringen, sie zu priorisieren, etc.
Letztendlich fanden alle die Idee vom agilen Arbeiten sehr interessant, doch niemand hatte genug Vertrauen und Mut, es jetzt zu versuchen. Ausschlaggebend war, dass man einen so engen Kontakt zum Kunden besser unterbindet, weil man weiss, dass immer wieder neue Anforderungen erhoben werden, wenn man frühzeitig Funktionen präsentiert - GENAU! Das ist der Unterschied - bei agilem Arbeiten heisst es "Changes are welcome!". Das Team hat gegen SCRUM gestimmt ...

Daraufhin habe ich den Kontakt zu Kollegen aus der "agilen Ecke" gesucht - mein Misserfolg ist bekannt und auch erklärbar:

• Druck
• Ungewissheit
• Transparenz
• Disziplin
  

Das sind so die grössten Hindernisse, die bei der Einführung von SCRUM im Weg stehen. Nächsten mal werde ich auf diese Punkte deutlicher eingehen ...