Tagcloud

Overzicht blog

5 tips voor betere teamschattingen

missing-the-target-480x238Het agile werken draait niet om voorspelbaarheid maar om de resultaten en de impact daarvan. Toch kunnen we als team een hoop doen om de voorspelbaarheid te verbeteren. En daar hebben we allemaal baat bij. Een van de factoren die voorspelbaarheid beïnvloedt is de mate waarin een team in staat is op een consistente manier werk te schatten. Hoe kunnen we onze schattingen als team verbeteren? Hieronder een paar tips.

 

Schat relatief, niet absoluut!

Een team schat hun werk in omvang (bijvoorbeeld story points) en niet in duur. Het streven is daarbij niet om heel precies te zijn, maar wel accuraat genoeg. Van een team wordt verwacht dat ze werk in omvang schatten relatief aan ander werk. In praktijk zie ik ze dat vaak niet doen. Okay, over tijd kan je als team best een redelijk goed gevoel ontwikkelen voor relatieve omvang, maar je voorkomt daarmee niet dat er story point inflatie ontstaat. Kortom blijf elke nieuwe schatting in omvang relateren aan eerdere schattingen.

Leren van schattingen

Kijk aan het eind van de sprint voor elke afgerond product backlog item (PBI) eens –met de kennis die we nu hebben- of de omvang die we aan de PBI hebben gegeven strookt met de werkelijkheid. Mocht die (substantieel) afwijken, wat hebben we dan geleerd? En belangrijker nog, hoe kunnen we die geleerde les borgen tijden de volgende refinement sessies? En of welk ander werk in onze product backlog moeten we ook schattingen herzien? Dit laatste wordt meestal vergeten!

Story point lineaal

Maakt fysiek of digitaal een ‘story point liniaal’. Plaats de afgeronde en eventueel in story points bijgestelde PBI op een lineaal met Fibonacci-schaalverdeling. Neem deze liniaal mee naar de refinement en vergelijk elke nieuwe schatting met PBI’s die op je story point liniaal staan. Over tijd, ruim je liniaal op zodat er niet te veel items op staan. Houd de goede voorbeelden op de liniaal en verwijder vergelijkbare stories.

Omgaan met teamdruk.

Als er te veel druk op een team gezet wordt om als team te verbeteren of meer story points te leveren per sprint, kan er ook story point inflatie ontstaan. Een van de krachtige elementen van Planning Poker is de discussies over onze potentieel verschillende schattingen. Dit levert ons kennis en inzicht; impliciete aannames worden expliciet. Wanneer er te veel druk op een team staat om te presteren, vervallen we al gauw in: “Rond maar af naar boven dan zitten we vast wel goed”. Niet alleen komt de broodnodige kennisuitwisseling onder druk te staan, ook zorgt het voor story point inflatie. Dit leidt tot een grotere onvoorspelbaarheid voor zowel de sprint als de product increment waar de sprint onderdeel van uitmaakt.

Triangulatie

Zoals eerder vermeld is het raadzaam elke nieuwe schatting relatief te schatten aan eerdere schattingen. Ideaal gezien zou je elke nieuwe schatting willen relateren aan alle eerdere schattingen. Maar dat is natuurlijk ondoenlijk. Met ´triangulatie´ wordt bedoelt om een PBI te vergelijken met zowel een item dat net iets kleiner is en net iets groter. Bijvoorbeeld een 5 SP PBI vergelijken met een reeds eerder geschatte 3 SP PBI en een 8 SP PBI. Dit draagt bij aan de consistentie van schattingen.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

Acht valkuilen van zelforganisatie (die je kunt vermijden)

zelforganisatie

Elke Agile organisatie experimenteert met zelf organiserende teams. Want te veel vertrouwen op structuren, regels en managers maakt medewerkers volgzaam, gedemotiveerd of zelfs gefrustreerd. De gedachte is om meer uit mensen te halen. Maar daarbij trappen we nog te vaak in acht onnodige valkuilen.

