Scrum in de praktijk - Q&A

Bij de inrichting van een Scrum team moeten er een aantal keuzes gemaakt worden. Op deze pagina enkele veel voorkomende vragen en antwoorden.

---

Q: Past Agile en Scrum bij mijn type organisatie?

A: Onderstaand plaatje uit het boek The reengineering alternative laat zien dat grote organisaties, die zich meestal in het rechter quadrant bevinden, verder afstaan van de waarden waar agile voor staat. Dat maakt de transitie moeilijker en langduriger.

Het onderzoek Agile & Culture: The Results bevestigt dit. Onderstaand diagram geeft de uitkomsten van het onderzoek weer:

Archetypes van deze culturen zijn: Een sport team of consulting organisatie (Collaboration), defensie (Control), universiteit (Competence), non-profit/religieuze organisaties (Cultivation) .

Ook al heeft de afdeling of het bedrijf een cultuur die past bij Agile en Scrum dan nog moet rekening gehouden worden met de cultuur van de opdrachtgever. Intern is dat de business, extern de klant.

Voor interne projecten is hat zaak de business stakeholders te overtuigen van hun rol binnen Scrum: dus niet eenmalig een opdracht formuleren en het resultaat afwachten maar actief participeren. Voor externe klanten is het zaak een agile contract af te sluiten dat past bij de aanpak.

Dit artikel waaschuwt Scrum implementations fail when they ignore organizational culture voor het negeren van de organisatie cultuur.

Q: Kan Scrum succesvol worden toegepast in een organisatie die niet Agile is?

A: Ja dat kan en dit is nu eerder regel dan uitzondering. Een minimale eis is wel dat de product owner zijn werk kan doen en feedback krijgt van de busniness over de wensen en de voortgang. De lijst met impediments kan alleen met kunst en vliegwerk worden opgelost door soms informele afspraken te maken. Ook zonder een optimale omgeving kan met Scrum worden bereikt dat de risico's van een project worden beperkt, de time-to-market wordt verbeterd en de productiviteit wordt verhoogd.

De stap om de hele organisatie om te vormen naar een agile organisatie is groot. Daarom worden meestal eerst enkele projecten met Scrum uitgevoerd. Dat klink logisch maar is moeilijk als de omgeving van die projecten nog in de oude stijl denkt en handelt. Het is dan ook essentieel dat deze projecten vanuit het top management gesteund en beschermd worden.Voor een blijvend succes moet de organisatie echter aansluiten bij de agile waarden. Dit kan bottom-up en top-down worden gerealiseerd zoals hier beschreven.

Q: Kan Scrum succesvol worden toepast buiten de IT afdeling?

Ja dat kan en gebeurd steeds meer. Zie het artikel Embracing Agile met video van de Harvard Business Review.

Q: Kan Scrum succesvol worden toegepast in een grote IT organisatie als de onze?

A: Scrum kan goed worden toegepast in grote organisaties. Belangrijk is dat de eerste teams geholpen worden met de omgang met de veelal starre regels. Als het om een los product gaat is het een idee het team naast de staande organistie te plaatsen en er meteen een DevOps team van te maken dat zelfstandig zijn software live kan brengen. Als een aantal teams samen aan een project werkt is er behoefte aan coordinatie. Zie deze pagina voor een drietal mogelijkheden.

Lees ook "How Microsoft dragged its development practices into the 21st century In the Web era of development, Waterfalls are finally out. Agile is in.". Wat opvalt is dat Microsoft de rol van product owner de titel program manager geeft. Als het om status en beloning gaat een terechte keuze. Steve Denning beschrijft in oktober 2015 in dit artikel dat Microsoft inmiddels agile is. In 'Microsoft's 16 Keys To Being Agile At Scale' beschijft hij hoe vele teams samenwerken.

Q: Hoe een Scrum project voor te bereiden?

A: Het Scrum framework verlangt alleen dat aan het begin van de eerste sprint een geordende backlog beschikbaar is waarvan voldoende user stories zijn uitgewerkt om door het team opgepakt te kunnen worden. De vraag is nu: Hoe komt de eerste versie van de backlog en het team tot stand?

