Login / Reg                    Nieuwsbrief  |   Agenda   |   Vacatures   |   Forum   |   Advies   |   Adverteer   |   Zoek
Bron: Procesverbeteren.nl
Agile: Wendbare organisatie
Boek 'Kracht van Scrum' (deel voorkaft) feedback klant bepaalt richting software-ontwikkeling
Scrum: Stapsgewijs software ontwikkelen
Door Dr Ir Jaap van Ede, hoofdredacteur procesverbeteren.nl, 19 september 2011


Software-implementaties worden steevast te laat en te duur opgeleverd, en dan voldoet het systeem ook nog niet. Kan zo’n project niet meer agile oftewel flexibel worden aangepakt? Een beetje zoals een rugbywedstrijd, waarbij de teams regelmatig schouder aan schouder een ‘scrum’ vormen en daarna een stuk van het speelveld overbruggen?

De gelijknamige projectmanagementmethode Scrum doet precies dat.  Stapsgewijs, met voortdurende feedback van de klant, wordt in meerdere korte ‘sprintjes’ het product ontwikkeld. Functionaliteit die de klant het meest waardevol vindt wordt daarbij als eerste opgeleverd, meteen als werkend product. Alsof je al toegang krijgt tot de woonkamer van een huis in aanbouw, waarna je op basis van voortschrijdend inzicht de trap nog kunt verplaatsen.

In hun business roman “de kracht van Scrum” leggen Rini van Solingen & Eelco Rustenburg uit hoe Scrum werkt. Opvallend is de overeenkomst met Lean en lean management: waardetoevoeging staat voorop. Aan de zelfsturende ontwikkelteams wordt alleen verteld wat de software waarom moet gaan doen en voor wie.  Hoe die oplossing er onder de motorkap uitziet wordt volledig overgelaten aan hun expertise.

Een helder en vlotlezend boek waar je enthousiast van raakt! Keerzijde van de medaille is echter wel dat haken en ogen vrijwel onbesproken blijven. Eén van de auteurs, Rini van Solingen, reageert op onze bevindingen.


De implementatie van software wordt vaak aangepakt als één groot project. Eerst wordt daarbij alle gewenste functionaliteit tot in de details beschreven. Denk daarbij bijvoorbeeld aan de roemruchte ‘blauwdruk’ van een ERP-systeem, of aan nieuwe administratieve software voor de politie.

Vervolgens mag er dan niets meer aan die specificaties veranderen, totdat het systeem – vaak pas maanden of jaren later – wordt opgeleverd. De problemen met deze aanpak zijn bekend: het duurt allemaal veel langer dan verwacht, de kosten rijzen de pan uit, het systeem doet niet wat de gebruikers voor ogen hadden, en de functionaliteit is achterhaald.

Business roman
Het softwarebedrijf in de business roman ‘De kracht van Scrum’ kampt ook met dit probleem. Zij moeten een nieuw voorraadbeheersysteem ontwikkelen voor Logistrux, één van hun klanten. Ze slagen er echter maar niet in, om die software op tijd te leveren. Eén van de oorzaken is de complexiteit: het moet een generieke module worden, die ook toepasbaar zal zijn bij andere klanten met andere databases en webbrowsers.

Aan het begin van het boek raakt het geduld van Logistrux op: ze willen uiterlijk binnen drie maanden een werkende versie van het systeem zien!’

De opzet van het boek lijkt op die van de moeder aller business romans, het boek “Het Doel” van de in juni 2011 helaas overleden Eli Goldratt.

Ook in dit geval is er een gestreste manager, chief technology officer Mart Verhulst, die onder grote tijdsdruk een oplossing moet vinden. Ook is er een goeroe, genaamd Pekka. In managementromans als dit is zo’n goeroe geen man in een glad pak, verwijzend naar het feit dat je competenties niet kunt afzien aan het uiterlijk. Pekka is een forsgebouwde Fin met een paardenstaart en een voorliefde voor een flinke pint bier. Hij legt Verhulst uit hoe hij de projectmanagement methode Scrum kan toepassen.

Het Scrum proces
Bij Scrum wordt het te bouwen software-product, waarvan de eigenschappen als 'waardeverzoeken' in de product backlog staan, opgeplitst in diverse korte sprints. Dit maakt snelle feedback door de klant mogelijk.  (bron illustratie: Wikipedia)


Incrementeel
In het kort komt die methode op het volgende neer: De software die de klant wil wordt niet in één keer ontwikkeld, maar incrementeel. In stapjes dus – in Scrum-terminologie sprints - van enkele weken per keer. Steeds is het resultaat daarvan een werkend en getest product, dat alvast kan worden opgeleverd. Natuurlijk bevat dat product nog niet alle functionaliteit, maar wél datgene wat voor die klant het meeste waarde toevoegt, want daar wordt het eerste mee begonnen!

