Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Scrum voor de enterprise

Impressie van Scrum Day Europe 2013

 

Rini van Solingen

Op vier juli 2013 was het zover: Scrum Day Europe in Amsterdam. Een vol programma met als hoofdonderwerp: Scrum voor de Enterprise! (Scrum op bedrijfsniveau). Vorig jaar mocht ik dagvoorzitter zijn. Dit jaar had ik een veel betere rol: die van bezoeker. Geen verplichtingen, maar me de hele dag onderdompelen in alle verhalen, workshops en ervaringen. Heerlijk! En natuurlijk het leggen van nieuwe contacten en bijpraten met reeds bestaande. Kortom, een leuke dag!

Om half negen was ik bij Pakhuis de Zwijger aan het IJ. Het was rustig onderweg en ook het parkeren was snel geregeld. Ik ben niet de eerste. Er staat een korte rij voor de ontvangstbalie. Ik krijg mijn badge met keycord. Eerst maar even op het gemakje wakker worden met een bak koffie. Lekker!

Ik ben, net als vorige jaar, weer onder de indruk van de locatie. Niet het standaard conferentiecentrum. Het is hier heel bijzonder. Klinkt een beetje tuttig, maar het is er knus; gezellig. Dat geeft meteen al een heel aparte sfeer. Lekker informeel. Ik ben dan ook klaar voor de dag.

Programma

De organisatie heeft een indrukwekkend programma neergezet. De openingspresentatie door Ken Schwaber (samen met Jeff Sutherland de bedenker van Scrum) en Gunther Verheijen. Beide zijn van Scrum.org: de organisatie die Scrum onderhoudt en trainers certificeert voor Scrumopleidingen. Zij presenteren op een vrolijke manier de consequenties van Scrum voor een onderneming. Wat betekent het als softwareteams met Scrum gaan werken en daardoor steeds sneller worden? Wat kunnen we met Scrum op organisatieniveau? Hoe ver gaan we hier op in?

De presentatie richt zich vooral op de voordelen van wendbaarheid en flexibiliteit voor een bedrijf. Agility dus. Hiervoor presenteren ze het Enterprise Scrum-model. Een model dat helpt om organisaties stapsgewijs meer Agile te maken. Centraal in dit model staat de Agility Index. Hoe Agile zijn wij eigenlijk en wat is de volgende stap?

Na deze eerste presentatie deelt Henk Richmond van PGGM hoe zijn leven als manager is veranderd sinds zij met Scrum zijn gestart. Wat mij vooral is bijgebleven van zijn presentatie is hoe veel beter de samenwerking tussen business en it is veranderd voor Richmond. Dat hij nu veel minder bezig is met operationele dingetjes en veel sterker bezig is met de samenwerking en het leveren van business waarde.

Daarna waren er een groot aantal parallelsessies. Het was moeilijk kiezen: Agile Games, het Scrum spel, Open-Space, Management zonder zweepjes, Agile Metrics, Scrum en SAP, SNS Reaal ervaringen. Te veel keus eigenlijk. Ik wilde overal wel bij zijn. Dat is dus ook wat ik stiekem heb gedaan. Een beetje van sessie naar sessie springen en overal een beetje luisteren. De opkomst bij de parallelsessie over Agile Metrics was indrukwekkend. Deze sessie was afgeladen! Ongeveer 75 procent van de deelnemers aan de Scrum Day Europe kwam hier op af. Misschien lag dat ook wel aan de pitch van spreker Rob van Lanen. Hij beloofde namelijk een sessie over ‘Management Pornography’ tijdens het plenaire pitchen van de sessies. Overigens wel een teken dat hier veel vragen leven.

Na de goed verzorgde lunch waren er nog twee plenaire presentaties en een panel. Ik moet eerlijk zeggen dat ik de eerste presentatie van Diego Lo Giudice van Forrester, over Agile Testing, heb laten lopen. Heb lekker op de gang een beetje staan bijpraten.

Ik ben wel naar de presentatie van Philips geweest. Die was echt geweldig! Edgar van Zoelen presenteerde met veel energie en daadkracht hoe Philips met Scrum bezig is. Indrukwekkend! Gaaf was het bijvoorbeeld om een filmpje te zien van Frans van Houten, ceo van Philips, die uitlegt hoe belangrijk Agility is voor Philips en wat Scrum daarin voor hen betekent. Het meest indrukwekkende van het verhaal van Van Zoelen vond ik de compromisloze manier waarop ze Scrum invoeren: 'fixed teams, fixed budgets, fixed releases'. Geen uitloop en dynamiek. Ze hebben Scrum echt begrepen!

De afsluiting van de dag was een CxO panel. Interessant om te zien hoe op het hoogste managementniveau over Scrum wordt gedacht. De dag werd afgesloten met een plenaire Retrospective en daarna: de borrel! Bij het weggaan kreeg ik nog een Scrum Day Europe rugbybal – mét handtekening van Ken Schwaber! Die staat nu in de kast met andere memorabilia.

Al met al was het een erg inspirerende dag. Veel geleerd en een aantal hele leuke nieuwe contacten gelegd. En natuurlijk ook weer lekker bijgepraat. Ik kijk al weer uit naar volgend jaar!!

Mocht je overigens een indruk van de dag willen krijgen, of de sheets van de presentaties willen inzien, ze staan inmiddels gewoon online op: www.scrumdayeurope.com.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4795855). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Eigenlijk niet te geloven dat zoiet occults als Scrum en Agile zo een opgang maakt. Nog meer rollen voor mensen die geen achtergrond in de techniek hebben om als een soort slavendrijvers die suffe technische ict ers aan te sturen, want ja de bussiness beslist. Wat moet je verwachten van een methode die zegt dat documentatie niet belangrijk is en dan ook nog durft te beweren dat mensen belangrijker zijn dan processen terwijl het omgekeerde waar is. Integendeel als ik de ervaring van de tecnhische mensen in mijn omgevingen hoor. Kinderachtige rituelen, overbodig vergaderen en de verkeerde mensen (businnes) die bepalen wanneer of wat. Zorg voor goede documentatie, zorg voor een goed technische projectleider, testers, ontwikkelaar en beheerder. Eerlijke heldere rollen. Sofware maken is een creatief vak wat niet fabrieksmatig geproduceerd wordt. Ik zie hier vooral een hele industrie van opleidingen, scrum en het misbruikte agile zijn typisch dingen voor het management om een soort van micromanagement uit te voeren over het het technisch personeel. Ik denk alleen maar, overbodig overhead en killing voor het creatieve ict vak. Ik lees hier trouwens ook alleen maar verhalen van mensen uit het hogere management.

@Louis Kossen: je argumentatie tegen is precies de argumentatie die ik vóór zou gebruiken. Want Scrum is wat mij betreft juist de mogelijkheid voor creatieve mensen om te exelleren. En dat was met strak, door projectleiders geplande, projecten nu precies waar de goede en creatieve ontwikkelaars op stuk liepen.
Een beetje pragmatiek en minder rituelen mag van mij ook, maar de positieve punten geven bij mij de boventoon.

Zelf gebruiken we Scrum binnen software development. Het nadeel van de methode zelf vind ik, dat het doel vaak uit het oog wordt verloren.

Ik denk dat veel mensen er tegen aanlopen dat er gepland wordt wat je moet doen. Dus iemand bepaalt dat voor je. Zelf hebben we het om gedraaid, je plant in, wat je doet. Dit betekent dat we doornemen wat we gaan doen, daarna moet je dit wel uitvoeren natuurlijk.

