ASL & Agile - een mooi koppel

Agile in relatie tot Softwareontwikkeling en onderhoud

Nieuwe methoden moeten zorgen dat we beter en sneller nieuwe producten kunnen opleveren. Agile beperkt zich niet tot softwareontwikkeling, maar in dit verhaal kijk ik alleen naar Agile in relatie tot softwareontwikkeling en onderhoud.

Onderhoud en vernieuwing?

Binnen ASL is één cluster, genaamd Onderhoud en vernieuwing, dat helemaal gericht is op het onderhoud en eventuele vernieuwing van applicaties. De gedachte daarbij is dat alle aspecten die bij nieuwbouw een rol spelen, ook van belang zijn bij aanpassingen op bestaande applicaties. Een volledig correcte aanname.

Als we naar dat cluster kijken, krijg je wel de indruk dat het allemaal erg gebaseerd is op de traditionele waterval methode. En inderdaad, de oorsprong van dit cluster is gelegen in de inzichten die verkregen zijn met ontwikkel methoden zoals SDM en VSOM. Dit zijn ontwikkelmethode waarvan de oorsprong gelegen is in de vorige eeuw. Dat klinkt super oud.

Ouderwets is Nieuwerwets

Toch, als je zonder vooroordeel leest wat in ASL hierover schrijft, kom je tot de conclusie dat dit cluster tamelijk tijdloos geschreven is. De dwingende aanpak van toen is er beslist niet meer in terug te vinden.  Wat wel overgebleven is zijn de elementaire fases die noodzakelijk zijn om tot een betrouwbaar product te kunnen komen. Welke systeem ontwikkelmethode je ook pakt, je vindt altijd zaken als impactanalyse, ontwerp, realisatie, testen en implementatie. Wat per methode anders kan zijn, zijn de gebruikte ontwerp technieken en bouwtools. Daarover schrijft ASL niets voor. Agile overigens ook niet.

Bij Agile gaat het om in een korte tijd een werkend product op te leveren. Het is een iteratief proces waarbij na elke oplevering weer meer van de beoogde functionaliteit tot stand komt.  Er is niets in het Agile manifesto te vinden dat strijdig zou zijn met de uitgangspunten van ASL.

Agile Manifesto 

Het Agile Manifesto geeft 12 principes:

• Klanttevredenheid, door snelle, continue levering van bruikbare software. 
  Klanttevredenheid en continu opleveren van bruikbare software staan centraal in ASL. Het aspect snel heeft vooral te maken met het opdelen van een complex vraagstuk in een aantal minder complexe en meer autonoom te ontwikkelen en op te leveren componenten.
• Zelfs late veranderingen in de requirements zijn welkom.
  Door het iteratief karakter en het werken met kleine releases is dit geen enkel probleem. Problemen die er wel zijn komen meer voort uit de complexiteit van het businessvraagstuk.
• Werkende software wordt regelmatig geleverd (weken in plaats van maanden).
  De traditionele omgeving is nog niet gewend aan een dergelijk kort cyclisch traject van releases. Moderne omgevingen werken al steeds meer volgens het DEVOPS concept. En weer, ASL staat dit niet in de weg. De manier waarop velen in het vakgebied tegen deze moderne aanpak, staat dat wel in de weg. Zoals altijd, wij IT’ers zijn gek op veranderen … maar dan vooral bij anderen.
• De ontwikkelaars werken nauw en dagelijks samen met de mensen die de business kennen.
  Met name in het gedeelte van impactanalyse, ontwerp, testen en realisatie komt deze betrokkenheid van de business in ASL tot stand. Slechts bij Realisatie is er geen directe betrokkenheid van de business. Aangezien we in het kader van Agile werken, ons focussen op kleine releases, zal ook die realisatie fase slechts een beperkte omvang kennen.
• Projecten steunen op gemotiveerde en betrouwbare personen.
  Dit is niet afhankelijk van de beheer- en onderhoudsmethode, maar van de manier waarop je aan peoplemanagement doet en vanuit het management een ondersteunende rol vervult..
• Een gesprek in levende lijve is de beste manier van communicatie, wat betekent dat men zich bij voorkeur op dezelfde plek bevindt.
  Dit gaat over de manier waarop mensen samenwerken. Ook binnen ASL is het communicatie-aspect een belangrijk element. ASL laat de manier van samenwerken vrij. Bij de implementatie van ASL moet daar natuurlijk wel vorm aan gegeven worden.