#1: Focus op individuele taken.
Wie aansturing van bovenaf gewend is, loopt het gevaar om volgzaam te worden.  Handelen in het belang van je team is dan helemaal niet zo vanzelfsprekend. Bovendien vinden sommigen het ook wel prettig om een afgebakende bijdrage te leveren. Dit laatste wordt bovendien in veel ondernemingen in de hand gewerkt door eenieders bijdrage te beperken tot een bepaalde rol of expertise. In het uiterste geval creëren we zo robots met oogkleppen. ‘Teamspelers’ die zich niet verantwoordelijk voelen voor het resultaat van het team als geheel.
Een succesvol zelf organiserend team heeft gemeenschappelijke doelen en gedeelde verantwoordelijkheid. Naast dezelfde uitvoerende taken als voorheen, moet het team ook de verantwoordelijkheid dragen voor het regelen en coördineren van alle samenhangende activiteiten die nodig zijn om als team een volledig product te leveren. Denk hierbij aan onderhoud, planning, kwaliteitscontrole, wegwerken van belemmeringen en verbetering van het samenwerkingsproces.

#2: Weinig tijd of aandacht voor transitie.
Het concept ‘zelforganisatie’ doorgronden en eigen maken kost tijd en energie. Het is ook een hele uitdaging om ineens intensief met teamleden samen te werken. Teamleden leren naast gelijkwaardig met elkaar samen te werken ook gezamenlijk besluiten te nemen.  En problemen of conflicten onderling op te lossen, zonder de manager erbij te betrekken.
Het is belangrijk dat het team niet zonder begeleiding het diepe in wordt gegooid. Zonder voldoende begeleiding is de kans groot dat het management na enige tijd concludeert ‘dat de medewerkers blijkbaar nog niet toe zijn aan zoveel verantwoordelijkheid’. Een gemiste kans voor iedereen. Aandacht geven dus, dat zelf organiserend werken!

#3: Terugvallen op controlereflexen.
Managers hebben graag grip op zaken. Ze behoren tot het Als-je-wilt-dat-het-goed-gebeurt-doe-het-dan-zelf geloof. Ook managers moeten dus wennen aan hun nieuwe rol-op-afstand. Loslaten betekent echter niet uit handen laten vallen. Managers moeten leren op een andere manier te sturen. Het gaat erom de voorwaarden te scheppen waarbij professionals zichzelf kunnen organiseren.
Ruimte en vertrouwen geven is wat anders dan geen leiding meer geven. Er is wel degelijk richting nodig. Het gaat niet meer om het voorschrijven hóe iets moeten gebeuren, maar om wát er gerealiseerd moet worden en waaróm!
Hoe een leidinggevende kijkt naar zijn medewerkers en hun prestaties is een belangrijke voorwaarde voor het succes van zelforganiserende teams. Ga je ervan uit dat werknemers niet graag werken, weinig ambities hebben en geen verantwoordelijkheid willen dragen? Dan is kans groot dat je medewerkers zich ook zo opstellen. Of ga je uit van het omgekeerde? Dan is het makkelijker om ruimte te geven, mensen te vertrouwen en krijg je dat ook terug. Zolang een manager liever controleert dan vertrouwt, is zelforganisatie gedoemd te mislukken.

