Overzicht blog

Scrum Master en Product Owner combineren? Doe maar niet.

Een veel voorkomende vraag is of het aanvaardbaar is om de rol van Product Owner en Scrum Master te combineren en de taken en verantwoordelijkheden van beide rollen aan één persoon toe te vertrouwen. Tegengestelde belangen, benodigde tijd en benodigde competenties zijn enkele overwegingen om daar niet voor te kiezen. Je helpt het product en het team hier niet goed mee vooruit. 
Lees meer…

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.
Lees meer…

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.
Lees meer…

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.
Lees meer…

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