De voordelen van deze aanpak zijn evident. De klant ziet de voortgang, en kan alvast feedback geven of dit nu wel hetgene was wat ze in gedachten hadden. Op die manier kan zo nodig direct worden bijgestuurd, en wordt voorkómen dat verder wordt ontwikkeld in een verkeerde richting. De maximale hoeveelheid werk die mogelijk opnieuw gedaan moet worden heeft slechts de lengte van één sprint. Ook wordt per spint steeds duidelijker wat de klant nu precies wil, die geeft immers voortdurend feedback. Met Scrum kun je dus heel flexibel op de behoeften van de klant inspelen, ook als die in de loop van het traject veranderen.

Leren en bijsturen
Volgens de auteurs van het boek, Rini van Solingen en Eelco Rustenburg, is Scrum geïnspireerd op lean manufacturing. Inderdaad is de gelijkenis met een boek zoals Toyota Kata, elders besproken op deze site, frappant.  In dat boek weet een productieteam slechts ruwweg hoe de eindstaat van hun productieproces eruit ziet. Wat ze wél heel precies weten, is hoe dat proces er over korte tijd uit moet zien, en daar werken ze gericht naartoe. Op het moment dat die beoogde verbetering is gerealiseerd, hebben ze nieuwe kennis opgedaan over hun proces, en zijn dus beter in staat om het volgende verbetertraject af te leggen.

Toyota Kata is een methode die het mogelijk maakt om stapje-voor-stapje een berg in het donker te beklimmen, waarbij na elke stap een nieuw te beklimmen stukje van die berg zichtbaar wordt.  Het hele traject van tevoren al inplannen is weinig zinvol, want dan loop je grote kans dat je verdwaalt of doodloopt.

De manier waarop Scrum software ontwikkeling aanpakt werkt eigenlijk net zo: Omdat je in het begin toch niet precies kunt vaststellen wat de klant wil, wordt het product in stapjes (sprints) ontwikkeld, waarbij je gaandeweg leert en bijstuurt. In dit geval wordt niet alleen bijgeleerd over het proces, de Scrum-methode, maar ook over de klant.

De naam Scrum is ontleend aan het Rugby. Er is namelijk sprake van teams die steeds bijeenkomen voor evaluatie en overleg (de scrum), en die vervolgens een stukje sprinten in de richting van het doel. Daarna volgt een nieuwe evaluatie, een nieuwe planning en een nieuwe sprint. De gelijkenis met Rugby is echter niet volledig. Een Scrum bij Rugby is het spelmoment waarbij de spelers bijeendrommen en een soort duwwedstrijd aangaan met hun tegenstanders. Dit in de hoop de bal, die op dat moment in de scrum wordt gebracht, te bemachtigen. Bij Scrum in softwareontwikkeling zijn er geen tegenstanders. Je weet zeker dat je als team de bal krijgt in de vorm van een sprint backlog. Daarop staat het tussendoel dat je moet gaan bereiken.

Waardeverzoeken
Om er voor te zorgen dat de ontwikkelteams waarde toevoegen voor de klant, is er bij Scrum een product-eigenaar. Die houdt nauw contact met de klant, en vertaalt hun wensen naar gebruikersverhalen over wat de software waarom moet gaan doen en voor wie. Feitelijk zijn die user stories van de klant waardeverzoeken. Deze hebben als format:

Als <rol> wil ik <actie> doen om daarmee <waarde> te bereiken


Een voorbeeld,  vrijelijk geciteerd uit het boek:  “als gebruiker wil ik onze planning kunnen zien zonder dat ik aan een netwerk hang, zodat ik bij een klant op locatie direct deals kan afsluiten”.

Alle waardeverzoeken bij elkaar, die in de loop der tijd kunnen wijzigen, vormen de product backlog. Dit is een ruwe beschrijving van de functionaliteit die nog moet worden ontwikkeld. Het woord backlog verwijst naar een achterstand ten opzichte van de wensen van de klant.

Bovenaan de product backlog staan de zaken die op dat moment het meeste waarde kunnen toevoegen. Deze worden samengevoegd tot een sprint backlog. Dit is het werk dat het software ontwikkelteam in de eerstvolgende paar weken zal gaan doen.  Hoe ze dat werk plannen en uitvoeren wordt volledig aan hen overgelaten, op die manier worden hun competenties optimaal benut. Het team splitst het werk op in kleine brokjes van enkele uren elk. De ontwikkelaars zijn vervolgens vrij om een bepaalde taak te kiezen, en verplaatsen die dan op een bord van een to do positie naar een busy positie, en uiteindelijk naar done. Problemen met de voortgang worden dagelijks besproken in een productieoverleg.

