Viewing entries tagged
experience

Forecasting in agile Projects - Do you get your things done within time and budget?

1 Comment

Forecasting in agile Projects - Do you get your things done within time and budget?

Well, this sound like a question for classic approaches J. However, I often get asked how could we know in agile projects, or on product level if we get things done in time?

Agile projects are cool and simple, planning is sprint by sprint and team size defines monthly budget. However, if you’re a product owner you might be asked by your stakeholders and sponsors "what of the product backlog could be done until when", "what does it cost" and most difficult "are we still on track"?-As usually just sprints are under deep monitoring I’d like to share with you a very simple instrument, the product burn up chart.

Usually I paint this to a physical flip-chart, but I was curious if I could manage to create a simple monitoring tool?-This tool should keeping track over whole product lifecycle. As I’m a mac user I’ve done that with 

numbers

, however you could download and convert it to excel if you like. Just to to download here:

2014-07-20_21-16-13

From my point of view most important things for a product owner to monitor towards his team are:

  1. Progress and Forcasting of Product Backlog implementation (Top Chart)
  2. Tracking continous Improvement of Team (Bottom left Chart, even if that’s in responsibility of SM I’d like to know about)
  3. Budget Burndown (Bottom right Chart)
agile-forecasting-chart

While creating these graphs I started to play around with some scenario’s and I found out that this is getting more and more complex. E.g. it might be interesting to monitor development of product backlog size as well. In my scenario the product would be implemented within 6 sprints and additional stories would be rarely added. However in corresponding data sheet I’ve added some notifications if it gets unrealistic to stay within time and budget. Furthermore over time the best/worst case forecasts are getting more and more accurate. In my example the team is performing very well, since sprint 4 near best case scenario.

agile-forecasting-sheet

My calculations might have still some bugs, so I do not guarantee nothing. I’m curious about your input about, may be we could develop it more and somebody creates a standard plugin for Atlassian Agile?

Please note:

I pass any monitoring of outcome like end user feedbacks, increasing of revenue, etc. at this moment.

1 Comment

 How Hierarchy prevents Agility

3 Comments

How Hierarchy prevents Agility

Big projects tend to setup a big project organization, but why?-And is this really supporting agility needed or is it create other risks, that slows down time-to-market?

In my previous blog entry I told you about 

alternatives how to handle very big projects

. Well, I’ve noticed even though big projects have been broken down into smaller waves companies tend to setup a big project organization. Basically there’s nothing against an agile organization consisting of multiple teams such as 

SaFE

or similar. However, there have to be considered some important topics.

trafic-organization

I’d like to start with 2 phrases of the Agile Manifesto

„Individuals and Interactions over Processes and Tools“
and
„Customer collaboration over..“
 Agile Manifesto, 2001

First phrase tells us that tools should have less priority than direct interactions and communication. Well from my point of view in a big project organization that’s true AND false at the same time, let me explain you why!-On one hand it’s crucial to invest more in direct communication as in a single team organization. Otherwise we end up in well-known situation of the calling game, that first/team says red and until the end of the queue it’s green to the last. On the other hand in a scaled agile organization it’s impossible to talk to each teams from scaled product owner organization perspective and not all the teams could talk to each other at all the times. Otherwise team productivity will decrease dramatically. So key is identifying and planning dependencies. But product owner should not exclude teams in direct communication then again we come back to a multi-layered proxy organization. 2nd part of first sentence „..over Processes and Tools“ gets another importance in scaled agile organizations. Tools such as for agile portfolio management could support transparency in progress and budget burn-down. They deliver real time informations bottom up and prevent the calling game situations.

agile-portfolio

Image Source: rallydev.com

With real time information product refinements, problems identification and intervention could be done much earlier. Furthermore the agile organization, with it’s self organized approach, reduces overhead costs but also organizational risks.

"In reports about the failed project Insieme from the Swiss Fedural Departement of Tax the risks were much more positiv reported at management level, than originally at project level. For the followup project Fiscal-It Findel proposes reports on a half-year-based by the governement."

