• 2012/09/01
  • ALbert Mietus
  • 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’.

comments powered by Disqus