#4: Enthousiast, maar doelloos.
Een feest der herkenning: je manager is enthousiast over Agile werken, heeft er goede verhalen over gehoord en maakt van ‘zelforganisatie’ een toverwoord. ‘Eindelijk gaan ze eens doen wat we van ze verwachten.’
Het enige probleem: er is geen duidelijk doel gesteld. Waar helpen we aan mee? Waar gaan we naar toe? Waarom doen we het? Het is stil bij het management.
Zonder duidelijke doelen kan geen team zich doelgericht organiseren. Formuleer een centrale antwoord op de vraag: Wat willen we met Agile werken bereiken? Is het uiteindelijke doel kostenbesparing, sneller producten realiseren of flexibeler omgaan met verandering? Of producten realiseren die beter aansluiten bij de behoeften van eindgebruikers? Legio mogelijkheden. Pas als het doel duidelijk is gecommuniceerd en alle betrokken het ‘ademen’ kan een team zich organiseren om bij te dragen aan het doel.
Het ontbreken van duidelijke doelen leidt nog tot een ander risico: het team dreigt een soort autonome enclave te worden, waar het groepsproces bepaald waar de focus ligt. Er kan extra weerstand ontstaat zodra er wél doelen worden gesteld.

#5: Demotiveren team.
In beginstadium van een Agile team gonst het van de positieve geluiden: Jullie kunnen nu echt meedenken, we gaan het samen doen. En vervolgens komt er een dikke streep door het eerste het beste verbetervoorstel waar het team mee komt. Zit het team dan te slapen of de manager?
Goed idee of niet, een team moet fouten kunnen maken om te groeien.  Zoals eerder gesteld zal een manager snel terugvallen op controlereflexen als het mis dreigt te gaan. Dit wil niet zeggen dat management tandenknarsend moeten toekijken. Het gaat vaak mis door het ontbreken van (voldoende) duidelijke randvoorwaarden.
Hoe minder controle er op het team wordt uitgeoefend en hoe minder beperkingen worden opgelegd, des te beter gedijt een team. Wanneer leiders te weinig ruimte geven om tot oplossingen te komen, zal zelforganisatie niet tot stand komen. De oplossing wordt dan min of meer aangedragen, waardoor een team in een volgstand komt. En het behoeft geen toelichting wat dat met motivatie doet.

#6 Angst voor delegeren.
Zelforganisatie valt of staat met een manager die durft te delegeren. In praktijk zie je dat er verschillende redenen zijn waarom een manager dat liever niet doet:

  • Hij/zij heeft geen vertrouwen in het adequate handelen van het team in de wetenschap dat ze het niet op de manier doen, die de manager het beste acht. Maar anders is niet altijd slechter. Het gevolg is dat de manager de zaken zelf oppakt en te druk is om zijn of haar team te trainen hoe ze het kúnnen doen. Dit leidt tot een vicieuze cirkel. Veelal benadert het team het anders dan de manager zelf zou doen. Geef ze die ruimte!
  • Een manager is bang om status te verliezen. Hij of zij mag immers mensen het werk niet meer voorschijven. Wat is zijn of haar rol dan nog? Inderdaad dienend leiden in plaats van aansturen.
  • De manager weet niet goed om te gaan met de tijd die vrij komt door taken te delegeren.  Immers waar is de manager dan voor nodig als deze het kan delegeren? Een manager moet leren dat hij/zij op een andere manier meer ballen in de lucht kan houden.

#7 Team niet zorgvuldig gekozen.
Een groep collega’s is niet hetzelfde als een team. Ook niet wanneer die collega’s al heel lang samen projecten doen. Ja als iedereen vrij geïsoleerd zijn bijdrage levert en het deelresultaat over de schutting gooit, zullen ze elkaar de tent echt niet uitvechten. Maar wat als ze ook de verantwoordelijkheid dragen voor het regelen en coördineren van de overige werkzaamheden die de individuele taken tot een geheel maken? Dit verreist een veel intensievere samenwerking. Dan zie je al snel waar de karakters botsen en wat zelforganisatie in de weg staan. Wie zal er in het team een toontje lager of juist hoger moeten zingen? Hoe voorkomen we dat er nieuwe leiders opstaan? Als de balans in de groep niet goed gekozen is, gaat er onnodig veel energie verloren aan het groepsproces. Vooral tegenstanders van verandering kunnen de situatie dan behoorlijk naar de hand zetten.
Zonder een team zorgvuldig samen te stellen en te begeleiden heeft zelforganisatie weinig kans.