Voor dit antwoord nemen we aan dat:

1. Het project één of meerdere stakeholders heeft en de gebruikers hierin zijn vertegenwoordigd.
2. De stakeholders een visie delen over de doelstelling van het project.
3. De stakeholders bereid zijn een product owner aan te stellen met het mandaat prioriteiten te stellen.
4. Het project naast organisatorische een ICT component heeft.

Met Scrum worden user stories met stukjes end-to-end functionaliteit gerealiseerd. De meest waardevolle eerst. Het vóór de bouw in detail analyseren van de requirements en het technische ontwerp zijn gewoonten van de waterval aanpak en eerder een last voor het Scrum team. Meer hierover in Big Modeling Up Front (BMUF) Anti-Pattern. Maar voor het verkrijgen van het projectbudget, de te kiezen technologie en daarmee de samenstelling van het team is wel een globale analyse nodig. Meer hierover in Project Startup Activities are Key to Success in Both Agile and Traditional Approaches. Hou de analyse globaal en steel geen tijd van de realisatiefase van het project als er een deadline in voor de oplevering. Het team wordt niet alleen geremd door een teveel aan up-front modeling maar het kost ook veel geld het zelfde resultaat in een kortere tijdspanne te realiseren. Zie de uitgestelde projectstart. Zodra de business case positief wordt beoordeeld en het budget is vastgesteld kan het team worden aangewezen of samengesteld. De product owner zal met het team per user story de requirements en het ontwerp vaststellen. Voordat sprint 1 van start gaat moet het team de top van de backlog volledig begrijpen en de inspanning hebben ingeschat. Voor dit doel en de inrichting van de omgeving van het team worden vaak een paar dagen gereserveerd in sprint 0.

Scenario 1: volledig Scrum

De stakeholders gaan onder leiding van een uit hun midden aangewezen product owner aan de slag met het creëren van de backlog op hoofdlijnen (epics, zowel organisatorische als ICT). De ICT gerelateerde epics komen op een eigen lijst maar behouden hun verwijzingen naar de organisatorische afhankelijkheden. Behalve functionele worden ook de non-functionele (beschikbaarheid, performance, security) eisen vastgesteld. De ICT partner of afdeling wordt gevraagd een globale analyse te doen. Na goedkeuring van de business case kan het team geformeerd worden met de expertise die past bij de aard van de ICT behoefte. Als de product owner geen tijd heeft om zelf deze rol voor het ICT team te vervullen wijst hij een gedelegeerde product owner aan. Het team maakt voorafgaand aan de eerste sprint (sprint 0) een inschatting van de inspanning die nodig is om de eerste nu bekende epic te realiseren door deze samen met de product owner in user stories op delen en in te schatten. Daarna start sprint 1 met de realisatie van de eerste en meest waardevolle user stories. Mogelijk zal de uitkomst eerder een proof-of-concept zijn dan de uiteindelijke oplossing. Tijdens de eerste sprint is het team al in staat meerdere user stories nauwkeuriger in te schatten waardoor de product owner een idee krijgt van de totale inspanning om ten minste de kerneigenschappen van het systeem te realiseren. De product owner kan de stakeholders een voorlopig releaseschema voorleggen. Na een aantal sprints wordt dit release schema nauwkeuriger en is het tijd de business case te evalueren. Mogelijk is de backlog uitgebreid met onvoorziene functionaliteit die belangrijker wordt gevonden dan de aanvankelijk gevraagde functies. Mogelijk is het budget te krap om alle wensen te realiseren en vallen de minst belangrijke af.

Scenario 2: Prince2, Scrum voor alleen de ICT component

De traditionele aanpak. Zie voor de integratie van Prince2 met Scrum dit artikel. Uit de Project Brief, een besluitenlijst, notulen of door derden opgestelde notities blijkt wat de visie en de doelstelling van het project is. Er worden één of meerdere projectmanagers aangesteld waarvan één verantwoordelijk voor het ICT aspect.