De doelen voor een team (met of zonder Scrum)
• Doe wat je moet doen, je stemt nl met je team af welke dingen wel mogen en welke dingen niet. En Scrum hoeft helemaal niet alleen over development te gaan. Wij nemen alle activiteiten mee, zoals marketing materialen schrijven, trainingen geven, services uitvoeren etc. Alle prioriteiten hebben nl met elkaar te maken.
• Zorg voor duidelijke regels voor je budget.
• Zorg ervoor dat problemen zo vroeg mogelijk naar voren komen. in Scrum heb je dus de dagelijkse meetings en wij plannen in principe 2 weken vooruit.
• Zorg dat je mensen die belang hebben bij jouw team resultaat, er ook bij betrokken zijn. Zij kunnen nl invloed op de prioriteiten uit oefenen.
• Zorg er voor dat je niet teveel hooi op de vork neemt.
• Verdeel het werk niet alleen op basis van rollen, maar ook op basis van competenties. Als er een klant gebeld moet worden, zullen er vast meerdere mensen zijn die het kunnen.
• En wees niet rigide. Als je het niet haalt, schuift de planning gewoon door. Je kunt wel een keer overwerken, maar als dat structureel is, dan doe je wat gepland is en dat zorgt voor frustratie. Omdraaien dus. Plan wat je doet / kan!
• Daarnaast heb je natuurlijk klussen die geen eind datum kennen. Denk bijvoorbeeld aan innovatie, verbeteringen, onverwachte problemen etc. Dit hoort bij je werk net zo goed als andere dingen. Plan dit dan ook in. Bijv. dat je op dinsdag innovatie doet en op andere dagen niet. Het einddoel staat wel vast, maar niet hoe je er komt en binnen hoeveel dinsdagen. Als je dat nl wel weet dan is het geen innovatie meer. Zo wordt creativiteit dus nog steeds behouden.

Het zijn maar wat tips, maar zelfs ik als vrijheidslievend mens (ik wil geen controle) vind Scrum fantastisch. Zorg gewoon voor goede, bruikbare regels en zorg ervoor dat het leuk blijft.

Louis Kossen heeft gelijk.

Het is al verdacht dat het mensen niet eens opvalt dat hele volksstammen klakkeloos met dat scrum weglopen, vooral de mensen die niet zoveel van computers snappen.

Als mensen zélf zouden nadenken i.p.v. anderen (goeroes!) nawauwelen, dan zouden er veel meer van methoden in gebruik zijn en niet alleen dat ergerlijke scrum. Het werkt net als met voetbal, films uit Hollywood, boeken uit de boeken top 10. Dat vindt men massaal prachtig en dat is gewoon omdat het wordt aangeboden/opgedrongen. Er zijn nu allemaal bedrijven die dat scrum zitten te pushen en dan wil men gewoon "bij de groep horen" door het ook prachtig te vinden. Over vijf jaar is scrum weer weg en verzint men weer wat nieuws en noemt men scrum gekscherend 'scum'. scrum gekscherend 'scum'. http://www.urbandictionary.com/define.php?term=scum

Er zijn veel argumenten tegen scrum. In de reacties op dit artikel hoor ik eigenlijk alleen dat niet iedereen het begrijpt. Alle genoemde scrum nadelen worden in talloze (Internet) publicaties over scrum misunderstandings op Internet gewoon besproken en serieus genomen. Agile/Scrum suggereert nooit dat de methode altijd voor iedere situatie de beste oplossing is, dat documentatie niet belangrijk is, dat elke ritueel altijd even uitvoerig moet worden uitgevoerd. Het is een reactie op de falende Waterval methode (proven failed technology) die het vertrouwen in ICT als geldverslissende nerds kostenpost, weer enigzins teruggeeft.
Maar misschien is inderdaad niet iedere ontwikkelaar competent en zelfstandig genoeg om de verantwoording aan te kunnen die bij Agile/Scrum noodzakelijk zijn.

@LeenBlom Bij een maat van me was door de leancoach (een variant op het thema) van dienst de tekst opgehangen: het zijn niet de slimsten die overleven maar wel zij die zich het beste weten aan te passen. Oei. Dat is ook waar ik tegen aanhik: dat Scrum/Agile etc. is niet helder, biedt ict inhoudelijks niets behalve verwarring (het agile manifesto) en bovendien het is belemmerend met zijn gewoontes en rituelen en heeft het welhaast fundamentalistische karakter. Proces boven inhoud. Leuk voor een Aziatische autofabriek maar niet voor een ict project. Wat moet ik ermee dat je als ontwikkelman niet mag praten met anderen en alleen mag praten met de gebruikers als de scrum master dat goed vindt? Is dat een situatie waarin een creativiteit optimaal benut wordt? Dat geloof ik niet. Ik geloof niet dat als je een project laat leiden door inhoudelijk geschoolde en ervaren mensen ipv een combi van gebruikers en procesbegeleiders, dat een project dan star en strak is. Ook daar kan ruimte zijn voor onzekerheid en voortschrijdende inzicht. Agile zeg maar... en dan is voor de creativiteit die eigen verantwoordelijkheid wel het beste medicijn.

