Ik zei:
“Ieder zijn expertise: de klant kent zijn/haar domein het beste, de IT-leverancier de techniek. De klant moet niet aan de IT-leverancier dicteren wat de techniek wordt, en de IT-leverancier moet niet dicteren aan de klant wat het probleem is dat opgelost gaat worden.”

Ik zie geen verschil.

Ik wil best hierover discussiëren, maar niet als je mijn argumenten niet goed vertegenwoordigd.

Ik zag toevallig ook dat zowel jij als Jan de Wit vanaf dezelfde proxy reageren. Dat lijkt me overbodig als je gelijk zou hebben.

Maar ik begrijp dus dat jij als ICT-er dus adviseren over ieder product, althans dat je kan bepalen of een product een oplossing voor een probleem is? Of gaat dat alleen maar om technologie die vrij beperkt is, als content management oplossingen? Want op CMS-gebied is vrij veel laagdrempelige documentatie te vinden. Lijkt me dat daar een discussie over product x of y met een gemiddelde opdrachtgever serieus te voeren zou moeten zijn.

Ik proef uit de negatieve benadering van iemand die een kritische kanttekening bij een artikel plaatst toch wel enige frustratie. Want jullie schieten wel heel hard in de verdediging. Dat lijkt me overbodig als je gelijk zou hebben.

Waar wil je over meedenken dan? Over zijn kanaalstrategie? Over zijn informatie distributiestrategie? Over zijn communicatiestrategie? Hoe abstract moet een probleem volgens jou geformuleerd worden? Beste IT leverancier, onze marge staat onder druk. Graag horen we wat jullie de beste aanpak voor dit probleem vinden.

Maar waarschijnlijk werkt het plezieriger met klanten die geen idee van IT hebben. Zo lastig, klanten met een mening. Of is dat de klant centraal stellen zolang hij maar luistert?

Ieder zijn expertise: de klant kent zijn/haar domein het beste, de IT-leverancier de techniek. De klant moet niet aan de IT-leverancier dicteren wat de techniek wordt, en de IT-leverancier moet niet dicteren aan de klant wat het probleem is dat opgelost gaat worden. Beide partijen moeten samenwerken om tot het beste resultaat te komen.

Het probleem is dat de oplossing in de markt gezet wordt, in plaats van het probleem. Een CMS is de oplossing. Maar als je geen verstand hebt van IT, dan is het moeilijk in te schatten of een CMS de juiste oplossing is voor het probleem.

Het maakt hierbij geen zak uit wat het specifieke product is (Typo3, Drupal, Radiant, etc). Je hoeft als ICT-er geen ervaring te hebben met al die producten om te weten of het probleem opgelost kan worden met een CMS of niet. Maar ga niet van te voren vragen om een CMS, want dat wordt de enige vraag die je kan stellen: “welke dan?”

Dus de probleemdefinitie moeten de meeste IT bedrijven echt aan de klant overlaten. Ik ben het met je eens dat een opdrachtgever idealiter niet zelf moet gaan kijken wat de beste oplossing voor zijn probleem is. Maar wellicht is het verstandiger is om bij een partij die geen medicijnen verkoopt advies te vragen mogelijke oplossingen voor het probleem zijn. Om daarna een aantal alternatieven naast elkaar te leggen en met leveranciers van die alternatieven in gesprek te gaan over hoe zij het probleem zouden oplossen en welk budget daarvoor nodig zou zijn.

De organisaties die pretenderen met een onafhankelijk advies te komen en dan toch weer hetzelfde kunstje doen vind ik nog veel erger dan de mensen die gewoon Pulsatilla leveren als daarom gevraagd wordt.

Ik denk dat als je niet de moeite neemt om te bekijken wat het echte probleem is je ook een grote kans maak een oplossing aan te bieden die geen oplossing is. En wat een verrassing. Als een leverancier expertise heeft van een bepaald product (of ruimte in de planning van het team met expertise van dat product) dan is dat nou net toevallig de ultieme oplossing voor het nog niet onderzochte probleem.

In dat geval ben je de verkoper van Pulsatilla. Je verkoopt het medicijn zonder dat je je per geval hebt verdiept in het ziektebeeld. En dat gaat gewoon vaak mis. In de gevallen dat een leverancier wel naar het waarom, wat en het hoe kijkt, zoals het in mijn ogen hoort, is de ICT leverancier in mijn analogie wel de huisarts.