Bij een Prince2 geïnspireerde aanpak laat de ICT projectmanager een globale analyse uitvoeren en stelt een PID (Project Initiation Document) op. De project manager benoemt de deliverables als ware het backlog items. De stuurgroep besluit aan de hand van de business case en de in de PID geschatte kosten en doorlooptijd of het project van start kan. Na goedkeuring vraagt de projectmanager de ICT partner of afdeling een team beschikbaar te stellen of te formeren met de expertise die past bij de aard van de ICT behoefte. De projectmanager wijst in overleg met de stakeholders een product owner aan of wordt zelf de product owner.

Let op: In de PID moet nadrukkelijk worden opgenomen dat het budget en de tijd de vaste waarden zijn en dat de gerealiseerde functionaliteit de variabele is. Voortschrijdend inzicht is welkom, maar dat kan ten koste gaan van eerder gewenste maar minder belangrijke functionaliteit. Scrum vermindert het risico in die zin dat eerst de meest waardevolle functionaliteit wordt gebouwd en in productie genomen. Het project eindigt als de minder belangrijke user stories de kosten niet langer rechtvaardigen.

Scenario 3: RUP als inspiratiebron,

RUP (Rational Unified Process) kent de Inception en de Elaboration fase voordat met de bouw wordt begonnen. Na beide fasen wordt besloten of de business case nog valide is. Het beslisdocument is geen PID zoals bij Prince2 maar bevat (uit The Rational Unified Process: An Introduction van Philippe Kruchten):

• A vision document: a general vision of the core project's requirements, key features, and main constraints.
• A initial use-case model (10% -20%) complete).
• An initial project glossary (may optionally be partially expressed as a domain model).
• An initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast.
• An initial risk assessment.
• A project plan, showing phases and iterations.
• A business model, if necessary.
• One or several prototypes.

Deze documenten kunnen prima na de eerste sprint en, met een update, na de volgende sprints worden opgeleverd. In plaats van use-cases worden user stories beschreven. Met Scrum zijn er geen fasen die voorafgaan aan de bouw. Het team streeft er niet naar code voor eens en voor altijd te schrijven maar is gewend bij de realisatie van een volgende user story eerder gerealiseerde code te herschrijven.

Q:Hoe moet het ontwikkelteam samengesteld zijn?

A: Voordat het project van start gaat moeten één of meerdere teams worden bemand. Het is belangrijk dat dat meteen goed gebeurd. Veranderingen in de teamsamenstelling gedurende het project zijn verstorend omdat het team opnieuw moet uitvinden wat men van elkaar kan verwachten. De Scrum master moet ook opnieuw uitvinden wat de velocity is

Een team moet alles in huis hebben om zelfstandig werkende software te realiseren die aan de eisen van de "definition of done" voldoet. Op basis van de aard van de user stories in de product backlog worden één of meerdere teams samengesteld. Het ligt voor de hand om teams te formeren naar de business units die zij bedienen (een finance team, een commerce team). Een andere afweging kan zijn dat de teams worden gevormd om de bestaande systemen (een front office en een backoffice team). Een standaard invulling van een team is:

• Eén of twee analysten die de details van de user stories uitwerken met de business.
• Enkele ontwikkelaars met verschillende specialisaties.
• Minimaal één testspecialist.

De analisten werken intensief samen met de ontwikkelaars. De ontwikkelaars ondersteunen de testspecialist maar de laatste blijft einverantwoordelijk. De onwikkelaars verdelen een aantal rollen onder elkaar. Eén onwikkelaar stelt zich verantwoordelijk voor de centrale source code repository. Een andere ontwikkelaar voor de technische kant van het CI (Continious Integration) systeem (als dat niet al buiten het team is geregeld). Een ander voor de security aspecten en mogelijk de single sign-on functionaliteit. De definition of done schrijft mogelijk voor dat er QA en andere documentatie opgeleverd moet worden. Op den duur zal blijkt wie die taken het best kan en wil doen. De Scrum master kan adviseren bij de verdeling van de taken maar het is uiteindelijke het team zelf die de zeggenschap heeft. Als een team een tijd lang goed functioneert in een stabiele omgeving is het mogelijk dat een van de leden van het team ook de rol van Scrum master vervult. Voor dat zover is is het beter een ervaren Scrum master aan te stellen die meerdere teams bedient en tevens een ondersteunende functie vervult naar de product owner en de rest van de organisatie. Als een team groter wordt dan 10 personen is het verstandig het team te splitsen omdat de zelfsturende eigenschappen van een team groter dan 7 personen snel afnemen.

