Release 2.0 erfolgreich ausgeliefert

Gestern, 22.05.07 haben wir den Release 2.0 (Anneboda) erfolgreich ausgeliefert. Wir haben daran zwei Sprints a eine Woche gearbeitet. Geplant war pro Sprint eine Velocity von 10 SP's. Es hat sich jedoch gezeigt, dass einwöchige Sprints nicht wirklich gut sind, denn es ist das Ziel am Sprint Ende alle User Stories auf DONE zu bringen. Wir konnten das nicht einhalten. Im ersten Sprint wurde lediglich eine User Story mit 1 SP abgeschlossen, im zweiten Sprint dann 5 weitere mit insgesamt 25 SP's. Damit wurden total 26 SP's für diesen Release realisiert. Wir werden zukünftig wieder Sprints a zwei Wochen planen - Velocity 20.

Ein alt bekanntes Problem gab es auch während dieses Releases - Resourcenlage. Es gab erneut wieder, sagen wir mal "flüchtige Resourcen". Teammitglieder wurden mal stunden-, mal tagweise abgezogen und es ist viel Arbeit liegengeblieben. Der Rest des Teams hat diese dann übernommen und fertiggestellt - immerhin fördert das den Teamzusammenhalt, auch wenn man beim Einen oder Anderen Säbelrasseln hört...

Was haben wir daraus gelernt? Nun ja, die Scrum Rituale sind wichtig! Bisher haben wir Estimation, Planning Meeting und Daily Scrum nicht nach Scrum durchgeführt. Hier war es eher so, dass ein kleiner Teil des Teams diese Meetings durchlaufen hat, nicht aber alle. Damit haben die Daily Scrum Meetings eher den Stil von "Du machst heute das!" (Weil ich es Dir sage!). Was passiert? Niemand übernimmt Verantwortung und klemmt sich hinter die Arbeit. Man bekommt auch keine Hindernisse oder Verzug gemeldet. Am Ende wird es eng und die Gemüter sind erhitzt!

Wir machen jetzt Planning Meeting mit allen Teammitgliedern und jeder wählt selbst, welche Arbeit er übernehmen möchte. "Scheissarbeiten" werden demokratisch verteilt, so kommt jeder mal in den Genuss. Jedem ist klar, dass er allein für die Fertigstellung der Aufgabe verantwortlich ist. Wenn Hindernisse auftauchen müssen diese in erster Linie selbst gelöst werden.

Wir arbeiten jetzt konzentrierter und fokussierter an den Aufgabe - ein guter Schritt nach vorn, wie ich finde.

Scum bei der SAF AG, Tägerwilen

Die SAF AG, Tägerwilen arbeitet an verschieden Standorten an zwei ihrer Produkte - SAF ApplicationSuite und SAF Engines.

Die Verteilung der Entwicklungsteam stellt besondere Anfordungen an das Projektmanagement. Kompetenzen müssen optimal zusammenspielen, Produktverbesserungen sollen schnell und iterativ in die Produkte einfliessen und man möchte die Qualität der Software nachhaltig sicherstellen.

Die SAF AG setzt Scrum als Vorgehensmodell ein und verfügt über 11 zertifzierte Scrum Master. Täglich gibt es teamübergreifend ein Daily Scrum, der für die Transparenz im gesamten Unternehmen sorgt. Mit Scrum gelingt es der SAF AG die Qualität bei der Softwareentwicklung zu sichern.

Gibt es noch andere Unternehmen in der Schweiz, die Scrum erfolgeich einsetzen?

Was ist ein Story Point

Soll man eine Aussage über den Aufwand für eine Aufgabe machen, ist man gezwungen zu Schätzen. Je nachdem, wieviel Erfahrungen man hat, um die Aufgabe zu lösen, oder ob man eher optimistisch oder pessimistisch schätzt, oder, oder, oder kommt man zu einer anderen Aussage - eben einer Schätzung.

Wie auch immer man zu einer Schätzung kommt wurden meistens folgende Punkte mit einkalkuliert:

• Risiko
• Know-How
• Komplexität
• Zeit
• Qualität
• Resourcen

Story Points sind eine Einheit für Komplexität (ausschliesslich). Sie dienen der Schätzung von Aufwand für die Erledigung einer Aufgabe. Beispiel:

Wie komplex ist es, vom der Wohnungstür zum nächstgelegenen Supermarkt zu gelangen. Nehmen wir an, es ist 1. Wie komplex ist es dann wohl, von der Wohnungstür zum nächstgelegenen Flugplatz zu kommen? Vielleicht eine 3. Dass bedeutet, dann die Bewältigung der zweiten Aufgabe 3-mal so komplex ist, wie die für Aufgabe eins.