Anne.

Als het probleem is “ik heb een website die niet meer voldoet aan de verwachtingen van de moderne internetgebruiker” kun je gaan zoeken naar de oorzaak van het probleem. Maar je kan ook gewoon gaan aan de slag gaan en kijken welke oplossing je voor dat probleem kan aanbieden. En als je geen Typo3 expertise hebt zal je nooit met de conclusie komen dat dat de meest geschikte oplossingis.

De ICT leverancier is in je analogie niet de dokter. De ICT-leverancier is de farmaceut die Pulsaltilla produceert of een verkoper van Pulsatilla. Als je de producent van Pulsatilla gaat vragen om objectief advies ben je aan het verkeerde adres.

Op welke manier zou ik nu als naïve lezer niet in verwarring moeten worden gebracht? Overigens kan ik me in het artikel van Iain meer vinden dan in het eerdere verhaal. Zeker als je niet een externe contractor bent, maar onderdeel bent van het bedrijf waar het product voor moet worden gebouwd… zonder voortschrijdend inzicht zou je dan al niet meer bestaan. Met de juiste methodologie zijn ook veranderingen in een software project best wel manageable en software is geen fysiek product. Als je code fatsoenlijk is, zouden zelfs grote veranderingen niet heel veel impact hoeven te hebben.

Misschien past een Shu benadering niet bij iedereen of elke cultuur. Dat is een goed punt. Volgens mij heeft het ook voor een heel groot deel te maken met geloof. Als je echt gelooft dat dit de manier is waarop je software ontwikkeld kan je je daar erg sterk voor maken. Ook bij de klanten en je eigen management. Maar vaak wil men eerst bewijzen zien en dus starten we maar een soort van hybride oplossing. Zo ook bij mij hoor. Maar het beste besluit dat we hebben genomen en waardoor we als team pas echt zijn gaan groeien is om eerst het raamwerk in zijn geheel te volgen.

Hij vertelde dat, in tegenstelling tot zijn Japanse leerlingen, Nederlandse leerlingen steeds vroegen waarom een bepaalde oefening moest worden uitgevoerd. Misschien past een Shu-benadering, blindelings volgen van instructies zonder de achterliggende beweegredenen te kennen, niet in een westerse cultuur, wat leidt tot Scrumbuts.

Of het is misschien alleen weerstand tot verandering?

Hoe dan ook, laten zien dat de methode en alle aspecten daarin daadwerkelijk helpen lijkt me essentieel, bijvoorbeeld door middel van een Scrum experience en door intensief coachen en zo rekening te houden met de specifieke omstandigheden van de klant in plaats van alleen te redeneren vanuit de methodiek.

Uiteindelijk gaat het bij Agile natuurlijk om aanpassen en verbeteren en niet jezelf in een keurslijf te stoppen. Daarom is het belangrijk na elke sprint tijdens de retrospective te kijken wat er beter of anders kan en veranderingen voor een bepaalde periode uit te proberen en op een vooraf bepaald moment te evalueren. Als blijkt dat een team prima functioneert zonder standups, moet je dat natuurlijk zeker doen. Maar bij voorbaat standups af serveren lijkt me een bijzonder slecht plan.

Ik zou zeggen dat bij een zelforganiserend team, eenieder (of ieder pair) prima in staat is om een nieuwe feature op te pakken, zonder dat iedereen hier z’n zegje over hoeft te doen. Dat gebeurt gedurende de gehele dag aan de hand van wanneer de vorige feature klaar is.

Bottlenecks spotten gebeurt zodra je verandering maakt in je Kanban-bord. Je ziet dan dat bijvoorbeeld je capaciteit voor bijv. testing vol begint te zitten. Daar is dat bord juist zo handig in: je ziet direct wat er aan de hand is.

Je hebt gelijk dat de backlog geen Gantt-chart is (alhoewel het helaas meestal wel op die manier aangepakt wordt). Toch is je backlog wel geprioritiseerd op waarde. Dus de volgorde waarop je dingen oppakt zal wel enigszins overeenkomen met wat je besproken hebt tijdens de sprintplanning.

Enfin, het gaat erom dat je dingen doet die je helpen. Ik kan niet voorspellen wat in welke situatie het nuttigst is, dat mag je helemaal zelf uitvinden tijdens het project. Ik geef slechts een alternatief.

