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.

Best Practise: Daily Scrum mit Excel

Während ich sehr gute Erfahrungen mit TargetProcess als Management -Tool für agile Softwareprojekte gemacht habe, verwende ich neben TP noch Excel für den Daily Scrum.

Hier werden von jedem Team-Mitglied folgende Fragen beantwortet:

• Was hast Du gestern gemacht?
• Was machst Du heute?
• Was hindert Dich Deine Arbeit zu machen?

Daily Scrum ist ein formloses, 15-minütiges Stand-up Meeting.

Das Protokoll (Excel) wird anschliessend aufs Team-Wiki hochgeladen und per plug-in der Reiter "Today" ausgelesen. So kann jedes Teammitglied im Wiki schnell das Tagesgeschehen einsehen.

Als Vorlage hier ein Beispiel: sprint-6-daily-scrum.xls

Braucht es eine Rolle - Tester ?

Nach Scrum gibt es folgende Rollen:

• Scrum Master
• Product Owner
• Scrum Team
  

Diese Rollen werden vor dem Projektbeginn definiert und personifiziert. Eine Rollenaufteilung innerhalb des Scrum Teams ist nicht vorgesehen. Nach Scrum ist das Team selbstorganisierent. Eine Aufgabenverteilung ausserhalb des Scrum Teams ist nicht vorgesehen.

Klar ist, dass getestet werden muss, da sonst die Definition von DONE nicht erreicht wird und somit eine User Story nicht im Sprint zum Abschluss gebracht werden kann.

Wer macht das Testing? Gibt es einen Tester?
Entgegen vieler Annahmen gibt es im Scrum Team keinen dedizierten Tester! Warum?

Das Team löst eine Aufgabe, nicht einzelne Personen bzw. Rollen. Scrum ist Teamarbeit und fördert das "Wir"-Gefühl. "Wir" haben eine Aufgabe, nicht "Ich" habe ein Aufgabe. Gemeinsam wird eine Aufgabe in den Zustand DONE gebracht:

• Dokumentiert
• Implementiert
  
• Reviewed
• Getestet
  

Geht man davon aus, dass man automatisierte Test mit einer Abdeckung von 99% hat, was in einem agilen Software Entwicklungsprojekt unbedingt angestrebt werden sollte, so stellt sich nicht die Frage: "Wer testet?", sondern "Wer schreibt die Tests und wann?".

Test werden zum Zeitpunkt der Erfassung der User Stories "geschrieben", sagen wir dokumentiert. Sie stellen User Acceptance Test(UAT) dar. Der User kann als Kunde (Product Owner) bzw. Benutzer des Systems ausgelegt werden. Wie auch immer, der User definiert ob und wie ein User Story brauchbar (valuable) ist. UAT kann man als Abnahme Tests verstehen.
Vor dem Review einer User Story werden die Tests automatisiert. Nur wenn der Review im Team und der automatisierte Test erfolgreich waren, ist DONE erreicht.

iSBB - SBB Fahrplan auf dem iPod

Nervig, oder? Immer den iPod dabei, aber nie den SBB Fahrplan ... Hier die Lösung!

Man benötigt einen iPod Video, sonst funktionierts nicht! So gehts:

Bei der SBB einen persönlichen Fahrplan erstellen und per Email zusenden lassen.
Mit einem Tool der Wahl den iSBB Fahrplan erstellen, z.B. Excel. Ich persönlich habe den SBB Fahrplan aus von PDF direkt in Excel übernommen, dann muss man nix abtippen ;-).

Dann Screenshot von den Fahrplänen machen (320x240px) und auf den iPod synchronisieren - DONE!

Ich hab das am Beispiel von Kreuzlingen - St. Gallen zusammengestellt:

1. Runterladen
2. Entzippen
3. Mit iTunes auf als Photos auf den iPod synchronisieren.

Viele Spass!

Wer noch weiter gehen möchte, es gibt auch schon U-Bahn Pläne für den iPod - iSubwayMaps.com.

Scrum Einführung

Peter Stevens, Scrum Master bei der namics ag, hält einen Vortrag zum Thema Scrum. Er veranschaulicht am Beispiel eines Transportunternehmens auf dem Weg von Neapel nach Amsterdam, wie und warum klassisches Projektmanagement bei Software Projekten scheitert und wie man mit agiler Managementmethode gegensteuern kann.

Sehr interessant .... was ist, wenn der Gotthard geschlossen ist?
Zum Anschauen: http://www.simplex.tv/xbend/simplex/34/266 - Enjoy!