#8 Teamomgeving belemmert
Agile werken beperkt zich niet tot individuele projecten. In de meeste gevallen groeit het Agile werken vanuit een individueel project. Een bij voorkeur zorgvuldig gekozen pilot project wordt gebruikt om te wennen aan de nieuwe manier van werken. Al gauw worden de eerste successen behaald en dreigt het zich als een olievlek te verspreiden. Maar de ‘mindset’ van management blijft vaak achter. Ze denken dat het ‘slechts’ om een andere projectaanpak gaat en dat alles verder ‘business as usual’ blijft. De omgeving van het team groeit niet mee en al snel wordt duidelijk dat het management de beperkende factor wordt voor verder succes.
We hebben in de voorgaande valkuilen al gezien dat er een belangrijke rol weggelegd is voor management om zelforganisatie te laten bloeien. Hoe help je een team het best? Wat staat er in de weg? Krijgen ze voldoende ruimte? Om dit mogelijk te maken moet het management op haar beurt ook voldoende ruimte krijgen om te leren en een nieuwe invulling te geven aan hun rol. Het probleem is echter dat de inrichting van de organisatie zwaar leunt op oude protocollen, regels en systemen (denk bijvoorbeeld aan beloning). Zolang je die in takt laat, krijgt zelforganisatie weinig kans.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op! 

Hoe maak je frictie in een team bespreekbaar?

wrijvingKortcyclisch werken in een multidisciplinair team vraagt veel van de betrokken personen. Door de nauwe samenwerking ontstaan er vaak spanningen die zijn weerslag hebben op het team. Voor een teamlid is het niet gemakkelijk om ongenoegen te uiten in een groep die bij gelegenheid gevormd is. Een groepsoefening kan hierbij uitkomst bieden.

In tegenstelling tot een traditionele aanpak resulteert een Agile werkmethode in meer contactmomenten tussen de betrokkenen. De taken zijn kleiner en het team is van elkaar afhankelijk voor het boeken van resultaat. Bij menig bedrijf – met name die waarbij matrix management een groot goed is – bestaat elk project bovendien uit een nieuwe groep mensen. De spanning en het onderlinge wantrouwen dat bij nieuwe teams aanwezig is zou in een aflevering ‘Expeditie Robinson’ niet misstaan.

Een goed functionerende groep ontstaat niet zomaar; een voetbalelftal met uitmuntende spelers wordt niet per definitie kampioen. Psycholoog Bruce Tuckerman identificeert in z’n ‘Forming-Storming-Norming-Performing’- model de stadia van groepsvorming die een team doorloopt. Het boekt vooruitgang, valt terug en groeit naar elkaar toe. In ‘Five Dysfunctions of a Team’ stelt Patrick Lencioni bovendien dat gebrek aan vertrouwen de belangrijkste beperking is voor samenwerking. Teams waarbinnen vertrouwen bestaat kenmerken zich door deelnemers die hun zwakheden durven te tonen. Ze geven elkaar hulp, feedback en ondersteuning. Een goed functionerend team tenslotte kijkt uit naar vergaderingen en andere gelegenheden om als groep op te treden.

Een teamoefening biedt een veilig podium waarin elk teamlid kan aangeven wat hij of zij belangrijk vindt, zonder een ander teamlid ergens persoonlijk op aan te spreken. Op deze manier wordt het onderling vertrouwen niet in gevaar gebracht, maar wél de pijnpunten kenbaar gemaakt die leven binnen een team. De normen en waarden van de teamleden resulteren – in overleg – in overkoepelende normen en waarden die voor het hele team gelden. Deze teamwaarden worden gezamenlijk gedragen. De afspraken die worden gemaakt zorgen voor onderling vertrouwen, en de stap om spanningen onderling te bespreken wordt kleiner.

