Screw Scrum | Hoe het beter kan in software prototyping -en productie

21 Jan 2018

Joris Snoek - Business Dev
+31 (0)20 - 261 14 99

Veel organisaties zijn hard op weg om Agile / Scrum te implementeren, of hebben dat al gedaan. Zo deden wij dat ook enkele jaren geleden, maar wij hebben gemerkt dat het strict adopteren hiervan niet goed werkt. Onderzoek van HBR bevestigt dit; wij zijn er inmiddels voor een groot deel vanaf gestapt.

Agile softwareontwikkeling

Kaders voor adaptive software development zoals Agile, bestaan al heel lang en hebben zich in vele vormen gemanifesteerd. Maar de kern van de meeste van deze modellen bestaat uit twee dingen:

  1. Het vormen van hypothesen (bijvoorbeeld wat voor taak zou een functie moeten volbrengen).
  2. Het samenwerken van verschillende afdelingen en expertises aan prototypes.

Dit voornamelijk in het kader van het 'faciliteren van voortschrijdend inzicht' en niet het afleggen van een vastgelegd pad -wat achteraf vaak onjuist blijkt.

Toen Agile softwareontwikkeling in 2001 ontstond, formuleerde het een set van vier kritische principes om softwareontwikkeling te verbeteren en de motivatie van software developers en productmanager te boosten:

  1. Individuen en interacties boven processen en tools.
  2. Werkende software boven uitgebreide documentatie.
  3. Klant samenwerking boven contractonderhandelingen.
  4. Reageren op verandering boven het volgen van een plan.

Gedurende de afgelopen drie jaar heeft Harvard in zijn onderzoek naar motivatie de praktijken van software developers in meer dan 500 verschillende organisaties geanalyseerd met behulp van onderzoeken en enquetes. Zij hebben geconstateerd dat wat in de praktijk gebeurt, ver afwijkt van deze genoemde principes.

Dit hebben wij hier bij Lucius ook zo ervaren:

Processen en hulpmiddelen

In de praktijk blijken processen en hulpmiddelen de drivers van werk geworden, niet 'individuen en interacties'. In een groot Fortune 100-bedrijf zei het hoofd van digitale producten tegen Harvard: "We mogen het Agile-proces niet in twijfel trekken". In een andere Fortune 500-organisatie communiceren productmanagers en engineers uitsluitend via hun hulpmiddelen, die voornamelijk worden gebruikt om taken verdelen en beheren.

Documentatie essentieel

Tegenwoordig is documentatie een essentieel onderdeel voor werkende software, helemaal als je Test Driven' ontwikkelt.

In een onderzocht technologiebedrijf richtte het productteam zich op het vooraf schrijven van kleine vereisten ("user stories" genoemd), voordat er daadwerkelijk geproduceerd werd.Deze vereisten werden in een ticket queue geplaatst als taken voor de volgende beschikbare developer om aan te werken.

De mate van documenteren lag erg hoog om de ticket queue in beweging te houden. Uiteindelijk werd dit proces een van de vele kleine 'watervallen', waar werk werd doorgegeven van een productafdeling naar ontwerpers naar development.

Dit proces is precies wat Agile juist wilde elimineren. Het is geen wonder dat de CTO van dit bedrijf zei: "mijn software developers hebben het gevoel dat ze ontzettend veel kleine bestellingen in een restaurant koken."

Zonder integraal plan kom je er niet

Als het gaat om 'reageren op een verandering vóór het volgen van een plan', wordt dit vaak verkeerd geïnterpreteerd als 'geen plan hebben'.

Zonder een (globaal) plan zullen teams niet weten hoe ze acties moeten prioriteren, en hoe ze op verantwoorde wijze in die acties kunnen investeren. Dit principe is zo ver gegaan dat software developers geloven dat het niet nodig is om te timeboxen of gemeenschappelijke mijlpalen te hebben.

Het zou prima zijn als deze onjuiste toepassingen de motivatie en -prestaties daadwerkelijk zouden verbeteren, maar we hebben geconstateerd dat in de praktijk het tegenovergestelde gebeurt.

Weinig gevoel, verminderde motivatie, eigen hachie eerst

Agile, wanneer uitgevoerd zoals hierboven beschreven, vermindert de totale motivatie van software developers. Omdat ze:

  • niet mogen prototypen,
  • hun eigen werk niet beheren,
  • geen contact hebben met klanten.

Hierdoor hebben ze weinig gevoel voor het project, de mogelijkheden en het doel; in plaats daarvan voelen ze emotionele en economische druk om alleen eigen taken af te krijgen. Ze stoppen met leren en doen alleen hun uiterste best om eigen tickets af te krijgen, slechte zaak.


Hoe dan wel

De sleutel lijkt te liggen in het balanceren van productiewerkzaamheden met voortschrijdend inzicht (adaptieve prestatie). Of je nu een developer of een productmanager bent, hieronder een aantal suggestie die je kunt overwegen om dit evenwicht te vinden. Zodat iedereen gemotiveerd blijft en prestaties van software development team verbeterd worden.

1. Softwareontwikkeling moet een integraal team effort zijn.

