Scrum succesvol inzetten

Scrum succesvol inzetten

Ik merk dat steeds meer bedrijven kiezen voor Scrum en Agile als productontwikkelmethode. Soms heel succesvol. Soms ook zie ik grotere bedrijven toch weer terugkomen van Scrum en overstappen op een wat meer traditionele watervalmethode. Waarom, wat gaat er mis? Welke methode past bij welk bedrijf en project

NB. Ik kijk in dit artikel naar de wat complexe projecten waarvan CMS, CRM of ERP onderdeel zijn. Traditioneel gaan we daarbij uit van eerst een product ontwerpen en specificeren, en dan bouwen. Dat noemen we een watervalmethode.

Heel vaak wordt de watervalmethode in verband gebracht met PRINCE2. Deze projectmanagementmethode is gericht op het management, de besturing en de organisatie van een project.

Prince2 kent zeven principes.

  1. Voortdurende businessrechtvaardiging
  2. Leren van ervaring
  3. Duidelijke rollen & verantwoordelijkheden
  4. Managen per fase
  5. Manage by exception
  6. Productgericht
  7. Aanpassen aan de projectomgeving

Het hanteren van deze zeven principes is wat bepaalt of een project werkelijk PRINCE2 gebruikt, niet de toepassing van alleen de processen en de documenten. Als je enkel de documenten of processen gebruikt, maar de principes niet toepast, spreken we schertsend over een PINO-project (Prince In Name Only).

Aan het eind van een project verwacht je iets op te leveren. Software bijvoorbeeld. Hier ontstaat vaak de verwarring over wat je inzet als management. Ik zie bedrijven PRINCE2 of iets soortgelijks vervangen door Scrum Agile alleen. Maar Scrum Agile is een manier van softwareontwikkeling, géén projectmanagementmethode!

Wikipedia: De meeste agile-methoden proberen risico’s te verminderen door software te ontwikkelen in korte overzichtelijke perioden (timeboxes), die ‘iteraties’ genoemd worden. Elke iteratie is als het ware een miniatuurproject op zichzelf, en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie.

Scrum is een flexibele manier om (software)producten te maken. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende (software) producten opleveren. Scrum valt onder de Agile-softwareontwikkeling. 

Scrum-projecten hebben vijf uitgangspunten.

  1. Toewijding: alle leden moeten zich er vol voor inzetten; het is geen deeltijd klus.
  2. Focus: … op wat er in de sprints gedaan moet worden.
  3. Openheid: je houdt elkaar goed op de hoogte van de voortgang en mogelijke problemen.
  4. Respect: respecteer mensen met een andere achtergrond en expertise.
  5. Lef: benoem zaken, stel vragen en kom met nieuwe oplossingen.

Scrum accepteert dat de wereld veranderlijk is en dat softwareontwikkeling iets anders is dan bijvoorbeeld een huis bouwen.

In de afgelopen periode ben ik de volgende situaties tegengekomen bij bedrijven.

  1. Scrum en/of Agile wordt gebruikt als projectmethode. Dit geeft veel verwarring.
  2. Het management verwacht projectmanagement, de rest van de organisatie gebruikt alleen Scrum.
  3. Het management wil Scrum en Agile, maar een project- of programmamanagement-methodiek ontbreekt.
  4. Het management heeft het over Agile-projectmanagement.

Situatie 1. Scrum en/of Agile wordt gebruikt als projectmethode en dit geeft veel verwarring

Bedrijven die puur en alleen willen werken met Scrum of Agile, zien dit als vervanging van projectmanagement. Ze willen dat er in korte tijd software gemaakt kan worden. Als het goed is, is de opdrachtgever, de producteigenaar, daar dan ook dagelijks of minimaal wekelijks bij betrokken. Dagelijks zijn er meetings (daily scrum) van ongeveer 15 minuten, waarin besproken wordt

  • wat je gedaan hebt,
  • wat je gaat doen,
  • welke problemen/uitdagingen je ziet,
  • waar je hulp bij nodig hebt,
  • of er dingen zijn die voor andere teamleden van belang zijn.