Findel-Report, NZZ 4. April 14

That leads me to 2nd phrase „Customer collaboration over ..“. Beside self-organization of scaled agile organization the stakeholder involvement is key. Based at real time informations and feedback about the periodically delivered working increments the stakeholders take there responsibility and even big projects could be worked out successfully!-How agile is that if we send reports on a half-year base, as mentioned in the Findel-Report (Findel is the delegation for finance from the Swiss Governement)?

3 Comments

Comment

Importance of Meetings on same level in distributed Teams

While sharing customer experiences about distributed scrum a very simple action came up, that could have big impact to team culture and satisfaction. Last week we made a workshop with one of our team sourcing customers, that has it's own nearshore team at youngculture as workbench extension of his local developement team. While discussion with customer about they're implementation of a distributed scrum we noticed one simple action I'd like to share with you.

Usually meetings, e.g. daily standup, were done using video conferencing. Therefor each part of team moves to it's meeting room. So far so good.

augenhöhe

In this case scrum master was part of local part of scrum team. So local team was talking and talking and often after a while they realized, that delocated part of scrum team was recently disconnected because of network issue. This sounds now nothing special, this happened to everybody of us in the past.

However, customer had afterwards internal discussions about this from another perspective. How this meeting passed off until this moment from point of view of delocated part of team?-The local part of team put themselfs in place of delocated team members and decided together the following action.

From now on scrum master was in any meetings added remotely too. In my opinion they reached with this very simple action, that  both parts of team are handled at same level. Doing so local part of team accepted delocated part of team as full-fledged team members!

To be honest I never looked at this from this perspective, but I will give this higher priority in the future for sure.

Comment

Comment

Fazit aus Speech von @JeffSutherland über Einsatz von #StoryPoints oder #Stunden in @Scrum

Noch immer erlebe ich oft Diskussionen ob Stories mittels den abstrakten #StoryPoints oder aber mittels den etwas greifbareren Stunden geschätzt werden sollen. Eine kurze Zusammenfassung der Speech von @JeffSutherland am @Scrum Master Certification Course vom 26. April 13 in Zürich.

Aus menschlicher Sicht scheint die Aufwandschätzung in Stunden nachvollziehbarer und vorderhand einfacher. Die Studie von Microsoft aus dem Jahre 2012 hat aber einen wesentlichen Mangel bei Aufwandschätzungen anhand von Stunden ausgemacht. Diese konnte nachweisen, dass im Gegensatz zur Schätzung via StoryPoints die Aufwandschätzung mittels Stunden eine massiv höhere Standardabweichung aufweist im Verhältnis zum Detaillierungsgrad der Anforderungen. D.h. eine Schätzung mittels StoryPoints bleibt sich mit zunehmender Verdichtung der Anforderung in etwa gleich. Dies ist insbesondere auch für die Kunden essentiell, da nicht immer nachgebessert werden muss.
2013-05-25_21-03-15
Vorausschätzung hierfür ist jeweils, eine gewisse Kontinuität im Team und natürlich eine gemeinsame Referenzschätzung (Vergleiche auch Artikel Distributed Scrum 1 -  Planning Poker).
Interessant fand ich, dass gemäss Erhebungen von ScrumAlliance  mittels StoryPoints ca. 48x effizienter geschätzt wird. Zudem ist aus psychologischen Sicht auch ein Vorteil, wenn sich die Teammitglieder mit jeder abgeschlossenen StoryPunkte gewinnen, anstelle Stunden abarbeiten zu müssen.
Why should you still use estimations in hours if by story points it's 50 times faster and much more accurate?
Jeff Sutherland, co-inventor of SCRUM, Zurich 26.4.13
Nun gilt es die Kunden, als auch das interne Management zu überzeugen auf StoryPoints zu wechseln (Vergleiche auch Artikel Scrum – Ein umdenken im Sales Prozess). Ich kann dies jedem Scrum Team nur empfehlen.
Mehr Details siehe auch im Artikel von Jeff Story Points: Why are they better than hours?