@JohanVeldhuizen Je schrijft dat scrum gebruikt wordt maar dat het doel uit het oog verloren wordt. Ik ben benieuwd. Wat ik zelf lees als het over scrum gaat is dat de scrumgemeenschap eigenlijk zelf niet weet waar ze mee bezig is en weet wat scrum betekent. Dus ja, je krijgt een verlegde discussie wat nu ware scrum/agile is. Wat moet er in de product backlog? Hoe lang moeten die sprints? Moet je staan of moet je zitten? Moet je met zijn tweeen werken of niet? Hoe lang moet de dagstart duren? En @mauwerd, ja moet er toch wel of niet documentatie zijn? Met de statement in het Agile manifesto, werkende software belangrijker dan documentatie, geeft je alle ruimte tot verkeerde conclusies. Ik denk dat het ICT vak al de handen vol heeft aan zichzelf. Wat dat betreft vond ik het artikel van Nicole de Swart: http://www.computable.nl/artikel/opinie/development/4793962/1277180/niet-elke-eis-is-een-requirement.html#4794959 en hele interessante maar ook een kenmerkende. Dit was een inhoudelijk ict artikel over wat requirements zijn maar als je alle reacties lees dan weet je ook hoe moelijk het is tot een algemeen begrip over ict terminologie te komen.

@mauwerd Ik ben heel benieuwd wat jouw kritiekpunten op scrum zijn. Over de waterfall en de kostenverslinde nerds kostenpost. Hmm, dat zal toch niet de reden zijn waarom projecten zo vaak uit de klauwen lopen zoals we hier kunnen lezen? Daar geloof ik helemaal niets van. Ik lees het wel vaker uit de scrum hoek. Is het geen scrum dan is het waterfall en deugt het niet. Ik geloof niet dat het zo zwart wit is, ict is toch vaker toch maar een end wegrommelen naar beste kunnen. Daar is niet zoveel mis mee, gewoon een poging doen het gezonde verstand te gebruiken en op gevoel en ervaring proberen te werken. Maar misschien heb je gelijk en is scrum/agile alleen geschikt voor competente ontwikkelaars die zelfstandig genoeg zijn om die verantwoording aan te kunnen. Nu ben ik een uitvoerend it man die meer niet weet dan wel weet en daarom hoor ik misschien ook wel tot de mensen die er doodongelukkig van worden, al die ruis en onduidelijkheid die niet over ict gaat. En weer een hele groep niet ict-ers die erom heen loopt te springen.

Nog 1 ding, deze ontwikkelingen waarbij procesbegeleiders belangrijker zijn dan de inhoud is wel iets wat past in in de huidige tijd. De ene helft van de medewerkers is bezig met het controleren, coachen en procesbegeleiden van de andere helft. Dit is zeker niet alleen voortbehouden aan de ict. Verantwoording van de werkzaamheden is minstens zo belangrijk geworden als het werk zelf. Goed voor de werkverschaffing, slecht voor de productiviteit en vooral heel kostbaar.

Aan de ene kant ben je tegen gewoontes en rituelen, regels mbt contact met eindgebruiker. Aan de andere kant moet het allemaal helder zijn. Wat we vast allemaal willen : werkende software. Maar hoe weet je nou zonder documentatie dat de software werkt (user acceptance test) ? Eenvoudig, dat doe je na elke sprint, typical 3 weken. Die periode is zo lang dat er een gedefinieerde set requirements in geimplementeerd kan worden en zo kort dat we nog allemaal weten wat die requirements dan waren.

Misschien kan ik een paar antwoorden op je vragen mbt scrum/agile geven. Zeg maar een soort uitgangs punt van concrete antwoorden op vragen boven end wegrommelen naar besten kunnen ;-)

Agile manifesto zaait verwarring : elk manifesto roept vragen op. Daarvoor is het een manifesto en geen proefschrift.
Proces boven inhoud : Nu ineens gaat in Agila/Scrum het proces weer boven de inhoud en eerst was het proces niet duidelijk ?
Praten met eindgebruikers : In principe na elke sprint, dan bepaalt de Product Owner uit naam van de business wat er ontwikkeld moet worden.
Documentatie niet belangrijk : In het manifesto lees ik "comprehensive documentation" aan de rechterkant en het zegt daarover dat "there is value on the items on the right"
Wat moet er in de product backlog : Dat bepaalt de Product Owner voor 100%. De sprint backlog, dat doet het team weer en daar is creativiteit voor nodig.
Moet je met zn tweeen werken : nee, hoeft niet.
Hoelang moeten sprints : Lang genoeg om iets te kunnen leveren, kort genoeg om lenig bij te kunnen sturen tbv nieuwe wensen.
Hoe lang moet dagstart duren ? : Volgens mij spreekt Agile/Scrum voornamelijk over daily standup, dat dat het beste rond rond lunchtijd kan plaatsvinden, niet zittend want standup en niet veel langer dan een kwartier mag duren.
Nicole de Swart over requirements : In requirements-ict-specilisatie is een requirement kennelijk wat in normale ICT een functional requirement wordt genoemd. Rest zijn non-functional requirements (in rest van ICT).
zwartwit waterval/agile: Agile is net als projectmethoden als PRINCE2 iteratief. Daarin verschilt het van traditionele methoden. Agile geeft oplossingen voor dat waarin waterval tekort schiet.
Procesbegeleiders belangrijker dan inhoud : geen idee waar je het over hebt. Scrum gaat over de business die bepaalt wat er gedaan moete worden (hoe idioot ook :-), de Product Owner die de business represtenteert en het hele team dat er een Sprint backlog van maakt. Heel weinig overhead en er-omheen-gespring zou ik zeggen.

@mauwerd Jazeker, ik heb een dwingende behoefte aan duidelijkheid maar daarmee bedoel ik natuurlijk niet de kadaverdiscipline die de betreffende scrummaster graag ziet. Maar het is wel goed om te lezen dat requirements worden vastgelegd en de basis is om te bepalen of software werkt. Welliswaar in de tijdspanne van een sprint maar toch. Kan ook niet anders want zonder documentatie weet je ook niet of je software werkt. Hopelijk zijn die requirements niet verstopt in de product backklog en bestaan ze ook in de vorm van expliciete functionele specificaties van de toepassing. Een van de verplichte deliverables van een bouwproject denk ik.

Je relativeert het agile manifesto maar dat kan natuurlijk niet voor iets wat voor een hele gemeenschap als leidraad en waarheid geldt. Daarom juist had ik liever gelezen: zorg voor functionele specs want dat is de basis om te bepalen of je software werkt. Dat soort helderheid zou ik verwachten. En niet de dubieuze statement: werkende software boven documentatie. Ik vind het eigenlijk niet te geloven dat dit serieus genomen wordt.

Ik kwam met een aantal vragen die ik lees van de scrummers waar je antwoorden op geeft. Logische antwoorden. Maar even gemakkelijk lees ik op dezelfde vragen hele andere antwoorden vanuit de scrumgemeenschap. Vandaar ook mijn statement: de agile/scrumgemeenschap weet zelf niet waarover ze het hebben. En weer, het gaat niet over de inhoud, het gaat over het proces.

