- 2012/09/01
- Nederlands
- Narrative Geïntegreerd Agile
Zwart-Wit, zonder Grijs!¶
Agile is vrij informeel qua processen. Met weinig absolute regels die aangeven wat goed en wat
fout is. Agile kent veel meer kleuren dan wit en zwart. Immers tussen spierwit en pikzwart
zitten heel veel tinten grijs! Met Geïntegreerd Agile proberen we continue te verbeteren. Een
sprint die beter gaat dan de vorige is goed. Maar wat nu goed genoeg is, is over een halfjaar
verouderd.
Dit maakt het invoeren lastig: als niets fout is, hoe kun je het goede dan leren?
Geïntegreerd Agile is ‘anders’; het zit vooral tussen de oren. Dat anders is moeilijk te ervaren,
zonder jarenlange ervaring. Maar door de verschillen met de traditionele, ‘V-model’ processen te
benadrukken kunnen veel mensen het in de praktijk vrij snel leren. En als we dan ook nog sterk
overdrijven kunnen we een zwart-witte wereld schetsen.
Al omvat de Agile wereld veel grijs, zo’n overdreven zwart-wit benadering helpt de meeste valkuilen
te vermijden,
Hiermee kunnen mensen heel snel een redelijk beeld krijgen van wat (meestal) goed en (meestal) fout
is. Maar bedenk dat zodra je voldoende agile ervaring hebt elk zwart toch vooral een donkere
grijs-tint is. En elke wit vooral lichtgrijs.
Ditzelfde geldt voor de beschreven valkuilen. Probeer die te vermijden, zeker in het begin. Na een
paar jaar agile ervaring blijken die kuilen veel minder diep. Maar om het agile concept te leren is
het verstandig ze voorlopig als fout te beschouwen.
Wat is «fout»?¶
Omdat fouten veel leuker en leerzamer zijn dan zaken die goed gaan, geeft ik vooral die aandacht. De volgorde is vrij willekeurige en zeker niet volledig.
Testteams¶
Bij ontwikkelteams is scrum al vrij lang populair. En ook test- organisaties gaan mee inmiddels in
de agile-flow. Waarbij je vaak specifieke ‘agile’ testteams ziet ontstaan. Dit is fout!
Elk team moet minimaal bestaan uit bouwers en testers. De gewenste, verhoogde productiviteit
ontstaat door samen te werken. Er is (vrijwel) nooit een goede reden om een team te hebben dat
uitsluitend test.
De term ontwikkelteam is niet persé fout. In sommige branches omvat “(software) ontwikkelen” namelijk alle fases uit het V-model: van idee tot werkend product. En dan is het logisch om het team dat al die taken doet een ‘ontwikkelteam’ te noemen. Het is dan een Geïntegreerd Agile ontwikkelteam; met programmeurs en met testers.
NB Als men hyper-productieve-teams wil moeten ook de andere ‘lagen’ uit het V-model in het team vertegenwoordigd worden. Om te starten is dat niet nodig.
ScrumMaster & ProjectLeider¶
Een traditioneel project kent de rol ‘projectleider’ en/of ‘-manager’; die besturen het project. In een scrum-project doet de ScrumMaster dat. Of, als de projecten groter worden een (virtueel) team van ScrumMasters. Een scrum-project dat zowel een ScrumMaster als een projectleider heeft is fout!
Een scrum project wordt anders bestuurd; er ligt meer verantwoordelijkheid in het team. Maar de
ScrumMaster heeft de verantwoordelijkheid om te zorgen dat het werkt. Zowel ‘intern’ (in
het team), als ‘extern’. Dat doet hij samen met het team. Een scrum-project dat lekker loopt heeft
nauwelijks aandacht nodig van de ScrumMaster.
De dagelijkse besturing gaat vooral middels de daily scrum, het ScrumBoard en de (sprint-)
BurnDown. Zeker bij een nieuw team moet de ScrumMaster daar tijd aan besteden. Maar
een goed team kan dat prima zonder de aanwezigheid van de ScrumMaster.
In “Geïntegreerd Agile” bestaat een informele rol Quarterback, die op een natuurlijke
manier deze dagelijkse zaken regelt. Dat is een gewoon teamlid, die dit erbij doet.
Soms herken ik die rol in ‘scrum-teams’, maar wordt die persoon “scrummaster” genoemd. En is er een
projectleider die andere zaken, vaak op een niet agile manier regelt. Dat is een duidelijk teken:
ga er maar vanuit dat het fout is.
Hyper-flexibel¶
Agile teams zijn ‘wendbaar’; dit is de letterlijke vertaling van agile. En kunnen daardoor flexibel
omgaan met nieuwe eisen, voortschrijdend inzicht etc.
Maar niet elke gril hoeft direct gevold te worden. Een project dat nauwelijks sturing kent, is
ook flexibel. Zo’n JBF-project noemt zichzelf soms ‘scrum’; maar dat is zeer waarschijnlijk een
foute voorstelling van zaken.
Sommige schattingen geven aan dat 90%(!) van alle projecten die zich scrum en/of agile noemen, dat eigenlijk niet zijn.Het is vrij gemakkelijk om te ontdekken of een project tot die 90% of de resterende 10% behoort. Namelijk door jezelf de vraag te stellen: “Gaat het beter?”.
Het invoeren van agile en of scrum is (vrijwel) nooit het doel; maar een middel om het project te
verbeteren. Als bovenstaande vraag negatief beantwoord wordt, is dat doel zeker niet
gehaald. Helaas zit je dan waarschijnlijk ook bij die 90%.
Het goede nieuws is: Het invoeren van “Geïntegreerd Agile” kan (alsnog) helpen!
Alleen korte termijn focus¶
Scrum formuleert veel ‘korte termijn doelstellingen’; dat alleen helpt al. Zo geeft de daily-scrum
geeft inzicht in wat er vandaag moet gebeuren. En de sprint geeft focus om wat komende weken
belangrijk is. Maar een project heeft ook lange termijn doelstellingen. Zo wil de klant of de
gebruiker graag weten wanneer ‘alles’ af is. Dat raakt nogal eens op de achtergrond.
Maar een project dat geen inzicht kan geven over wat er over een kwartaal, of een jaar ongeveer
opgeleverd gaat worden, doet het fout!
Vaak zie ik wel een sprint-BurnDown, maar geen product-BurnDown; noch een ‘Business Added Value’-grafiek, zoals “Geïntegreerd Agile” die gebruikt. Beide grafieken gaan over het hele project; zonder (een van die) grafieken is er waarschijnlijk geen focus, geen controlle en geen sturing over op de langere termijn. En dat is fout
Deze lange termijn grafiek is voor de meeste teamleden minder belangrijk. En wordt daardoor vaak vergeten. Waarmee vaak ook de aandacht voor tactische en strategische doelen vergeten wordt. Dan is er dus ook geen zicht op verbeteringen; in de praktijk is die dan vaak negatief.
Notitie
De Business Added Value (of kortweg: BAV) heeft diverse voordelen boven
een burndown. Zo staat hij ‘op zijn kop’; voor managers is een lijn die omhoog
loopt meteen veel beter dan een die omlaag gaat. Ook kunnen aan dit vorm-verschil meteen
zien of het één sprint of het gehele product omvat.
Tot slot geeft de BAV ook de vrijheid project-omvang te visualiseren.
Disqus
Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.