HNW leidt tot NWS (Niet Werkende Software)
Veel projecten mislukken, met name ICT projecten, en de zoektocht naar mogelijke verbeteringen wordt volgens mij steeds vaker in de wielen gereden door het nieuwe werken.
De belangen zijn namelijk strijdig, hoewel het een eenvoudige afweging lijkt voor de opdrachtgever; wil ik graag medewerkers die het eigen werk kunnen indelen op de zelf gekozen locatie, of wil ik werkende software?
We hoeven de krant maar open te slaan om te lezen dat er weer ergens een project is mislukt, waarbij er te laat is opgeleverd, of dat er iets is opgeleverd dat voor alle betrokkenen een grote verrassing was. Hebben we dat gemaakt? Hebben we er echt zo lang over gedaan? Het schijnt zelfs voor te komen dat projecten worden beëindigd, wat in veel gevallen eigenlijk niet eens zo’n gek idee is.
Bij de ICT projecten die wel worden afgerond en waar software is ontwikkeld, blijkt dat ongeveer 64% van de ontwikkelde functionaliteit zelden of nooit gebruikt zal gaan worden. Slechts 20% zal uiteindelijk vaak of altijd gebruikt gaan worden.
Hoe worden we weer lenig?
Om goede software te ontwikkelen, zonder overtollige functionaliteit, is in 2001 het Agile Manifesto opgesteld. Dit handvest geeft aan dat het mogelijk moet zijn om op een snellere wijze betere software op te leveren. Agile is het Engelse woord voor lenig. Dit kan bijvoorbeeld door kort-cyclisch te werken, en door een projectorganisatie niet terug te laten deinzen voor mogelijke veranderingen. We weten immers zeker dat er veel gaat veranderen tijdens het project, dus kunnen we de veranderingen beter omarmen als kansen.
Focus op personen en interacties
Een van de uitgangspunten van het handvest adviseert om ons in projecten te focussen op personen en interacties, in plaats van op processen en tools. De Agile werkwijze stelt bijvoorbeeld voor om zelfsturende projectteams in te richten, die nauw moeten samenwerken, waardoor kennis en vaardigheden kunnen kruisbestuiven. Volgens mij knelt daar de schoen met het nieuwe werken. Het wordt namelijk een stuk lastiger om een aantal van de aanbevelingen van Agile werken op te volgen, zoals:
- Bullpen: zet het projectteam samen in een open ruimte (de zogenaamde bullpen), om communicatie en samenwerking te faciliteren.
- Pair programming: om kennis over de software te borgen en elkaar te kunnen helpen, wordt voorgesteld om programmeurs in paren te laten werken, achter één pc; de ene programmeur programmeert, terwijl de ander meedenkt.
- Stand-up meetings: elke dag staan de leden van het projectteam gedurende een kwartier samen voor het planningsbord. Op dat bord hangen de geeltjes met activiteiten, en iedereen kan de status van de activiteiten veranderen door de geeltjes te verhangen, bijvoorbeeld van doing naar done. Psychologische theorieën beschrijven zelfs dat mensen zich extra verbonden voelen met een activiteit als ze het geeltje in handen hebben gehad.
Worden we leniger met een webcam?
De uitgangspunten van Agile zijn niet in beton gegoten, maar geven wel aan wat veruit de grootste kans op succes biedt. Of betreffende best practices worden gehanteerd is de keuze van elk bedrijf zelf, maar ervan afwijken leidt a priori tot minder optimale omstandigheden, en slechtere software.
Natuurlijk zijn er technische oplossingen om communicatie over grotere afstand te laten plaatsvinden, maar leniger worden projectteams niet als ze via webcams moeten samenwerken.
Laden ...
donderdag, 7 oktober, 2010 at 4:49
Leniger worden we vooral door op een volwassen wijze en met passie en inzet samen te werken. Daarvoor hoef je niet fulltime met elkaar in een hok te zitten. HNW vereist een volwassen houding van medewerkers. Wanneer je als medewerker met HNW om kan gaan geeft het je de vrijheid die je passie voedt en zullen de resultaten (ook in teamverband) volgen.
HNW doet net als vele agile methodieken een beroep op passie en inzet van mensen. Doe die dingen die er toe doen en die tot bruikbare resultaten leiden en matig minder relevante activiteiten (overhead). In potentie dus een mooi combi!
dinsdag, 12 oktober, 2010 at 11:29
Je geeft een mooi ideeël antwoord. Daarom kan ook de lenige manier van werken alleen maar succesvol als (ik citeer uit Wikipedia over de geschiktheid van agile-methoden):
“…
– De cultuur van de organisatie moet openstaan voor discussie en onderhandeling
– Mensen moeten vertrouwd worden
– Minder maar competentere mensen
– Organisaties moeten de beslissingen accepteren die ontwikkelaars nemen
– Organisaties moeten een omgeving hebben waarin snelle communicatie tussen team-leden mogelijk is …”
donderdag, 7 oktober, 2010 at 8:30
Agile praktijken, de tools en rituelen van bv Scrum, zijn ondergeschikt aan de agile waarden zoals vastgelegd in het manifesto. We kunnen onze praktijken aanpassen aan HNW door vanuit die waarden te redeneren.
dinsdag, 12 oktober, 2010 at 11:23
Een belangrijk uitgangspunt van de Agile manier van werken is dat er directe communicatie kan plaatsvinden, bij voorkeur via persoonlijk contact, en dat mensen op één locatie samenwerken. Het is niet verplicht, maar de kans op succes is groter als we het wel doen.
donderdag, 7 oktober, 2010 at 10:26
Behoorlijk veel onzin in één stuk.
Ten eerste: dit probleem is al heel wat jaren een groot probleem. Met name ook in de tijd dat we allemaal juist in een hok zaten, wat nu nog het geval is. Kijk naar Microsoft. Is daar al ooit een werkend product dat af is uitgekomen? Hebben we al ooit een week zonder update gehad omdat het blijkbaar niet af was? Dat terwijl ze daar toch juist allemaal nog op kantoor werken. Dus de fouten in software en HNW heeft geen relatie.
Natuurlijk zijn er limieten, soms is het heel erg goed bij elkaar te zitten. Toch kan het heel erg goed zijn om ook juist niet bij elkaar te zitten. Het probleem is volgens mij: vragen. Gewoon zorgen dat je zeker bent dat je als IT’er begrepen hebt wat de opdrachtgever wil. Dat zou juist wel eens verbeterd kunnen worden als men niet met z’n allen in een hokje zit, juist omdat je dan beter doorvraagt.
Het grootste probleem zit overigens in goed opdrachtgeverschap, want daar waar een IT’er te weinig vraagt en checkt en te vaak denkt dat wat hij denkt klopt, is de opdrachtgever natuurlijk ook verantwoordelijk voor het feit dat hij bereikbaar is voor vragen, doorvraagt of het echt begrepen is en in staat is iets goed uit te leggen.
Als je echter uitgaat van HNW in het brede perspectief, dus niet enkel ‘op andere locaties werken’ denk ik dat het de oplossing geeft. Namelijk verantwoordelijk én bevoegd zijn voor je eigen werk, maar daar ook dus de verantwoording voor nemen. Dus een deadline is een deadline, punt. Zorg dat het werkt op de manier die vooraf besproken is (definitions of done). Etc.
dinsdag, 12 oktober, 2010 at 11:02
Het klopt dat het samen werken op één plek geen enkele garantie biedt om fouten te voorkomen. Als mensen op één locatie moeten samenwerken, maar zonder goede structuur of zonder te weten waar ze mee bezig zijn, en zonder eigen verantwoordelijkheid, dan zal dat zeker niet tot succes leiden. Meerdere kippen zonder kop in een hok lopen elkaar omver.
Maar dat is niet mijn punt. Binnen ICT projecten, zeker bij softwareontwikkeling, is vastgesteld dat klanten vaak niet krijgen wat ze willen, en het te laat krijgen. Om dat te doorbreken is de Agile wijze van softwareontwikkeling bedacht. Ik citeer uit Wikipedia: ” Bij agile-methoden ligt de nadruk op directe communicatie, bij voorkeur als persoonlijk contact, in plaats van geschreven verslaglegging. De meeste agile-teams zijn gehuisvest op één locatie. Zo mogelijk zijn alle mensen die nodig zijn voor het project in zo’n team ondergebracht. Maar ten minste zijn dit de ontwikkelaars en diegenen die het product definiëren. Dat kunnen product-managers zijn, business-analisten of zelfs klanten. ”
Misschien zijn er manieren om ook de perfecte communicatie te laten plaatsvinden zonder dat mensen bij elkaar in een hok zitten, hoewel ik ze nog niet gezien heb. Uit “best practices” binnen softwareontwikkeling is vastgesteld dat er juist een grotere kans op succes is als de projectleden bij elkaar zitten (ook bij niet Agile methoden). Het is geen verplichting om het te doen, maar het levert een risico op, waarvan de opdrachtgever van een softwareproject waarschijnlijk niet op de hoogte is. Nee, we nemen bewust het risico dat we de opdrachtgever mogelijk een illusie voorspiegelen dat we betere projecten voor hem gaan doen door het nieuwe werken.
p.s. verantwoordelijk én bevoegd zijn voor je eigen werk kan tot beter resultaat leiden, maar dat geldt in alle gevallen; ook wanneer mensen wel op één locatie werken.
donderdag, 7 oktober, 2010 at 12:21
Ik begrijp de link met HNW niet zo. Of bedoel je als auteur aan te geven dat er ook in softwareontwikkeling vormen en gedragingen van HNW en sociale innovatie nodig zijn (zoals Agile) om tot betere en bruikbare software te komen? Ik vind de titel daardoor een beetje misleidend. Sorry.
dinsdag, 12 oktober, 2010 at 11:12
Ik probeer aan te geven dat de uitgangspunten van HNW op gespannen voet kunnen staan met het opleveren van goede software c.q. goede ICT projecten. Door mensen niet fysiek op één locatie te laten samenwerken, denk ik dat we het risico lopen dat we software opleveren die minder goed is, dan die zou kunnen zijn geweest.
vrijdag, 8 oktober, 2010 at 8:22
Ik denk dat projecten pas succesvol eindigen als de mensen die moeten werken met hetgeen opgeleverd wordt er mee kunnen werken. Veel meer tijd besteden aan uitleg, begeleiding, motivatie etc., niet alleen aan het begin of tijdens het project, maar vooral bij oplevering. HNW werkt, als de mensen met alle handige tools leren werken
dinsdag, 12 oktober, 2010 at 10:01
Je hebt gelijk dat mensen goed opgeleid moeten worden in opgeleverde systemen, want anders weten ze niet eens wat het systeem kan. Uit onderzoek is echter gebleken dat er bij ICT projecten veel functionaliteit wordt opgeleverd die nooit gebruikt zal worden, ongeacht of mensen weten dat het erin zit, want (niet uitputtend):
1) Het gebeurt vaak dat gebruikers en ICT-ers samen zitten, waarbij het de ICT-ers niet lukt om het écht belangrijke zaken boven tafel te krijgen.
2) ICT projecten duren vaak te lang, terwijl de wereld verandert. Na een jaar zijn de zaken die aan het begin zo belangrijk leken, achteraf toch niet meer zo heel erg belangrijk.
3) Gebruikers denken in de eerste fase van een project vaak “als ik het nu niet mee laat nemen, krijg ik het nooit meer”, waardoor alle mogelijke wensen aan het begin heel belangrijk worden gemaakt.
Een manier zoals Agile, die ik beschrijf, kàn helpen om bovenstaande valkuilen te voorkomen. In het artikel probeer ik aan te geven dat het nieuwe werken en de lenige manier van software ontwikkelen elkaar in de weg kunnen zitten.
donderdag, 14 oktober, 2010 at 19:54
Vanwaar toch steeds die assumptie dat HNW betekent dat iedereen zelf een opportunistisch werkplekje uit gaat zoeken? HNW betekent dat vooral dat je los durft te laten, en vertrouwen en verantwoordelijkheid geeft aan je professionals. Wanneer je dit écht implementeert zul je zien dat je projectteam daadwerkelijk die verantwoordelijkheid pakt, en elkaar opzoekt wanneer dat nodig is. In mijn ervaring levert dit veel betere (en leukere) projecten op dan de strak gemanagede hokjesgeestprojecten waar vooral het eigen hachje hoog op een ieders prioriteitenlijstje staat…
woensdag, 13 oktober, 2010 at 5:21
Wij hebben zeer goede ervaringen door met Agile Scrum te werken. Als softwarebedrijf van 10 programmeurs kun je een mooi team samenstellen wat gezamenlijk naar één doel werkt. Waar ik vroeger als projectleider moest optreden is het team nu volledig zelfsturend. Een sprint duurt bij ons vaak twee weken en wordt op dag één geheel besproken door alle programmeurs. Daarna worden de taken onderling verdeeld tijdens de sprint.
Mijn mening is dat Agile software ontwikkeling uitstekend te combineren is met HNW, zolang er maar een goede voorbespreking is, een dagelijkse update en de sprint niet te lang duurt (bij voorkeur twee weken). Waar en hoe er dan geprogrammeerd wordt kun je zelf indelen. Pair programming is overrated.
zaterdag, 16 oktober, 2010 at 16:44
Er kan altijd worden afgeweken van wat wordt geadviseerd, en er zijn zeker tussenoplossingen. In het boekje “Scrum and XP from the trenches (how we do scrum)” van Henrik Kniberg, wordt teams aangeraden om zoveel als mogelijk fysiek op 1 locatie te zitten. Als dat toch niet mogelijk is, dan moeten de afwezige (thuiswerkende) teamleden wel het gevoel krijgen dat ze erbij zijn, bijvoorbeeld door de hele dag de anderen te kunnen raadplegen of geraadpleegd te kunnen worden (met Skype of instant messaging). Het is belangrijk dat alle teamleden “in sync” blijven.
Maar welke tussenoplossingen ook gekozen worden, het blijft minder optimaal dan met zijn allen in een hok.
woensdag, 13 oktober, 2010 at 13:57
Ik ben geen ICT-er en ik ken het genoemde manifest niet, maar bewijst open source software niet juist dat software prima ontwikkeld kan worden door verschillende mensen op verschillende locaties?
Als ik de historie van (IT) projecten bekijk, dan denk ik ook dat lukken of mislukken niet van HNW afhangt. En is HNW juist niet flexibel werken, dus in één ruimte indien nodig en op je eigen tijd en plaats als het kan?
zaterdag, 16 oktober, 2010 at 16:54
Volgens mij is de ontwikkeling van open source software niet vergelijkbaar met het ontwikkelen van software binnen een project voor een opdrachtgever, waarbij er juist wel grenzen worden gesteld aan budget, tijd en kwaliteit (en beschikbare mensen/kennis).
HNW propageert volgens mij inderdaad flexibel werken, zoals jij het aangeeft. Maar eigenlijk moet er voor het beste resultaat (binnen de methode die ik beschrijf) bij voorkeur juist niet op die manier flexibel gewerkt worden. Alle teamleden moeten zoveel als mogelijk bij elkaar zitten, en op dezelfde momenten/tijdstippen. HNW is pas mogelijk als het uitkomt, maar niet HNW voorop stellen en daarna pas kijken naar de consequenties.