In plaats van een proces waarbij één persoon (product owner) vereisten samenstelt, is het beter om dit door het gehele team te laten doen: dus product owner, designer, software developers en project managers. Bij zo'n proces werken de product owner en de software developers samen van begin tot eind bij het ontwerpen van een functie.

Wanneer er technische onduidelijkheden zijn, kunnen deze middels een Proof of Concept getackeld worden.

2. Een 'leveringseenheid' van het team moet minimaal een levensvatbaar prototype zijn.

Teams vinden vaak dat ze tijd verspillen doordat ze zich constant moeten aanpassen. Om dit te voorkomen, moeten niet alleen ideeën worden ontwikkeld als een strategische uitdaging, maar moeten ze ook worden uitgevoerd met snelle prototypes die erop gericht zijn precies genoeg te leren om te weten wat werkt voor klanten.

Met andere woorden, wat ze moeten doen:

de snelheid tot waarheid maximaliseren

Om verspilde inspanningen te beperken en de autonomie van het team te vergroten, moeten prototypes van korte duur zijn. Een prototype mag niet langer dan een week duren.

Soms vereist dit dat het team een functie minimaliseert tot wat absoluut noodzakelijk is om de 'zwakste veronderstelling' te testen. Soms betekent dit dat het team niet codeert, maar in plaats daarvan een offline prototype voltooid door middel van onderzoek.

3. De aanpak moet klantgericht zijn.

Het proces van het bouwen van software (zelfs software voor intern gebruik) moet altijd klantgericht zijn.

In het eenvoudigste geval zouden deze principes moeten gelden:

  • "Uitdagingen" worden altijd ingekaderd rondom de impact bij de klant.
  • Probleemoplossende vergaderingen beginnen altijd met een klant update, en stakeholders komen regelmatig mee naar deze discussies.
  • Elk prototype is rond een klantgerichte hypothese gebouwd. Op die manier kan het team zich verantwoordelijk houden voor de uitkomst van het prototype.

Nog belangrijker is echter dat software developers met eigen ogen zien hoe klanten hun producten gebruiken. Dit vereist dat de frontlinie en de software developers samenwerken om te zien of het product de gewenste impact bij de klant creëert.

4. Gebruik timeboxing voor focus op prototypes en voorkomen van verspilling

Interessant is dat adaptieve / agile softwareontwikkeling timeboxen aanmoedigt als een manier om ervoor te zorgen dat een prototype de investering krijgt die gerechtvaardigd is en om het acceptabele kwaliteitsniveau van een bepaalde functie aan te geven.

Aan de andere kant vermijden typische agile beoefenaars timeboxen of deadlines, uit vrees dat de deadline zal worden gebruikt om emotionele druk te creëren.

Een van de ergste gevoelens voor een softwareontwikkelaar is om een paar maanden bezig te zijn met iets dat uiteindelijk niet nuttig is.

Hierdoor kan emotionele druk ontstaan ("ik laat iedereen in de steek") en een gevoel van nutteloosheid ("waarom doe ik dit eigenlijk?").

Om dit te voorkomen, wil je duidelijk zijn hoever developers kunnen gaan voordat ze controleren of de richting nog steeds correct is. Hoe groter de onzekerheid over het prototype van een team, hoe groter het risico, hoe korter die weg zou moeten zijn. Met dat in gedachten is de timebox geen deadline. Het is een beperking die het niveau van diepte en kwaliteit voor een prototype zou moeten leiden vóór een echte test. Op deze manier kan timeboxing de totale motivatie verhogen.


Thai boxing, een ander soort van Time boxing

5. Het team moet hun proces voortdurend in twijfel trekken.

Een beroemd principe van technisch ontwerpen staat bekend als de wet van Conway. Het stelt: elke organisatie die een systeem ontwerpt, zal een ontwerp produceren waarvan de structuur een kopie is van de communicatie (dat wil zeggen proces-) structuur van de organisatie.

Met andere woorden: als je een monolithische organisatie bent, produceer je monolithische ontwerpen. Als je georganiseerd bent in segmenten, optimaliseer dan de software architectuur voor die structuur.

Als je de wet van Conway wilt gehoorzamen, is het beter om je structuur en processen voortdurend aan te passen aan het probleem. Dit vereist teams die eenvoudige, lichtgewicht processen en structuren hebben die ze voortdurend in twijfel trekken en bijstellen.

Dus in plaats van "Agile" te bouwen als een religie die niet in twijfel kan worden getrokken, zouden development teams de gewoonte moeten hebben om de processen van hun eigen team voortdurend te analyseren en te optimaliseren. In de beste voorbeelden stellen teams hun model op maandelijkse basis vast en beslissen of ze of het moet worden gewijzigd om een beter product te produceren.


Conclusie

Het vermogen om digitaal talent aan te trekken, te inspireren en te behouden wordt cruciaal voor organisaties. De meeste organisaties zijn ten prooi gevallen aan een eenvoudige boodschap - implementeer Agile als een reeks van ceremonies en alles wordt beter.

Helaas wordt het meestel niet beter, omdat de menselijke kant verloren gaat. Door terug te gaan naar de basisprincipes van motivatie en adaptive performance, kan je een organisatie bouwen die echt agile is.

Inspiratiebron op HBR

Comments

Nóg meer
kennis nodig?

Check ons ons blog archief >