Vind ik dan alles slecht aan de Agile/Scrum++ beweging? Nee, bijna wel maar ben het wel met je eens met dat het goed is dat er nu ruimte is voor onzekerheid en dat er gerealiseerd wordt dat het maken van software een iteratief proces is. Software schrijven is: weggooien en hergebruiken en de tijd moet duidelijkheid brengen. Het is goed dat om te weten dat voortschrijdend inzicht zijn plek heeft maar dat was trouwens al zo voordat de agile beweging nog maar bestond. Dat is software maken. Een ander goed punt vind ik toch die dagstart omdat het een heartbeat geeft aan project. Al mag die dagstart wmb die zonder overbodige scrummasters, met een technisch projectleider, mag je zitten en met elkaar praten, mag het 1 keer inde week en mag het wmb ook een uur duren.

Wat ik heel slecht aan de scrum methode vind is dat de productowner/business icm de scrummasters de prioriteiten bepalen. Dat vind ik niet goed voelen dat niet ict-ers een ict project bepalen. Dan is mijn vraag: wat doe je nu als technische ict-ers vaststellen dat het voor de software beter is om andere prioriteiten te stellen? Dan hebben uiteraard de technische ict-ers het laatste woord? Ik denk namelijk de business/klant bepaalt wat maar de uitvoerende ict-ers bepalen hoe. Ieder zijn vak maar zeker niet de scrummasters en productowner.

Het mag duidelijk zijn, ik ben geen liefhebber van al die uit management theorie voortkomende procesbegeleidings methodes (controle) maar aan de andere kant als mensen zich daar wel in voelen en het levert resultaten dan is het ook allemaal prima want daar gaat het uiteindelijk om. Misschien is belangrijker dan wat voor methode dan ook dat je net een juiste combinatie van mensen hebt die met elkaar klikt in de samenwerking. Dan ga ik verder voor de JBF methode!




@Louis

jij en ik weten waarschijnlijk ongeveer even veel (weinig :-) van scrum en hebben minimaal een aantal jaar ervaring in softwareontwikkeling. Toch vind jij bijna alles slecht aan scrum, terwijl ik bijna alleen maar positieve kanten zie.

Lijkt me niet dat ik je kan overtuigen. Kan alleen maar aangeven waarin jij volgens mij Agile/Scrum verkeerd interpreteert en waarom.

Eerst ff Agile/Scrum definieeren (voor daar weer narigheid van komt :-) : Agile is het een generieke filosofie mbt projectmanagement en/of softwaredevelopment, die uitgaat van het manifesto. Scrum is een implementatie daarvan.

Nu waarin we fundamenteel verschillen. In alle moderne PM en software development-methoden gaat men uit van de business die de touwtjes in handen heeft. Die bepaalt alles. Budget, prioriteiten, methoden, requirements, alles. ICT heeft alleen een adviserende en uitvoerende rol. Geldt overigens voor bijna elke vorm van dienstverlening. Als ik mijn huis met scheepvaartverf wil laten beschilderen in 3 lagen, want das mooi waterdicht, dan zegt zo'n schilder waarschijnlijk: nou meneer, dat lijkt me niet zo'n goed idee. Daar geef ik geen garantie op. Of misschien weigert hij gewoon de opdracht. Maar de betaler bepaalt.

Documentatie is gewoon een deel van de oplevering. Wil de business dat niet, dan blijft 'ie weg. Tenzij het team niet zonder kan, dan is het een non-functional en impliciet requirement geworden. Team adviseert natuurlijk wel enige documentatie. Agile is alleen tegen Big Design Up Front. Ik ook.

Ik relativeer het agile-manifesto. Nee hoor, doet het minifesto :-) zelf. Bestaat uit vier korte beweringen bestaande uit linker en rechterdeel met de toevoeging:
"That is, while there is value in the items on
the right, we value the items on the left more."

Scrumgemeenschap weet niet waarover ze het hebben ? Luister dan maar naar mij.

Iteratief werken kan en kon! ook zonder Agile/Scrum. Ja.

Dagstart is volgens mij geen scrum. Scrum spreekt over daily standup meeting, waarin je drie zaken bespreekt. Wat deed je gister, wat vandaag, wat is blocking. Precies datgene dus nodig om je collega's een kort beeld te geven wat je deed/doet, dus hoever je bent in je deel van het project en je evt te helpen met blocking issues. Stand-up en niet veel langer dan kwartier, omdat dat helpt bij scherp- en bondigheid. 1 scrummaster op 4-9 medewerkers lijkt me niet echt veel. Scrummaster is overigens geen Gestapo-functie. Scrum spreekt over ondersteunend en motiverend.