Stap 1: Opening
Zorg voor een ontspannen opening van de sessie. Bijvoorbeeld door teamleden een vraag te stellen als: “Waar zou je nu willen zijn als je hier niet zat”.

Stap 2: Doel
Leg uit wat je wilt bereiken: het streven naar teamwaarden.

Stap 3: Verzamelen van input.
Elk teamlid schrijft op een kaartje of ‘Post-It geeltje’ “Ik hou er niet van als iemand …”. Als je met ‘Post-It geeltjes’ werkt, plak er dan gespiegeld op de achterkant één tegenaan. Houd er rekening mee; hoe meer input per persoon hoe meer tijd je nodig hebt voor deze sessie. Probeer dit op voor jouw passende manier te beperken. (2-5 items p.p.?)

Stap 4: Uitwisselen input
Verzamel de input, hussel het door elkaar en verspreid de kaartjes over het team. Laat – als bijdrage in zelforganisatie – het team zelf items blind selecteren. Als een teamlid één van de eigen kaartjes heeft ontvangen: kaartje teruggeven en andere kiezen.

Ik hou er niet van als ...

Stap 5: Tegenmaatregel
Schrijf op de achterkant van het kaartje het tegenovergestelde: “Ik waardeer het als iemand….”.
Variatie: maak groepjes van 2-3 personen voor het beschrijven van de tegenmaatregel.

Ik waarder het als ...

Stap 6: (optioneel) categoriseren
Deel een lijst met categorieën uit en laat elk teamlid beoordelen welke categorie het beste van toepassing is. Laat deze toevoegen op het kaartje. Zie bijvoorbeeld: Positieve waarden.

Stap 7: Waarden delen!

Om de positieve waarden van de groep te delen leest ieder teamlid de door hem of haar positief geherformuleerde waarden op totdat alle waarden benoemd zijn. Het is belangrijk dat deze waarden door andere teamleden worden uitgesproken. (Stap 4 zorgt ervoor dat we aan de slag met elkaars pijnpunten en niet de individuele)

Tip: plak deze tijdens het benoemen op bijvoorbeeld een flip-over, zodat iedereen ze kan zien.

Stap 8: Overzicht maken en ophangen.
Maak een voor jouw team bruikbaar overzicht van de waarden die je samen als team draagt. Zorg dat je elkaar op een positieve wijze feedback geeft zodra bepaald gedrag niet in lijn is met wat het team samen belangrijk vindt.

Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op! 

Knikkebollende samenwerking

Pair programming, je haat het of je bent er dol op. In de Agile community wordt het gezien als een van die middelen die je eigenlijk niet links kunt laten liggen. En wel om de simpele reden dat pair programming zorgt voor software van hoge kwaliteit in relatief korte tijd (Cockburn & Williams 2000). Eén van de grootste uitdagingen met pair programming is hoe degene die niet achter het toetsenboard zit betrokken blijft. Een mens is nu eenmaal snel afgeleid door allerlei interne gedachten die niets te maken hebben met de taak waaraan gewerkt wordt. En laten we eerlijk zin, staren naar opdrogende verf houdt niemand lang vol. Promiscuous Pairing (Belshee 2006) lijkt een antwoord te bieden op focus en betrokkenheid. Lees meer…

Magere Sprint Reviews

Gedurende de Sprint Review bekijken het Scrum Team en de belanghebbenden samen naar wat er bereikt is in de afgelopen Sprint.  De informele presentatie en bespreking van tastbare resultaten heeft als doel feedback te verzamelen en samenwerking te bevorderen. Het resultaat van de Sprint Review is een herziend perspectief van het product en de oplevertermijn. In praktijk komt een effectieve Spint Review niet altijd goed van de grond. Lees meer…

Bepaal je sprintlengte gericht

