If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization.

Gerald M. Weinberg

If we do not feel grateful for what we already have, what makes us think we'd be happy with more?

Blessed are they who see beautiful things in humble places where other people see nothing.

Camille Pissarro

De enthousiasme trilogie
hoe de flame, flow en flood van enthousiasme... een popster doen schitteren... organisaties succesvol maken... en de wereld een stuk mooier!
Rijn Vogelaar

Bij Bol.com | Managementboek

Problemen veroorzaken niet de haast; haast veroorzaakt de problemen.

Olaf Hoenson

In het boek Managen van agile projecten beschrijven Bert Hedeman, Henny Portman en Ron Seegers op beknopte wijze de verschillen tussen de watervalmethoden en een agile aanpak en gaan ze in op het nut en noodzaak van het met een agile aanpak ontwikkelen van software:

In de traditionele projectaanpak is de Projectmanager verantwoordelijk voor het opstellen van de plannen , het aansturen van de uitvoering en het rapporteren van de voortgang. Kortom, hij is verantwoordelijk voor het ‘aansturen en beheersen ’ van het project.

Voortgang wordt in traditionele projecten vaak gemeten op basis van het percentage gereed van de uit te voeren activiteiten. Mijlpalen richten zich op het opleveren van tussenproducten, bijvoorbeeld een schaalmodel of een stroomschema. Fasen worden meestal standaard ingedeeld naar type werk, bijvoorbeeld analyse, planning, ontwerp, werkvoorbereiding, uitvoering en implementatie. Werkzaamheden worden volgtijdelijk uitgevoerd (waterval-
methode). Resultaten worden pas aan het eind van het project opgeleverd. Gestuurd wordt meestal op basis van gedefinieerde scope en kwaliteit terwijl men probeert tijd en geld te beheersen.

In agile projecten ligt de verantwoordelijkheid duidelijk anders en worden projecten bovendien anders gestructureerd. Bij agile projecten vormen de zelfsturende teams de basis. Deze zijn volledig verantwoordelijk voor het realiseren van het op te leveren resultaat dat tot stand komt via korte iteraties in vaste timeboxes

De eisen worden bepaald door de gebruikersvertegenwoordigers in samenspraak met het Realisatieteam. De Projectmanager is alleen verantwoordelijk voor het inrichten van het project, het opstellen en bewaken van het Realisatieplan en de communicatie tussen het Realisatieteam en het bedrijfs- en programma-management. De rol van de Projectmanager kan hierbij het beste worden getypeerd als ‘structureren en faciliteren’.

In agile projecten wordt de voortgang gemeten op basis van het aandeel ‘gereed product’ en niet op basis van de gereedheid van de uit te voeren activiteiten. Mijlpalen zijn de data waarop de verschillende deelproducten worden opgeleverd (bijvoorbeeld een nieuwe functionaliteit in een website) en niet wanneer bepaalde activiteiten zijn afgerond.

Daarom kent agile ook increments en geen fasen. Soms worden increments wel fasen genoemd, maar in essentie is een increment toch iets anders dan een fase. Een increment levert een werkend deel op van het eindresultaat. Een fase levert meestal slechts een tussenproduct op. In agile projecten is altijd sprake van een incrementele oplevering .

Een belangrijk verschil zitin het iteratief ontwikkelen en het ontwikkelen op basis van timeboxes. Een iteratie is een cyclus van vaststellen, plannen, ontwikkelen en reviewen, waarin het gewenste eindresultaat verder wordt ontwikkeld. Een timebox is een vaste tijdsperiode waarbij op het einde van die periode een doelstelling wordt gerealiseerd.

Verder worden agile projecten niet beheerst op basis van tijd en geld maar op basis van het aantal op te leveren functies binnen een vooraf gedefinieerde tijd. Het Realisatieteam richt zich daarbij geheel op de prioriteiten van de klant en de gebruikers. Wat de hoogste prioriteit heeft, wordt ook als eerste ontwikkeld. Het voordeel daarbij is dat juist daarvan ook meestal de eisen al het duidelijkst zijn te definiëren. Omgekeerd zou je misschien zelfs kunnen zeggen: als we nog niet weten waar iets aan moet voldoen, dan zal de urgentie in werkelijkheid wel niet zo hoog zijn als wordt beweerd.

Een ander uitgangspunt van agile is dat niets in één keer perfect is en dat voor een goed resultaat herhaaldelijk terugkoppelen noodzakelijk is. Verder gaat agile uit van een voortschrijdend inzicht bij zowel de klant, de gebruikers als het uitvoerende team. Klanten en gebruikers weten vaak pas wat ze echt willen als ze een eerste resultaat zien. Net als het uitvoerende team zien ook klanten en gebruikers gaandeweg nieuwe, betere oplossingen. Het zou toch zonde zijn hier geen gebruik van te maken. Dit houdt wel in dat eerdere opgeleverde resultaten later soms opnieuw aangepast moeten worden. Dat is jammer, maar staat in geen verhouding tot het blijven doorgaan op de foutieve weg. Doordat de afzonderlijke iteraties meestal kort zijn, is het aanpassen van eerdere resultaten voor de meeste teamleden ook geen groot probleem. Bovendien zien zij dat het nieuwe resultaat extra toegevoegde waarde oplevert voor de klant. Al met al een hele aanpassing.

Waarom agile projecten?