Werkend en getest
Het eindresultaat van elke sprint is een werkend en getest product. Dit heeft dan weliswaar nog maar een deel van de gewenste functionaliteit, maar kan al wel door de klant worden uitgeprobeerd. Op die manier ontstaat snelle feedback, die wordt gebruikt om de product backlog bij te werken. Hierdoor neemt de kans dat de eerstvolgende sprint maximaal waarde toevoegt toe.

Voor wie meer wil weten over hoe Scrum werkt, is het lezen van het boek beslist een aanrader. Al na enkele uren heb je dan een prima beeld van het hoe en wat rond Scrum. Die kennis is niet alleen nuttig als je in een bedrijf werkt dat software ontwikkelt, maar ook als je ICT-oplossingen door anderen laat bouwen. Zoals wordt benadrukt in het boek, is Scrum bovendien toepasbaar bij elk te ontwikkelen product waarbij het van te voren lastig is om alle details vast te leggen. Denk bijvoorbeeld aan de bouw van een huis.

De Kracht van Scrum (voorkaft)Titel: De Kracht van Scrum
Subtitel:  Een inspirerend verhaal over een revolutionaire projectmanagementmethode


Auteurs:
  Rini van Solingen en Eelco Rustenburg.
Rini van Solingen is chief technology officer bij iSense Prowarenes en deeltijdhoogleraar Globally Distributed Software Engineering aan de TU Delft. In die laatste rol onderzoekt hij onder meer de toepassing van Scrum binnen teams waarvan de leden zich op meerdere locaties bevinden. Eelco Rustenburg is manager van de Agile Consulting & Training afdeling van Xebia.

Overige informatie:  Uitgeverij Pearson Education Benelux, 144 pagina’s, eerste druk juni 2010. Het boek is inmiddels vertaald in het Engels, Duits en Frans. De Nederlandstalige versie is te bestellen bij Bol.com

Pro’s en Con’s:
++ Op heldere en bondige wijze wordt in romanvorm verteld wat Scrum is, aan de hand van een softwarebedrijf dat deze methode invoert.

+ Scrum is niet alleen interessant voor softwarebedrijven, maar ook voor bedrijven die ICT applicaties laten ontwikkelen. Daarnaast is de methode toepasbaar bij de ontwikkeling van alles, waarbij het onmogelijk is om het eindproduct vooraf compleet te definiëren.

+ Vanuit de business is er een enorme behoefte aan flexibele software. Dit boek reikt software-ontwikkelaars een methode aan om in die behoefte te voorzien.

+- Een korte introductie over de historie van Scrum ontbreekt. Voor wie het weten wil: Het basisidee om software te laten ontwikkelen door een cross-functioneel team, met tussentijdse review- en overlegfases (zoals de vorming van een Scrum op het rugbyveld), werd al in 1986 geopperd door Hirotaka Takeuchi en Ikujiro Ninaka.  Later werd de methode verder uitontwikkeld door diverse personen, waaronder Ken Schwaber en Jeff Sunderland. Deze laatste persoon schreef ook een voorwoord in het boek “De Kracht van Scrum”.  

- Haken en ogen rond de toepassing van Scrum komen in het boek nauwelijks aan bod.

- In het boek wordt een relatie gelegd tussen Scrum en duurzaamheid (stroombesparing e.d.), ik vind dat een beetje opportunistisch.


Overeenkomsten Lean

Zoals eerder reeds aangestipt zijn er veel overeenkomsten tussen Scrum en Lean. Tijdens het lezen van het boek heb ik speciaal daarop gelet. Hieronder staan die overeenkomsten samengevat:

  1. Focus op maximale waardetoevoeging: bij elke sprint wordt na overleg met de klant steeds datgene aan het product toegevoegd dat op dat moment het meeste waarde toevoegt.
  2. De software-ontwikkelaars kennen het (nog vage) einddoel zodat ze op de hoogte zijn van de missie. Tijdens elke sprint werken ze echter toe naar zeer concrete tussendoelen (Toyota Kata methode). Voortschrijdend inzicht, na feedback door de klant, bepaalt daarna het vervolg.
  3. De software-ontwikkelaars wordt alleen verteld wat ze moeten doen, het hoe wordt aan hen overgelaten.
  4. Er is sprake van werken in multidisciplinaire teams, die zelf verantwoordelijk zijn voor hun werkproces (eigenaarschap en zelfsturing)
  5. Er wordt gewerkt in kleine stapjes (de sprints) waarbij het tussenresultaat wordt gecheckt en geborgd. (plan-do-check-act)
  6. Halffabricaten worden meteen getest, om stapeling van fouten te voorkómen
