10 Gründe für Agile Development

1. Wertschöpfung (Revenue)
   Iterative Softwareentwicklung bedeutet in erster Linie inkrementelles Entwicklen von Features, um diese bereits früher bereitzustellen, während das Produkt noch (weiter)entwickelt wird.
2. Marktnähe (Time to market)
   Es ist bekannt, dass 80 % der Marktführer mit ihrem Produkt/Service jeweils die ersten am Markt sind(waren). Neben der hohen Wertschöpfung trägt die Philosophie von frühen und regelmässigen Releases bei agiler Projekten nicht zuletzt auch dazu bei.
3. Qualität (Quality)
   Ein wesentlicher Aspekt bei agilen Softwareentwicklungsprojekten ist, dass Testing ein integrativer Bestandteil des Produkt-Lebenszylus während der Entwicklung ist. Somit hat der Produkt Owner die Möglichkeit früh Abweichungen zu erkennen und im Rahmen der Sprint Planungen gegenzulenken.
4. Transparenz (Visibility)
   Ein wesentlicher Grundsatz für agiles Arbeiten ist die Beteiligung von "aktiven" Personen während der gesamten Produktentwicklung - das Team. Jeder Stakeholder kann somit den Projekt- und Produktfortschritt verfolgen und somit sicherstellen, dass die geleistete Investition den gewünschten Ertrag bringt.
5. Risiko Management (Risk Management)
   Kleine, regelmässige Releases ermöglichem dem Produkt Owner und dem Team schnell Probleme zu erkennen und frühzeitig darauf zu reagieren. Die Transparenz trägt dazu bei, dass alle nötigen Entscheidungen zu frühest möglichen Zeitpunkt getroffen werden können, um Probleme zu lösen.
6. Flexibilität (Flexibility / Agility)
   Bei klassischen Softwareentwicklungsprojekten wird vor Projektbeginn eine Spezifikation geschrieben. Obendrein wird darauf hingewiesen, dass es teuer wird, wenn sich an der Spezifikation etwas ändern sollte, insbesondere wenn das Projekt bereits begonnen hat. Oftmals werden Changes hinausgezögert und ein Kontroll Organ eingesetzt, um sich vor never-ending Projekten und Verlagerungen des Scops zu schützen. Der agile Ansatz ist anders - Changes sind willkommen, genauer gesagt: werden erwartet!
7. Kostenkontrolle (Cost Control)
   Der Zeitplan ist fix, der Umfang wage bekannt und natürlich gibt es auch ein fixes Budget. Der Projektscope und die Product Features sind variabel, die Kosten nicht. Der Produkt Owner hat alle Steuerungselemente in der Hand, um seine anfallenden Kosten zu kontrollieren und zu steuern, pro Sprint.
8. Business Engagement und Kundenzufriedenheit (Business Engagement/Customer Satisfaction)
   Die aktive Beteiligung aller Mitglieder inklusive dem Product Owner, die hohe Transparenz des Projektverlaufs und die Flexibilität von Änderungen, wenn Änderungen notwendig sind erhöhen die die Kundenzufriedenheit und das Business Engagement. Dies sind wichtige Vorteile, die nicht zu letzt eine positive und nachhaltige Kundenbeziehung sicherstellen.
9. Das richtige Produkt
   Aufgrund der gegebenen Flexibilität und regelmässigen Releases kann auf Marksituationen schnell und zielgenau reagiert werden. Mit agilen Entwicklungsprojekten steht der User im Zentrum der Aktiviäten. Man nennt das auch User Centered Design (UCD).
10. Spass an der Arbeit
    Eine aktive Beteiligung, die Mit- und Zusammenarbeit von jedem einzelnen machen agile Entwicklungsteams für viele zu einem attraktivem Arbeitsumfeld.

Use Case, User Story und Szenario

Use Case, User Story und Szenarien - irgendwie ja alles das Gleiche, oder doch nicht?

Ich meine, es ist sehr wichtig die einzelnen Begriffe doch deutlich voneinander abzugrenzen.

Ein Use Case ist eine graphische Modellierung eines Anwendungsfalls mittels UML.

Eine User Story ist eine formale Bescheibung einer Aktivität eines Benutzers mit einem System für agile Softwareentwicklung. Im Vordergrund steht die Frag: Wer macht Was, um welches Ziel zu erreichen.

Ein Szenario ist der User Story ähnlich, nur das zusätzlich zur Aktivität noch Rahmenbedinungen, Stimmungen, Gefühle und vieles mehr addressiert werden. Szenarien werden häufig bei der Modellierung von Personas verwendet.

Agile Development: Back to the future!

Kelly Waters schreibt gestern auf seinem Blog, wie man mit Features umgeht, die nach Ablauf eines Sprints nicht fertig gestellt wurden. Er beschreibt, wie man den Code für eine releasefähige Version verwalten und zurückrollen kann - daher der Name: "Back to the future!"

Er beschreibt, warum das nur theoretisch funktioniert, und warum das in der Praxis nicht so einfach ist.

agile-development-back-to-future

Wie führt man Scrum ein

Man hat sich mit agiler Vorgehensweise nach Scrum beschäftigt, befürwortet dieses Arbeitsweise, fragt sich, warum ma nicht schon immer so gearbeitet, hat ein paar Sympathisanten an seiner Seite und möchtes Scrum mal selbst "ausprobieren".

Die Frage lautet: Wie führt man Scrum ein?
Iterativ, alles auf einmal, mit oder ohne Kunden, etc? Viele Fragen, hier ein paar Antworten.

Aus meiner Erfahrung kann ich nur empfehlen, Scrum nur gesamthaft, d.h. mit allen Rollen und Ritualen einzuführen. Das bedeutet, Einführung von agiler Vorgehensweise von heute auf morgen, zur Stunde 0.

Wie kann man das vorbereiten? Schulen, Schulen, Schulen! Zunächst ist es wichtig, dass das zukünftige Scrum Team der Idee folgen kann/will. Dazu braucht es auch unmittelbar die Zustimmung der operativen Ebene in einem Unternehmen.
Ein paar "early adaptives" sind sehr wichtig. Es bietet sich an, dass man bestimmte Themen auf verschiedene Personen verteilt und ein paar Rollenspiele vor der Einführung organisiert. Es ist wichtig, dass das Team die Arbeitweise anerkennt und "lebt"....

Was macht man mit dem Kunden? ....coming soon.

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.

Wer ist der Product Owner?

Scrum definiert eine Reihe von Ritualen und Rollen. Eine sehr wichtige Rolle ist der Product Owner, ich würde sogar sagen, dass dies die wichtigste Rolle eines Scrum Projekts ist.

Was, oder besser Wer genau ist der Product Owner?

Bei jedem Projekt gibt es einen Geldgeber, der Investor. Er verfügt über eine Budget zur Lösung diverser "Probleme" innerhalb des budgetierten Zeitraums. Er entscheidet, welche Projekte wieviel Budget in einer solchen Periode zugesprochen bekommen.

Wird einem Projekt Budget zugesprochen, gibt es einen Projekt Manager, der dieses Projekt leitet. Nach Scrum ist diese Person der Product Owner. Er steuert das Projekt. Er balanciert Investment und ROI. Darüber hinaus ist er der Interessenvertreter aller Stakeholder.

Das Scrum Team wird vom Product Owner gesteuert.

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.

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.