Natuurlijk vind jij het niet goed voelen dat de business de prio bepaalt. Die schilder vindt mij vast ook een idioot. Maar hij levert mij die schilderdienst waarvoor ik betaal. Niet mee eens, dan zoek ik ander. In Scrum bepalen uiteindelijk productowner en team (= master + members) hoe en wanneer geleverd gaat worden. Ik kan die schilder ook niet dwingen dat die eerst de buitenste laag verft.

Juiste mensten in een ontwikkelteam? Dat is een essentieel onderdeel van Scrum. Multidisciplinair, skilled en kunnen samenwerken. Vroeger zag ik the A-team altijd zo werken. In een sprint van 3 kwartier met maar 1 iteratie maakten ze van elk project een succes. N.B. De opdrachtgever kwam met de probleemstelling, de man met dat sigaarritueel was de interface naar het team, het team kwam met de werkende oplossing (dat telt) en kreeg daarvoor ruimte van de klant.

Mauwerd,

Met je voorbeeld van waterdichtheid en drie lagen scheepsvaartverf geef je prachtig aan waarom Louis gelijk heeft dat de beste stuurlui aan wal staan ;-)

@mauwerd, jij schreef:

"jij en ik weten waarschijnlijk ongeveer even veel (weinig :-) van scrum en hebben minimaal een aantal jaar ervaring in softwareontwikkeling. Toch vind jij bijna alles slecht aan scrum, terwijl ik bijna alleen maar positieve kanten zie."

Spijker op de kop denk ik!

Een paar weken terug had ik een een probleem met een slecht sluitende voordeur dus ik had een paar mannen gecharterd om dat probleem te verhelpen. Ik hoor van ze wat er nodig is en de prijs wordt bepaald. Ga je gang. Ik zou het werkelijk niet in mijn hoofd halen om tegen die mannen te zeggen hoe ze hun werk moeten doen. Ik ken mijn plaats en is het voor alles en iedereen, en zeker de deur, verstandig dat ik de mannen hun gang laat gaan. En misschien wel het belangrijkste, ik heb vertrouwen in de mannen die het werk moeten doen en laat ze hun gang gaan.

Je schrijft dat de bussiness betaalt en daarom bepaalt en daarom ook aan moet geven wat en wanneer er gebeuren moet bij een ict project. Is het verstandig dat mensen inhoudelijk ict projecten bepalen die geen ervaring in de ict hebben? En het andere wat ik me afvraag: is dat nou nog leuk als je op die manier te werken als uitvoerend ict'er? Ook hierbij denk ik ieder zijn vak. De vraag zou niet moeten zijn, wat willen de business en de scrummasters, de vraag zou moeten zijn wat het beste voor een project is en wat zijn de deliverables die nodig zijn en je zou verwachten.

Probleem met de ict is dat eigenlijk iedereen er wel verstand van heeft, precies weet hoe het moet en er ook nog meent over mee te moeten praten. Wat dat betreft ook wel mijn ervaringen gehad, bij een beetje project loopt er een zo een hoop volk om heen te springen. En dat is niet alleen voorbehouden aan de scrum methode al helpt dat dus naar mening niet.

Ik geloof niet de scrummaster een gestapo functie is maar het bepalen van leef en gedragregels (rituelen!) voor de teamleden door de scrummaster vind ik wel van een dubieus niveau. Maar een uniform en een herdshond heb ik zelfs nog niet gezien bij de scrummaster.

@Louis,

wat betreft je voordeur. Jij bent opdrachtgever en jij beslist dat de opdrachtaannemer zelf de oplosmethode kiest. Nix mis mee.

De vraag moet niet zijn wie bepaalt wat, in ICT vraagstukken en of dat leuk is. Want antwoord is te simpel : Business is opdrachtgever en dus de enige die bepaalt. Of iemand anders dan de business dat verstandig vindt doet niet terzake.