Q: Door wie en hoe wordt het team aangestuurd?

A: Het team verbetert zijn prestaties zelf met de Scrum master als facilitator. Tijdens de retrospective meeting wordt besproken welke verbeteringen in de onderlinge samenwerking, de kennisopbouw en de toepassing van tools gewenst zijn. Vervolgens maakt het team een keuze voor aantal acties die ze de komende sprint zullen realiseren. Niet alle verbeteringen kunnen in één sprint uitgevoerd worden. Wel is het zaak af te maken wat wordt voorgenomen.

Q: Hoe gaat de besluitvorming in het team?

A: Ontwerpbeslissingen worden gedurende een sprint on-the-fly gemaakt. Foute beslissingen kunnen later veel rework en daarmee vertraging en extra kosten veroorzaken. Het is gevaarlijk te vertrouwen op dat ene teamlid met al zijn ervaring en status. De luchtvaart heeft geleerd van een aantal catastrofale ongelukken die hierdoor werden veroorzaakt. Sinds de jaren 80 is nu de Crew Resource Management training verplicht om de crew te trainen hoe problemen gezamenlijk aan te pakken. Het TRIM acroniem:

• Talk with each other
• Respect each other
• Initiate action
• Monitor results

sluit mooi aan bij de waarden van Scrum. Het is de taak van de Scrum master om er op toe te zien dat de besluitvorming volgens TRIM plaatsvindt.

Q: Wat is de optimale sprint duur?

A: Voor de start van het project wordt de sprint duur afgesproken. Scrum schrijft een duur van 2 tot 4 weken voor. Langere perioden worden afgeraden omdat:

• het gevaar groot is dat binnen een sprint toch weer met de waterval methode gewerkt wordt
• het contact met de business verwatert
• het aantal momenten van reflectie, de retrospective en de sprint review, afnemen
• het afbreukrisico groter wordt als een sprint mislukt

Berekening van de optimale sprintduur

Met een variatie op de formule van Camp is de optimale sprintduur te berekenen. Zie deze pagina voor een formule die de sprintduur berekent voor de minimale kosten voor het project wanneer één of meerdere sprints moeten worden overgedaan.

Q: De organisatie vraagt om een planning; wat kan ik als Scum master presenteren?

De business wil weten wanneer het project af is. Dat is een valide vraag. Alleen kan die vraag pas bij benadering beantwoord worden als alle wensen en specificaties volledig zijn uitgewerkt. De waterval methode probeert dat te doen; helaas met bedroevende resultaten. Scrum pakt de zaak anders aan. Zodra de product backlog vorm krijgt zullen de team(s) de meest belangrijke user stories uitwerken en tijdens de backlog refinement sessies schattingen afgeven. Met die schattingen kan de Scrum master samen met de product owner een voorlopige release kalender opstellen. Daarin wordt met de nodige voorbehouden aangegeven wanneer de eerste versies van het product beschikbaar komen. Pas nadat de teams een aantal sprints hebben doorlopen wordt duidelijke wat de velocity (de productiviteit is stoty points per sprint) is. De release kalender krijgt een vastere vorm en gedeeld met alle steakholders. Eén voorbehoud blijft, de data staan vast maar delen van de functionaliteit kunnen worden doorgeschoven naar een volgende release.

Q: Wat is een leuke game om het team te leren in iteraties te werken?

A: Probeer het marshmellow spel.