Sprint 5 Abschluss

Zum fünften mal trifft sich das Team vor der Sprint 5 Vorführung, morgen Vormittag.

Der letzte Sprint, der mit Excel geführt wurde, geht zu Ende.
Das Team geht nach dem Daily Scrum noch mal schnell die Liste der Tasks durch. Alles Done, bis auf einen Task. Damit sind von 26 geschätzten Story Points letztendlich 23 Done.

Done, bisher :( Velocity)
Sprint1:24
Sprint2:30
Sprint3:27
Sprint4:42

Done, durschnittlich: (Velocity)
29.2

Die Herausforderung für den kommenden Sprint besteht darin, die Anforderungen des Kunden in User Stories zu überführen.
Bislang hat das Team noch nicht mit User Stories gearbeitet - TargetProcess zwingt uns das auf und das Team begruesst das.

Obeya

.. so nennt man bei Toyota den Raum, der täglich 15-Minuten zum Abgleich des Projektstatus (Stand-Up-Meeting) aufgesucht wird.

Daily Scrum im Obeya. Nichts ist unmöglich.....

Auch eine Meinung

Ich hatte heute ein interessantes Gespräch mit einem Entwickler-Kollegen, der nicht in einem agilen Projekt arbeitet. Er hatte davon gehört und findet das irgendwie nicht so gut.

"Der Entwickler muss direkt mit dem Kunden aushandeln, was er haben möchte? Dafür gibts doch Consultants. Das wäre für mich ein Kündigungsgrund!"

Es ist ja bekannt, dass ca. 30% der Entwickler ein agiles Projekt verlassen. Naja...

Best Practice: Estimation

Im Sprint 5 hat das Team erstmalig begonnen mit "echten" User Stories zu schätzen. Keine Spezifikation, nur ein Satz nach dem Muster X kann Y machen, um Z zu tun.

Der Product Owner hatte das Team beauftragt, neben dem eigentlichen Produkt eine kleines Neben(Nischen)produkt zu konzipieren. Man bewegt sich quasi auf der grünen Wiese. Diese Situation kann man mit einem Projektstart vergleichen. Man hat kein Systemarchitektur, kein ERM, kein Domain Model, kennt keine Schnittstellen, das GUI ist nicht definiert, etc.

Ok, wir haben aber etwas - ca. 35 User Stories!
Das Team ist konfrontiert mit dem "Wie" in Form von User Stories und soll nun schätzen - das funktioniert nicht, wie wir bitter erkennen mussten.

Lessons learned (in zeitlicher Reihenfolge):

1. Systemkontext muss kurz visualisiert werden, um das System und Umsystem zu erkennen
2. User Story Writing Workshop mit dem Team durchführen, um Rollen und Funktionen a la Brainstorming im Team zu erarbeiten. Das Team macht sich dadurch frühzeitig mit der Aufgabenstellung verraut und "lernt", was zu realisieren ist.
   
3. Ein paar einfache Wireframes/Story Boards sollten erstellt werden, damit man sich das vorstellen kann
4. Fragebogen für Experteninterviews erstellen und Experteninterviews durchführen
5. Interview mit potenziellen Benutzern durchführen um herauszufinden, was diese eigentlich möchten. Die Top 5 Hindernisse finden.
6. Ergebnisse des Fragebogens und der Interviews als Feedback ins Team bringen und dann die bstehenden User Stories neu formulieren bzw. hinzufügen
7. Estimation

Das funktioniert und die Akzeptanz im Team ist da!

Best Practice: Experteninterview

Der meist verwendetste Ansatz zum Schreiben von User Stories ist Experteninterviews in Workshops durchzuführen. Ein wichtiger Schlüssel zum Erfolg ist die Auswahl der "Experten". Wenn immer möglich sollten "echte" Benutzer befragt werden, nicht Benutzer, die sich in die Rolle hineinversetzen. Experteninterviews sollten idealerweise mit allen Benutzern durchgeführt werden, nur so bekommt man ein abgestimmtes Portfolio von User Stories auf die Bedürfnisse.

Es ist nicht sinnvoll den Benutzer zu fragen, was er braucht. Die meisten Benutzer können diese Frage nicht richtig beantworten oder sich nicht richtig ausdrücken. Besser ist der Ansatz zu Fragen, wie Ihr Arbeitsprozess heute aussieht und was die grössten Probleme sind. Dann kann man sehr schnell die Frage stellen, was der Benutzer sich beim Problem X als Lösung vorstellen würde. Der Benutzer kennt seinen Arbeitsprozess in der Regel sehr gut und bei Problemen ärgert er sich immer wieder und hat sicher eine oder mehrer Lösungsansätze bzw. Wünsche.

