Schatten in een Agile wereld

Inschatten wat de kosten moeten zijn is lastig. Vaak wijzen mensen in een agile omgeving op de driehoek Scope, Resources en Schedule. Je kunt niet Scope (wat je bouwt), Resources (wat je ervoor nodig hebt) én Schedule (de planning) vastzetten. Wanneer je Scope en Schedule vastzet kun je er wellicht extra geld tegenaan gooien. Op eenzelfde manier kan er ook voor gekozen worden om juist de planning los te laten en/of de scope. Alle drie zaken zeker en vast gaat niet. Maar toch, we willen een idee: wat gaat het kosten en wanneer is ‘het’ (het geplande) af?

Planningspoker

Scrummers doen hun schattingen met het spelen van planningspoker. Deelnemers aan een planningssessie werpen kaarten op tafel waarmee ze uitdrukking geven aan hoe zwaar ze een taak achtten t.o.v. een referentietaak met kaarten die genummerd zijn volgens de Fibonacci(-achtige) reeks. De grotere getallen liggen verder uit elkaar en geven daarbij ook uitdrukking aan een grotere mate van onzekerheid.

Je ku…

De principes van murb

Toelichting: Niet iedereen maakt applicaties op dezelfde manier. In de loop der jaren heb ik wat principes ontwikkeld waaraan ik mij probeer te houden wanneer ik oplossingen realiseer. Het zijn handvatten waaraan ik mijzelf probeer te houden. Ik hoop ook dat opdrachtgevers mij hieraan helpen herinneren mocht het, vergeef me, toch nodig zijn. Vandaar deze openbare declaratie.

Simpel

Ook het idee dat zaken veelal onnodig complex gemaakt worden? Het komt maar al te vaak voor dat IT-bedrijven oplossingen willen bouwen die geschikt zijn voor alles. Maar dat heeft een prijs: complexiteit. De software van murb is eenvoudig in het gebruik en ook nog eens goedkoper aan te passen aan jouw wensen.

De eindgebruiker staat centraal

Heb je het gevoel dat de gebruiker wordt vergeten bij lange lijsten met features? Er wordt door murb in de eerste plaats gewerkt aan gebruiksvriendelijke oplossingen. Met een duidelijke mens-machine-interactie en interactieontwerp achtergrond st…

Embedded development

Hyper agile development, yeah! Nee, ik ga het niet hebben over ontwikkeling voor embedded systems (systemen zoals pinautomaten tot magnetrons). Maar over ontwikkelen midden in een organisatie die werkt. Zoals journalisten in het leger, op die manier embedded. Niet Kennismaking, Ontwerp, Bouw, Testen, en uiteindelijk de Grote Oplevering (waarbij iedere stap een vertaalslag is zonder de bron om op terug te vallen). En zelfs niet het iteratieve ontwikkelen zoals dat in Scrum gangbaar is. Nee, iedere dag te maken krijgen met verzoeken: “Nu wil ik dit graag kunnen.” “Kun je dit voor mij doen.” En dan beslissingen nemen. Dat is embedded development voor mij.

Hyper agile. Beetje (erg) hectisch, maar daarom des te leuker. M’n code is van tijd tot tijd een rotzooi, in de loze minuutjes proberen op te schonen. En het moet blijven draaien, want ieder moment kan er een nieuw verzo…

Scrum en UX: met de billen bloot

Scrum is hot. Niet alleen als trend. Het is heftig voor iedereen. Intensief. En continue blijven leren. Zo heb ik sinds gisteren ook weer veel geleerd en inzichten erbij.Gisteren een NL Scrum meeting bijgewoond. Onderwerp dit keer was UX en scrum (een zogenaamde agile ontwikkelmethode). Erg interessant. Veel typische misstanden kwamen naar boven (volgens mij ook niet onbekend bij bij traditionelere ontwikkelmethoden): De business mensen zitten wel aan tafel als stakeholder, maar de eindgebruikers zijn voor de bouwers vaak onzichtbaar. Gelukkig kost testen weinig tijd en daarom is tijd ook geen excuus om niet met gebruikers te testen (tot zover de samenvatting van Joris Ketelaar’s presentatie van UserIntelligence). Naast testen met gebruikers is ontwerp voor gebruikers natuurlijk belangrijk. Doe je dat vooraf (soms is design gewoon een eindproduct), in een design sprint voor de productie sprint, of als übersscrum; tegelijkertijd? (een belangrijk thema in het verhaal van Patrick, Fabr…

Nemawashi

Kort voorwoord: sommige ideeën moet op gebroed worden. Deze post lag er ook al een tijdje. Maar het is tijd voor publicatie. Misschien dat meer mensen er op door kunnen broeden. Het is geen 'af' product, geen implementatie handleiding, geen nieuwsfeitje of eigenaardigheidje, maar een idee, dat op z'n best inspireerd…

Alweer een tijdje geleden, maar helaas ben ik vergeten waar (verdorie, waar is mijn 'Google History' voor offline gebruik?), las ik een artikel over een ontwerper, of architect, die Nederland al geruime tijd had verlaten en momenteel werkzaam was in Japan. Een opvallend cultuurverschijnsel werd door hem opgemerkt: nemawashi.

Nemawashi verteld ons dat -ik hoop dat ik hier niet te kort door de bocht ben- in plaats van de directeur direct te overtuigen van je idee, dat je  eerst de mensen onder de leidinggevende (je collega's) dient te overtuigen van de kwaliteiten van je plan. Wanneer je het idee daarna voorlegt aan de leidinggevende is de organisatie onder …

Mike Cohn over Scrum en Interaction Design

 Hoewel het nog te vroeg is om iets zinnigs te zeggen over de door ons onlangs ingeslagen weg om interaction design en scrummen te combineren, blijven we natuurlijk lezen over de mogelijk betere methodes. Zodoende kwam ik een hoofdstuk in Mike Cohn's boek 'User Stories Applied' (2004, ISBN: 0321205685, hoofdstuk 16) tegen. In plaats van interaction design mee te nemen in de sprint (onze eerste opzet), of een sprint voor te laten lopen (waar we dus onlangs aan zijn begonnen) stelt hij iets anders voor: doe het interaction design voor dat je met het daadwerkelijke scrummen (lees: programmeren) begint, een idee eigenlijk afkomstig van Constantine and Lockwood (2002). Gesuggereerd wordt, alvorens aan het sprinten te beginnen, de volgende stappen te doorlopen:

Modelleer de gebruikersrollen (zoals gebruikelijk) Selecteer de belangrijkste user stories (interaction design specifiek(?)) Prioriteer deze met hoge, midden, en lage prioriteit (interaction design specifiek(?)) Ver…

UX design en agile development - eerste evaluatie

 Zoals ik in mijn eerdere post al aanstipte is er nog veel onduidelijkheid over hoe user experience (/interaction) design en agile development, en in specifiek SCRUM met elkaar samen gaan. Het beste is om er in zo'n geval gewoon mee te beginnen en te kijken of er ook inderdaad problemen zijn. Onlangs hebben we onze eerste aanpassing gemaakt (in andere woorden, we zijn tegen een probleem aangelopen): interaction design moet uit de sprint.

Hoewel het niet zwart op wit door de scrum methode wordt voorgeschreven, zijn er doorgaans de volgende kolommen op het 'scrumboard': backlog, todo, in progress, to test, en done. Een user story op de sprint backlog wordt in de todo kolom in stukjes geknipt tot werkbare stukjes (work items). Ons idee was dat interaction design daar tussenin zou passen, en dat de interaction designer de work items min of meer definieerde als pagina's in de applicatie. Een workitem (in de praktijk dus vaak een pagina) werd verplaatst naar de todo wanneer…

Working @ the Bean machine

For little over a month, I'm working at a start up named 'the Bean Machine' based in Enschede, The Netherlands. It's a fresh new startup with a clear vision on project management: doing it with scrum. So if you were wondering where murb is hanging out, its over there. My ideas about agile development and how my passion of user experience/interaction design can be integrated in this development method are mainly posted at the beanblog (sorry, in Dutch only). I will try to post the interesting things on this blog as well… especially when I'm at a stage that I can really share best practices (I'm still learning).

Nooit meer mislukte ICT projecten?

 Gisteren schreven ze bij Computable een stukje over de mogelijke oorzaak van het falen van het Wia-project bij de uitkeringsinstantie UWV. Dit Wia-project werd geannuleerd na een investering van 87 miljoen euro. De conclusie van het Computable-artikel is dat een andere ontwerpmethodiek, nl. agile i.p.v. de traditionele waterval, dit falen had kunnen voorkomen. Michael Franken wijst in zijn blog bij Agile Holland er echter op dat met het huidige systeem van aanbestedingsprocedures zoals deze zijn opgelegd door de EU het eigenlijk niet  mogelijk is om nog echt agile te werken; aanbestedingen vereisen nl. al uitvoerige uiteenzetting van hoe het eindproduct er uit moet komen te zien:

> Ten eerste zijn de eisen van een aanbesteding echt funest voor een project aangezien alle parameters van de Iron Triangle (tijd, resources, scope) worden dichtgetimmerd.

Agile development maakt het, met zijn iteratieve karakter, goed mogelijk om aanpassingen op een later moment door te voe…