Hoe de duur van de sprint bepalen.Om uiteenlopende redenen lukt het een startend team vaak niet om het geplande werk af te ronden binnen de duur van de Sprint. Toch kiest een team vaak voor een voor de hand liggende oplossing, het verruimen van de duur van de Sprint. Maar als je het werk niet af krijgt in bijvoorbeeld twee weken, waarom denk je het werk dan wel af te krijgen in drie of vier weken? “Ja, maar Scrum zegt één-vier weken, dus het mag toch?” Werk niet afkrijgen is een signaal waar we niet omheen moeten werken. Wat zijn de oorzaken dat het niet lukt? Waar doet het pijn? Lukraak een Sprint-lengte kiezen en de leercurve aangaan is niet de beste optie. Hoe kies je nu een Sprintlengte die het best past voor jouw team en project? Lees meer…

Cynefin & Scrum

Alhoewel Scrum in veel situaties geschikt is, is het niet onder alle omstandigheden de meest geschikte oplossing. Als onderdeel van een gerichte assessment om de fit te bepalen, moet er o.a. gekeken worden naar de omgevingssituatie. Het Cynefin model (Snowden en Boone) is een interessant hulpmiddel om de omgeving waarin we Scrum willen gebruiken te begrijpen. Dit model wordt gebruikt voor het classificeren van problemen, situaties en systemen. Er worden daarbij 5 verschillende typen onderkend: simpel, gecompliceerd, chaotisch, complex en wanorde.
Lees meer…

Deadline vs voortschreidend inzicht

Een vaak gehoorde opmerking is “Hoe kunnen we als team ons inzetten om naar een oplevering toe te werken, en daarnaast omgaan met verandering gedurende het project?

Een van de misverstanden bij de introductie van een Agile aanpak is de gedachte dat Agile synoniem is aan: ‘we zien wel waar we uitkomen’. Niets is echter minder waar! Ook bij de start van een Agile project is een zekere mate van projectinitiatie onmisbaar. Dit zorgt immers voor een goed beeld van het probleem dat je probeert op te lossen. En belangrijker nog, het stelt de succescriteria vast van het project. Agile werken of niet, zonder meetbare succesfactoren is een project gedoemd te mislukken! Lees meer…

Rotte appel uit de mand

Een team is maar zo sterk als zijn zwakste schakel. Een gezegde dat op de agile werkvloer extra van toepassing is. Je hebt er maar één nodig. Iemand die zich niet bewust is van de kwaliteit van z’n werk. Iemand die niet respectvol is. Iemand die zijn steentje niet bijdraagt. Iemand die stijf staat van de negativiteit en het cynisme. Iemand die voortdurend de lol en de energie uit elk teamlid zuigt. Herkenbaar? Lees meer…

Hier zit een luchtje aan…

In de vorige blog is er gekeken naar de meest gangbare klantwaarden. De conclusie is dat je een ontwikkelproces pas echt kan configureren en inrichten als bekend is welke specifieke klantwaarden er centraal staan. In deze blog borduren we hierop voort. Lees meer…

Twee onsjes ‘business value’ graag…

Het leveren van waarde aan de klant is de belangrijkste drijfveer in een agile aanpak. Maar hoe velen van ons weten concreet welke specifieke waarden het meest belangrijk zijn voor de onderneming van onze klant? En hoe velen van ons weten hoe ze hun projectaanpak daarop kunnen inrichten? Vaak blijkt agile een doel op zich, in plaats van een middel naar een doel. In deze blog beschrijf ik de meest gebruikelijke waarden. Met de aansluitende praktische oefening krijg je een beter beeld van jouw projectsituatie.
Lees meer…

Krijg de business aan boord!

