De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder.
In het algemeen wordt als advies gegeven dat de items op volgorde van waarde moeten staan. In mijn ervaring is dat echter te beperkt. Wat mij betreft bepaalt een mix van de volgende factoren de volgorde van de backlog:
- waarde - de waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de product owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig);
- risico - spannende stories waar mogelijk ellende in zit moeten relatief hoog op de lijst staan; fail fast is beter dan fail late;
- technische afhankelijkheden - er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.
>> lees verder
Het mopje is denk ik voor velen wel bekend en anders zeker herkenbaar: een extraverte software engineer is iemand die bij het handen schudden niet naar zijn eigen voeten kijkt, maar naar de voeten van degene van wie hij de handen schudt.
Lachen is een teken van herkenning. En ik herken dit wel. >> lees verder
De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder.
In het algemeen wordt als advies gegeven dat de items op volgorde van waarde moeten staan.
In mijn ervaring is dat echter te beperkt. Wat mij betreft bepaalt een mix van de volgende factoren de volgorde van de backlog:
- waarde – de waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de product owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig);
- risico – spannende stories waar mogelijk ellende in zit moeten relatief hoog op de lijst staan; fail fast is beter dan fail late;
- technische afhankelijkheden – er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.
>> lees verder
Een Scrum master die ik vorige week sprak verzuchtte: “mijn teamleden pakken nog steeds niet zelfstandig taken op van het Scrumboard”. Een duidelijk signaal dat er iets grondig mis is. Een nader gesprek leverde het volgende op:
De teamleden gaan steeds als ze ergens mee klaar zijn naar de Scrum Master en vragen hem wat ze nu eens moeten gaan doen. >> lees verder
De schrijvers van het Agile Manifesto vinden working software belangrijker dan comprehensive documentation. Zo direct gesteld zal iedereen het daar wel mee eens zijn. Maar de vraag blijft wel wat dan de waarde is van documentatie. Moeten we helemaal stoppen met het schrijven van design documentatie? Het laatste zinnetje van het Manifesto geeft al aan dat dit niet het geval kan zijn: there is value in the items on the right, er zit dus waarde in het schrijven van documentatie, we value the items on the left more, maar we moeten het niet overdrijven. >> lees verder
Het klinkt in ieder geval als een een onmogelijkheid. Hoe dikker de procesbeschrijvingen hoe statischer en bureaucratischer de projecten. Dat lijkt logisch toch?
Toch is het misschien niet zo eenvoudig.
Ik maak even een uitstapje naar juridische systemen. In Europa, in de Rijnlandse wereld, wordt het oude romeinse systeem gebruikt. Het Civil Law systeem. >> lees verder
In de Scrumcursussen die ik geef, krijg ik vaak allerlei tegenwerpingen nadat ik heb verteld dat Scrum/Agile streeft naar multidisciplinaire teams:
* hoe verhoudt zich dat met de waarde die Agile hecht aan vakmanschap, je kunt toch alleen echt een vakman zijn als je je op één specialisme concentreert?
* dat kan bij ons nooit, onze front-end developers kunnen echt geen backend code schrijven en omgekeerd, programmeurs kunnen geen goede user-interaction ontwerpen, enzovoorts! >> lees verder
Breaking the code of change is een van de meest grondige boeken die ik gelezen heb over verandermanagement. Het boek is een verslag van een conferentie onder de top van de wetenschappers over veranderkunde. Grofweg zijn er in de wetenschap twee stromingen, theorie E en theorie O. Theorie E is de harde, maakbare, planbare kant van veranderen, angelsaksisch gestuurd. >> lees verder
CMMI is een model, dat organisaties helpt hun processen voor (software)ontwikkeling te verbeteren. Het model geeft allerlei suggesties voor werkwijzen (engels: practices) van projectmanagement, procesmanagement, ontwikkeling en ondersteuning. Dit zijn globale suggesties. Je kunt ze niet direct toepassen, daar zijn ze te algemeen voor. Het model vereist een vertaling naar de praktijk, een implementatie. >> lees verder
Een van mijn favoriete fimpjes op YouTube is “What really motivates us” van Dan Pink. Naast de originele en functionele vormgeving spreekt de inhoud me zeer aan.
Kort samengevat, de oude vertrouwde manier van motiveren, straffen en belonen, werkt niet bij taken waar denkwerk aan te pas komt. Voor dat soort taken zijn er drie dingen die je moet doen om mensen te motiveren: autonomy, mastery, purpose. >> lees verder