Comment

Comment

Distributed Scrum 1 - Planning Poker in virtuellen Teams

Bei verteilten Scrum Teams bzw. einem #DistributedScrum oder #ScrumOfScrum kam schnell die Frage auf wie ein #PlanningPoker durchgeführt werden kann?-Wie so oft war für uns die Einfachste die Beste Lösung.
708454fb3a4c311a62c44197c56afde5
Das Wichtigste im Planning Poker, auch um Beeinflussungen zu verhindern, ist das zeitgleiche Schätzen. Bei verteilten Teams gestaltet sich dies schwierig. Wir hatten zuerst Tools recherchiert, u.a.:
  • Jira Plugins, siehe https://marketplace.atlassian.com/search?q=planning+poker
  • Webtools, bspw. http://www.planningpoker.com
  • Apps, u.a. https://play.google.com/store/apps/details?id=com.pxr.planningpoker
Doch was uns aufgrund der Einfachheit überzeugt hat, bzw. sich bewährt hat, ist das Schätzen via Google Spreadsheet. Hierfür hatten wir ein Sheet wie folgt aufgesetzt (bitte kopiert dieses, falls ihr es nutzen wollt):
ab6a3bc265e5efb6d85fc9dbb0f30741
Dabei ist das Vorgehen analog zu normalem Planning Poker. Zuerst wird die Story vorgestellt, hierfür wird im Spreadsheet die entsprechende ID eingetragen. Dann tragen alle ihre persönliche Schätzung ein und auf Kommando wird gemeinsam mit ENTER quittiert. Über farbliche Formatierung lassen sich noch analoge Schätzungen visualisieren und sofort sind die minimalen bzw. maximalen Schätzungen ersichtlich. Die dann wie gewohnt im Team besprochen werden.

Comment

Comment

Scrum - Ein umdenken im Sales Prozess 3, Kooperationsmodell "Money for nothing"

Bei Vertragsverhandlungen bezüglich Buchung eines Scrum Teams hatte @JeffSutherland @Scrum Master Certification Course Zurich einen etwas radikaleren Ansatz, wie Scrum verkauft werden könnte, vorgestellt. Gemäss Jeff ist dies nur mit erfahrenen Scrum Teams eine Option.
Im Kooperationsmodell "Money for nothing" bucht der Kunde nicht bloss über einen definierten Zeitpunkt ein Scrum Team, sondern hat auch die Möglichkeit dieses bei Zielerreichung zu stoppen bzw. zurück zu geben. Konkret bucht der Kunde bspw. für 10 Sprints ein Scrum Team à 3 Personen. Daraus resultieren Fixkosten pro Sprint von beispielsweise CHF 100'000.- bzw. über CHF 1Mio. für 10 Sprints.
7e46fa53eb7e5df6757b8e6b551d4d1c
Da der PO/Kunde die Umsetzung hinsichtlich Features mit höchstem Business Value steuert ist bspw. nach 5 Sprints 80% des Business Values erreicht und der Kunde entscheidet sich die Umsetzung zu stoppen. Der Kooperationsvertrag sieht nun vor, nicht die restlichen 5 Sprints à CH 100'000.-, sondern dem Lieferanten nur ein zu definierenden "Penalty" für den Arbeitsausfall bspw. 30% also CHF 150'000.- zu bezahlen.
Dieses Vorgehen kann in zeitlich beschränkten Projekten eine win-win Situation für Kunde und Lieferant sein. Da der Kunde weniger bezahlt als für alle 10 Sprints bezahlen würde aber eigentlich nicht mehr Funktionalität benötigt. Andererseits für den Lieferanten, der das Scrum Team stellt, der einen Teil des Umsatzausfalls vergütet kriegt.

Comment

Comment