Scrum (ik laat de overkoepelende methodiek Agile verder achterwege) richt zich daarmee op snelle, korte ontwikkeltrajecten, de sprints, waarin resultaten zichtbaar worden voor de producteigenaar. Van tevoren is niet geheel duidelijk wanneer een project  (in Scrum de backlog) compleet gerealiseerd is. Logisch, want Scrum staat voor snel en flexibel de werkzaamheden kunnen aanpassen aan veranderende inzichten, wensen en uitkomsten van eerdere sprints.

Gebruikelijk is dat we de items op de sprint backlog schrijven op post-its. Er zijn dan drie kolommen

  • “to do”,
  • “in progress”,
  • “done”.

Soms met een vierde kolom “testing”. Zo is voor iedereen duidelijk hoe het ermee staat.

Tip: Trello.com is een eenvoudige en handige tool om dit online te doen.

Conclusie:

Werk je bij complexe contentmanagement-projecten (CMS, CRM, ERP) alleen volgens Scrum, dan  verlies je de middellange en lange termijn uit het oog. Daarnaast vergeet je samenhang en afstemming van milestones met andere projecten. Je gehele project wordt met alleen Scrum niet gemanaged. Programmamanagement en projectmanagement blijven daarom van belang binnen wat complexere structuren.

Situatie 2. Het management verwacht projectmanagement. De rest van de organisatie gebruikt alleen Scrum

Deze situatie komt voor als het management bepaalde verwachtingen heeft van het project, in tijd, geld en kwaliteit, maar verder geen projectmanagementmethode gebruikt. Bijvoorbeeld als je alleen Scrum gebruikt, of ontwikkelaars alleen Scrum willen toepassen. Ontwikkelaars weten veelal niet hoe een project aangestuurd moet worden. Daarnaast vinden ze het vaak overbodig! Wat gebeurt er? Het management benadrukt de vastgestelde oplevertermijnen, terwijl onderweg complexiteit naar boven komt en Scrum voorziet in verandering van koers. Een spanningsveld is geboren. Het wordt nog schrijnender als het management verwachtingen heeft en het team onderweg met behulp van Scrum een andere richting heeft gekozen, zonder dat zij dit verder hebben gecommuniceerd naar een projectmanager. Een projectmanager heeft formeel geen rol binnen Scrum. Alleen de Scrum-manager en een producteigenaar – als die er al zijn –  worden erkend.

Conclusie:

Organisaties die geen duidelijke projectmanagementmethode hebben gekozen en zeggen volledig Scrum te opereren, lopen hier tegenaan. De chaos is compleet als er meerdere complexe projecten tegelijk binnen het bedrijf lopen. Grote bedrijven die al eerder van Prince2 naar Scrum zijn gegaan, zie ik daarom weer van Scrum teruggaan naar Prince2. Zij verwarren een softwareontwikkelmethodiek met een projectmanagementmethodiek.

Kies je voor bijvoorbeeld een projectmethodiek als Prince2 samen met bijvoorbeeld Scrum als softwareontwikkelmethodiek, dan kan je daar voordeel uit halen. Scope, planning, budget en milestones bewaak je binnen het projectmanagement en de wekelijkse sprints zet je uit binnen deze planning. Het projectmanagement is daarmee het kader en de voorwaarden voor de softwareontwikkeling-sprints.

Situatie 3. Het management wil Scrum en Agile, maar een project- of programmamanagement-methodiek ontbreekt

Ik ben bedrijven tegengekomen waarbij het management een vernieuwing wil doorvoeren in het kader van innovatie. Zij kiezen voor Scrum om sneller een product voor de markt te kunnen opleveren. Deze bedrijven zijn een bestaande ‘traditionele’ planningsmethodiek gaan vervangen door Scrum. Het management heeft de verwachting dat als de organisatie Scrum gaat toepassen, zij de software eerder kunnen opleveren. Deze situatie levert een omgekeerde situatie op als bij 1 en 2. Je vergroot de capaciteit niet, je verandert alleen de methodiek en verwacht daar wonderen van. Feitelijk haal je projectmanagement weg en vervangt het door een softwareontwikkelmethodiek. Dit kan alleen goed werken als

  • het een eenduidige softwareomgeving (product) betreft, waarbij er geen complexe afhankelijkheden zijn met andere projecten,
  • én het systeem al in beheer genomen is.