Pair programming helpt ook delen van informatie. Zo ook bij elkaar zitten, zodat je kan horen waar anderen het over hebben.

@Rini:

Waarom die timebox van 15 minuten? Als het nuttig is, moet je het doen zolang het nuttig is (imho). Als er genoeg te bespreken valt om een uur mee te vullen, en dat is nuttige informatie, waarom dan stoppen? Of is er iets nuttigers om te doen?

Achter de computer zitten typen is lang niet altijd het nuttigste wat je kan doen.

Leuke presentatie over M&M’s (Meetings en Managers): http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html

Leuke post! Goed geschreven ook!

Dit is ook precies waarom Scrum een framework wordt genoemd. Blijf nadenken: wat is het nut van een meeting, waarom doen we dit? Heeft het geen nut, ga het dan niet doen voor t ritueel. Denk wel na over het doel achter de meeting; gooi niet t kind met t badwater weg.

Als je het doel op een andere manier afdekt moet je geen rituele dansen gaan uitvoeren. Zoals je zegt is het elke dag even afstemmen wel handig, afhankelijk van jouw situatie kies je het meest waardevolle onderwerp. Let wel op de time-box: 15 minuten en dan ook stoppen.

Leuk boek over meetings: http://www.managementboek.nl/boek/9780787968052/death_by_meeting_patrick_lencioni

Tijdens mijn huidige Scrum-project hebben we behalve de eerste twee dagen geen stand-up meetings meer gehouden. Maar ik moet daarbij wel vermelden dat het team maar drie leden telde. Als je dan niet al continu op de hoogte bent van wat iedereen aan het doen is heb je inderdaad een ernstiger communicatieprobleem.

Voor een groter team weet ik het nog niet.

Een van de belangrijkste doelen van de stand-up meeting is ‘work scheduling’. In Scrum werk je als team zoveel mogelijk zelfsturend. Dit betekent dat je als groep (met alle teamleden samen dus) werk inplant en verdeelt. Hoewel je tijdens de sprintplanning werk hebt geïndentifeerd, geprioritiseerd en van schattingen hebt voorzien is er normaal gesproken geen grote Gant-chart met de planning voor de sprint. Hiervoor gebruik je de stand-up meeting.

Een betere manier om een stand-up meeting vorm te geven is te stoppen met het stellen van ‘de drie vragen’ en samen het Kanban bord door te spreken van rechts naar links. Op deze manier wordt werk door het systeem getrokken en wordt het duidelijk op welke plaatsen in het proces er capaciteit ontstaat op zich blokkades voordoen. Deze manier van stand-up meetings wordt succesvol toegepast in projectteams van meer dan 50 personen en staat beschreven in het boek van David Anderson over Kanban: http://www.amazon.com/Kanban-David-J-Anderson/dp/0984521402

Een stand-up meeting is volgens mij niet bedoeld voor het uitwisselen van ‘lessons learned’. Ik denk dat andere technieken, zoals pair-programming zich daar beter voor lenen.

Klopt dat of mis ik iets?

Het analogon is natuurlijk een simplificatie. Het spectrum van toepassingen is in de software minder discreet. Programmeurs zijn altijd wel x% gebruikers van een geprepareerde omgeving en 100-x% preparatoren. Hoe meer je met verschillende talen leert omgaan en de achterliggende abstracte concepten begrijpt, hoe beter je zal programmeren.

Maar in essentie heeft een gelijkaardige verschuiving plaatsgevonden in de software-industrie. Er is nu een massa webdevelopers, die vooral leuke websites willen ontwikkelen en maling hebben aan de achtergronden. Opleidingen moeten hier op inspelen, door de gemakkelijskte omgevingen aan te bieden om snel resultaten te halen. Anderzijds is er nog altijd, of nog meer, nood aan breedte en diepte in de opleiding, zodat dergelijke omgevingen überhaupt nog kunnen worden gemaakt of onderhouden.

Een opleiding tot mechanicien is veel complexer dan een rij-examen. Evenzo is een opleiding computerwetenschappen moeilijker dan een cursus webdevelopment. Het brede spectrum tussen die uitersten zorgt misschien voor verwarring. Technologische bedrijven en opleidingen doen er echter goed aan het bestaan van die uitersten voor ogen te houden.