Scrum is niet voor watjes

Scrum is de ‘de facto’ software ontwikkelmethodiek van dit moment. Toch maken we vaak mee dat Scrum projecten niet lopen zoals gewenst. Eén van de oorzaken kan zijn dat niet wordt voldaan aan de hoge eisen die Scrum aan het team stelt.

Iets over de context

MetaFactory bouwt software. Maar een beetje anders.
MetaFactory heeft tooling ontwikkeld waarmee we kunnen metaprogrammeren. Wat betekent dat we het ontwikkelproces zélf kunnen automatiseren. En dat leidt, aantoonbaar, tot een veel hogere productiviteit en kwaliteit dan bij vergelijkbare projecten die handmatig worden geprogrammeerd. We hebben een crew met eersteklas java ontwikkelaars, die gedeeltelijk aan interne projecten en gedeeltelijk bij projecten van klanten werken. Zowel intern als extern werken ze volgens Scrum.

Wat opvalt bij veel Scrum projecten bij onze klanten

• De ontwikkelaars hebben het over het algemeen naar hun zin.
• En kunnen dingen doen omdat het leuk is: “Laten we Kubernetes proberen.”
• Er is weinig aandacht voor Velocity, ofwel productiviteit.
• Als er al aandacht is voor softwarekwaliteit, gaat dat meestal niet veel verder dan de code door SonarQube halen.
• Er worden braaf stand-ups en retro’s gehouden, maar er is zelden sprake van kritische introspectie.
• Soms biedt onduidelijkheid over de rollen binnen het team ruimte voor ambities, die het project geen goed doen.
• Bij grote organisaties als banken en overheid zien we dat kwaliteit zelden expliciet gemaakt wordt en productiviteit nauwelijks gemeten.

Het Team, daar draait het om

Het mooie van Scrum is de empowerment van het team. Het team heeft een grote autonomie. Het is goed dat gedetailleerd ontwerp en programmeren bij elkaar gebracht worden, liefst bij dezelfde ontwikkelaar. Als je [1] leest wordt ook uit zijn voorbeelden duidelijk dat de auteur een team in gedachten heeft als het eerste van Hamster: een team zonder hiërarchie met echte vakmensen die kritisch zijn, geen boodschap hebben aan hobbyisme en vooral: presteren.

Uit [1]:

(…) It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. (…)

Een team waarvoor je de leden het liefst zelf kan selecteren. Maar meestal kan je niet kiezen en doen er ook onervaren ontwikkelaars mee. Wat als een teamlid onevenredig veel oog heeft voor het leren en uitproberen van nieuwe dingen omdat het leuk is en goed op zijn of haar CV staat in plaats van het hierboven genoemde Product Goal?

De Scrum Master

Daar werd de Scrum Master voor bedacht.

Uit [1]:

(…) I realized we needed someone whose job it was to make sure the process itself was effective. Not a manager – more of a servant-leader, something between a team captain and a coach. (…)

De rol van de Scrum Master is dus vooral adviserend en begeleidend.
Er wordt niet aan de autonomie van het team getornd.

De Product Owner

Een heel team laten beslissen wat het beste is voor de klant, gaat niet werken. Daarom is het team versterkt met de Product Owner.

Uit [2]:

(…) The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. (…)
en
(…) The Product Owner decides what the work should be. He or she owns the Backlog, what’s on it, and, most important, what order it’s in. (…)

Het Team

Het Scrum team heeft de opdracht om aan het eind van elke sprint een waardevol en bruikbaar increment op te leveren. Dus zij moeten het doen:

• Ontwikkelaars (inclusief Testers en Ops),
  zij in het team die betrokken zijn bij het creëren van elk aspect van een bruikbaar increment bij iedere Sprint.
• De Product Owner,
  die ervoor zorgt dat het team een maximum aan waarde (business value) produceert en de eigenaar en beheerder is van de Backlog.
• De Scrum Master,
  die borgt dat gewerkt wordt volgens Scrum zoals beschreven in de Scrum Guide ([2]) en verantwoordelijk is voor de effectiviteit van het Scrum team.
  (…) helping the team to figure out how to do the work better (…)

Maar wat nou als het team niet functioneert als het eerste team van Hamster?
“Tja” zegt de Scrum ‘believer’ dan, “dan is je team gewoon immature!” “Dan moet de Scrum Master dat oplossen.”

Moeilijke missie

Als het de Scrum Master niet lukt om een team op te bouwen dat slagvaardig is, open staat voor nieuwe ideeën (maar daarin niet doorschiet), collegiaal is én kritisch, dan heeft hij een groot probleem.
Want vanuit de definitie van zijn taken heeft hij weinig momentum om het team naar zijn/haar hand te zetten.

Eigenlijk stuurt Scrum de Scrum Master, maar ook de Product Owner op een moeilijke missie.
Want de Scrum Master heeft de opdracht om een continue verbetering van de effectiviteit van het proces te stimuleren. Maar hoe je effectiviteit zou kunnen meten en daarop sturen, blijft ongewis.
Wat ook niet meehelpt is, dat softwareontwikkelaars ook maar mensen zijn. Die het soms wel lekker vinden om hun eigen dingetje te doen en liever niet teveel op hun vel gezeten worden door een projectleider die voortdurend de voortgang van het project in de gaten houdt.
Zo’n team is moeilijk in beweging te krijgen en te houden.

En de Product Owner zit in een dergelijk schuitje. Die moet sturen op Business value.

Uit 3:

(…) 6. Don’t think that you can ‘determine’ value upfront
What many of us Product Owners do, is focus a lot on ‘determining’ the value of a Product Backlog Item (in Dutch: ‘waarde bepalen’). This is such a shame in my eyes! There is no way you can ‘determine’ the value of a Product Backlog Item upfront! (…)

Nou, Product Owner, ga daar maar aanstaan! Er wordt je gevraagd een proces te sturen op iets, dat je pas achteraf (hopelijk) kan meten. Als dit klopt haalt dat de primaire verantwoordelijkheid van de Product Owner onderuit.

Hoge eisen

Dus waar het op neerkomt is dat, als je met Scrum een project doet, zonder de inrichting van extra projectmanagement elementen, je enorm afhankelijk bent van de vakbekwaamheid, intelligentie, teamgeest en inzet van de afzonderlijke teamleden.
Daarom eist Scrum in [2]:

(…)

Successful use of Scrum depends on people becoming more proficient in living five values:

Commitment, Focus, Openness, Respect, and Courage

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems. (…)

Conclusie

Scrum geeft het Team veel ruimte en autonomie.
Dat kan echter alleen als er hoge eisen gesteld worden aan de teamleden.
Scrum werkt goed met mensen die hoog scoren op bovengenoemde kwalificaties.
Zoals die in het eerste team van Hamster.
Dat zijn zeker geen watjes.

Mocht het zo zijn dat je team niet helemaal als het dreamteam van Sutherland is samengesteld of functioneert, dan is het raadzaam om de beheersbaarheid van het project te versterken met bijvoorbeeld:

• Een software architect of lead developer in het team die de technische lijnen uitzet en bewaakt,
• De Product Owner promoveren tot projectleider, die verantwoordelijk is voor het op te leveren eindproduct binnen een afgesproken budget en tijd,
• Het schatten van de omvang van het werk in uren, zodat voortgang kan worden gemeten en werkelijke productiviteit kan worden bepaald.

Daarover later meer.

Zie ook: Ook Scrum projecten begroten in uren

Referenties

[1]	SCRUM   The Art of Doing Twice the Work in Half the Time Jeff Sutherland 2014 ISBN 978-1-847-94110-7
[2]	The Scrum Guide   The Definitive Guide to Scrum: The Rules of the Game Ken Schwaber & Jeff Sutherland 2020-Scrum-Guide-US.pdf
[3]	Scrum.org The Home of Scrum https://www.scrum.org/resources/blog/10-tips-product-owners-business-value