Delay your decisions

I design very little upfront. Sometimes I need to make an estimation, I design a little more. Sometimes the project is hardly specced and there is a lot of exploring to do.

In this post I would like to give a demonstration of how a recent project developed.

Initial stage

> Client: “We want a fancier frontend for our data”.
> Me: “Sure, any limitations?”
> Client: “We give you 4 months”
> Me: “Can I use any tech I want?”
> Client: “Na, we want to be able to continue on what you’re going to create, so please use P, X, Y and/or Z.”
> Me: “Sure, P is not my favourite, but some time ago I’ve dealt with it, so ok, we keep it simple anyway.”

The plan that followed:

Initially I thought I could fancy up the CSS, but the old product was in a very bad state and not really maintainable. So I decided to create a thin API layer in P (yes of PHP), a modern front-end layer in JavaScript using a framework that I co-introduced in the organisation a few years ago (R…

To stay agile

When you don’t train and eat you grow fat. When you grow fat it’s hard to move fast and swiftly, to be agile. To stay lean many decide to train, but training costs effort.

You can have fun and hack around with your friends cq. colleagues (which is what “Individuals and interactions over processes and tools” seems to suggest), but if you just drink beer and have fun, responding to change will someday become hard. You run fat, how agile your weekends of hacking may seem.

The end-goal of agile software development is continuous and fast delivery of better software, no matter how you’d like to define that. But to stay agile requires training. Not only adding features (consuming feature-stories) but also continuously sharpening the tools that support the process, automate the process. Developing software that supports it to such extent that the process becomes a no-brainer. Hence, proper tooling over (manual) processes: automated tes…

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…

Agile is dood, leve agility!

Niet lang nadat ik een eerste post had geschreven in mijn miniserie over het agile manifesto kwam ik een talk tegen van Dave Thomas, een van de opstellers van het manifest voor agile software ontwikkeling, die verklaarde dat Agile dood is.

TLDW (too long, didn't watch); Agile is geen zelfstandig naamwoord, dus 'Agile Manifest' is sowieso een raar begrip, maar het verkoopt lekker. Agile wordt verkocht als een kant en klaar pakketje wijsheden dat je gemakkelijk kunt implementeren met behulp van (goed betaalde) experts. Deze wijsheden worden gepresenteerd als universeel (iets dat geen enkele regel is). Probeer daarentegen altijd stapsgewijs je proces, product, project (… eigenlijk alles) verder te optimaliseren volgens het enige universele stappenplan dat er is:

1. Weet waar je je bevind
2. Neem een klein stapje naar je doel …

Mensen boven procedures

"Mensen en hun onderlinge interactie boven processen en hulpmiddelen," zo schrijft het Agile Manifesto voor. Maar waarom hebben zoveel bedrijven dan nog steeds urenregistratie systemen die niet werken? Waarom houden we allemaal zaken bij over de tijdsinvestering in een feature terwijl de voortgang er niet anders van wordt? Mensen zijn écht belangrijker.

De voortgang bewaken is belangrijk. De kosten onder controle houden ís belangrijk. Ga echter niet voorbij aan het primaire tastbare, en dus ook meetbare, resultaat waar de meeste medewerkers in je organisatie aan werken: het eindproduct. Stop met geloven dat je zeker weet wanneer iets precies af zal zijn, want geen ontwikkelaar kan in uren schatten. Schat grof in story points (of complexiteitspunten) en meet de snelheid en kosten van de realisatie op basis van afgeronde onderdelen.

Helaas, ook bij organisaties die aan een agile-variant zeiden te doen heb ik het maar al te vaak mis zien gaan. Blijkbaar blijft de aantr…

Onkruid bestaat niet

Gisteren stond in de NRC (Lex Veldhoen, p. 12-13) een necrologie van Louis Le Roy. Ik heb wel eens een documentaire over hem gezien. Zijn motto: “Onkruid bestaat niet.” Na zijn kunstopleiding tekenen is hij zich gaan verdiepen in bio- en ecologie. Kunsthistoricus Huub Mous beschrijft hem in het artikel als een bouwmeester in ruimte en tijd, géén tuinarchitect.

Als de bouw klaar is, begint het pas, maar de architect is klaar. De bouwmeester die ook tijd overziet daarentegen is altijd bezig.

Louis le Roy in zijn ecokathedraal in Mildam (fotograaf: Peter Wouda)

Werken met de natuur, mensen incluis, is eindeloos meer schoner dan een architect ooit kan verzinnen. Architectuur is ontwerpen voor stilstant, want beweging laat zich niet modelleren.

Ik verzin er als amateurfilosoofje, en als [agilist](…

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…

100% zelfstandig

Even geen inhoudelijk geneuzel over het grote web, goede mens-machine interactie, ERP systemen of wat dan ook. Even een mededeling: sinds 1 juni ben ik niet langer meer werkzaam als werknemer bij The Bean Machine, maar werk ik als zelfstandige/zzp'er/freelancer(!)Hoewel ik het bij The Bean Machine bijna drie jaar lang ontzettend naar mijn zin heb gehad deed zich onlangs een niet voorziene kans voor waarvan ik heb besloten dat ik die moest pakken. Hoezeer ik mij ook verbonden voelde met het bedrijf waarvoor ik werkte, soms is verandering goed.Natuurlijk was ik al wat langer bezig met verzelfstandigen, maar overnight succes was er voor mij niet bij. (en als je het gelinkte artikel kent, dan duurt dat ook nog wel even ;) )Waarschijnlijk komen er nog wel samenwerkingen met The Bean Machine terug, maar vooralsnog ben ik dus vooral bezig met die klus waardoor ik het dus aandurfde om mijn arbeidscontract te beëindigen. In opdracht van de ING zal ik Postkantoren (voornamelijk technisch) on…

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…

Hacking versus doing things ‘correctly’

Although in mainstream media hacking is considered as something bad, something criminals would do, hacking has really nothing to do with bad things. Hacking in software is about building a bazaar instead of building a cathedral (Raymond, 1999). Hacking is central to the idea of agile programming and the free software movement. While building a cathedral is about planning things properly, the bazaar way is the shacky way of hacking things together. Being able to build something cheaply, quickly. The it-just-works approach. Others counter this notion of hacking it together as something being unstable. In the long run, they argue, hacking will be more expensive. But think about it… how often have you worked on something great, something really complex, something you’ve tried to release perfectly, and a) how often have you succeeded in actually releasing something and b) how much better has it become through this careful process of discussing, planning and crafting - doing it the right …

Wat blijft er over van de Toyota way?

Veel genoemd in de Agile wereld is de zgn. 'Toyata way'. Het is dan ook enigszins schrijnend te lezen dat het zo slecht gaat met Toyota. Want eigenlijk hoop je, als Agile minded persoon, dat het goed gaat, ongeacht crisis, met bedrijven die inspirerend zijn voor de manier van werken zoals jij dat doet. Toyota zou toch mean lean moeten zijn t.o.z. van de concurrentie? Het over het algemeen erg conservatieve The Free Republic (ik vond het ook maar via Google ;) ) kwam met een, naar ik kan beoordelen, aardig inzicht in de situatie van Toyota. Toyota is niet mean t.o.z. van zijn werknemers.

Vanuit een Angelsaksisch-perspectief is dit niet echt gunstig, want flexibel werknemers in en uit het bedrijf kunnen zetten lijkt financieel gunstig (en lean). Maar de Toyota way heeft op de langere termijn wel bewezen dat er wel degelijk iets te zeggen valt voor een lange termijnscontract met de werknemer. De werknemers leren zichzelf managen, en processen zelf te sturen naar verhoogde …

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…