De oorsprong van Agile

Ook al is je ontwikkelteam nog niet overgestapt op agile methoden zoals Scrum of Extreme Programming, de kans is groot dat ze het op z'n minst overwegen. "Agile" pakt namelijk een aantal van de grootste problemen aan waar softwareteams al tientallen jaren mee worstelen. Veel productmanagers, designers en ook mensen uit de kwaliteitsborging zijn echter in eerste instantie geïrriteerd door Agile, omdat ze nog niet echt vertrouwd zijn met hun rollen binnen agile methoden. Deze methoden vereisen absoluut deze rollen, maar de verwarring schrijf ik toe aan de oorsprong van de agile methoden. Om de problemen te belichten die "Agile" wil oplossen en om te ontdekken welke uitdagingen blijven bestaan, is het handig als ik de oorsprong van Agile uitleg.

Veel mensen zijn verbaasd als ze horen hoe lang Scrum – de bekendste agile methode – al bestaat. Het ontstond in 1986 in Japan. (Een voorbeeld van hoe lang het kan duren voordat een nieuw idee eindelijk doorbreekt.)

De oorsprong van Agile ligt in maatwerkoftware

Het belangrijkste is echter dat deze methoden afkomstig zijn uit de wereld van maatwerkoftware (Custom Software).

Maatwerkoftware, dus software voor een specifiek doel en voor een specifieke klant ontwikkelen, was lange tijd een extreem lastige vorm van softwareontwikkeling. Dat komt deels doordat klanten notoir niet weten wat ze precies willen. Ze hebben echter wel een behoefte en dus tekenen ze een contract met een bedrijf voor maatwerkoftware of zitten ze met hun interne IT-mensen om de tafel, die er vervolgens aan moeten werken. Maar als er dan iets wordt opgeleverd, zeggen klanten standaard dat het niet is wat ze wilden en dan begint alles opnieuw, waarbij de frustratie natuurlijk steeds groter wordt. De onderliggende behoefte blijft echter bestaan en dat heeft ontelbare softwareontwikkelaars, bedrijven en dienstverleners hun baan bezorgd.

Bovendien heeft men bij de ontwikkeling van maatwerkoftware vaak aan het kortste eind getrokken als het ging om het aannemen van mensen en het binnenhalen van de beste softwaretalenten. Dat komt waarschijnlijk deels doordat professionals liever werken bij bedrijven die software ontwikkelen voor duizenden of zelfs miljoenen klanten. De reden daarvoor is onder andere dat professionals bij die bedrijven een hogere beloning ontvangen, waar het productteam softwareproducten moet ontwikkelen die veel mensen willen hebben, omdat ze anders geen geld verdienen. Deze bedrijven weten dat ze goede mensen moeten aannemen om succesvolle producten te maken en de beloning is daar dan ook naar. Toch werkt slechts een klein percentage van de softwareontwikkelaars aan standaardsoftware – de meesten ontwikkelen maatwerkoftware.

Het voordeel van Agile?

Omdat de klant bij maatwerkoftware ervan uitgaat te weten wat hij wil, kom je daar zelden de rol van productmanager tegen. Net zo min vind je er User Experience Designers. De redenen daarvoor zijn behoorlijk complex en omvatten een zekere mate van onwetendheid (de meesten in de wereld van maatwerkoftware weten niet wat UX Designers doen en waarvoor je ze nodig hebt) en kostengevoeligheid (kosten verlagen door de ontwikkelaars het design te laten doen). Eerlijkheidshalve moet gezegd worden dat de weinige designers die er in onze branche zijn, meteen worden weggekaapt door productbedrijven die begrepen hebben hoe belangrijk designers zijn. Daardoor blijven er voor teams die maatwerkoftware ontwikkelen nauwelijks designers over, als de leidinggevenden eindelijk hebben begrepen dat ze hen nodig hebben. Net zo is er nauwelijks kwaliteitsborging als aparte discipline bij maatwerkoftware en wordt van de ontwikkelaars verwacht dat zij ook het testen op zich nemen.

Een ander belangrijk punt om de wereld van maatwerkoftware te begrijpen, is dat de meeste maatwerksoftwareprojecten relatief klein zijn en bedoeld zijn om de interne activiteiten van een bedrijf te ondersteunen – zoals de HR-afdeling, facturering, productie enzovoort. Allemaal gebieden waar er slechts een beperkt aantal gebruikers is en zaken als schaalbaarheid en prestaties doorgaans niet zo heel belangrijk zijn.

Het watervalprocces

Vroeger gebruikte men bij maatwerkoftware het watervalprocces, omdat de verschillende stakeholders een manier nodig hadden om de voortgang tijdens het lange ontwikkelproces van de gewenste applicaties te kunnen volgen. Strikt genomen vindt ook de watervalmethode hier zijn oorsprong.

Bij standaardsoftware, die vanwege de prestaties en voordelen wordt gekocht, werden een aantal rollen geïntroduceerd. De productmanager moet de behoeften van alle klanten verzamelen en vertegenwoordigen. Designers moeten een bruikbare en aantrekkelijke User Experience creëren en de testers van de kwaliteitsborging moeten controleren of de software ook zo werkt als in de reclame aan de klant is beloofd.

De oplossing van de watervalproblemen kwam met agile methoden

Bij maatwerkoftware bleven echter dezelfde problemen opduiken als het ging om het creëren van iets dat klanten tevreden stelt. Juist voor deze teams betekenen de agile methoden een grote verbetering. De communicatie tussen klanten en ontwikkelaars verbetert. Het risico wordt door kleinere en frequentere iteraties aanzienlijk verlaagd. Klanten kunnen zo veel sneller ontdekken of ze iets goed vinden, dan wanneer ze zouden moeten wachten op het einde van een lang proces. Bovendien helpen agile methoden bij het invoeren van moderne concepten voor het testen van software en besparen ze teams het urenlang opstellen van documenten die toch nauwelijks worden gelezen en snel verouderd zijn.

Agile voor maatwerk- & standaardsoftware

In principe gelden deze voordelen natuurlijk ook voor standaardsoftware, maar ik benadruk altijd dat er dan een aantal zaken moeten worden aangepast. Een ander gebied waar moeilijkheden ontstonden, is de softwarearchitectuur oftewel het softwaredesign.

De agile methoden moedigen ontwikkelaars aan om zich niet te veel vast te bijten in hun manier van implementatie, want alles moet snel en eenvoudig kunnen worden herzien of omgebouwd. Hoewel dat bij maatwerkoftware vaak goed werkt, is deze aanpak bijvoorbeeld voor grote internetdiensten met honderden, duizenden of miljoenen gebruikers te naïef.

Het is dus geen verrassing dat veel teams voor standaardsoftware problemen hadden met agile methoden, omdat de oorsprong van agile methoden bij maatwerkoftware ligt. De vele boeken, artikelen en cursussen die noch productmanagers noch User Experience Designers (Interaction Designers en Visual Designers) noemen, zijn niet bedoeld voor de ontwikkeling van standaardsoftware.

Teams die willen overstappen op agile methoden in de softwareontwikkeling zouden dus vooraf moeten controleren of het bedrijf dat hun organisatie wil helpen, ook begrijpt wat er voor standaardsoftware nodig is. Dat is niet altijd het geval, maar wel vaak genoeg.