Wie gehe ich mein erstes Scrum-Projekt an?

Wie heisst es so schön "die Theorie ist das Eine aber die Umsetzung etwas ganz Anderes". @JeffSutherland hatte hierfür das Beispiel eines Tangotänzers genannt, der sich bei den ersten Tanzversuchen wohl auch ziemlich doof vorkommt :-). Gleiches gilt auch für die Implementierung von Scrum, zumindest hatte ich dies damals so erlebt. Nachfolgend möchte ich Euch einige Learnings aus eigener Erfahrung mitgeben.
Die @ScrumAlliance gibt bei der Einführung von Scrum relativ wenig vor, was einerseits ein Vorteil ist da flexibel und adaptiv. Andererseits fühlt man sich u.a. vor einem unüberwindbaren Berg beim erstmaligen Setup eines Scrum Teams.
 124b2531bdd94b5401ec1ec8a668b80c
Generell macht es sicherlich Sinn vor Start eines Initialprojektes ein Training mit dem Pilotteam durchzuführen. Um die Kosten klein zu halten bieten sich Scrum Trainer  zum Teil auch für Gruppenschulungen ohne Zertifizierung an. Ist erstmals das Grundwissen vorhanden gilt es praktische Erfahrungen zu sammeln, entweder in einem nicht zeitkritisches internes oder aber externes Projekt. Sehr gut geeignet für eine erste Scrum Implementation  sind bspw. auch Maintenance Projekte/Teams. Denn idealerweise kennen sich die Teammitglieder bereits und d.h. funktionieren als Team, verfügen über einen guten Kundenfokus bei hohem Qualitätsverständnis. Letzteres ist wichtig bei der Erreichung von Done. Als nächstes werden die Rollen (PO, SM, TE, Testing, etc) innerhalb des Teams verteilt.
Es empfiehlt sich die Teststrategie zusammen mit Done bereits in der Projektinitialisierung zu definieren. Auch sollte vor Projektstart sichergestellt werden, dass der PO über die notwendigen Entscheidungs-, als auch Fach-Kompetenzen verfügt. Die ideale Teamgrösse liegt unter 7 Personen, aus Erfahrung würde ich mit maximal 3-4 permanenten multifunktionalen Teammitgliedern starten. Sehen Sie bei der Kapazitätsplanung bereits auch adhoc Ressourcen wie IT-Unterstützung, internes/externes technisches Consulting bspw. für Architekturreviews und Audits vor. Die ersten Sprints würde ich kurz halten 1-2 Wochen um einerseits die Meetings zu trainieren, aber auch um schnellstmöglich einen ersten Output zu erhalten.
 "Vertrauen ist gut, Kontrolle ist besser"; setzen Sie Kontroll- und Optimierungsmechanismen auf bspw. über die Messung der Velocity, Sprintfortschritts via Burndown Chart, Qualität über das Tranken von Findings, etc. Sie werden sehen, dass die Messung der Velocity das Team zusätzlich anspornt und die Performance unglaublich schnell in die Höhe schnellt. Das Tool ist in einem ersten Projekt sekundär. Verlieren Sie damit keine Zeit sondern setzen sie ein Whiteboard inkl. Post-it's oder aber bspw. Excel via Dropbox ein, dies reicht erstmals völlig aus.
Starten Sie nicht mit einem verteilten Team. Dies ist höhere Schule bzw. ein Distributed Scrum, dazu später mehr. Dann geht's los. Etablieren Sie alle Artefakte und Meetings. Am Anfang wird alles noch sehr ungewohnt sein und evt. etwas länger dauern. Aber bereits ab Sprint 2 werden Sie die gemachten Erfahrungen in Adaptionen einfliessen lassen.

Comment

1 Comment

Scrum - Ein umdenken im Sales Prozess

Sowohl Stakeholder, als auch Sales Manager verlangen nach ausgewiesenen Lieferobjekten die geschätzt, offeriert und abgegrenzt werden können. Insbesondere wenn es sich um Projekte im Fixpreis handelt wird seitens des Software Lieferanten sehr viel Energie in die Definition des Skopes investiert um sich abzusichern. Scrum bietet hier einen revolutionären Ansatz diese Mittel besser -nämlich in die Produktentwicklung- einzusetzen.
Generell ging ich früher bei der Ausarbeitung einer Offerte immer in zwei Schritten vor:
1. Kurzanalyse Grobkonzept
2. Detailanalyse
Im 1. Schritt wurde jeweils geprüft ob die Projektanfrage ins Portfolio passt, Timing für Erstellung der Offerte bzw. Umsetzung realistisch sind und die nötigen Ressourcen zur Verfügung stehen. In der Detailanalyse wurde durch ein technischer Senior Consultant die Lieferobjekte im Detail ausgewiesen, eine Lösung skizziert und die Lieferobjekte einzeln geschätzt inkl. Definition von Abgrenzungen. Dieser 2. Schritt war seit jeher immer sehr aufwändig. Es stellte sich zudem heraus, dass die erste Einschätzung des Projektvolumen aus Schritt 1 und die detaillierte Schätzung aus Schritt 2 meist nicht gross abwich.
Als Konsequenz entschieden wir uns daher in der Offerte von Scrum Teams auf den 2. Schritt zu verzichten und stattdessen Kapazitäten zu offerieren. Die KOSTEN definieren sich dabei neu aus der SUMME von verwendeten RESSOURCEN X RATE X TIME.
Hierfür sind folgende Eingangsparameter nötig:
  • RESSOURCEN: Benötigten Ressourcen/Profile anhand Anforderungen inkl. deren Velocity
  • RATE:  Rate pro Ressource, wobei von einer maximalen Buchung ausgegangen wird
  • TIME, die Nutzungsdauer bzw. das Projektvolumen resultiert aus der Einschätzung des Grobkonzeptes bei Berücksichtigung des Endtermins und der eingesetzten Ressourcen inkl. Buffer
Nachfolgend ein abstraktes Rechenbeispiel zur Kalkulation der Kapazitäten und der Projektkosten:
scrum_visual.001
Setzt man nun diese Parameter in obiges Rechenbeispiel ein erhält der Kunde eine Kostenplanung pro Sprint inkl. Kostendach fürs Gesamtprojekt. Bei youngculture setzen wir diese Kalkulation schon seit 2004 ein und diese wurde vom Markt sehr gut aufgenommen. Da die Vorgehensweise nach Scrum nachweislich nach einem working Inkrement verlangt ist zudem gewährleistet, dass der Kunde zum Projektende innerhalb des definierten Kostenrahmens ein Produkt erhält mit höchst möglichen Business Value. Aber dazu mehr in einem späteren Beitrag.

1 Comment

Comment

Was macht ein erfolgreiches Scrum Team aus?

