ga naar de navigatie ga naar de inhoud

Opgelet!Schijnbaar begrijpt uw browser geen Cascading Style Sheets of u hebt e ondersteuning voor CSS uitgeschakeld. Dat is niet erg, maar besef dat u momenteel een andere lay-out ziet dan de ontwerpers van deze site bedacht hebben.

Een site over Vlaamse overheidscommunicatie
 

Scrummen in de praktijk: hoe begin je eraan?

Projecten die aanslepen omdat ze als een harmonica worden uitgerokken over verschillende maanden, waarbij de focus zoek raakt omdat je zo onmogelijk "in de zone" kunt blijven? Energie die verloren gaat omdat de volgende vergadering pas over vijf weken kan doordat iedereen ook andere projecten heeft lopen? Derden die ondertussen niet worden geraadpleegd en daardoor pas aan het einde met fundamentele opmerkingen komen? En die niet begrijpen hoe het project zo lang kon duren zonder dat ze erbij werden betrokken? Herkenbaar?

We hadden het hier al eerder over sprinten & scrummen en over agile ontwerpen of wendbaar werken als antwoord op zulke problemen, ook als je geen sites of software bouwt. "Is scrummen duurder? Pieter Jongenius: 'Onze ervaring is dat de kosten ongeveer gelijk zijn aan die in traditionele methoden. het resultaat echter wordt sneller behaald, heeft meer kwaliteit, je zet disciplines direct bij elkaar die anders ook aan hetzelfde project hadden gewerkt.' In een scrummethode werken ze gefocust en intensief samen, met hoge snelheid, is men gezamenlijk verantwoordelijk. Gaandeweg al worden resultaten geboekt. De ervaring is dat er veel minder rework is: 'Als er iets niet klopt, herstelt men dat meteen; de verificatie zit nu in het team en niet achteraf'." (Bron: Douma's artikel, zie verderop.)

Hoe begin je nu precies aan dat scrummen? Meer openheid creëren en je team organiseren volgens het model van een redactie volstaan daarom niet. Godfried Knipscheer nam de handschoen op voor de afdeling Communicatie. Zijn belangrijkste inzichten:

  • "Iedereen kent wel die tekening van de schommel en de boom over hoe ICT-projecten kunnen mislukken, of sarcastische uitspraken als 'you wait nine months and then the screaming starts'. Helaas heel herkenbaar ... maar tegelijk zag je webontwikkelaars zelf nieuwe wegen zoeken én vinden. Nadat ik op deze blog zag dat agile werken ook voor de communicatieplanning werd aanbevolen, ben ik me gaan afvragen hoe wij het in onze eigen projecten zouden kunnen aanpakken.
  • De kerngedachte is om zaken niet meer van A tot Z te gaan plannen en uitwerken, maar ze pragmatischer te benaderen. Werken met tussentijdse opleveringen zorgt niet enkel voor quick wins en de bijhorende bevrediging een resultaat in handen te hebben. Het laat ook toe bij te sturen én bij te leren uit wat je al gedaan hebt, telkens weer. Evalueren wordt zo iets dat je frequent doet in plaats van als een eenmalig verplicht nummertje achteraf. Dat je die reflex kweekt is ook essentieel. [En het rijmt goed met een real time marketing aanpak - nvdr.]
  • Praktisch betekent dat: opdelen. Werken in cycli van 2 à 3 weken, de zgn. sprints. En per sprint bekijk je: wat hebben we al, wat hebben we vorige keer wel en minder goed gedaan, en hoe gaan we onze eerstvolgende sprint aanpakken? Dat is echt afvinken en attribueren zonder inhoudelijke discussies, hoogstens "wat heb ik gedaan, wat ben ik van plan, waar zit ik vast, wat of wie heb ik nodig". Zo vermijd je dat mensen klem komen te zitten, iets als een onoverkomelijke berg aanvoelen. Het is integendeel motiverend, dingen worden behapbaar, men gaat zich als groep verantwoordelijk voelen voor elkaar, wilt niet afgaan. Als je het werk goed verdeelt, krijg je een echt samen-gevoel.
  • Allereerst begin je met een grote brainstorm over wat er allemaal bij je project komt kijken, wat zeker moet gebeuren en wat goede ideeën zouden kunnen zijn. Want je moet natuurlijk van in het begin een totaalvisie op je project hebben. Bv. "we werken aan een nieuw intranet" wordt dan de hoofdnoemer waaraan elke deeltaak blijft gerelateerd worden. Zo kun je ook toetsen of je nog wel het essentiële aan het doen bent, vermijd je tunnelvisie of ongepast perfectionisme.
  • Die brainstorm kun je nog heel fysiek aanpakken, bv. door post-its op een grote muur te plakken. Dat is makkelijker als je veel items moet ordenen, maar ook heel leuk want je zet het hele team aan het werk - iedereen is betrokken, iedereen beslist mee hoe het project gefaseerd wordt. Al kun je met deze manier van werken altijd nog deelprojecten van volgorde veranderen als het moet.
  • Na die brainstorm ga je dat alles groeperen en ordenen in een zgn. backlog. Daarin sorteer je alles volgens prioriteit, en zo kom je dan tot deelprojecten: wat moeten we eerst doen als voorwaarde om aan dat andere te kunnen beginnen? Op die manier komen zowel abstracte dingen (bv. stakeholdermanagement) als praktische klussen (bv. sessies organiseren) naar boven. En dan stel je bv. vast dat je het ene al bewezen hebt te kunnen maar dat je dat andere veel meer in het oog moet houden en misschien weer opsplitsen in een reeks tussensprints die de voorwaarden scheppen.
  • Na zo'n kickoff ga je er ook wat orde in willen brengen, en daarvoor bestaan ondertussen ook prima softwaretools ter ondersteuning. Die dwingen je in de logica van dat agile plannen want je moét een backlog aanmaken, dingen toewijzen, afvinken of van status veranderen ... Je hoeft dus niet in Excel te gaan knutselen.
  • Het is ook heel handig om die tool tijdens een sprint op de muur te projecteren en de aanpassingen gelijk in te voeren, of zaken te gaan herindelen. Iedereen kan er nadien weer in, want het is een webtoepassing. En doordat je elkaar frequent ziet, ga je ook minder mailen, waarvan we de nadelen genoegzaam kennen.
  • In onze afdeling hebben we uiteindelijk gekozen voor Planbox, met licenties voor een vijftiental medewerkers (ze rekenen per jaar, niet per project, dus dat blijft eenvoudig en betaalbaar, en voor wie meekijkt is het zelfs gratis). Er bestaan ook app-versies van (Android, iOS, andere) en het werkt net zo handig op een tablet als op een gewone pc.
  • Je hebt ook complexere tools zoals Jira, voor organisaties die al verder staan ... Het evolueert sowieso, softwarematig, maar ook wat je als team aankunt. Maar niet elke project- of samenwerkingssoftware is geschikt; bv. Podio heeft de methodiek niet ingebakken.
  • Wat ook heel leuk is aan sprints, is dat je aan planning poker moet doen. Eerder dan taken te begroten in werkuren, moet je er punten aan geven: 0,5 / 1 / 2 / 3 / 5 / 8 /13 / 20 / 40 of 100 met name - zo'n beetje volgens de Rij van Fibonacci. Dat verloopt veel intuïtiever. Eerst maakt ieder voor zich een inschatting, en nadien pas komen alle kaarten op tafel, wat dan vanzelf tot discussies leidt als "zo véél, wat verstà jij er dan onder". Meestal moeten enkel de teamleden met de hoogste en de laagste score hun redenering uitleggen, en daarna kun je al gaan herscoren à la "we zullen die 13 op 8 zetten". Zulke dingen maken het samenwerken leuk, al moet je wel gedisciplineerd blijven wat betreft kort maar krachtig vergaderen. Staand vergaderen is daarvoor het meest geschikt.
  • Na verloop van tijd leer je als team bv. "wij kunnen veertig punten per week aan". Als je dan naar je totale planning kijkt, ga je die ook veel realistischer kunnen herberekenen, en krijg je een duidelijke horizon in de tijd.
  • Je kunt ook veel efficiënter gaan plannen tussen teams of in een periode. Bv. terwijl een deelteam met een sprint bezig is, zijn de collega's van de redactie weer even vrij om met hun reguliere publicatie bezig te zijn, waarna ze verderop in het project weer inspringen met hun specifieke talent voor een andere sprint. Zo creeër je synergie eerder dan dat je het ene team op het andere laat wachten. Je leert elkaar beter kennen en kunt organischer op elkaar inhaken. En een onverwacht voordeel is misschien ook dat je sneller van elkaar doorkrijgt wanneer iets niét gaat lukken: beter fail fast dan een miskraam na negen maanden.

Aanvullend aanbevolen:

Bent ù al aan het scrummen? Kent u praktijkvoorbeelden? Deel ze met ons a.u.b. - via de reacties hieronder, of mail ons met het oog op een vervolgartikel. (Om te reageren klikt u op de titel van dit artikel en ga naar het reactieveld onderaan.)


Update: Godfried Knipscheer schreef ondertussen een samenvattend artikel met als titel"Agile projectmethode voor communicatieprojecten" (pdf van 350 kB).

Op 2015-09-08 verscheen "Scrum bij andere projecten dan ICT? Hoe werkt dat? Scrum-ervaringen bij Pluryn" van auteur, socioloog, managementconsultant, emeritus hoogleraar én redacteur van ManagementSite Willem Mastenbroek.

En op Managementsite staan ook enkele boeiende artikels, bv.


Pagina afdrukkenTip een collega over deze pagina
Gepubliceerd op 30 juli 2014. Laatst gewijzigd op 8 september 2017

Discussie

Geen reacties tot nu toe.

(Alle reacties zullen met de naam van de afzender gepubliceerd worden)

:


: