Het valt niet te ontkennen, want inmiddels wordt 80% van de software wereldwijd ontwikkeld met een agile methodiek. Agile is in, maar misschien moeten we wel op zoek naar ‘the best of both worlds’ van de software ontwikkeling; traditioneel en agile. In deze blog gaan we terug in de tijd (1986!); het eerste artikel wat scrum beschrijft zoals het vandaag de dag nog steeds wordt toegepast. En wat blijkt? Zo eenvoudig als agile in de ogen van sommigen misschien wordt voorgespiegeld, zo is het niet helemaal. Zoekt u antwoorden op de vragen en dilemma’s die aan de orde worden gesteld in dit blog? Bel dan eens met VKA, of stuur een mail!
De agile goeroes deden hun inspiratie op uit een artikel van Hirotaka Takeuchi en Ikujiro Nonaka met de titel “ The New New Product Development Game” . We schrijven 1986(!), en de auteurs vergelijken zes cases op het gebied van productontwikkeling in een wereld die steeds hogere eisen stelt aan innovatiesnelheid en flexibiliteit. Verwijzend naar overlappende productiefasen beschrijven ze een ‘holistic approach, where a team tries to go the distance as a unit, passing the ball back and forth [and] engages in iterative experimentation. “Moving the scrum downfield (…) like a rugby team, the core project members stay intact from beginning to end and are responsible for combining all the phases.”
Bij nader inzien echter, wordt er toch nog ook wel weer een klein beetje ge-managed. Een bestuurder van Honda zegt onomwonden: “It’s like putting the team members on the 2nd floor, removing the ladder, and telling them to jump or else. I believe creativity is born by pushing people against the wall and pressuring them almost to the extreme.” En over specialismen vertelt een project leider bij Epson: “I tell my people to be well-versed in two technological fields and in two functional areas. Like design and marketing. Even in an engineering-oriented company like ours, you can’t get ahead without the ability to foresee developments in the market.” Het eerste wat deze projectleider zelf deed toen hij als mechanical engineer toetrad tot een scrumteam was electronica gaan studeren, en oude kennis opdoen. Takeuchi en Nonaka zeggen over teamleden: “ they must accumulate knowledge from across all areas of management, across different levels of the organisation, functional specialisations, and even organizational boundaries. Such learning in breadth serves as a necessary condition for shared division of labor to function effectively.” Over een HR uitdaging gesproken….
We weten bijvoorbeeld dat ook de ‘oude wereld’ niet zonder improvisatie kan. En we weten dat een proces-oriëntatie in plaats van een procedurele oriëntatie tot de belangrijkste competenties van projectmanagers behoren. Scrum tackelt perfect het probleem van pooled dependancy van taken. In een operatiekamer staat het personeel ook allemaal aan dezelfde tafel te werken. Maar soms is informatie zo omvangrijk, complex en verweven dat enige ordening vooraf handig is. Misschien toch nog eens kijken naar de oude versnipperde en hiërarchische wereld? Het Scaled Agile Framework (SAFe) onderkent dit met introductie van top down gekoppelde regelkringen met high level planning en ontwerp, met “functiescheiding” tussen architecten, coördinerende rollen, analisten, ontwikkelaars en testers, en met een sterke nadruk op voortgangsmeting. De meeste kritiek op het raamwerk lijkt dan ook te komen van de Agile community zelf, precies vanwege dit soort dingen. Het zou een Janus-kop zijn, het is niet Agile meer. En ondertussen heeft een Agile aanpak als SAFe een wel heel bijzonder effect: de nadruk verschuift van projectproductie en -planning naar serieproductie en –planning. En door verregaande industrialisatie via geperfectioneerde productiestraten is de ruimte voor daadwerkelijke innovatie wel heel klein geworden. Ook daar lijken Takeuchi & Nonaka al voor te waarschuwen….Maar hoe kan dat nou, hoe moeten we dan wel innoveren, want daar was het toch allemaal om begonnen? En wat verstaan we eigenlijk onder innovatie?
Kortom, het glas is voor zowel de hiërarchen als de Agile scrummers half leeg en half vol, en misschien is dat wel realistisch? Laten we dus toch maar heel zuinig zijn op al onze architecten, projectmanagers en testers! En beter kunnen we ons afvragen welk werk we het best kunnen laten uitvoeren in waterval projecten, in agile scrum projecten, of in een fabrieksmatige omgeving.
Het is duidelijk, zo eenvoudig als het in de ogen van sommigen misschien lijkt, zo is het niet helemaal. Zoekt u antwoorden op de vragen en dilemma’s die aan de orde worden gesteld in dit blog? Bel dan eens met VKA, of stuur een mail!