Wie in klassischen Projektmethodiken bspw. nach Wasserfall basiert  der Erfolg von agilen Projekten v.a. auch auf der richtigen Zusammenstellung des Scrum Teams. Gerade wenn man das erste Projekt mit Scrum durchführt können folgende Erfahrungen hilfreich sein.
Typischerweise ist man beim Setup eines Scrum Projektes, v.a. wenn es sich allenfalls um das Erste handelt, meist mit  den Artefakten von Scrum beschäftigt und wie diese in Kooperation mit dem Kunden implementiert werden sollen. Beispielsweise wie ist das Testing in den Entwicklungsprozess einzupassen, oder Stories zu komponieren, etc. Dabei geht häufig vergessen, dass der Erfolgt von Scrum nicht nur in der Methodik zu suchen ist, sondern meines erachtens auch mit grossem Anteil auf den Paradigmenwechsel zurückzuführen ist. Nachfolgend nochmals eine Zusammenfassung wichtiger Prinzipien & Werte von Scrum:
  • Team-Spirit: Das Team steht im Zentrum, Scrum setzt auf Selbstorganisation und Stärkung der Übernahme von Verantwortung durch alle Team Mitglieder
  • Transparenz & Vertrauen: Die Grundlage für die enge Zusammenarbeit zwischen Team und Kunde bildet die gegenseitige Transparenz bzw. das Vertrauen
  • Kunde & -Bedürfnisse im Fokus: Das Team geht auf den Kunden ein und macht technische Objekte für den Kunden verständlich (User Stories) bzw. präsentiert diese in der Sprache des Kunden
  • Agile == Evolution: Sowohl auf der technischen Ebene, als auch auf den Kooperationsprozess bezogen bittet Scrum Hand sich kontinuierlich zu Verbessern
  • Dinge abschliessen: Es wird erst mit Neuem gestartet wenn Offenes, im Sinne von Done, abgeschlossen ist.
  • Geschäftswert maximieren: Der Business Case bzw. Kundennutzen steht im Zentrum von Scrum und wird entsprechend in der Priorisierung mit dem Kunden mitberücksichtigt
Scrum stärkt über diese Prinzipien das Team und dessen Selbstverantwortung und bezieht den Kunden näher in den Entwicklungsprozess mit ein. Die kurzen Zyklen machen den Scope überschaubar und reduzieren die Risiken. Diese Prinzipien verteilen die Rollen von Grund auf neu und erfordern entsprechend passende Charakteristiken der Teammitglieder mit komplementären Kompetenzen. Nachfolgend möchte ich auf die aus meiner Sicht wichtigsten Charaktereigenschaften der verschiedenen Rollen von Scrum hinweisen:
Stakeholders (SH)
Sprechen das Budget und setzen das Vertrauen in den agilen Prozess bei zum Teil noch ungenauen Lieferobjekten. Im Wissen, ein funktionstüchtiges Produkt mit dem maximierten Businessnutzen zu erhalten. Dabei gewähren Sie entsprechende Entscheidungskompetenzen insbesondere an den Product Owner.
Product Owner (PO)
In enger Zusammenarbeit mit dem Business steuert er voraus schauend die agile Entwicklung und das Scrum Team. Dabei stellt er den Business Nutzen in den Vordergrund und hat idealer Weise sowohl einen  technischen, sicher aber einen fachlichen Hintergrund. Er ist ein ausgewiesener Team Player, der die Vorschläge des Teams annimmt und Team Entscheide mitträgt.
Scrum Master (SM)
Hat praktische Erfahrung in der Anwendung von Scrum und im Coaching von -Teams. Er ist im Team als Prozess Owner akzeptiert und stellt die "richtige" Implementation von Scrum und somit auch die die Performance/Velocity des Teams sicher. Der SM fungiert dabei als vollständiges Team Mitglied und ist nicht zwingend dessen Team Leader.
Team Members (TM)
Die TM ergänzen sich komplementär sowohl durch ihre Erfahrung (Junior - Senior Level) als auch durch ihre technischen Fähigkeiten (Entwickler, Fester, IT-Support, Architekt, etc). Sie zeichnen sich durch ihren ausgeprägten Kundenfokus und die proaktive, jederzeit transparente Kooperation aus. Alle TM sind gierig Neues von anderen Mitgliedern zu lernen um als Team sich stetig weiter zu entwickeln.
Wird nur eine Rolle unpassend besetzt kann dies bereits den Projekterfolg gefährden. Dabei muss sich das Scrum Team in den Retrospektive Meetings auch jeweils selbst hinterfragen und den Mut aufbringen allfällige "Fehlbesetzungen" zu korrigieren.
Ist das Team zudem multikulturellen Mitgliedern muss dies noch speziell berücksichtigt werden, da diese Komponente das Verständnis der Zusammenarbeit noch weiter hemmen, oder zumindest die Ramp-up-Phase verlängern kann.
Viel Spass bei der Teamzusammenstellung!

Comment