Scrumbreakfast: Projektverwaltung mit Target Process

Der Scrumbreakfast ist ein regelmässiges Treffen für CIOs, strategischen und operativen Projektleitern, die entweder Scrum einsezten oder Scrum einsetzen wollen.

Der erster Scrum Breakfast fand in November bei namics in Zürich statt. Wir waren 10 Teilnehmer, etwa 50/50 geteilt zwischen aktuellen Scrumnutzer und möchte gern Scrumnutzer. Nach einem (mehr oder minder kurzem) Vortrag haben wir dann auch untereinander Erfahrungen und Informationen rund um Scrum und Softwareentwicklungs-Projekte austauschen können.

Nächster Anlass:
Jean-Pierre König, Senior Software Engineer bei namics ag und Verfasser von Inside Scrum gibt uns eine Hands-On Einblick in Target Process. TP wird seit etwa 3/4 Jahr bei namics für die Verwaltung von agilen Projekte eingesetzt. Damit kann der Scrum-Master sämtliche Aufgaben rund um ein Scrumprojekt verwalten und Team-Mitglieder können ebenfalls ihre eigene Aufgaben im Projekt pflegen.

Themen:

• Estimation
• Planning
• Daily Scrum

Anschliessend gibt es Fragen, Diskussion und Erfahrungsaustausch.

• Wann: 05 Dec 2007, 08:00 am -- 10:00 am (Vortrag 8.35 bis 9.00)
• Wo: City/Location Konradstrasse 12, 8005 Zürich
  2 minutes from Zürich HB near Tram stop Sihlquai/HB

Anmeldung per E-mail an peter.stevens@namics.com oder per Xing Event.

TargetProcess 2.5 released

TargetProcess kommt bei der neuen Version 2.5 mit einem sehr guten HelpDesk Adapter daher.

Oft gibt es während der Iterationen Anfragen, neue Requirements, Verbesserungen und sonstigen Feedback (auch von nicht Scrum Mitgliedern), die aber nicht klar als User Story identifizierbar sind, dennoch aber im System verwaltet werden sollten - HelpDesk. Man kann den HelpDesk Adapter per Excel, Email oder einem externen HelpDesk Portal verwenden - nicht schlecht. Wir werden das mal probieren, denn die Zusammenarbeit mit Excel ist immer noch üblich, auch wenn es unschön ist.

Release 3 ausgeliefert

Nach nur einem Sprint von 2 Wochen haben wir am Freitag den Release 3.0 ausgeliefert.
Das Team hat insgesamt 23 Story Points, verteilt auf 8 User Stories, angenommen und zu 100% fertiggestellt. Zusätzlich wurde ein Bug bearbeitet.

Die Velocity in diesem Sprint betrug 23- damit ergibt sich ein Durchschnitt bisher von 19 Story Points pro Release.

Seit Projektbeginn Anfang April 07 hat das Team 59 Story Points abgearbeitet.
Das Projekt wird am 15. Juni mit einen weiteren Release abgeschlossen. Es sind noch 13 Story Points geplant.

Daily Scrum mit TargetProcess, Teil III

Nach gut 4 Wochen mit der neuesten TargetProcess Version haben wir das Tool TaskBoard vielfach verwenden können, und - nicht mehr wegzudenken!

TaskBoard ist für die Auslegung des Daily Scrum optimal. Das Team hat dieses neue Werkzeug gut angenommen, jeder arbeitet damit und der Scrum Master, sowie Product Owner haben eine aussagekräftige Übersicht. Sehr gut.

Einzig ein neues Feature fehlt noch: automatisiertes Hinzufügen von Task, wenn eine User Story angelegt wird, z.B. Write a UAT, Write a Unit Test, etc.

TargetProcess 2.4 - TaskBoard

Seit der Auslieferung des letzten Release setzen wir für das Projektmanagement TargetProcess Version 2.4 ein. Insbesondere haben wir das neue Feature "TaskBoard" in unsere Daily Scrum Meetings aufgenommen.