Om een agile aanpak het meest effectief te laten werken, weten we dat we de ‘business’ actief betrokken moet zijn en samen moet werken met het delivery team. De vraag die ik vaak gesteld krijg is: “Hoeveel tijd kost dat dan?”. Uiteraard is dit afhankelijk van de projectomvang en de projectsituatie. Wel  kunnen we stellen dat het doorgaans geen full-time betrokkenheid is. Op zijn minst gaat het om ongeveer vier tot acht uur om iedere sprint de requirements te identificeren, te prioriteren en te communiceren en hands-on  betrokken te zijn bij het reviewen van sprintresultaten. Idealiter ook een paar uur extra voor hun betrokkenheid gedurende de sprint om samen te werken met het team daar waar nodig. Als richtlijn zou hun betrokkenheid niet meer dan 10-20% van hun tijd in beslag moeten nemen. En hierbij doel ik nadrukkelijk op een optimale samenwerking met het team (just enough, just in time). In complexere omgevingen met meerdere stakeholders is er intern de nodige politiek en afstemming nodig om de neuzen van de verschillende stakeholders in dezelfde richting te krijgen. Hoe kiezen we nu de juiste vertegenwoordiger? Lees meer…

De vierde standup-vraag

Een van de doelen van de standup meeting (ook wel ‘daily scrum meeting’ genoemd) is om de activiteiten van het ontwikkelteam te synchroniseren en een plan te maken voor de komende 24 uur. Hierbij kijkt het team naar het werk dat afgerond sinds de afgelopen standup. Daarbij is het van essentieel belang om obstakels (impediments in jargon) te identificeren en te verwijderen die de sprint belemmeren. Helaas blijven de nodige impediments onopgemerkt, waardoor de standup als middel door en voor het team zijn kracht verliest.
Lees meer…

Story decompositie – Deel 2

In deel 1 van deze blog is gesteld dat de juiste omvang van user stories en onderliggende taken enorm bijdraagt aan het slagen of falen van scrum. Ook is gesteld dat niet afgeronde sprints, slechte schattingen en slecht lopende Daily Scrums vaak symptomen zijn van werk dat niet de juiste omvang heeft. In het tweede en laatste deel van deze blog gaan we verder met een aantal tips om een user story op te delen.
Lees meer…

Story decompositie – Deel 1

De juiste omvang van user stories en onderliggende taken kan het verschil maken in het slagen of falen van Scrum. Krijg je het werk niet af in een sprint? Zijn de schattingen slecht? Loopt de Daily Scrum niet lekker? Je zou in eerste instantie niet direct een verband leggen, maar dit zijn typische symptomen van werk dat niet de juiste omvang heeft! (In een apart blog zal ik die relatie eens toelichten, maar ik nodig de lezer graag uit zelf dit verband te leggen.)
Lees meer…

Impact Mapping

Er zijn talloze software producten en projecten die een stille dood sterven. Tijd, geld en energie is verspeeld door verkeerde aannames, gebrek aan focus, slechte communicatie en onvoldoende stil te staan bij de doelstellingen. We gaan vaak te snel aan de slag. De opdrachtgever heeft vaak zélf niet eens een goed beeld van zijn eigen wensen. Of komt zelfs met een oplossing, in plaats van de achterliggende probleemstelling. U vraagt, wij draaien.

Hoe krijgen we de doelstellingen boven tafel? En zitten de verschillende betrokkenen wel op één lijn zitten? En hoe weten we welke oplossing het beste bijdraagt aan het doel? Gewapend met de antwoorden op deze essentiële vragen, hoe gaan we dit allemaal duidelijk communiceren naar een ontwikkelteam?

Lees meer…

Generalisten vs specialisten

