Agile development = betere business (software)

Online software en webapplicaties moeten afgestemd worden op de business processen van uw bedrijf. Niet andersom. Dit klinkt logisch, maar al te vaak zien we het omgekeerde: een software pakket dat de business NIET ondersteunt, en soms zelfs hindert. Hoe komt dit? Waarom is er zo veel software binnen bedrijven dat zijn doel mist?

Laat ons even uitgaan van een business proces dat we willen automatiseren. We willen hiervoor een online software laten ontwikkelen. We werven een legertje Deloitte/Accenture/… consultants aan die de processen komen beschrijven in flow charts. Na een paar weken of maanden hebben we een bundeltje Powerpoints. Vervolgens betalen we Softwarehouse XYZ om de processen in functionele designs te gieten. 3 maanden na de kick off van het project hebben we een FD (=Functionele Design, of beschrijving van de software die we willen laten ontwikkelen), een Word document van zo’n 250 pagina’s, waarin elk mogelijk scenario en scherm is beschreven. We gaan naar Web Dev Agency ABC, overhandigen de FD, en laten de webapplicatie ontwikkelen. 4 maanden en enkele tienduizenden euro’s later staat onze software online. Hoera!

En wat blijkt nu?

  • Je bedrijf is sterk aangegroeid op die 7 maanden. De business is veranderd. Je processen eigenlijk ook.
  • Functionaliteit ABC die op papier super nuttig en sexy leek, is eigenlijk toch niet zo interessant als eerst gedacht.
  • De mensen “op de vloer”, oftewel de dagdagelijkse eindgebruikers, vragen zich af waarom feature XYZ ontbreekt…in hun ogen cruciaal, maar blijkbaar compleet vergeten door Deloitte/Accenture/het management.

Screen shot 2011-01-03 at 15.24.11

In het algemeen geldt dat software over de tijd heen devalueert. De wereld verandert, de business verandert, processen veranderen, concurrenten veranderen, leveranciers haken af, klanten krijgen andere eisen . Alleen groeit software niet altijd mee. Agile development is een methode van software ontwikkeling, die deze problemen wil aanpakken. De belangrijkste filosofie erachter is de volgende:

Focus op 1 core probleem

Tracht dat ene, aller belangrijkste basisprobleem duidelijk te omschrijven en op te lossen. Laat eindgebruikers het probleem omschrijven. Externe (dure) consultants mag, maar eindgebruikers werken dagdagelijks met de software en bedrijfsprocessen. Zij weten waar de nood het hoogst is! Los dit ene core probleem op met het minimum aantal features die nodig zijn. Less is more. Wie houdt er niet van een eenvoudige, simpele software, die exact doet wat ie moet doen en niet meer? Het bekendste voorbeeld is het volgende scherm. Je vergissen in wat deze online soft doet is onmogelijk.

Screen shot 2011-01-03 at 15.05.38

Laat je business meteen genieten van de software

Laat je software en gebruikersinterface zo snel mogelijk los op eindgebruikers. Zet meteen online wat je online kan zetten, zelfs al ben je beschaamd over hoe weinig je software kan en hoe lelijk de interface is. Eindgebruikers zullen je dankbaar zijn, want vanaf de eerste release hebben ze (1) een basis oplossing voor hun core probleem, en (2) je geeft hen een manier om concrete feedback te geven. Feedback die gebaseerd is op gebruik van de software en niet op een 250 pagina’s dik document dat men “Functionele Design” noemt. Beter een software die na 1 week al online staat en (een deel van) het basis probleem oplost, dan een software die 7 maanden op zich laat wachten om te verschijnen op het moment dat uw processen en de wereld al deels veranderd zijn!

Korte release cycles op basis van feedback van je gebruikers

Na de eerste prille versie krijg je ongetwijfeld feedback. Positieve en negatieve. En aan de hand van die feedback kan je je gebruikers omtoveren van onverschillige gebruikers tot echte fans. Zorg ervoor dat je een eenvoudige release cycle hebt, waardoor je wekelijks kleine verbeteringen en nieuwe fine tunes online kan brengen zonder al te veel moeite. Gebruikers die vandaag klagen over een button op een ongelukkige plaats, zullen veranderen in enthousiaste fans indien die knop de week erna al op de juiste plaats staat! Gebruikers zijn je veel meer dankbaar indien je erin slaagt om een probleem meteen op te lossen of binnen de week hun feedback in nieuwe functionaliteit om te zetten, dan indien je hen belooft dat er ooit, one day, in de toekomst, een enorm fantastische soft aankomt die elk aspect van hun werk ondersteunt.