Man macht also bewusst keine Aussage über Zeit, Resourcen, Know-How oder ähnliches. Man versucht vergleichbare Aufgaben in Komplexitätsrelationen herunterzubrechen. Gebräuchlich ist die Fibonacci Folge 1,2,3,5,8 - nicht mehr!
Wenn man ein paar mal mit Story Points geschätzt hat, bekommt man sehr schnell ein Gefühl dafür, wass eine 1, 2 oder 5 ist. Da das Team die Story Points pro User Story definiert, hat der Kunde einen Feedback. Zusammen mit dem ihm bekannten Business Value kann er nun die Priorisierung festlegen. User Stories mit hohem Business Value und geringer Komplexität werden in aller Regel zu Beginn realisiert. Für alle anderen Kombinationen gibt es unterschiedliche Ansätze. So geht man bespielsweise davon aus, dass ein Feature mit einer hohen Komplexität, aber geringem Business Value auch möglichst früh in einem Projekt begonnen werden sollte, da eine hohe Komplexität das Team und den Kunde bezüglich gewonnenem Know-How am weitesten voranbringt. Man geht davon aus, dass nicht die Entwicklung des Produkts die grösste Errungenschaft ist, sondern das gewonnen Know-How ...

Release 1.0 erfolgreich ausgeliefert

Am Montag 07.Mai 07 haben wir den ersten Release (Ecktorp) im neuen Scrum Projekt planmässig ausgeliefert. Alle Features, die geplant waren, wurden firstgerecht fertigestellt und in Produktion genommen. Der Kunde ist sehr zufrieden und hat mit dem Team die weiteren Schritte definiert.

Trotzdem der Release erfolgreich war, hatten wir einige Problem, die ich hier kurz erläutern möchte.

1. Sprint-Planung
   Von Begin an war klar, dass wir einen ersten Release nach ca. 3 Wochen in Betrieb nehmen werden. Das Produktbacklog bot genug Arbeit für ca. 3 Releases. Der Kunde hat ein Priorisierung der Features vorgegeben und das Team hat die Arbeit zunächst auf einen Sprint mit 3 Wochen mit 25 Story Points geplant. Ein weiterer Release steht in 2 Wochen an, was uns zur Frage bringt, wie man dass in eine Sprint Planung einbezieht. Wir haben für den 2. Release (Anneboda) zwei Sprints a eine Woche geplant. Die Problematik besteht nun darin, eine realistische Planung aufzustellen, denn man hat keinen Vergleich für die Sprint Geschwindigkeit (Velocity). Unsere Annahme ist, dass wir pro Woche 12 Story Points realisieren können. Wir werden sehen ...
   
2. Resourcenplanung
   Sprint 1 wurde mit einem Team von 4 Entwicklern geplant. Wir haben die User Stories aufgeteilt und parallel an Features gearbeitet. Nach ca. 1 1/2 Wochen hat sich die Resourcenlage leider verschlechtert - es wurden 2 Teammitglieder abgezogen. Nun, was ist passiert? Ein Scrum Teammitglied arbeitet weitestgehend eigenverantwortlich. Wenn jemand das Team während des Sprints verlässt, hinterlässt man begonnen Arbeit in einem mehr oder weniger unklarem Zustand. Wir haben also in der Hälfte des Sprints die Strategie zur Abarbeitung der User Stories verändert und auf Stabilität statt Menge gesetzt - sprich den Umfang reduziert. Der Rest vom Team hat die liegengebliebene Arbeit (grossteils durch Überstunden) auf DONE bringen können. So haben wir es trotz nicht geplanter Lage geschafft, alle gewünschten Features fertigzustellen. Das hat nur funktioniert, weil das Team bereits mit dem Scrum Vorgehensmodell vertraut ist und technologisch sattelfest ist. Wenn das Know-How nicht homogen verteilt ist, ist eine solche Lage durchaus als riskant einzustufen.
   