Leren door experimenteren: de fako backends van Intuit
In het artikel “The Innovation Catalysts” (Harvard Business Review, juni ’11) pleit Roger Martin, dean van de Rotman School of Management van de Universiteit van Toronto, voor het betrekken van het lagere management bij innovatie. Dit in nauw contact met de klant en daarbij ondersteund door innovatie coaches. Als lichtend voorbeeld wordt Intuit besproken. Dit is een Amerikaans software bedrijf dat financiële software ontwikkelt, onder meer voor belastingaangiften.

Via een proces dat Design for Delight heet, detecteren managers van Intuit pijnpunten bij (potentiële) klanten via field research, en brainstormen vervolgens over oplossingen. Na die ‘painstorms’ worden er razendsnel prototypes ontwikkeld om te onderzoeken of dit nu de oplossing is waar de klant op zit te wachten. Leren door experimenteren dus!

Hoewel Scrum wel binnen Intuit wordt toegepast, wordt deze methode in het artikel van Martin niet genoemd. De overeenkomst is niettemin duidelijk: Nieuwe softwareproducten worden zo snel mogelijk uitgetest door klanten, zodat ze kunnen worden aangepast op hun behoeften. In de Inuit-case zijn dit echter geen klanten waarvoor je software in opdracht maakt, maar consumenten waar nieuwe producten voor worden ontwikkeld.

Intrigerend is dat een product niet eens gereed hoeft te zijn om te worden getest, als een potentiële klant maar denkt dat dit het geval is! Een belangrijk pijnpunt voor arme Indiase boeren bleek onverkochte voorraad bederfelijke producten. Voor hen ontwikkelde Intuit Mobile Bazaar, een eenvoudig tekstgebaseerd marktplaatssysteem. Binnen 7 weken kon dit systeem al worden getest. Om dat te doen, waren sommige delen die later duizenden regels code vergden, op dat moment echter nog niet echt. Fako backends, zo is dit inmiddels gaan heten. Achter de schermen handelde een mens de transacties af!


Enthousiasmeren
Het doel van de business-roman ‘De kracht van Scrum’ is om die methode kort en duidelijk uit te leggen. Het is de bedoeling dat je geïnteresseerd raakt. Daarna is er voldoende vakliteratuur en consultancy beschikbaar om je verder te helpen.  In dat doel – enthousiasmeren voor Scrum – zijn de auteurs prima geslaagd.

Er is echter ook een keerzijde: in hun enthousiasme slaan de schrijvers een beetje door. Het lijkt me onwaarschijnlijk dat het verhaal in het boek op een ware geschiedenis berust. Zo is de werkvloer na een korte introductie meteen vrijwel unaniem enthousiast om met Scrum aan de slag te gaan! Zou dat echt zo zijn, als je zegt dat je voortaan via tussensprints binnen vastgestelde periodes geplande doelen wilt gaan halen?

Ik denk dat er in de praktijk heel veel verandermanagement nodig is, om uit te leggen dat Scrum niet harder maar slimmer werken betekent, en dat het team eigenaar blijft van zijn eigen werkproces. Ik denk dat Scrum heel goed kan werken in een team dat nu ook al goed en harmonieus samenwerkt, maar wat als dat niet het geval is? De zeer frequente cycli van terugkoppeling tijdens het dagelijkse overleg zullen de sfeer dan niet verbeteren denk ik, hoewel je wellicht zou kunnen stellen dat op die manier latent aanwezige problemen slechts boven water komen.

Tot slot nog een paar vragen aan de auteurs die in mij opkwamen, en die in het kader hieronder door Rini Van Solingen worden beantwoord:

  1. Bij Scrum is de scope van het totale software-project van tevoren niet bekend. Dit suggereert dat je de klant een factuur stuurt op basis van aantal gewerkte uren, maar hoe kan die klant de kosten dan in de hand houden? Met name als die klant de broncode niet krijgt, betekent dit qua prijs een zeer onzeker traject. Je krijgt weliswaar steeds een werkend tussenproduct, maar als je door te hoog oplopende kosten alsnog moet switchen naar een andere partij ben je al je geld kwijt.

  2. Tijdens sprints kunnen ontwikkelaars zelf kiezen aan welke deeltaken ze willen werken. Hoe voorkom je daarbij onderlinge strijd om de leukste taken?

  3. Na elke sprint wordt een werkend tussenproduct opgeleverd, via een grotendeels geautomatiseerde test & build (=code omzetten in werkend product) procedure. Die procedure moet je dus steeds bijwerken als het product verder wordt uitgebouwd. Is dit wel een haalbare kaart en zo ja, wat kost het om dit te doen?