Wat is jullie ervaring met software ontwikkeling? Waar loopt het vaak fout, en hoe kunnen we dit verbeteren? Comments welkom!

Author: Pieter Eerlings

http://www.linkedin.com/in/pietere http://www.last.fm/user/pietereerlings

7 thoughts on “Agile development = betere business (software)”

  1. Pieter,

    ik ben het niet helemaal eens met 2 stellingen die je hier inneemt:

    1. een gebruiker kan je beter omschrijven waar het probleem zit, hij wordt dagelijks geconfronteerd met de processen

    2. pak probleem voor probleem aan. Beter 1 goed dan 10 half aangepakt.

    Wat beteft de gebruiker die jou als softwareontwikkelaar zal helpen met de ontwikkelingen van een stuk software: je geeft hiermee zelf een antwoord op de vraag: waar loopt het soms fout ? Wel, net daar waar de gebruiker niet het hele beeld ziet, inderdaad zijn proces te groot, te moeilijk met té veel uitzonderingen omschrijft. Immers, hij is onvervangbaar, zo lijkt het wel, én het zou jaren vragen eer iemand dat allemaal onder de knie zou hebben, weet je wel ;-). Ik blijf er van overtuigd dat het net de kracht van een consultant of een goede business of proces-analist blijft om de ware toedracht van een probleem, de juiste omschrijving van de vraag op papier te zetten. Wat is het probleem, wat is het antwoord, niet meer, niet minder. In mijn boekje omschrijf ik ook het probleem van werkgroepen en hoe men begint te fantaseren over allerlei functies die een absolute must zijn maar later bij het effectief gebruik totaal overbodig lijken.
    Secundo: je geeft aan dat je beter één probleem aanpakt en dan naar het volgende gaat als softwareontwikkelaar. Kan mij daar in vinden maar dan moet je verdomd goed weten wat the whole picture is hé. Als favoriet aanhanger van ERP-oplossingen weet ik maar al te goed dat juist de coherente samenhang, de wisselwerking en uitwisseling van informatie tussen de verschillende diensten, de verschillende werkwijzes, de grote troef is voor een goed softwarepakket. Dus ja, zorg er voor dat de elementen stuk voor stuk aanwezig zijn en goed zijn uitgewerkt maar zorg dat je eerst een duidelijke, brede basis hebt, één waar alle elementen reeds zijn uitgetekend en begin ze dan één voor één uit te werken.

    Mag ik zo vrij zijn om lezers ook mijn blog alexdossche.wordpress.com aan te bevelen. Ik heb het daar ook ERP en software in zijn algemeenheid en sluit mooi aan bij deze blog.

  2. Alex,

    Bedankt voor je bijdrage!

    Ik stel het inderdaad wat zwart-wit voor in mijn post. En ik denk ook dat onze stellingen elkaar niet tegenspreken eigenlijk…

    1 – Ivm feedback eindgebruiker:
    Het punt dat ik wil maken is het grote belang van een korte development cyclus met tussentijdse feedback van eindgebruikers. (Waarbij eindgebruikers alle stakeholders zijn natuurlijk die in aanraking komen met de soft, dus ook bijvoorbeeld het management dat er rapporten uit trekt). Op zich waardeer ik zeker het werk van business analysten / process analysten!

    2 – Ivm 1 core probleem aanpak:
    Ik heb het eigenlijk vooral over het feit dat de eerste release van een software zicht moet richten op een enkel core probleem. Probeer geen 10 zaken in release nummer 1 te steken: de gebruikers zullen enkel verward zijn. Uiteraard kan het niet bij die ene release blijven. Uiteraard groeit de soft en gaat die meer aanpakken dan enkel 1 core probleem. Maar ook daar is weer belangrijk dat die soft groeit met korte release cycles, gebaseerd op feedback.

    En ik ben zelf natuurlijk ook voorstander van ERP-systemen (ik heb zelf lang in SAP business gezeten). Maar ook de eerste release van een ERP moet in mijn ogen focus vertonen op één enkel probleem (namelijk integreren van processen), en snel ter beschikking worden gesteld van de klant, om snel feedback te verzamelen.

    => Volgens mij heeft het geen enkele zin de beste business analysten en top developers 3 jaar samen op te sluiten om een pracht soft te ontwikkelen zonder regelmatige feedback van klanten (= uiteindelijk de mensen die je betalen voor de soft).

Leave a Reply

Your email address will not be published. Required fields are marked *