Conclusie:

Omdat je gewend bent te werken met een traditionele methode en Scrum wil toepassen als tovermiddel, ontstaan er grote verwachtingsverschillen. Zonder de capaciteit uit te breiden, zal ook met Scrum de snelheid niet groter worden. Doordat dit wel de verwachting is van het management, ontstaan er enorme spanningen. Het management gooit in het ergste geval elke week nieuwe functionaliteiten in ‘de groep’, want “we werken tenslotte Agile”. Hierbij ga je volledig voorbij aan alle uitgangspunten van Scrum. Als dan ook de producteigenaar ontbreekt bij de dagelijkse daily scrum meetings, is de communicatie vrijwel compleet verstoord.

Situatie 4. Het management spreekt over Agile-projectmanagement

Ik vind dit persoonlijk een verkeerde term. Agile en Scrum zorgen voor een iteratief proces waarin nieuwe inzichten en wensen meegenomen kunnen worden in een volgende iteratie. Het management en de producteigenaar hebben vaak een totaalbeeld van en eisen aan het nieuwe product. ‘Vroeger’ werden die in een watervalmethode eerst helemaal uitgekauwd. Pas daarna betrok je de ontwikkelaar erbij en ging je plannen en bouwen. Vaak tot frustratie van de ontwikkelaar en de opdrachtgever/producteigenaar. Zo leverde je iets op wat al achterhaald was of niet was wat er verwacht werd. Daarom is het goed om in iteraties te werken. Echter, als er afhankelijkheden zijn, bijvoorbeeld meerdere platforms of meerdere projecten, ontslaat het je als organisatie niet te werken met een projectmethodiek!

Daarnaast, als een producteigenaar (het management) echt Agile wil werken, dan verplicht die zich ook tot een continue bijdrage aan het team.

Conclusie:

Scrum en Prince2 zijn beide geen tovermiddel.  Je hebt zowel een softwareontwikkelmethodiek en een projectmanagementmethodiek nodig. Zeker in meer complexere projecten waarvan ERP, CMS of CRM onderdeel zijn.

Alle betrokkenen moeten weten wat beide methodieken inhouden en waarvoor zij dienen. Zéker het management moet goed beseffen waar de methodieken voor staan en die inzetten waar dat nodig is.

Advies

Een middenweg die ik zelf gebruik in organisaties is een Prince2-laagje rondom Scrum. Ik gebruik niet alle processen van Prince2 maar wel de processen voor het opstarten en afsluiten van het project. Ook gebruik ik een projectboard met een Senior User (meestal de Scrum producteigenaar) en een Senior Supplier. Ik rapporteer aan de projectboard zoals zij dit gewend zijn, maar zodra het gaat over het ontwikkelen van de producten, gebruiken we Scrum. Je hoeft dan niet te veel concessies te doen op de Scrum-aanpak. Met deze aanpak volg je Prince2 niet helemaal volgens het boekje, maar wees eerlijk, PINO was toch al populair!

Nog een enorm voordeel aan deze middenweg. Een belangrijk aspect van Prince2 is het continu monitoren van de business case. Dit vind ik zelf een erg sterk punt van Prince2. Je moet immers niet met je project doorgaan als je ziet dat de business case die ten grondslag lag aan het project niet meer valide is. Dankzij Scrum is een nauwkeurige schatting te maken van het resterende deel van het project, tijdens het project. Met een traditioneel watervalproject is dit veel lastiger.

Welke situatie herkent u?

Edwin de Kuiper
www.nieuw-initiatief.nl

Maandelijks een artikel ontvangen over hoger rendement behalen met bestaande content? Schrijf u in: