Het begrip Agile kennen we vooral van het Agile Manifesto van begin deze eeuw. Iteratief ontwikkelen als tegenhanger voor ontwikkelen in een waterval methode is terug te leiden naar 1957 bij IBM. Ik bespreek eerst kort wat achtergrond over Agile werken. Daarna ga ik in op de factoren die de implementatie van Agile tot een succes maken.

Scrum

Het begrip Scrum werd gebruikt als analogie voor iteratief ontwikkelen door Takuchi en Nonaka in hun baanbrekende artikel over New New Product Development in 1986. In dit artikel kwamen de heren tot de conclusie dat de ontwikkelingen zo snel gaan dat je op een andere manier innoveren moet faciliteren. Dus niet in kop-en-staart trajecten waarbij je gebaseerd op uitgebreide studies en plannen toewerkt naar een product gereed voor marktintroductie, maar veel meer iteratief waarbij de ontwikkelaars elkaar de bal toespelen en samen bepalen hoe ze richting het einddoel komen. Vandaar de analogie met een Scrum.

Scrum is een term uit rugby en dient om al de forwards en de scrum halves op één plaats van het veld te verzamelen, zodat de backs een aanval kunnen opzetten door de gecreëerde ruimte te gebruiken. Hierbij werk je samen vanuit verschillende competenties, bescherm je de aanvallers en ga je het liefst in een rechte lijn, maar in de praktijk zigzaggend naar het einddoel toe omdat je moet reageren en waar het kan anticiperen op jouw tegenstander.

De noodzaak van Scrum

In hun artikel gaven Takuchi en Nonaka aan dat het sneller opleveren van innovaties een noodzaak is om de simpele reden dat de omgeving sneller verandert. Je wilt namelijk voorkomen dat op het moment dat je iets oplevert hetzij de oorspronkelijke vraag van de klant achterhaald is of dat de technologie of een substituut je ondertussen heeft ingehaald. Is het sneller opleveren dan succes of bittere noodzaak om het tempo van veranderingen te kunnen bijbenen? Het is maar hoe je ernaar kijkt. Het sneller opleveren is een duidelijke indicator, want als per saldo projectmatige opleveringen in een Agile & Scrum omgeving niet sneller worden opgeleverd, dan is de vraag wat je met de hele transformatie bent opgeschoten.

Kortere doorlooptijd is geen garantie voor succes

Verkorten van doorlooptijd is dan ook een duidelijke indicator, maar geen doorslaggevende om twee redenen. De eerste reden is het feit dat als je in timeboxes gaat werken en werkt met tussentijdse opleveringen, je vanzelf effectiever wordt. Het is bekend dat als studenten tussentijds toetsen hebben of tussentijds moeten opleveren, dat dan de kans op studiesucces groter is dan als ze pak hem beet 4 keer per jaar moeten opleveren. Timeboxing en tussentijds opleveren in korte tijdsintervallen zorgen ervoor dat je naar verhouding meer oplevert.

De tweede reden dat verkorten van doorlooptijd bij een Agile & Scrum implementatie vaak niet doorslaggevend is, is als bij de implementatie derde partijen zijn betrokken zoals begeleiders van de Scrum en/of Agile transformatie, heel veel handjes in de IT die in het voormalige Oostblok of India zitten enzovoorts. Dan is de vraag of al die extra handen licht werk maken of dat dat komt door de Agile & Scrum transformatie. Ook hier zullen beiden effect hebben waarbij de vraag dan is welke het sterkere effect heeft: de transformatie of de extra inzet.

De sleutel tot een succesvolle Agile implementatie: betere innovatie

Doorslaggevend voor een succesvolle Agile implementatie is of je in staat bent nieuwe producten of diensten te ontwikkelen die jouw klanten kunnen cultiveren. Succes is dan meetbaar in toename van het marktaandeel ten opzichte van directe concurrenten of in een krimpende markt het doorbreken van een dalende trend.

Alleen het lastige is dan dat je niet meer innovaties moet hebben met het risico dat je meer van hetzelfde krijgt, maar dat je betere innovaties moet hebben. Dat is lastig, want werken met kleinere tijdsintervallen, wil nog niet zeggen dat je ineens innovatiever wordt en betere ideeën krijgt. En als je krijgt wat je vroeger al kreeg maar dan sneller, dan kan je dat een tijdelijk voordeel opleveren, maar zodra in de markt jouw concurrenten hetzelfde gaan toepassen, dan is die voorsprong ook al weer weg. De echte sleutel in een succesvolle Agile implementatie zit dan ook in betere innovaties. Die betere innovaties komen niet vanzelf en moet je faciliteren en je daar ook naar gedragen.