3. Prototype
   In der Offerte wurden bereits Screen/Design Vorschläge offeriert. Unmittelbar zum Projektbeginn hat der Kunde das Design abgenommen. Daraufhin wurde ausserhalb des Scrum Teams ein HTML Prototype realisiert. Als das Scrum Team die Arbeit aufgenommen hatte, ergaben sich die ersten Probleme. Das Design war für eine Website, nicht aber für eine Webapplikation ausgelegt. Klassiker, wie Links, die einen Form Submit auslösen, Breadcrumb Trail in einer Applikation, Dialoge, die keine Dialoge sind, etc. wurde falsch gemacht. Somit konnte das Team nur verzögert mit der Arbeit beginnen. Dazu kam, dass der Kunde das Design abgenommen hatte und nunmehr bereits nach wenigen Tagen schon ein Re-Design besprochen werden musste, bevor überhaupt Features realisiert werden konnten. Der Kunde war sichtlich irritiert - verständlich! Daher die Empfehlung einen Applikationsdesigner von Beginn an einzusetzen. Es ist sicher auch hilfreich ein Developer über das Design schauen zu lassen - das hat sich in der Vergangenheit immer bewährt.

Was vielleicht noch erwähnenswert ist: wir haben die Scrum Rituale auf eine Minimum beschränkt. Wir machen täglich ein 15-minütiges Stand-up Meeting, Sprint und Release Planung und eine Retrospective bei einem Bier am Abend. Wir setzten Target Process ein, beschränken uns aber nur auf die Funktionen für Release und Sprint Planung, sowie User Stories und Bugs. Sonst kommen keine weiteren Tools zum Einsatz.

Daily Scrum mit TargetProcess, Teil II

Ich wurde von einem Mitarbeiter von TargetProcess durch einen Kommentar auf einen Post darauf hingewiesen, dass TP ab der kommenden Version auch ein Feature für den Daily Scrum anbietet, was es bisher nicht gab. TargetProcess hat sich dazu entschlossen, in das Produkt mehr Scrum Kompatibilität einzubauen - sehr gut!

--> TargetProcess v.2.0 Day by Day | Agile Development On Real Project: Daily SCRUM Support via TaskBoard

Ich habe ihm versprochen mir das neue Feature einmal anzusehen und mein Feedback dazu abzugeben - so, here we go ...


Auf den ersten Blick ist in dem neuen Feature alles da, was man für den Daily Scrum benötigt. Man bekommt schnell einen Überblick und sieht:

• User Stories, die Hindernisse haben
• alle offenen Tasks pro User Stories und die zugewiesenen Entwicklere
  
• alle Tasks und wer daran arbeitet
• alle abgeschlossenen Task

Darüber hinaus kann man schnell die Restzeit pro Task erfassen, neue Task anlegen, den Status eines Task modifzieren und vieles mehr.

Sieht also gut aus. Für mich sieht das Task Board, wie TP das nennt, etwas überladen aus. Meine präferierte Arbeitsweise ist etwas anders. Wir gehen beim Daily Scrum folgenden Fragen nach:

1. Was hast Du gestern gemacht?
2. Was machst Du heute?
3. Wo sind Deine Hindernisse?

D.h. wir konzentrieren uns beim Daily Scrum auf die Team Mitglieder, nicht auf User Stories oder Task. Die Fragen für die Arbeitsweise mit dem Task Board müssten eher so heissen:

1. An welchen User Stories arbeitet das Team?
2. Gibt es Hindernisse?
   
3. Wie ist der Status der Tasks pro Story?
4. Wer arbeitet an welchem Task?
   
5. Kann der Status einer Story auf Done gesetzt werden oder müssen neue Task hinzugefügt werden?
6. Wie gross ist die Restzeit pro Task?
   

Wie man sieht, ist das alles sehr prozesslastig und geht in Richtung Micro Management. Dazu kommt, dass für den Daily Scrum 15 Minuten veranschlagt sind, was mit diesem Tool eher mehr sein dürfte . Unsere Arbeitsweise passt nicht auf das Task Board, auch weil die Entwickler die Tasks selbst definierten, nicht der Scrum Master im Daily Scrum.

Wir freuen uns trotzdem auf das neue Feature von TP und werden uns das genau ansehen ... stay tuned!

Die ersten Schritte in einem Scrum Projekt

Das Product und Sprint Backlog sind definiert, das Team ist aufgestellt, der erste Sprint hat begonnen - wie geht es los?

Eine Frage, die nach jedem erfolgreichen Projektgewinn gestellt wird und zunächst immer ein bischen Unruhe und Nervosität hervorruft - mit Scrum alles kein Problem! Konzentrieren wir uns auf die wichtigen Aufgaben zuerst.

1. Projektinfrastruktur
   Zunächst wird die Projektinfrastruktur festgelegt und eine zuständige Person definiert. Dazu gehören TargetProcess, Team Emailadresse, Wiki und diverse andere Kommunikations-Tools.
   
2. Applikationsdesign
   Nach gründlichem Studium der Offerte und des Product-Backlogs wissen wir, wohin die Reise gehen soll. Das Fernziel "Amsterdam" ist bekannt, doch wir möchten im ersten Sprint mit einem Beta-Release nur bis "Madrid" fahren. Wir sind in Neapel! Der Application Architect arbeitet einen Architekturvorschlag, das Team trifft sich, diskutiert und verabschiedet diesen. Dabei steht Sprint 1 im Vordergrund, auch wenn das Fernziel durch die Architektur getragen werden soll. Beim Applikationsdesign wird das Layering definiert.
   
3. Packaging
   Aus der Architektur und dem Layering wird die Maven Projektstruktur abgeleitet und von einer Person umgesetzt. Darüber hinaus werden pro Projekt die Package Richtlinien definiert und pro Layer eine Zuständigkeit vergeben.
   
4. Design/Wireframes
   Das Design und die Wireframes sind vom Kunden verabschiedet. Der Form-Flow/Story Boards ebenfalls. Ein HTML Prototyp für die Features von Sprint 1 wird bereits umgesetzt und Selenium Tests für alle Features am Prototyp aufgezeichnet.
   
5. Domain Model
   Durch die Wireframes kann das Domain Model für die Features von Sprint 1 begonnen werden. Auch hier wird das Model nur für "Madrid" entworfen, vom Team verabschiedet und von einer zustänidgen Person umgesetzt.
   
6. Entwicklungsumgebung
   Nachdem die Maven Projektstruktur bekannt ist, kann die Entwicklungsumgebung von einer Person aufgesetzt werden. Es wird eine Anleitung für alle Team Mitglieder geschrieben.
7. Done Definiton - das Team definiert, wann eine User Story Done ist.
   

Alle Beschlüsse und Entscheidungsgrundlagen werden im Projekt Wiki dokumentiert. Der Product Owner überführt aus der Offerte Fachbegriffe in ein Projekt-Glossar. Darüber hinaus verlinkt er alle relevanten Dokumente.

Die Umgebung für automatisiert Tests und CruiseControl werden vom Team nicht hoch priorisiert - werden auf Sprint Ende verschoben. Wichtig ist, dass man so schnell als möglich Features entwicklen kann. Es werden zwar Selenium Tests geschrieben, aber noch nicht automatisieret.

So, das Ziel ist, alle hier genannten Punkte binnen 4 Arbeitstagen abzuarbeiten - das ist die Arbeit des Teams für die ersten Tage im Projekt.

Ein neues Scrum Projekt

Seit gut einer Woche arbeite ich an einem neuen agilen Projekt. Da oft die Einführung von Scrum und agiler Arbeitsweise auf "später" verschoben wird, möchte ich mit ein paar Posts zeigen, dass man auch zur Stunde Null mit Scrum und agilem Vorgehen beginnen kann.

Das Team
4 Entwickler, ein Scrum Master, ein Produkt Owner!

DasProjekt
Relativ kurzer Zeitplan - nach dem ersten Sprint (3 Wochen) soll ein Beta-Release in Produktion gehen.

Product Backlog
... wurde durch von einer Offerte abgeleitet. Der Kunde hat seine Prioritäten gesetzt und wir entwickeln die "Must be in" Funktionen.

Erwähnenswert ist vielleicht, dass der der Product Owner nicht der Kunde selbst ist. Ich habe bereits in diversen Blogs und in der Literatur davon gelesen, dass Scrum bei Produktentwicklungen oft eingesetzt wird, im Projektgeschäft allerdings weniger zum Einsatz kommt. Wir möchten in diesem Projekt jedoch agile arbeiten und haben uns für folgendes Setup entschieden:

• Product Owner ist der Key Account Mangager. Er kennt den Kunden, war in der Offert-Phase beteiligt und hält ständig Kontakt zum Kunden. Über den Product Onwer wird das Product- bzw. Sprint Backlog gefüllt. Der Product Owner ist bei allen Scrum Ritualen anwesend.
• Scrum Master ist ein Team Mitglied, genauer gesagt ein Entwickler. Er wurde vom Team gewählt. Er koordiniert die Scrum Meetings.

Das Projekt ist ein Java Web Applikation. Wir werden folgende Tools verwenden:

• Maven2 für den Build, Test und Deployment Prozess
  
• Mavenium für automatisierte Test mit Selenium
• Tomcat und Apache Server
• CruiseControl für Nightly Builds
• Checkstyle für Code-QS
• Subversion als Code Repository
• Sprint Framework 2.0 für den Web Teil der Applikation
  
• Tiles und JSP für den View Layer
  

Ich werde in den nächsten Tagen noch einen Beitrag über die ersten Schritte im Projekt schreiben.