Jouw ervaringen zijn niet die van mij. Maar als business wil dat er gesprongen wordt, dan spring of sprint ik fijn mee. Als het maar betaalt en nuttig is voor mijn carriere. Natuurlijk zorg ik meteen dat ik certified meespringer word. Dat scheelt weer hoop gezeik met vervolgopdrachten.

Scrum overhead ? Dagelijkse standup meeting (met precies alle relevante info voor die dag) en paar meetings aan begin/eind van elke sprint, waar het hele team actief aan deelneemt..
Waren al mijn projecten maar zo.

Jij ervaart het blijkbaar anders. Gelukkig heeft Scrum na elke sprint een korte retrospective meeting. Kan jij steeds weer aangeven hoe waardeloos het allemaal was.

@mauwerd Ik denk dat je de verstandigste van ons twee bent, als er gevraagd wordt om mee te springen of sprinten als de business dat wil als het maar goed voor je carriere is, dat is waarschijnlijk de beste instelling om te hebben. Je moet het wel kunnen of willen.

Met verbijstering heb ik het artikel gelezen. Ik ga allereerst met Respect wel uit van de goede intenties van de auteur. Ik zie het plaatje en denk dan.... Ja hoor, daar gaan ze weer. Ze nemen een heel oude 'methodiek'... in dit geval het Kaizen, iets wat Toyoda in 1954, geloof ik, bij zijn eigen Toyota introduceerde maar nu noemen we het vrolijk Agile/Scrum. Van mij mag dat natuurlijk maar ik heb een zeer eenvoudige vraag voor de auteur.

Pakt u om het even, welke digitaal plaatje van het internet. Sla dit op als .... en open het dan nog eens opnieuw. Daarna blaast u het betreffende plaatje helemaal op. Zo groot mogelijk. Dan stel ik u alvast deze vraag....: Hoe denkt u dat een pixel eruit ziet?

Die ene pixel die u uiteindelijk op uw scherm krijgt, is synoniem voor elk IT proces die u zich voor kunt stellen. Of dit nu het indrukken van een knop is, of het opzetten van een IT traject. Vat u hem al? Niet?
Een IT proces, in de meest elementaire vorm, is NIET ROND! Die is lineair! Vierkant of rechthoekig.

Elk proces binnen IT is onderworpen aan precies dezelfde wetmatigheid. Dat betekend dat je dat met elke procedure ook zult moeten doen. Doe je dit niet? Dan weet je zeker dat je een keer 'probeert' buiten de grenzen van je proces te treden en dan weet je wat er zal gebeuren met IT als materie. Je krijgt Problemen.

Nu weten heel veel van die bedenkers die tot 'scrum en agile' zijn gekomen, helemaal niet eens af van het gegeven van wetmatigheden van de lineaire IT. Dat is meteen waarom het dan ook zo vaak FOUT blijft gaan.

We kijken, heb ik vernomen, tegen een nieuw product aan. Wat heeft men bedacht. We gaan oude Chinese/Japanse wijsheden Lean noemen. U kunt uw groene of zwarte band halen, maar dan ben je ook 'master'... in...... vult u hier maar iets in.

Ik heb kennis genomen van Scrum, ik heb kennis genomen van de achtergrond, intentie en werking van Lean. Na ruim dertig jaar Aikido en Iaido kom ik tot de zeer eenvoudige slotsom dat men gewoon oude wijn in nieuwe zakken probeert te verkopen. Lees hier, Lean of Scrum. Men is alleen heel even iets vergeten.

Fix the problem, not the cause!
De basis en gedachte van Kaizen is namelijk....dat je door herhalen tot verbeteren komt van een proces, procedure, output. Die wetmatigheid kan alleen maar werken wanneer men oog heeft voor behoud van Human Capital.
Aangezien we hier in NL te maken hebben met een cultuur van Blame, Shame and Serve out, zul je zien dat de Scrum en Lean in a: In IT contraproductief is en B: Als methode er slecht zal blijven hangen.
Dit laatste omdat er commercie erbij is betrokken d.m.v. externen die na de klus de deur weer achter zich dicht trekken.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×