Wichtig ist, wie man Fragen stellt. Es sollten keine Ja/Nein oder "abgeschlossene" Fragen gestellt werden. Hier kann leicht ein falscher Eindruck aufgrund der Frage entstehen. Ein gutes Beispiel von Mike Cohn hierzu: "Would you like our new application in a browser?". Die Antwort ist klar. Man könnte in seinem Lieblingsrestaurant von der Bedienung auch gefragt werden "Möchten Sie heute Ihr Lieblingsessen bestellen und gratis essen?". Die Antwort ist auch hier klar: "Natürlich!". Trotzdem sind Ja/Nein Fragen berechtigt und notwendig. Wenn die Prozesse dokumentiert und genügend hinterfragt sind, kann man solche Fragen stellen, um an die Details zu gelangen. Man sollte solche Fragen nur gegen Ende des Interviews stellen.

User Stories sollten nicht direkt im Interview geschrieben werden. Die Benutzer sind mit der Methodik nicht verwandt und werden nur irritiert.

Die Ergebnisse des Worshops sollten im Anschluss in User Stories umgewandelt werden.
Sie können als Input für Fragebögen einfliessen ...

Scrum tifft .Net

Die Dienstleister Conchango hat im November 2006 ein Scrum Plug-In fürs Visual Studio 2005 freigegeben. Es wurde in Zusammenarbeit mit Ken Schwaber und Microsoft entwickelt.

Was kann es?
Das add-in bietet eine volle Integration auf den MS Visual Studio Clients und dem Team Foundation Server. Es gibt ein Installation für den TFS und eine für die Clients. Jeder Developer kann sich anschliessend inScrum Projekte einklinken.

Es ermöglich einfaches Reporting und Monitoring von Sprint Retrospecitve, Sprint und Product Burndown Charts und Bugs. Darüber hinaus kann man auf einfache Weise auf Sprint Backlog, Product Backlog znd Tasks zugreifen.

Hier gibts mehr ...

[Quelle]

Lessons learned from Scrum implementation at Google

Jeff Sutherland

TechTalk

Der Scrum Master in dem Projekt, an dem ich gerade arbeite beim TechTalk:

http://blog.internet-briefing.ch/2007/01/10/agile-software-entwicklung-scrum-xp-etc/

Erfahrungsaustausch und Meinungen zum Thema Scrum.

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
  

Sprint 3 Retrospective

Der Puls schlägt höcher - das so im allgemeinen die Tendenz.

Das Team findet im Kern, dass die Aufgaben sehr gut abgearbeitet wurden. Die Stimmung ist gut.

Was war gut:

• Scrum Methodik hat sich langsam etabliert, Routine
  
• Sehr gute & schnelle Release-Auslieferung
• Ein neuer Mitarbeiter wurde innerhalb kurzer Zeit eingearbeitet

Was ist verbesserungswürdig:

• Schätzung der "Must be in"Story Points zu ungenau -> Viele "Should be" in abgearbeitet
• Dokumenten-Dschungel im Wiki - Reorganisation notwendig
• Zu viele Meetings mit zu vielen Excel Problemen
• Product Owner ist am Planning Meeting nicht gut vorbereitet

Massnahmen:

• Crash Course-> User Stories Applied für bessere Estimation
• Excel als Planning Tool abschaffen
• Wiki Reorganisieren
  

ScrumMaster Certification

Was macht den Unterschied zwischen einem guten und einem weniger gutem Scrum Master aus?

Eine Zertifizierung? Bislang habe ich erst einen zertifizierten Scrum Master kennengelernt und musst feststellen, das die geschriebene Methodik von der zertifizierten abweicht, besonders in der Frage der Rollenverteilung.

Beim regelmässigen Treffen der Scrum Gurus wurde von der Zertifizierung berichtet, dass der Product Owner keineswegs der Kunde ist. Hier geht man davon aus, dass der Key Account Manager des Anbieters der Product Owner ist. Er kennt den Kunden und kann die Wünsche dokumentieren und in das Planning Meeting bringen.

Legt man allderings Mass an der Literatur, so trifft das Scrum Team bei der Sprint Planung auf den Product Owner, um die Wünsche für den nächsten Sprint zu besprechen. Wenn das Team fragen stellt, wie ist gewährleistet, dass der Product Owner wirklich die Wünsche des Kunden richtig vertritt?

Any ideas?

http://www.controlchaos.com/