Scrum

Scrum en Innovatie

Op 4 juli was het thema in ons Agile cafe Scrum & Architectuur. Ervaren Eindhovense Scrum facilitators openden de avond met een ludieke workshop. We kwamen tot hele verrassende conclusies over Scrum. Niet verwonderlijk, want in klassieke ICT wereld botsen Scrum en Architectuur veel. Wij denken in oplossingen, zoals ook in deze volgende tekst: de impact van Scrum zal steeds meer toenemen en klassieke architectuur moet dus veranderen.

Scrum: best lastig in praktijk!

Scrum is een groeiende trend in de ICT, ook vanwege de laagdrempeligheid. Certified Scrum Master is de meest gewilde ICT training op dit moment: na een intensieve training van twee dagen mag je officieel Scrum projecten faciliteren. Echter, sprookjes bestaan niet: echt begrip van Agile werkt natuurlijk veel sterker dan twee dagen Scrum theoriebasis. Scrum is net als voetbal: de theorie snapt iedereen, maar in praktijk komt er vaak veel meer bij kijken, voordat je een echte professional bent!

Wat is Scrum simpelweg? (zie de officiele handleiding van 15 pagina's)

Scrum is de meestgebruikte Agile projectaanpak. Het is ontwikkeld door ondertekenaars van het Agile Manifesto. Scrum technieken helpen bij het Agile werken, bij het vakwerk dat we moeten nastreven. Scrum ziet ICT als een zichtbaar gezamenlijk teamspel met hoge snelheid. Samen ben je nu eenmaal veel sterker. Ook al is Scrum een stap vooruit, het is geen wondermiddel: een project goed runnen blijft vakwerk.

Wens: goede architectuur

Een van de probleemgebieden van Scrum is Architectuur. Scrum en Architectuur hebben iets tegenstrijdigs. Scrum is de standaard Agile projectmethode, welke regelmatige opleveringen verwacht (korte termijn doelen) en onder Architectuur wordt verstaan duurzame fundering (lange termijn middelen), net als bij huizen. Beiden zijn heel belangrijk, goede resultaten blijven tonen en tegelijkertijd op lange termijn goede fundering leveren. Toch kennen we de prioriteit voor teams: eerst de korte termijn zekerheid en daarna pas lange termijn. Helaas is dus voor architectuur beperktere ruimte, betekent niet dat we niet het essentiele moeten doen. Wat is voor de engineer essentiele architectuur in Scrum?

Probleem: Scrum en Architectuur gaan niet vanzelf samen.

Scrum legt terecht veel druk op het regelmatig opleveren. Door het vele snelle opleveren van Scrum kan de kwaliteit van de softwarebasis in geding komen. De hoge snelheid vermindert kwaliteit. Maar wat is kwaliteit? Het opleveren van minder documentatie, wil niet zeggen dat dit niet op een latere termijn niet veel beter kan worden ingehaald. Regelmatig opleveren is goed, als dit niet ten koste gaat van software kwaliteit.

Architectuur legt soms veel nadruk op lange termijn zaken, helaas werkt dit bij Scrum averrechts. De volledigheid in detail in Architectuur documentatie, dat is in Scrum alleen maar lastig om voor iedereen consistent te houden: werkende software is veel simpeler dan honderd afspraken. En al bij de eerste Scrums volgens de volledig beoogde eind architectuur willen ontwikkelen, dat is heel veel overhead: idealiter evoluert architectuur lichtjes mee met het product, want architectuur is geen doel naar een middel (voor werkende software etc).

Goede architectuur ondersteunt de Scrum doelgericht. Het gaat niet om kwaliteit in de middelen (als documentatie), maar wat je ermee doet. Het doel heiligt immers de middelen. Het gaat om de essentiele kwaliteit in bereikte doelen: de werkende software zelf moet van goede kwaliteit zijn. De vakman zal bewust goede architectuurprincipes doelgericht toepassen, goede software realiseren en houdt zodoende op lange termijn een goede architectuur over.

Wil het Scrum team in de toekomstige code sprints nog altijd Agile/doelgericht blijven en dan moet de architectuur van vandaag daarvoor zorgen. Wat waren de 4 doelen volgens het Agile Manifesto? Interactieve Mensen, Werkende Software, Cooperatieve Klanten en Begripvolle Verandering. Dus een Scrum Architectuur is een software basis: die voor teamleden begrijpelijk is, die werkende software biedt, die de klant blijft interesseren en waarmee je krachtig kunt blijven anticiperen. Dit klinkt als een krachtige codebase!

Een goede oplossing: een kwalitatief hoge codebase

Voor Scrum is een kwalitatief hoge codebase nodig. Dit geeft een basis waardoor een engineering team doelgericht kan blijven werken, dwz Agile zijn op de lange termijn. Goede code geeft Agility: eenvoudig te doorzien, ook dankzij voldoende tests en automatische promotie procedures. Slechte code zorgt ervoor dat het team niet meer Agile is op de lange termijn. Bijvoorbeeld wanneer een collega niets met je code qua mogelijkheden kan (bijvoorbeeld omdat er geen tests bij zitten) en hierdoor fouten in de code brengt. In een goede codebase met ondersteunende tooling zit volop eenvoudige mogelijkheden en is van clean code tot continuous integration gewoon vakwerk!

Natuurlijk zijn er nog veel meer ideeen die bijdragen aan krachtige Scrum Architectuur oplossingen. Kom ze delen op de volgende bijeenkomst van ASC Eindhoven! ;-)

View more presentations from Jurgen Appelo