Nach anfänglicher Skepsis stellt sich heraus - sehr gutes Tool! Das Team pflegt jetzt Tasks, was vorher nur sporadisch gemacht wurde. Nun kann man auf einen Blick sehen, wer woran arbeitet und was noch zu tun ist. Der Austausch und das Mitarbeiten an den Aufgaben von anderen Teammitgliedern funktioniert nun viel besser. Man nimmt sich einfach einen Task und beginnt zu arbeiten. Wenn man neue Arbeit erkennt, legt man einen Task an. Im Daily Scrum werden alle Tages-Aufgaben sofort erkannt und jeder weiss, was das Tagegeschehen ist.

Ich finde, TaskBoard hat eine Chance verdient.

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!

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 ...

Sprint 5 Planning Meeting

Sprint 1 bis 5 wurden bisher nicht mit dem Ansatz von User Stories durchgeführt. Bisher wurden vom Kunden nur Abkürzungen, Satzfragmente order Stichworte ins Product Backlog aufgenommen. Daraufhin gab es sehr ausführliche Planning Meetings und das Team hat on-the-fly während des Meetings im Wiki quasi die Spezifikation geschrieben, während der Product Owner seine Gedanken ausführt.

Das hat in der Vergangenheit dazu geführt, dass das Team zwar nach agiler Methodik iterativ arbeitet, aber agile Software Entwicklung war das nicht. Dies und der dringende Wunsch User Stories einzuführen haben dazu geführt, dass Target Process eingesetzt wird.

Im Sprint 5 Planning Meeting heute hat das Team während der Präsentation der Wünsche des Product Owners im Target Process die Aufgaben zu User Stories umgewandelt. Das war recht einfach, denn das Verhaltensmuster des Product Owner war immer das gleiche:
Jeder Backlog Eintrag, z.B. "Performanceoptimierung" wurde vom Product Owner immer selbst kommentiert, z.B. "Der Hintergund ist folgender: Wir bekommen von unseren Benutzern immer ...." Eigentlich liegt die User Story bereits auf der Hand: "Ein Benutzer bekommt nach der Suche innerhalb von 5ms eine Trefferliste angezeigt".

Während der Product Owner mit Powerpoint seine Wünsche präsentiert, wurden zusätzlich noch Notes und Contraints in der Story definiert, z.B. "Note: bei mehr als 1000 Treffer wird keine Trefferliste anzeigt, sondern ein Hinweis", "Contraint: es wurde mindestens ein Suchkriterum eingegeben".

Test Cases pro Story wurden in dieser Sprint Planung noch nicht erfasst. Das ist der gute Vorsatz für das kommende Planning Meeting, wenn alle Beteiligten mehr Erfahrung mit User Stories haben.

Best Practice: Requirement Management

Heute war die Sprint 5 Demo und Sprint 5 Planning Meeting. Zum ersten Mal wurde die Planung vom Team mit Target Process durchgeführt. Der Product Owner hatte zuvor User Stories, die eigentlich keine User Stories sind, erfasst - sehr viele sogar.

Das Team hat sehr verhalten reagiert. Der Product Owner wusste teilweise nicht, was die Stories beinhalten. Nach vielen Fragen wurde das Problem eingegrenzt:

Das Team hatte zur Einführung von Target Process beim Kunden einen Workshop durchgeführt, wo erklärt wurde, wie das Tool funktioniert und wie man sich die Zusammerarbeit damit vorstellt.
Der Product Owner bekam einen Accout und jedes Teammitglied. Der Product Owner hatte seinen Account im Unternehmen des Auftraggebers "allen" zur Verfügung gestellt.

Der Effekt war, dass man das Requirement Engineering und Requirement Management mit Target Process abgedeckt hat. Der Kunde war im Glauben, dass Tool sei dafür da. Falsch! Target Process ist ein Projekt Management Tool für agile Software Entwicklung. Nicht mehr und nicht weniger.

Als das Team dem Product Owner beigebracht hatte, das dies so nicht funktioniert kam die Frage: "Wo machen wir das dann? Können Sie uns wieder einen Zugang zum Testdirector freischalten?"

Hintergrund der Frage: Das Team hatte fälschlicher Weise in der Vergangenheit dem Kunden einen speziellen Tag im Test Director eingerichtet: Optimisation. Der Kunde hatte neben Bugs auch neue Features und Change Request im Test Director erfasst. Als das Team das erkannt hatte, wurde mit Absprache des Kunden der Account stillgelegt.

Wie auch immer, die Antwort des Teams war deutlich: "Nein, natürlich nicht! Für Requirement Engineering und Requirement Management müssen Sie ein anderen Weg finden."

Das Team hat beschlossen, jede neu erfasste User Story vom Product Owner zu monitoren und zu prüfen. Wenn die Story keine User Story im Sinne von Agile ist, wird der Kunde kontaktiert und es wird umformuliert. Visionen und Requirement Engineering werden gelöscht.

Target Process Einführung

Das Team hat beschlossen, die Excel Sheet Verwaltung von Product und Sprint Backlog fortan mit TargetProcess durchzuführen.

TargetProcess ist ein Tool für das Management von agile Software Projekten. Es ist nicht unbedingt auf Scrum abgestimmt, trotzdem aber einsetzbar.

Begrifflichkeiten:
Interationen im TargetProcess entsprechen Sprints. Ein Featrue ist ein Epic. Ein Task stellt Arbeit auf täglicher Basis dar (8h), was im Daily Scrum vom Scrum Master mit den Fragen "Was hast du gestern gemacht", "Was machst du heute" und "Was sind Deine Hindernisse" dokumentiert wird.

Was unterstützt das Tool:
Das Management ist stark an intertiven Prozessen orientiert. So beginnt alles mit einem Projekt, dem User mit bestimmten Rollen und Verfügbarkeit zugeordnet werden können, z.B. 3 Entwickler zu 100%, ein Tester zu 80% usw. Die Resourcenplanung ist nicht starr, kann pro Sprint neu definiert werden. Dann legt man Releases an und plant diese zeitlich. Dann werden Sprints angelegt, mit den Resourcen verknüft und Meta Daten, wie Velocity, angegeben. In der Sprint Planung werden dann User Stories und deren Tests erfasst und Sprints zugeordnet (Drag & Drop). Das Tool zeigt dabei stets an, wieviel User Stories noch angenommen werden können. Wenn zu viele angenommen wurden, bekommt man eine Warnung.

Das Team kann nun auf Sprint Basis die User Stories während der Estimation schätzen und User zuweisen. Die Schätzung kann, je nach Konfiguration, in Real Days oder Story Points erfolgen.

Was unterstützt TargetProcess nicht:
Daily Scrum Dokumentation. Es gibt zwar eine Today Ansicht mit allen Tasks, aber streng nach Scrum ist das nicht zu gebrauchen.
Desweiteren kann man keine Sprint Retrospective mit dem Tool durchführen, da dies auch Scrum spezifisch ist.
Das Team pflegt diese beiden Punkte weiter im Wiki. Hier werden pro Sprint zwei Pages angelegt: Daily Scrum (Excel) und Sprint Retrospective (Excel). Da das Confluence Wiki ein Excel Plug-in hat, wird das Excel Sheet auf der Wiki Page dargestellt. Man muss also nicht immer das File downloaden.

Zusätzliche Funktionen:
Bug-Tracking mit Subversion Intergration, d.h. man kann Bugs erfassen, Stunden aufschreiben und mit dem Check-In den Status des Bugs auf Fixed setzen. Der QA bekommt dann alle fixed Bugs in seinem Dashboard angezeigt.

Darüber hinaus bietet TargetProcess diverse Reports für das Projekt Reporting, z.B. Sprint Velocity, Release und Sprint Burndown Charts, Bug Reporting und Bug Process.

TargetProcess ist eine ASP.NET Implementierung. Es ist mit Atlas auf Web 2.0 ausgelegt und macht in der Anwendung echt Spass - wenig Page Reloads, viel Drag & Drop und vieles mehr...

Ab Sprint 6 setzt das Team das Tool ein. Erfahrungsberichte folgen ...

Target Process, a agile management tool

Produktebeschreibung

TargetProcess ist eine agile Projekt Management Software. Sie wurde entwickelt mit dem Ziel der Einfachheit. TargetProcess hilft bei der Softwareentwicklung die Komplexität von Software Projekt Management zu reduzieren, vereinfacht die Planung, das Tracking und die Qualitätssicherung.

Funktionen

Folgende Funktionen werden vom Hersteller den Produkt zugewiesen:

• Full Iterative Development support (Extreme Programming, SCRUM, other agile methodologies)
• Highly customizable dashboards
• Manage features, user stories, bugs and tasks
• Releases and iteration planning via drag & drop
• Development process customization
• Real time progress tracking
• Assign/reassign users everywhere
• Integrated bug tracking
• Integrated test cases management
• Bug Submission Tool (Tp.Tray)
• Customizable workflows
• Integrated time tracking

Technische Anforderungen

Die System Anforderungen sind wie folgt:

Database	MS SQL Server 2000 or 2005
App. Server	IIS 5+
.NET	.NET Framework 2.0
Browser	Internet Explorer 6+, FireFox 1.5+
CPU	2GHz+
RAM	1Gb+

Kosten

Lizenz pro User für Version 2.1: $ 249 (1 licence pro 1 named user)

Subscription pro User und Jahr bis Version 3.0: 49$

Anzahl User: 12 Lizenzen (6 bestehende und 1 neuer Entwickler, T-Praktikant, 2 Projektleitung, 1 Testingrolle, 1 Kundenlizenz)

Lizenzkosten: $ 2988 einmalig plus Subscription $ 588 pro Jahr

Zusätzlich entstehen indirekte Kosten durch Implementierung und Anpassung!

targetprocess.com

Sprint 4 Retrospecitve

Im Sprint 4 hat sich herauskristalisiert, dass die Eigenverantwortlichkeit vom Team nicht unbedingt mit guten Consulting beim Kunden einher geht. Der Scrum Master versteht seine Rolle als Coach und Schiedsrichter, er ist also inhaltlich beim Produkt nicht Ansprechpartner. Der Product Owner bringt wenig visionäre Ansätze ins Team und somit ist die Produktentwicklung schleppend. Das Team stellt den Antrag, einen Produkt Manager auf der Seite des Anbieters zu stellen, der dem Kunden mit Visionen und strategischer Aussichtung des Produkts behilflich ist ... es gibt eine neue Rolle im Scrum!

Was war gut:

• Team arbeitet sehr selbständig
• gute Zusammenarbeit
• GUI hat eine neue Richtung eingeschlagen - Web 2.0
• Entscheid: TargetProcess soll eingeführt werden und Excel ablösen
  
• Viele "Should be in" wurden realisiert
  

Was ist verbesserungswürdig:

• Sprint Planning Meeting erneut schlecht vorbereitet (vom Kunden und Team)
  
• Kommunikation mit Kunden wird schlechter, Briefings sehr schlecht
• Mangelndes Consulting vom Team beim Kunden
• viele, kleine User Stories, die das Produkt nicht weiter bringen
  

Massnahmen:

• User Stories für den kommenden Sprint müssen vor dem Planning Meeting vorliegen
• Mehr Consulting Leistung vom Team, neue Rolle: Product Manager wird vom Team gestellt
• Product Owner zum Sprint Retrospective Meeting einladen