Tagcloud

Hier zit een luchtje aan…

In de vorige blog is er gekeken naar de meest gangbare klantwaarden. De conclusie is dat je een ontwikkelproces pas echt kan configureren en inrichten als bekend is welke specifieke klantwaarden er centraal staan. In deze blog borduren we hierop voort.

In de agile community wordt de term ‘smell’ gebruikt als een indicatie dat er iets mis is. Zo kunnen we een ‘process smell’ definiëren als een indicatie dat iets in het ontwikkelproces het leveren van een of meerdere klantwaarde belemmert. Deze relatie biedt dan ook bijzonder waardevolle inzichten!  Laten we eens kijken naar een aantal typische proces smells, om deze vervolgens te kunnen koppelen aan klantwaarden.

Klant?!? Welke klant? – Directe en frequente klantinput is niet realistisch.
In veel omgevingen waar softwareproducten worden gemaakt, leeft men in de veronderstelling dat er geen klanten beschikbaar zijn tijdens de ontwikkeling van het product. Sterker nog, men is niet eens bewust van de noodzaak.  Tuurlijk, er zal vast wel een vorm van marktonderzoek zijn geweest, waarin eindklanten van de producten betrokken zijn. Maar rechtstreeks contact met hen is er meestal niet. Het marketingteam treedt doorgaans op als pseudo-klant voor het ontwikkelteam. Niet dat dit onwerkbaar is, maar er is doorgaans meer aan de hand. Hoe goed kan marketing als intermediair eigenlijk de behoeften zijn van eindgebruikers extraheren? En hoe effectief is de communicatie aan het projectteam? Bovendien zijn in een productomgeving marketing en ict nogal eens gescheiden. Marketing heeft immers belangrijkere dingen te doen dan deel te nemen in een delivery team!  De kans is groot dat als er wél iemand beschikbaar gesteld wordt om het development team te ondersteunen, dit zeer waarschijnlijk niet de bron zelf is, maar een rechterhand. Een nóg indirectere communicatie is het gevolg. (Zie ook deze blog). Hadden we op de kleuterschool niet al geleerd hoe vaker we een boodschap fluisterend doorgeven hoe groter de afwijking?

Ook in de context van een typische klant-leverancier verhouding hebben we moeizaam toegang tot de bron. Hoe vaak horen we management niet zeggen:  “Wij zijn er om onze klanten te ondersteunen en niet andersom. Onze klanten hebben geen tijd voor ons” Of een klassieker: “Het is onze taak om de software te bouwen, wij bedenken wel voor onze klant wat ze nodig hebben. Daar zijn we goed in.”

In beide scenarios is er erg weinig input van de klant. Dit is een typische process smell die leidt tot:

  • Features die niet gebruikt worden door klanten.
  • Software die de klant niet echt helpt hun werk op een efficiënte en prettige manier te doen.
  • Gefrustreerde eindgebruikers (in het ergste geval).

Management is verrast — gebrek aan transparantie
Management heeft doorgaans weinig inzicht in de werkelijke voortgang van een project. Planningen zijn gebaseerd op benodigde activiteiten en de klant heeft daar weinig kaas van gegeten. Bovendien zijn ontwikkelteams optimistisch als het gaat om deze activiteiten. Eerdere problemen worden genegeerd en ze zijn ervan overtuigd, dat ze in het uur van de waarheid, bijna met heroïsche inspanningen het allemaal wel voor elkaar krijgen. Helaas heeft niet alleen het management slecht zicht op de details van wat er fout gaat, ook het ontwikkelteam is niet altijd zeker van haar zaak. En als het moment van integratie van de verschillende delen van het systeem in zicht komt, weet het team uit ervaring dat dit geen feestje gaat worden. Dát er zich problemen zullen voordoen staat vast, alleen niet hoeveel. Met de actuele deadline in zicht komt er een moment dat het team niet langer meer kan ontkennen dat ze de deadline niet gaan halen. Dan is het te laat voor management om effectief te reageren. Dit gebeurt helaas te vaak. Management heeft als gevolg geleerd een buffer te communiceren om de beloften van het team te ondervangen. Het vertrouwen wordt er allemaal niet beter op. Er is duidelijk behoefte aan transparantie.

Resourceproblemen — engineers zitten tegelijkertijd in meerdere teams
Om software van hoge kwaliteit te maken is het geen onlogische gedachte om engineers zich te laten specialiseren. Het bijeffect is dat hun specialistische kennis en ervaring gewenst is op meerdere projecten tegelijk, waardoor ze opgenomen worden in meerdere projectteams tegelijk. Deze ‘vliegende spitsen’ worden dan al snel een beperkende factor in één of zelfs meerdere projecten. (Zie ook de blog generalisten vs specialisten). Dit is nu eenmaal de gang van zaken in een grotere onderneming, waar aan verschillende projecten wordt gewerkt, niet waar?

Research wijst uit dat de prestatie drastisch wordt verlaagd, als iemand in meer dan twee projecten tegelijk werkt. Het omschakelen tussen verschillende projecten kost significant tijd. Daarnaast gaat men zich focussen op het minimale wat verlangd wordt, terwijl een bredere blik juist gewenst is. En als iets in het ene project stagneert, dan heeft een ander project daar ook last van.

Deze process smell leidt onherroepelijk tot:

  • Een langere time to market.
  • Beperkte flexibiliteit om te reageren op verandering.
  • Hogere kosten.

Oeverloze projecten
Herken je dat? Projecten missen keer op keer hun deadline. Grote ontwerpbeslissingen hebben kennelijk niet kunnen voorkomen dat er naderhand problemen opduiken. (Wie leeft er eigenlijk in de veronderstelling dat dat kan?) Er lijkt geen eind te komen aan het project, in een poging toch bruikbare kwalitatieve software op te leveren. Soms worden dergelijk projecten na verloop van tijd stilgelegd. Helaas wel na een significante investering. In andere gevallen wordt uiteindelijk toch nog een werkend systeem opgeleverd tegen exorbitant hoge kosten.

Honderden (misschien duizenden) geregistreerde bug
Zodra er een fout in de software gevonden wordt, zijn we gewend deze te rapporteren in een ‘bug tracker’ en deze te prioriteren. Voor de release lossen we alle ‘showstoppers’  op en de bugs met de hoogste prioriteit, die met een lagere prioriteit zullen meestal het daglicht niet meer zien. Een groot aantal geregistreerde bugs is een indicatie van verspild werk. Er is immers tijd besteed aan het opsporen van bugs, het classificeren van bugs en in sommige gevallen beoordelen van de verwachte inspanning om de bug te verhelpen. Maar één ding is zeker, er wordt geen klantwaarde geleverd zolang de bug niet is opgelost en een update uitgeleverd is. Een grote hoeveelheid bugs in een bug tracker is een directe indicator voor een significante investering in werk dat geen toegevoegde waarde biedt. Zou het bovendien niet nog meer waarde opleveren als we de bugs überhaupt niet zouden registeren? Het kán!

Uithardingsfase aan einde van elke oplevering.
Voordat de software uitgeleverd wordt, moet er een periode ingelast worden waarin geen nieuwe functionaliteit toegevoegd wordt aan de broncode. De broncode wordt bevroren, een ‘branch’ wordt aangemaakt en er wordt uitvoerig getest.  Alleen bugs met hoge prioriteit worden verholpen mits van te voren goedgekeurd. Na voldoende tijd in acht genomen te hebben, wordt de software uiteindelijk vrijgegeven.

Dit is allemaal goed doordacht, niet waar? Waarom zit hier dan toch een luchtje aan? Als je iteraties op een goede manier uitvoert, lever je aan het eind van elke iteratie een werkend, geïntegreerd, getest en gedemonstreerd systeem op. Er is dan helemaal geen noodzaak om het project te bevriezen vlak voor oplevering. Een uithardingsfase is een indicator dat er niet iteratief gewerkt wordt. Iteraties worden dan gezien als een functionele decompositie. In elk brok werk worden fouten niet gevonden en dus ook niet verholpen. Als gevolg stapelen de problemen zich op. En hoe later fouten gevonden worden, hoe duurder ze op te lossen zijn.

Integratie gebeurd niet periodiek (meestal omdat het pijnlijk is)
Gespecialiseerde teams werken aan verschillende delen van de applicatie. Vlak voor de release worden de verschillende delen geïntegreerd. Tot die tijd vertrouwen ze erop dat de vooraf opgestelde specificatie- en ontwerpdocumenten zorgdragen voor een naadloze aansluiting van de systeemdelen. Dit is natuurlijk zelden het geval.

Met deze wetenschap zou je verwachten dat de behoefte om eerder en frequenter te integreren zich vanzelf creëert. Toch is dat niet het geval. Teams ervaren het builden en integreren als een tijdrovende klus. Eentje waar zich altijd vervelende dingen voordoen. De natuurlijke reactie is dan om dit juist minder vaak te doen en uit te stellen. Waarom is dit een indicatie dat er minder waarde geleverd aan de klant? Niet frequent integreren leidt tot een substantiële hoeveelheid code die niet getest is. Zonder volledige integratie blijven er tot op het allerlaatste moment vlak voor de release een flinke hoeveelheid fouten, miscommunicaties en misopvattingen verborgen. Dit remt de mogelijkheid voor het team om het systeem als een coherent geheel te laten evolueren. Daarmee wordt het bepalen van de voortgang ook nog eens bemoeilijkt.

Pijn als een stimulans
Pijn is een goede stimulans om dingen te veranderen. Het is dan ook van essentieel belang om vast te stellen wat het meest pijn doet. Dit vormt het vertrekpunt voor het gericht zoeken naar oplossingen. Ook al biedt het toepassen van een agile aanpak in potentie tegenwicht aan de nodige problemen, ook daar is een goede bewustwording noodzakelijk. Wat levert een bijdrage om de pijn te verzachten en hoe krijg je het voor elkaar krijgt om verbetering tot stand te laten komen? In een werkklimaat waar het credo “Het is nou eenmaal zo, we kunnen er niets aan veranderen” zegeviert is een oplossing sneller gevonden dan bereikt.

Van theorie naar praktijk. Welke process smells kun je vinden?
Beantwoord de volgende vragen om de process smells in je eigen organisatie te ontdekken, begrijpen en prioriteren.

  1. Vind zo veel mogelijk process smells en prioriteer ze. Relateer de gevonden process smells aan de klantwaarden uit de vorige blog.
  2. Is de prioritering van de process smells anders dan de prioritering van de klantwaarden in de opdracht van de vorige blog? Met andere woorden, is de meest pijnlijke process smell gerelateerd aan de meest belangrijke klantwaarde? En wat betekent dat?
  3. Gebaseerd op je eigen omgeving, zou het waardevoller zijn om van klantwaarden uit te gaan of vanuit process smells? En waarom?

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution