Door software te ontwikkelen met de agile-methode kun je snel leveren en aan de wensen van de klant voldoen. Dat klinkt te mooi om waar te zijn.
Als je als leverancier bij een organisatie aanklopt met de mededeling dat je gevraagde maatwerksoftware binnen drie maanden kunt opleveren tegen een lager tarief dan de concurrent, wordt dat niet vaak geloofd. "Dat het te mooi is om waar te zijn krijgen we regelmatig te horen", lacht solution delivery manager Ruud Hochstenbach van Outsystems. De leverancier pretendeert met zijn software sneller software te kunnen ontwikkelen dan de concurrent. Dat komt omdat het dat doet volgens de agile-methode.
Bij deze methode wordt een project in kleine stukken gehakt. Outsystems levert iedere twee weken een product op. "Dat is werkende software", zegt presales engineer Tony van Heijst van Outsystems. Maar de periode kan ook wat langer zijn, bijvoorbeeld een maand of zes weken. "Het gaat erom dat een klant een overzichtelijk product te zien krijgt waar hij feedback op kan geven", zegt van Heijst. De feedback van de klant wordt meteen verwerkt. De bedoeling is dat de klant een product krijgt waar hij niet om heeft gevraagd, maar wel is wat hij wil.
Traditionele manier
In tegenstelling tot een project dat op de traditionele manier wordt uitgevoerd, zijn de functies van de software aan het begin nog niet bekend. Een product kan daarom andere functies krijgen dan dat de klant in eerste instantie vroeg. "Dat wil niet zeggen dat het een heel ander product wordt. Als een klant een crm-applicatie vraagt, krijgt hij dat en geen erp-pakket", zegt van Heijst.
Deze manier van werken vereist dat een goede projectmanager het project moet beheren. Gebruikers hebben de neiging veel functionaliteiten toe te willen voegen. De projectmanager moet prioriteiten kunnen stellen en knopen moeten doorhakken. "Een projectmanager is wat meer tijd kwijt met een agile-project", vindt van Heijst.
Druk bij gebruiker
Maar ook bij de gebruiker ligt meer druk. Hochstenbach vergelijkt het met een trein. "De gebruiker moet zorgen dat de rails er ligt. Als er geen input is, dan kunnen wij niet verder." Het betrokken krijgen van de gebruiker is van essentieel belang en kost wat tijd. Marketingmanager Mike Jones: "Bij de eerste oplevering en feedbackronde zitten de gebruikers er erg ongeïnteresseerd bij. Bij de tweede ronde merken ze dat er echt wat met hun feedback wordt gedaan en dan zijn ze enthousiast." Ook Joost de Graaff, business process engineer bij energieleverancier Oxxio ziet dat gebruikers snappen dat ze niet te veel tegelijk moeten willen. "Het is natuurlijk een spel. De gebruiker vraagt meer dan hij eigenlijk wil."
Volgens CoolProfs-directeur Eric Ten Harkel legt agile-ontwikkeling ook een druk bij de ontwikkelaars. "Agile is meer house dan klassiek. Je moet iedere korte periode leveren. De druk is zeker hoger." Ontwikkelaars bij CoolProfs doen twee projecten en krijgen daarna even rust. "Als je alleen maar agile-projecten doet vanaf je twintigste, dan ben je op als je dertig bent."
Vergeten
Die snelheid zorgt er ook voor dat er dingen worden vergeten. Documentatie is daarvan een voorbeeld. Oxxio merkte dat agile wat minder geschikt is voor het aanpassen van een bestaand softwarepakket. "Veel maatwerk bij een standaardpakket maakt de software moeilijker beheerbaar. Snel opleveren gaat niet als je veel beheer moet doen. Om daar goed naar te kunnen kijken heb je meer tijd nodig", zegt De Graaff.
Software ontwikkelen op de agile-manier is niet nieuw. Voorloper van agile is Rapid application development (rad), een methode ontwikkeld in 1989. "Nu beginnen bedrijven de voordelen van agile te zien", zegt van Heijst. Dat komt, volgens hem, omdat zestig procent van de traditionele projecten faalt. Volgens Outsystems-ceo Paulo Rosado komt de populariteit omdat agile in tijden van economische teruggang interessant is. "Je kunt klein beginnen en hebt daarom minder budget nodig."
Klinkt inderdaad te mooi om waar te zijn.
Voor pure softwareprojecten die niet al te complex zijn zal dit werken, daar twijfel ik niet aan.
Maar gaat dit ook werken bij:
* grote projecten met complexe (embedded) software? Je architectuur moet het immers wel mogelijk maken om je product in kleine deelproducten op te leveren, die ook nog iets functioneels kunnen toevoegen
* projecten met mechatronica, waar je levertijden hebt van 12 weken of meer. Met een increment van 4 weken, moet je toch wat verder vooruit kijken dan je eigen increment lang is
* projecten met lange complexe testtrajecten (duurproeven op electro-mechanisch gebied, stralingsproeven, emc-proeven). Dit zijn dure, kostbare proeven, die je niet ieder increment even kunt herhalen
* projecten met lange vrijgavetrajecten (denk aan medische rontgen apparaten, MRI scanners, electronica in de auto-industrie). Zo’n traject is qua prijs vaak kostbaar, maar ook wat doorlooptijd en complexiteit betreft. Aan een interne klant kun je weliswaar wat werkends laten zien (proto’s), maar de echte, betalende klant zal toch tot het eind moeten wachten aleer hij iets opgeleverd krijgt.
Agile trajecten zijn erg goed geschikt om te gebruiken wanneer het einddoel helder is maar de weg ernaar toe nog onduidelijk is. Hoe meer er bekend is (of moet zijn) van het einddoel hoe minder geschikt een agile traject is.
Een MRI scanner bouwen is zeker ongeschikt voor een agile project omdat dit enkel de realisatie is met keiharde specificaties.
@Peter
Zo hard zijn de specs niet altijd van medische apparatuur. Voor de hardware kant zijn de specs redelijk “hard”, maar voor de software (denk daarbij bijvoorbeeld aan beeldverwerking / bewerking) zijn deze specificaties behoorlijk “zacht”
Op zich een leuke poging, maar diverse geinterviewde personen hebben toch duidelijk niet alle aspecten van het Agile zijn in de vingers:
“De Agile methode” bestaat in ieder geval niet. Agile is een verzamelnaam van methodieken zoals Scrum, DSDM, RUP, etc. die een aantal gemeenschappelijke kenmerken hebben (even googelen en dat wordt wel duidelijk). Afhankelijk van het project, de omgeving en van je persoonlijke voorkeuren kan de best passende methodiek worden gezocht.
Verder vallen mij zinsneden op als: “Als je alleen maar agile-projecten doet vanaf je twintigste, dan ben je op als je dertig bent.” Dan moet je echt nog eens het principe “sustainable pace” maar eens bestuderen. Het gaat er juist om dat je projecten doet in een tempo dat je lang kunt volhouden.
Het grootste deel van de snelheidswinst komt niet uit het harder of langer werken, maar juist uit de absolute focus op die features die daadwerkelijk bijdragen aan het realiseren van de business case, het continue zoeken en wegwerken van waste in het proces en gefocust bezig zijn in overzichtelijk perioden met een duidelijk einddoel (iteraties). Een prima principe is: Als je moe bent: ga naar huis!
Daarnaast is een observatie als “Die snelheid zorgt er ook voor dat er dingen worden vergeten. Documentatie is daarvan een voorbeeld” ronduit belachelijk. Dit gebeurt alleen maar in teams die Agile als excuus gebruiken om allerlei zaken niet te doen. In het geval je met een dergelijk team te maken hebt moet je de problemen niet in de methodiek zoeken, maar in de motivatie van de medewerkers.
Een goed Agile team heeft duidelijk op het netvlies heeft dat een bepaalde set aan documentatie onderdeel is van de “Definition of Done”, dit wordt van tevoren afgesproken met de product owner. In dat geval wordt de documentatie juist niet afgeraffeld in het laatste stadium van een project, maar wordt aan het einde van elke iteratie opgeleverd samen met de werkende software.
Als je meer wilt weten over Agile methodieken in grotere complexe projectomgevingen, medische applicaties, embedded systemen, etc. is het verstandig om eens te gaan praten met bedrijven als Ericson, Philips, bol.com, ThoughtWorks, Ebay, etc.
Als je werkelijk geinteresseerd bent in Agile methodieken is het erg leerzaam om een Agile conferentie te bezoeken (zoals de XPdays). Hier worden veel praktijkcases gepresenteerd. veelal over grote complexe projecten in complexe omgevingen.
Eens met Eelco, de essentie van Agile is veel genuanceerder dan in het artikel wordt verwoord. Beheersing en flexibiliteit gaan hand in hand. Een doel van Agile is grip en controle krijgen op wat je doet, hoe je het doet en wat je produceerd. Mede daardoor kun je bewuste en verantwoorde keuzes maken. Mensen laten opbranden in een project, zodat ze daarna weer rust nodig hebben kan een bewuste keus zijn, maar is beslist niet verantwoord. Dat getuigd niet van respect voor de medewerkers en visie op verwantwoordelijk opdrachtgeverschap.
@pascal: tuurlijk zijn er situaties die niet volgens het boekje kloppen, sterker nog, werken volgens het boekje bestaat niet. Agile methodes, zoals Scrum, bieden een basaal proces templeate dat je verder moet invullen naar jouw situatie. En natuurlij moet je verder kijken dan je huidige iteratie. Logisch, al was het maar om de situaties die jij beschrijft. Maar wat je echt wel uit Agile werken wilt halen is de PDCA cycle (Plan, Do, Check, Act). Richt je daar de proces, overlegstructuren en rapportage op in, dan ga je als (project)organisatie leren om steeds beter en effectiever te organiseren. Het gaat om de essentie en je doel, niet over het ritueel.
Bij Agile wordt de documentatie niet ‘vergeten’. Het is 1 van de basisprincipes van agile. Door nauwere samenwerking heb je geen documentatie nodig… (is de theorie).
Overigens werkt RUP ook met incrementeel en iteratief ontwikkelen.
I.g.v. RUP en volgens mij de meeste methoden uit de Agile familie is het gebruikelijk dat de meeste documentatie aan het begin van elke iteratie minimaal op hoofdlijnen klaar is. Als de iteraties lang zijn (> vier weken) is het normaal dat aan use cases e.d. nog wat alternatieve scenario’s toegevoegd worden, soms een paar dagen voor de realisatie, maar het meeste is dan af want anders kunnen je niet goed/effectief plannen. De werkwijze die hier beschreven wordt doet mij denken aan een andere tak van sport: Extreme Programming (zonder ontwerp), waarbij als het goed is op het eind nog wat gedocumenteerd wordt!
Leuke zinsnede van Kees:
“Door nauwere samenwerking heb je geen documentatie nodig… (is de theorie).”
Als je medische apparaten moet valideren voor de amerikaanse markt (FDA) kom je hier niet mee weg vrees ik.
@Gerard: ook een leuke slotzin:
“Het gaat om de essentie en je doel, niet over het ritueel”
Dat doel kun je ook halen met andere methoden, niet alleen met agile.
Agile heeft wat mij betreft 1 heel groot pluspunt: men moet op tijd nadenken over wat men wil en hoe. Nu zie je vaak dat mensen starten op basis van wat vage kreten, en er tijdens het project pas duidelijk wordt wat men moet maken. Binnen de agile methodieken wordt de vragende partij geforceerd hier op tijd over na te denken, en met duidelijke specificaties te komen.
@Eelco: bedrijven als Philips en Ericsson zijn mij niet onbekend; maar als ik kijk naar de projecten die daar met de Agile methodiek gedaan worden, zijn dat niet de grote complexe projecten waar ik op doel. De agile projecten die daar gedaan worden zijn hoofdzakelijk software-only projecten, en dan meetal ook nog zo opgezet dat er weinig relaties zijn met externe partijen die ook software moeten aanleveren.
Bij complex begin ik te denken aan overall project met daaronder meerdere sub-projecten, die elk weer ??n of meerdere deelsystemen opleveren; welke onderling weer relaties hebben. Dit gecombineerd met hardware, embedded software, 3rd party software en ontwikkeling over meerdere locaties / meerdere landen.
De grootste winst van Agile zit voor mijn gevoel met name in een stukje cultuuromslag: duidelijke afspraken maken over wat je maakt, wanneer je het oplevert en met welke kwaliteit, en misschien nog wel belangrijker: je er ook aan houden.
Agile ontwikkelmethodes zijn goed toe te passen in specifieke situaties. Deze situaties zijn als van te voren niet alles kristalhelder is mbt de klantwens. Agile zorgt ervoor dat beslissingen die genomen moeten worden daadwerkelijk genomen worden, omdat anders het proces stil valt. Als de klantwens voor de bouwfase stabiel en kristalhelder is, dan is een Agile-aanpak niet wenselijk ivm de kosten. Het is een mogelijkheid/optie die je hebt als ontwikkelmethode en niet DE ontwikkelmethode. Let wel op dus dat je niet de Agile-aanpak kiest om vervolgens de klantwens niet stabiel en kristalhelder te maken. Het zou mij niet verrassen als dat zo af en toe gebeurt, bewust en onbewust.