Een van de grote nadelen van het watervalmodel voor softwareontwikkeling, is dat het aanstuurt op functionele specialisatie. Een informatieanalist kan alleen requirements verzamelen, een programmeur alleen code schrijven, een architect alleen architectuur leveren en een tester alleen testen. Dit kan ertoe leiden dat een project stagneert als één van de functionele specialisten niet beschikbaar is. In scrum is het tegenovergesteld. Scrum teams zijn multidisciplinaire teams. Het team trekt samen op om een gemeenschappelijk doel te bereiken. Daarom kan iedereen in het team werken aan taken die niet tot hun kerncompetentie behoren. Meestal is er iemand in het team met een specifieke expertise om dit in goede banen te leiden. In scrum zou er dus nooit een enkel teamlid moeten zijn die verantwoordelijk is voor het falen van het hele team. Als een team effectief wil zijn, zullen alle teamleden ook buiten hun gebaande paden moeten gaan en meehelpen om het werk af te ronden. Om die reden krijgt het begrip multidisciplinair team een prominente plek in Scrum.
Een veel voorkomende misvatting echter is dat er in scrum geen plek is voor specialisten en dat iedereen even goed moet zijn in alle technologieën en disciplines. Onjuist! De sleutel is een goede balans tussen generalisten en specialisten!
Lees meer…

Root cause analyse niet je ding?

Als er iets is dat de afgelopen jaren de nodige aandacht heeft gekregen in de agile gemeenschap, dan is het wel ‘root cause’ analyse. In Scrum leert het team elke sprint te evalueren om binnen de grenzen van het scrum raamwerk, aanpassingen te vinden die de komende sprints effectiever en plezieriger maken.  Knelpunten dienen zich daarbij vaak moeiteloos aan en het team bedenkt hier oplossingen voor. Toch dweilen we vaak onbewust met de kraan open. We zijn bezig met symptoombestrijding in plaats van op zoek te gaan naar de brón van het probleem.Visgraaddiagrammen, de ‘5 why’s’ en ‘root cause analyse’ zijn effectieve middelen die al in vele artikelen beschreven zijn.
Lees meer…

Proxy Product Owner – Doe maar niet!

Een Product Owner kun je beschouwen als ‘directeur’ van een product. Een directeur wordt verantwoordelijk geacht voor de kosten en baten van zijn investeringen en legt verantwoording af aan belanghebbenden. Daarnaast managet hij de organisatie om de doelstellingen van de onderneming te bereiken. En dat we deze verantwoordelijkheid niet delegeren aan een plaatsvervanger, vinden we dan ook meer dan logisch. En gek genoeg zien we kennelijk geen kwaad in een proxy Product Owner. Wat maakt dat deze constructie in de praktijk ontstaat? En belangrijker, waarom werkt het contraproductief? Is er een alternatief op een volwaardige Product Owner?
Lees meer…

Projectinitiatie kan óók agile!

Herken je deze situatie? Business mensen zijn vol lof over agile. Pragtische aanpak, makkelijk omgaan met verandering, verkorte ´time-to-market´, sterke focus op doelstellingen en vooral een goede ´alignment´ tussen business en IT. Mooie woorden, maar bij alignment denkt de ‘business’ aan de operationele kant van het project. In praktijk worden daarom veel projecten op een klassieke, vaak tijdrovende manier geïnitieerd, om vervolgens pas daarna agile vorm te krijgen. En dat terwijl we snel op zoek zijn naar de klassieke go/no-go-beslissing!
Lees meer…

Agile & contracten

Kan agile project management gebruikt worden met een traditioneel fixed price contract? In hoeverre heeft een contractmodel invloed op de gekozen projectaanpak en het verloop van het project? Vereist agile project management nieuwe contractmodellen om succesvol te kunnen zijn? Zo ja, wat voor contract is dan nodig? Lees meer…

Onderhoud en Scrum werkt niet?!

Ook agile softwareontwikkeling leidt uiteindelijk tot onderhoud. Het doel van incrementele agile softwareontwikkeling is om werkende software zo snel mogelijk uit te kunnen leveren aan de klant en zorgen dat deze er mee aan de slag gaat. Hiermee ontstaan tijdige feedback loops. Op een bepaald moment, wanneer de klant op de software vertrouwt om hun business te ondersteunen, gaat het team over van ontwikkeling naar onderhoud. Maar er is geen reden waarom teams hun werkwijze fundamenteel zouden moeten wijzigen eenmaal in dit stadium aanbeland. Lees meer…

Problem to solution