Viewing entries tagged
Scrum Team

Are Scrum Members compatible with line Organization?

2 Comments

Are Scrum Members compatible with line Organization?

Scrum changes working culture of the team members fundamental, or as Henrik Kniberg from 

Spotify.com

 said: „Scrum Teams are designed to feel like a mini-Startup“.

But is this still compatible with traditional line Organization?

All companies I know, that run Scrum, still have a line organization. Idea of line organization is 

to link organizational units, with the help of managing relations, to a hierarchical organization system. In other words e.g. all Scrum Masters are part of a Scrum Master line, developer of a developer line, etc. By today there are

 a lot of  organization types known and hybrid implementations possible too. Don’t take the models in following graphic to serious, but it shows up „modern" implementations :-).

BZCJ685CQAA3TA_.png-large

But isn’t that hierarchical thinking incompatible with the self-organized multifunctional approach of Scrum?-Do we really need a managing role that has the last word and decides e.g. about strategy, salary, etc?

May be we find a solutions thinking about, what Henrik said

:

 How we’d organize a mini-startup, where all employees are company owners?-I personally like to be part of a team, where all are equal partners, similar to a Scrum Team. Of course the roles have to be shared, somebody has to take over product owner hat, another scrum master hat, etc. Depending at personal interests this could be fixed- or rotating roles. Critical decisions would be taken as team, well known in Scrum as team commitment. While base for decision would be worked out in team as well, as we do with a story. Planning meeting would help to structure our tasks in mini-startup, we would set Team goal for next time boxed sprint and would review result, but also continuously improve ourselves through retrospective’s.

If our mini-startup is getting bigger, we split team in two to minimize overhead. From my point of view 3 things would be important during scaling:

  1. Product Owner is working with both teams
  2. New Team members getting equal partners too
  3. Teams are building guild’s depending at topics

Now you’d say Product Owner is getting manager of mini-startup, but this is not true. He’s still equal partner to team members, but he has other focus. Decisions are still taken in team or by team representatives depending at topic. The more we scale organization the more important Guild’s will become. Those would be the glue to keep independent teams together, to exchange best practices and to take decisions within guild’s topic.

Wouldn’t that be more compatible company organization for Scrum Teams?-Or how you’d design your agile organization?

2 Comments

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

Comment

Scrum - Ein umdenken im Sales Prozess 2, Argumente fürs Management

Generell wurde, wie schon in "Scrum - Ein umdenken im Sales Prozess" angetönt, der Verkauf von Scrum Teams vom Markt sehr gut angenommen. Dennoch gilt es nach wie vor Kunden und Stakeholder, welche noch in klassischer Vorgehensweise denken von Scrum zu überzeugen. Vielfach erhalten ich die Frage, wie garantieren Sie mir dass wir am Ende des Projektes die für uns wichtigen Lieferobjekte erhalten, wenn wir diese nicht im Detail offerieren und den Skope gemeinsam festlegen?-Scrum bietet hierfür wundervolle Antworten.
Besteht das Vertrauensverhältnis zwischen Kunde und Lieferfirma die ein Scrum Team stellt, da man beispielsweise schon gemeinsame Projekte durchgeführt hat, ist der Kunde meist leicht für den Bezug von Kapazitäten eines Scrum Teams ohne genaue Skopedefinition zu gewinnen. Kennt der Kunde aber weder die Lieferfirma noch Scrum gilt es zuerst etwas Marketing für beides zu betreiben.
Seitens Scrum gibt es die allgemeinen Argumente wie Transparenz bzw. Einbezug des Kunden in den Entwicklungsprozess, kurze Releasezyklen mit dem Resultat eines working Increments, etc. Erfahrungsgemäss lässt sich das kundenseitige Management  durch folgende Aussagen und Statistiken noch besser überzeugen:
Gartner Inc. says "get agile"
Für die Kunden die sich primär an Anderen orientieren sagt u.a. auch @Gartner_inc "get Agile". Beispielsweise hat das Departement of Defense DoD der USA kürzlich entschieden nur noch agile Projekte zuzulassen. Mehr dazu im Blog-Beitrag von @JeffSutherland 
Scrum is faster
Aufgrund von der Bündelung der Kräfte in multifunktionalen Scrum Teams, dem einfachen Tracken der Velocity und der fortwährenden Verbesserung sind Scrum Teams, gemäss Erhebungen von Scrumalliance.org2-8 Mal schneller als klassische Team nach Wasserfall. Über die Velocity besteht in Scrum ein einfaches Instrument die Teamperformance zu messen und die gesteigerte Performance über mehrere Sprints zu visualisieren.
Classic methods more often fail
Scrum Projekte sind, gemäss der 8 jährigen Erfahrungswerte des CHAOS Manifesto von 2011, mehr als 3 Mal erfolgreicher als Projekte nach Wasserfall. Zudem senkt Scrum die Abbruchrate von Projekten signifikant, von fast 30% bei klassischen auf unter 10% bei agilen Projekten.
8679e826488e1757adfb26aa9cca60f9
Doing what is really needed
Gemäss einer Studie der @StandishGroup wurden nur gerade 20% aller umgesetzten Features durch die Anwender oft gebraucht. Das heisst es hätte mit einem Minimum an Investitionskosten der volle Kundennutzes erbracht werden können, wären der Kundennutzen Treiber für die Umsetzung gewesen. Durch den Produktowner hat der Kunde in Scrum jederzeit die Hoheit über die Priorisierung von Features und kann deren Nutzen jeweils nach Abschluss eines Sprints beim User abholen. Somit wird mit höchster Sicherheit nur das umgesetzt was das Business benötigt.
d77fa27fa78d42e6bc2be13a40aacbfd
Changes for free
Scrum kennt zwar auch Changes jedoch entfällt der gesamte Overhead für deren Nachofferierung. Es werden Anpassungen und neue Features jederzeit ins Backlog aufgenommen. Logischerweise entfällt somit Umsetzungszeit am Ende für nice-to-have Features. Dies ist aber weniger kritisch, da nur das umgesetzt werden soll was dem Business auch was bringt.
759d40323f6297f02d3aaae6c7411a9e
Aus eigener Erfahrung ist es am Wichtigsten dem Kunden im Salesprozess glaubhaft klar zu machen, dass er durch den Bezug des Scrum Teams innerhalb der gebuchten Zeit die Features mit dem grössten Business Nutzen erhält. Hierfür erstelle ich meist zusammen mit dem PO des Kunden, anhand der groben Aufwandschätzung, eine erste Road Map. Es hilft auch den Leistungsausweis des Scrum Teams anhand analoger Projekte und in einem letzten Schritt das Scrum Team selbst vorzustellen. Über einen etwas radikaleren Ansatz berichte ich das nächste Mal.

Comment