Scrum - Was ist Scrum? Wie funktioniert Scrum?

Ich schreibe gerade als Gast-Beitrag auf http://document-dot-write.blogspot.com/ zu Thema Scrum:

Was ist Scrum?
Wie funktioniert Scrum?
Warum sollte man Scrum einsetzen?

So wie ich bereichtet bekommen habe, ist die Resonanz sehr hoch. Danke!

Steht Scrum der Karriere im Weg?

Aufgrund meiner Erfahrungen mit Scrum ist die Frage mit Jein (ja und nein) zu beantworten!

Das Scrum Team arbeite interdisziplinär. Es gibt keinen dedizierten Projektleiter, Consultant, Tester, Software Architekten, Business Analyst etc. Das ganze Team erledigt die gesamte Arbeit allein. Wenn man also für längere Zeit in einem Scrum Projekt gearbeitet hat, hat man zwar viele kompetenzübergreifende Erfahrungen gemacht, über aber nie eine konkrete Rolle aus, übernimmt auch keine konkrete Verantwortung für etwas. Es gibt also nicht direkt eine spezielle Erfahrung, die man in seinem Lebenslauf vermerken kann, ausser, dass man ein einem agilen Projekt gearbeitet hat.

Möchte man also beispielsweise die Software Entwicklung mittelfristig verlassen und Richtung Projektleitung oder Consulting wechseln stellt sich spätestens beim Bewerbungsgespräch die Frage nach den bisherigen Erfahrungen. Dann wird es etwas schwer. Man kann nicht direkt sagen, dass man Projektleitungs- oder Consulting Erfahrungen gemacht hat, auch wenn man das zweiflos in einem Scrum Projekt getan hat.

Schwierig! Meine Empfehlung: Nach einen Scrum Projekt die Personalakte anfordern und konkrete Erfahrungen im Beisein des Scrum Masters dokumentieren lassen. Es bietet sich auch an, dass ein Vorgesetzten von Zeit zu Zeit die Scrum Meetings aufsucht um sich ein Bild von einer Person und deren Kompetenzen zu machen.

Daily Scrum mit TargetProcess, Teil I

TargetProcess arbeitet bereits daran das Produkt mit mehr Scrum Kompatibilität zu versehen - Daily Scrums mit folgenden Features:

• Change Task state
  
• Assign tasks (or subscribe to task for developer)
• Add new task
• Add impediments and see blocking tasks and stories
• Update remaining time

Ich werde das mal genauer ansehen und dann bei gegebener Zeit mal mein Feedback dazu abgeben. Stay tuned ...

Certified Scrum Master Training in Zürich

Am 14. und 15. Mai geben Boris Gloger / SPRiNT iT und Gerald Hüsch (Boston Business School) einen Kurs mit Zertifizierung zum Scrum Master in Zürich.

Agenda

• Was ist Scrum?
• Warum Scrum gut funktioniert?
• Was ist die Kunst des Möglichen?
• Was ist der Scrum flow?
• Was bedeutet done, iterative und incremental development?
• The Scrum 59 - Game
• Agile planning und estimation
• Sprint retrospectives
• Wie man Scrum einführt
• Der Unterschied zwischen planning und the planning meeting
• Strategische und taktische Planung
• Das Scrum Meeting und wie man mit dem Task Board umgeht
  
• The Velocity Game - planning and doing in action
• Scaling Scrum

Anmeldung und weitere Informationen: ScrumEducation

Wird der Scrum Master zugeteilt oder vom Team gewählt?

Der "richtige" Scrum Master ist ein zentraler Punkt - mit ihm steht und fällt der Erfolg des Projekts!

Aber wer sollte Scrum Master sein? Ein Teammitglied? Jemand vom Management? Ein Externer? Sollte der Product Owner den Scrum Master bestimmen?

Die Anwort ist: Das Team sollte den Scrum Master selbst wählen. Leider ist das nicht immer möglich!

Viel wichtiger ist die Frage, wie lange praktiziert das Team bereits Scrum? Ein relative neues Scrum Team hat wenig bis keine Erfahrungen und braucht eine Führung. Je länger das Team nach Scrum arbeitet, desto weniger wird die Führungsrolle beansprucht. Das Scrum Team ist selbstorganisierent, findet selbst raus, wer der Scrum Master ist .....

Für ein erstes Projekt nach Scrum ist es sicher ratsam, einen Scrum Master zu bestimmen. Da sollte von einer Person geschehen, die Umsatzverantwortung trägt. Nur so ist gewährleistet, dass man eine Person wählt, die das Projekt erfolgreich abewickeln kann.