Afgelopen Drupaljam presenteerd Anton Vanhoucke 'Get Agile! Scrum, ook in Strategie en Design', daarin gaf hij een aantal interessante inzichten hoe Agile Scrum kan werken, maar ook wat de valkuilen zijn.Zo noemde hij onder andere:
- Een vastgeklikte scope
- Bureaucratie
- Micromanagement
- Democratie
- Van links naar rechts gaan
- Wispelturigheid
Een aanleiding om meer valkuilen van scrum eens op te sommen:
Lucius loves Scrum
Deze project methode haalt het meeste uit mensen, waardoor een grote winst wordt behaald in productiviteit en effectiviteit van een project. Maar je zult selectief moeten zijn in de mensen in je scrum team. Zo schrijft David Taber, hij vervolgt:
Scrum projecten draaien om hechte samenwerking en snelle feedback cirkels. Als het werkt, dan zullen de verwachtingen van de projectleden dicht liggen bij project opleveringen en zal er weinig tijd verkwist worden door nice-to-haves of perfectionisme. Scrum goed uitgevoerd is prachtig en voordelig om mee te beginnen.
Kwaliteit scrum teamleden
De scrum productiviteit hangt af van de kwaliteit van teamleden. Teamleden moeten een hoog IQ, EQ en veel focus hebben. Wanneer je een teamlid betrekt die niet voldoende expertise heeft, niet genoeg passie of niet besluitvaardig is dan zal het team snel afbrokkelen.
Scrum draait verder om flexibiliteit en snelle iteraties, daarom zou je mensen die hier niet mee om kunnen gaan zo snel mogelijk moeten vervangen. Het liefst al tijdens sprint 0, de project kick-off. Maar hoe dan?
4 grote valkuilen bij scrum teams
Een goed ding van karakter problemen bij een teamlid, is dat ze meestal niet doorhebben dat ze het hebben en dus direct zichtbaar voor iedereen. Je moet alleen weten waar je moet kijken, in de meeste scrum teams zijn 4 gebieden die je kunt inspecteren: teamleden, ontwikkelaars, consultants en management. Hierbij ~40 dingen in willekeurige volgorde, waarbij een rode vlag omhoog zou moeten gaan:
#1) Gebruikers die...:
- Niet betrokken, geïnteresseerd of gemotiveerd zijn. Die het te druk hebben met hun standaard taken om diep betrokken te zijn.
- Niet bereid zijn om problemen te omarmen, pro-actief te zijn op taken; die zich niet willen commiteren aan iets (voornamelijk vereisten, validatie en test scripts)
- Zien risico, verandering en leren als een probleem, niet als ingrediënt.
- Gaan pro-actief actie ondernemen en deadlines halen uit de weg.
- Geven snel andere mensen de schuld en besteden tijd aan CYA (Cover Your Ass) activiteiten
- Zijn uitgesproken over wat ze willen, maar onwetend over software ontwikkeling en de (indirecte) kosten die ermee gepaard gaan.
- Lijken vertraging en dubbelzinnigheid aan elke beslissing toe te voegen. Hakken geen knopen door.
- Overleggen vullen met onzinnige bullsh*t, wollig praten over issues die al lang afgebakend zijn.
- Geen actie ondernemen als informatie niet compleet is. Ze kiezen één ding wat meest voor de hand lijkt te liggen en geven hun mening niet, ze spelen CYA.
- ADD hebben, of niet goed kunnen schrijven en lezen.
#2) Ontwikkelaars die...:
- Niet bereid zijn om door de zure appel heen te bijten
- Perfectionistisch zijn
- Over-gefocust zijn op software architectuur en duurzaamheid
- Constant kritiek proberen te vermijden in plaats van dingen af zien te krijgen
- Liever eerst code schrijven en dan vragen stellen
- Slechte communicatie skills hebben, voornamelijk bij stress
- Geen empatie hebben voor gebruikers
- Geen project management skills hebben, of een seagull manager hebben
- Bang zijn of besluiteloos
- Niet kunnen luisteren
#3) Consulants die...:
- 'Bieden om te winnen' -gedrag vertonen, of te graag een deal willen winnen om een account te behouden
- Te flexibel zijn, te toenaderend, commitments maken die ze niet kunnen naleven
- Slecht nieuws niet snel of effectief genoeg kunnen communiceren
- Geen nee kunnen zeggen, of zich er niet aan houden
- Niet bereid zijn leiding te nemen in bepaalde situaties
- Niet kunnen luisteren
- Niet bereid zijn om dezelfde dag nog een antwoord te geven op vragen van een klant
- Altijd 'ja' zeggen. 'Empty suits' gedrag
- Nadruk leggen op snelheid van code ontwikkeling, niet op bouwen juiste functies
- Niet op locatie willen komen
4) Management dat...:
- Niet bereid is actief mee te doen in een project
- Micro-managed
- Meer gefocust is op budgets dan product waarde
- ADD of geheugen problemen hebben.
- Iemand naar voren schuiven die geen ervaring heeft en het ook niet wil leren
- Een nare sfeer hanteren van interne competitie op budgets en opleveringen
- Mensen verantwoordelijk houden, maar ze geen controle geven op de benodigde resources.
- Angst gebruiken als management tool en publiekelijke straffen hanteren.
- Niet onvoorwaardelijk durven te prioriteren en realistische deadlines op te zetten.
- Tijdens contract onderhandeling irreële voorwaarden willen hanteren.
Wrap up
Er is geen manier om concreet te meten of een persoon in een scrum team past, het komt voornamelijk aan op 'gut feeling'. Maar door bovenstaande issues in je achterhoofd te houden, kan je hopelijk snel detecteren en vervangen.