Ik kan mij overigens wel voorstellen dat dit soort zaken niet aan de orde kunnen komen in een boek dat vooral is bedoeld om mensen enthousiast te maken voor Scrum.

> zie ook: Flow+ maakt Achmea digitaal én Lean

Reactie Rini van Solingen
Scrum stuurt direct op waardecreatie en maakt problemen transparant


Rini van SolingenHartelijk dank voor de review van ons boek: een gedegen stukje werk! Ik ben blij met de positieve ontvangst. De punten van kritiek zijn volledig terecht, maar die zijn het resultaat van bewuste keuzes. Hieronder een paar reacties:

Reviewer: “Hoe kan de klant de kosten in de hand houden? Met name als die klant de broncode niet krijgt, betekent Scrum qua prijs een zeer onzeker traject”  

Reactie RvS: De scope van een softwareproject kan net zo duidelijk zijn als bij een meer traditionele aanpak. Als je met Scrum begint zonder een beeld te hebben van wat je nodig hebt, ja, dan is het niet helder. Dat heeft echter niets met Scrum te maken. Ook als je het einddoel van te voren precies kent, zoals in het traditionele project management, kun je prima met Scrum werken. Scrum geeft je echter een extra mogelijkheid: bijsturen op basis van voortschrijdend inzicht.
Het idee om de scope van tevoren te bevriezen om de waarde van het eindproduct zeker te stellen, is geen goed idee. Scrum zorgt ervoor dat de klant steeds een gereed (tussen)product krijgt, waarbij de meest waardevolle functionaliteit steeds als eerste wordt opgeleverd, terwijl je in het vervolgtraject extra waarde kunt creëren door de scope aan te passen.
Bij de traditionele projectaanpak wordt indirect gestuurd op het leveren van waarde, door de scope, de tijd en de kosten te proberen te bevriezen. Scrum stuurt direct op het waardecreatie, via het voortdurend beschikbaar zijn van een werkend product, waarin de meest waardevolle zaken het eerste worden ingebouwd.
 
Reviewer: “Tijdens sprints kunnen ontwikkelaars zelf kiezen aan welke deeltaken ze willen werken. Hoe voorkom je strijd om de leukste taken?
 
Reactie RvS: Ook binnen een sprint zijn de taken geprioriteerd op waarde, dus de volgorde daarvan staat redelijk vast. Strijd om de leukste taken komt niet vaak voor maar áls het gebeurt is het een signaal. De groep softwareontwikkelaars is dan geen team, maar een elftal waarin iedereen wil pingelen en zelf scoren. Ook bij de traditionele aanpak is dat onwenselijk, een dergelijke mindset werkt immers contraproductief, maar in dat geval blijft het onzichtbaar. Scrum maakt deze en andere problemen transparant en inzichtelijk. Dat is juist goed, want dan kun je ze één voor één aanpakken.

Reviewer: “Een grotendeels geautomatiseerde test & built procedure, die je steeds moet bijwerken. Kan dit wel, en wat kost het om dit te doen?”

Reactie RvS:  In de praktijk valt dit mee. Bovendien moet je het uiteindelijk toch doen. Je trekt het alleen naar voren en je doet het vaker, maar dan geautomatiseerd. Op die manier creëer je snelle feedback (het lukt wel of niet) en kun je indien nodig fouten meteen corrigeren. Bovendien is het veel gemakkelijker om de oorzaak van problemen te vinden als je heel vaak test, het liefst elke keer als er maar één klein dingetje is veranderd. Test je pas aan het eind, dan is de kans groot dat het product niet blijkt te werken, én dat je geen idee hebt waaraan dat ligt.
Wij verzorgen veel trainingen en coaching trajecten. Met behulp van simulaties laten we dan zien dat hoe korter de feedback-loop is, des te effectiever je wordt. Je gaat dus slimmer werken, niet harder. Zelfs al je van tevoren nog niet helemaal overtuigd bent is dat geen probleem. Om met Johan Cruijff te spreken: "Je gaat het pas zien als je het door hebt". Begin dus gewoon met Scrum, dan wordt het vanzelf steeds duidelijker.



Hulp nodig bij de implementatie van Agile?

Verwijzen naar dit artikel op internet?
Gebruik als link: https://www.procesverbeteren.nl/Agile/Scrum.php

LeanDirectManagement Mindfucks