(Te) laat opleveren
Te laat opleveren van de afgesproken projectresultaten zorgt vaak voor grote frustraties bij de klant en de gebruikers. Het kan zelfs een reden zijn om het project in zijn geheel af te blazen. Agile ondervangt dit probleem door juist het op tijd opleveren van het eindresultaat als uitgangspunt te nemen in de gehele projectaanpak. Een agile project wordt beheerst door het al dan niet opleveren van het aantal functies en niet door het besteden van extra tijd of geld. De ruimte in de functies wordt gevonden door het prioriteren van de functies naar de toegevoegde waarde voor de klant en het opleveren van die functies in de volgorde van die prioriteit.

Ongebruikte functies
De ervaring leert dat vaak de helft van de opgeleverde functies in traditionele projecten in de praktijk niet of nauwelijks wordt gebruikt. Dit komt doordat bij het definiëren van de benodigde functies vaak alle theoretisch mogelijke alternatieven worden geïdentificeerd zonder dat deze goed worden geprioriteerd. In agile projecten worden bij alle beslispunten in het project de functies geprioriteerd. Overbodige functies worden niet meegenomen.

De klant wil wat anders
Een andere frustratie van klanten en gebruikers is vaak dat het opgeleverde resultaat niet voldoet aan verwachtingen, welke dit dan ook maar zijn. Het eindresultaat voldoet niet
aan de kwaliteitseisen, noodzakelijke functies ontbreken of het resultaat sluit niet aan op de gewenste bedrijfstoepassingen.

In agile projecten staan de klant- en gebruikerseisen centraal. Vanuit dit principe worden diverse technieken aangereikt om optimale afstemming tussen klanten en gebruikers enerzijds en het Realisatieteam anderzijds te bewerkstelligen. Dit gebeurt door het faciliteren van workshops, het actief stimuleren van een continue samenwerking tussen gebruikers en ontwikkelaars en door het telkens tussentijds opleveren van gebruiksklare resultaten.

Voortschrijdend inzicht
Een belangrijk kenmerk van de agile aanpak is het openstaan voor veranderingen als basishouding van het gehele team. Veranderingen worden vaak gezien als een probleem in plaats van een kans. Dat komt doordat de meeste projecten zijn dichtgetimmerd in op te leveren functies en onder druk staan ten aanzien van zowel tijd als geld; in plaats van dat zij binnen de gestelde tijd en geld een zo maximaal mogelijke toegevoegde waarde moeten leveren.

Maximaliseren toegevoegde waarde
In agile projecten worden functies nadrukkelijk opgeleverd in volgorde van hun toegevoegde waarde voor de klant. Verbeteringen die meer toegevoegde waarde leveren dan de oorspronkelijk beoogde resultaten worden in die context alleen maar toegejuicht. Door de iteratieve ontwikkeling in korte cycli zijn de perioden van ontwikkeling ook maar kort. Hierdoor en door de intensieve samenwerking tussen gebruikers en de teamleden zal ook het aantal verrassingen beperkt blijven.

Vertraagde ROI
Normaal neemt de toegevoegde waarde van projectresultaten af naarmate zij later worden opgeleverd. Een uitloop van het project kan dan ook funest zijn voor de business case van het project als geheel.
Agile ondervangt dit probleem door incrementeel op te leveren. Niet alles in één keer, maar per increment wordt een werkend deel van het eindresultaat opgeleverd dat vanaf dat moment ook meteen een deel van de beoogde toegevoegde waarde levert.

Over-engineering
Teamleden hebben vaak de neiging het beste van het beste op te leveren (gold plating). Dat is vaak niet in het belang van de bedrijfsvoering. Goed is goed genoeg! Dit gebeurt meestal als het Realisatieteam geheel naar binnen is gericht. In agile projecten is het Realisatieteam echter geheel op de klant en de gebruikers gericht. Agile richt zich volledig op het leveren van de maximale toegevoegde waarde aan de bedrijfsorganisatie. Over-engineering wordt voorkomen door frequente afstemming over en prioritering van de eisen
per functie en door het incrementeel opleveren van een werkend resultaat.

Bijkomende baten agile projecten

In agile worden oplossingen iteratief ontwikkeld en incrementeel opgeleverd. Bovendien worden eindgebruikers gedurende het gehele project betrokken. Dit levert bijkomende voordelen op:

• Agile teams zijn over het algemeen productiever omdat zij directer bij de toepassing worden betrokken.
• Gebruikers en andere betrokkenen voelen zich sneller eigenaar van het opgeleverde resultaat.
• Het risico dat het verkeerde resultaat wordt opgeleverd is minimaal.
• Gebruikers worden beter getraind omdat duidelijker is hoe producten moeten worden gebruikt.
• De invoering van het eindresultaat gaat eenvoudiger doordat partijen al intensief hebben samengewerkt bij de ontwikkeling ervan.

Bron: Managen van agile projecten, Bert Hedeman, Henny Portman & Ron Seegers

Managen van agile projecten
Bert Hedeman, Henny Portman, Ron Seegers

Bij Bol.com | Managementboek

The arrogance that usually comes with organizational success is normally the root cause of eventual failure.

George Koenigsaecker

A system is a whole that cannot be divided into independent parts or subgroups of parts.

Russell Ackoff

Volgens Katarzyna Knot vormt een zgn. boilerplate een goede manier voor het duidelijk en eenduidig vastleggen van requirements. Een boilerplate is een semi-formele methode die je dwingt om requirements op een vaste, gestructureerde manier te beschrijven.

Het International Requirements Engineering Board (IREB) adviseert bovenstaande boilerplate voor het formuleren van requirements.  Een veel gebruikte boilerplate is het formuleren van een user story in termen van:

'Als een <type gebruiker> wil ik <iets doen> zodat ik <deze benefits haal>'

Bron: De manier om requirements goed te formuleren, Katarzyna Knot