• Werkende software is de eerste maatstaf van vooruitgang.
  Het wijzigingenbeheer van ASL zal dit direct onderstrepen.
• De ontwikkeling kan te allen tijde worden voortgezet.
  Dit heeft vooral te maken met het architectuurconcept dat men gebruikt en het delen van kennis zodat voortgang of voortzetting niet afhankelijk is van een specifieke medewerker.
• Er is voortdurende aandacht voor technische uitmuntendheid en goed ontwerp.
  Dit staat expliciet beschreven in de ontwerp en realisatiefasen van ASL.
• Eenvoud is belangrijk: hoe meer er niet gedaan wordt, hoe beter. 
  Dit slaat vooral op het beperken van functionaliteit die men in eerste instantie wel denkt nodig te hebben, maar waarvan vaak achteraf blijkt dat niemand het gebruikt. Dit heeft meer te maken met een goede opdrachtdefinitie afkomstig uit BiSL9

• De teams organiseren zichzelf.
  ASL laat de inrichting van een bouwteam en de interne aansturing daarvan geheel vrij. Dus beslist niet strijdig met ASL.
• Men past zich aan aan de omstandigheden
  Het zoeken naar effectievere werkwijze is een aspect binnen ASL-kwaliteitsmanagement. Daarbij gaat het zowel over methoden, processen, producten en het kwaliteitssysteem zelf.

De kritiek op Agile is vaak ook geheel niet aan Agile te wijten

 Er wordt vaak gesteld dat Agile

• Een gebrek aan structuur, discipline en documentatie in de hand werkt;
  Traditionele ontwikkelmethoden bieden inderdaad wel meer structuur, maar discipline heeft vooral betrekking op het individu en het team. De ruimte om te documenteren is sterk afhankelijk van zij die de medewerkers faciliteren.
• onvoldoende softwareontwerp omvat;
  De vraag is wanneer iets onvoldoende is. De verleiding om maar zo weinig mogelijk vast te leggen vanwege de tijdsdruk is inherent aan kortcyclische aanpakken. Met de juiste vakkennis en discipline hoeft dit nadeel geen realiteit te worden.
• alleen werkt met ervaren ontwikkelteams;
  Hoe complexer de methode of het te ontwikkelen product is, des te belangrijker is het dat je met ervaren medewerkers aan de slag kunt. In dat opzicht zou Agile juist ook moeten werken met relatief onervaren medewerkers. De eerste cycli zullen vooral een leercycli zijn. Doordat medewerkers in een korte tijd met “repeterende klappen van de zweep” te maken krijgen is het verkrijgen van een brede ervaring gemakkelijker en op kortere termijn te realiseren. 
• te veel culturele verandering vereist; 
  Elke verandering is wennen en is vaak een cultuurverandering. Inderdaad, niet alleen het bouwteam, maar ook de klant zal moeten wennen aan een andere manier en intensiteit van samenwerken en communiceren. Dit is dus niet specifiek een nadeel van Agile.
• Niet vooraf aangeeft wat men krijgt. 
  Dit kan daardoor leiden tot moeilijkere contractonderhandelingen bij fixed price-projecten. Deze zijn daarmee bijna onmogelijk, men kan eigenlijk alleen een vast uurtarief afspreken.

En men weet niet vooraf wat men wil. Dit is waarom de traditionele aanpak niet werkt. Het is juist vereist dat de klant vooraf precies weet wat hij wil. “Men weet vooraf niet wat men krijgt” is juist het gevolg van niet vooraf weten wat je wil.  Dit nadeel is nauwelijks toe te wijzen aan Agile. En de klant zal hier ook blij mee kunnen zijn. Hij gaat immers niet betalen voor ontwerpen en gebouwde functionaliteit die nimmer gebruikt gaat worden.

Kortom, Agile en ASL bijten elkaar niet. Het agile concept is prima hanteerbaar binnen de kaders die ASL aanreikt.

Benieuwd naar onze Agile trainingen?

Of heb je vragen over dit vakgebied of één van onze trainingen? Neem gerust contact met ons op. We helpen je graag!