Focus

Een eerste gedragskenmerk voor het faciliteren van innovaties is Focus. In de meeste organisaties is het opstarten van projecten het probleem niet. Het afmaken is het probleem. Agile gaat over focus en dat betekent focus voor het ontwikkelteam en focus vanuit de business op wat wel en wat niet te doen. Nu je niet alles kunt doen, is juist een kenmerk van Agile duidelijke focus op wat wel je wel doet en vooral wat je dan niet doet.

Focus herken je door de duidelijke verhaallijn in de backlog zodat je zelfs als onafhankelijke derde na lezen weet waar de organisatie de slag om de klant denkt te gaan winnen en hoe ze dat willen bereiken. Als een Backlog echter rijp en groen door elkaar is en een hoog gehalte heeft van ‘niet geschoten is altijd gemist’ dan weet je dat je de basisvraag moet stellen Hoe je zometeen echt onderscheid maakt voor de klant en op de activiteiten die daaraan bijdragen de Focus legt. Dat wil zeggen dat je als organisatie Nee zegt tegen activiteiten die daar niet direct aan bijdragen en Nee durft te zeggen.

Co-creatie

Een tweede gedragskenmerk is co-creatie. Agile en Scrum hebben als basis gedachte dat innovaties tot stand komen door co-creatie met de klant. En als we het over de klant hebben dan hebben we het over ‘echte’ klanten van vlees en bloed. Want als we spreken met iemand die zelf met een klant heeft gesproken en onze informatiebron is, dan zit daar een extra slag in dus verlies van informatie. Laat staan als eigenlijk niemand echt met de klant heeft gesproken. Nu kan dat best wel eng zijn, want je moet je kwetsbaar durven opstellen als organisatie. Bedrijven als IKEA en Netflix zijn in ieder geval niet slechter geworden van co-creatie en voorbeelden van innovatieve bedrijven. Echte co-creatie op basis van gelijkwaardigheid met klanten is dan een onderscheidend kenmerk voor innovatieve organisaties en succesvolle Agile implementaties.

Bottle-necks

Een derde gedragskenmerk heeft betrekking op hoe je omgaat met de bottlenecks in jouw ontwikkeltrajecten. Ontwikkelaars met specifieke ontwikkelcompetenties zijn namelijk de bottlenecks in het toevoegen van waarde. En omdat ze specifieke kennis hebben, zullen ze in veel ontwikkelingen betrokken worden.

Zo kwam ik laatst een ontwikkelaar tegen met specifieke kennis die in 20 projecten betrokken was. Theoretisch zou hij dan 2 uur per project kunnen besteden, echter heeft hij ook zijn eigen werk en daarbij je bent zelfs in die twee uur niet continu bezig om waarde toe te voegen. Je moet afstemmen, je moet omstellen etc. Ik vroeg aan deze ontwikkelaar die een beetje met zijn ziel onder de arm liep om eens bij te houden hoeveel tijd hij nu bezig was met echt code te schrijven. Op een werkweek van 40 uur was hij eigenlijk bij elkaar niet meer dan 2-4 uur bezig om echt te doen wat hij zou moeten doen en dan nog werd dat ingegeven door wat hij noemde ‘degene die het hardste schreeuwde’.

Door iemand naast de bottleneck te zetten ontlast je de bottleneck niet alleen, maar krijg je kennisdeling. Verder kan de bottleneck maar aan één ding tegelijk werken dus in plaats van bottlenecks op van alles en nog wat te zetten, zul je ook hier een toestand van ‘one-piece-flow’ moeten creëren en daarop het kritieke pad afstemmen. Wat dan met iedereen die iets wilt van de bottleneck? Simpel gezegd wachten totdat de bottleneck klaar is en de volgende aan de beurt is.

Zelf leren?

Wil je zelf Scrum Master worden of je kennis opfrissen? Volg dan onze opleiding tot Scrum Master. Tijdens onze opleiding maken we gebruik van echte casussen en is er voldoende ruimte om jouw situatie in te brengen. Bovendien hebben wij een database met honderden oefenvragen, zodat jij je optimaal kunt voorbereiden op het officiële PSM examen!

Meer info?

Je kunt ook vrijblijvend contact opnemen met info@5st3ps.nl.