Agile, leiderschap en projectmanagement

Agile, leiderschap en projectmanagement

Agile, leiderschap en projectmanagement.

In de wereld van de ICT / Informatica – ik gooi beide, hoewel problematisch, voor het gemak op één hoop -, vrijwel geheel een mannenwereld, zijn een aantal trends te bespeuren die ik erg interessant vind. Nu zal ik niet uitweiden over trends met betrekking tot allerlei technieken & technologieën maar eentje melden die eigenlijk over het verschil tussen leidinggeven en managen gaat en een heel klein beetje over de ‘constructen’ feminien en masculien. Dus wellicht interessant voor de mensen uit mijn netwerk en dan met name diegene die in of voor projecten werken en/of regelmatig te maken hebben met ICT en Informatica.

Ontwikkelaars (je weet wel, de softwareprogrammeurs en degene die erg veel verstand hebben van techniek, de echte professionals op hun gebied) ervoeren dat er in de traditioneel geleide projecten teveel nadruk werd gelegd op documentatie, projectmanagementtools en geld in plaats van op kennis, mensen, soft skills en kwaliteit. Onder traditioneel verstaat men dan de verzameling ‘watervalmethoden’. Daar bedoelen de mannen die projecten mee, die in opeenvolgende projectfasen worden opgedeeld, waarin elke discipline haar ding doet , via een overdracht aan de volgende discipline wordt overgedragen én (dit is heel belangrijk!!) die bestuurd wordt via een soort ‘command and control’ structuur. Laten voor de discussie zeggen: de bureaucratische waterval methodiek.

Hele gemeenschappen van ontwikkelaars werden daardoor behoorlijk ongelukkig op hun werk en voelden zich als mens nogal ondergewaardeerd. Daarnaast resulteerden vooral IT projecten vaak in informatiesystemen en applicaties die niemand geschikt vond en die ook nog eens te laat opgeleverd werden en veel teveel kostten.

In een speurtocht naar methoden die zowel beter recht doen aan de professionele mens in ICT projecten en de vraag naar softwaresystemen waar de gebruikers iets aan hebben, werden manieren om software te ontwikken en projectmanagement aanpakken bedacht.

Een voorbeeld van een software bouwmethode is bv. eXtreme programming (XP), daarnaast heb je ook manieren van ontwerpen / bouwen die het testen van de software meteen meenemen zoals test driven development (TDD), je hebt Rapid Application Design (RAD) waarin de inbreng van de gebruikers wordt gefaciliteerd, Rational Unified Process (RUP) een raamwerk dat IBM uitvond, en managementmethoden zoals Dynamic System Development Method (DSDM), Project management Body of Knowledge (PMBoK), etc.

Elk van de software ontwikkelingsmethoden richtte zich op een deel van het proces dat doorlopen wordt om een werkbaar informatiesysteem te creëren en de managementmethoden gingen uit van ofwel iteratief werken ofwel opdelen van proejcten in overlappende fasen en hadden dus allemaal hun een eigen insteek of ‘smaak’. Een veelheid aan manieren, dus, waarvan de combinatie wel eens de oplossing voor de geschetste problemen konden zijn.

Op een gegeven moment (2001) hebben een aantal ICT experts de “Agile Alliance” opgericht . Dit waren mannen die elk min of meer een van de ontwikkelmethoden vertegenwoordigde. Deze alliantie wilde een beweging op gang zetten om er voor zorgen dat ICT mensen plezier in hun werk kunnen behouden terwijl zij tegelijk snel, kwalitatief goed werk opleveren. Ze hebben een viertal leidmotieven geformuleerd in een zogenaamd manifest die als volgt te vertalen zijn:

· Mensen en interacties gaan boven processen en hulpmiddelen

· Werkende software gaat boven lijvige documentatie

· Samenwerking met de klant gaat boven contract onderhandelingen

· Openstaan voor veranderingen gaat boven het volgen van een vooraf opgestelde plan

Er zijn ook nog een twaalftal principes maar dat zal ik jullie niet mee vervelen. Kijk daarvoor op de pagina van de Agile Alliance.

Vanaf dat moment is er een discussie ontstaan over welke methode nu wel of nu niet ‘agile’ is. Uit de discussies die ik gevolgd heb, begrijp ik dat methodes / methodieken in ieder geval aan de volgende criteria moeten voldoen:

· Iteratief (in korte –feedback- loops, circulair) of incrementeel ( kleine stukje) software opleveren

· Multidisciplinair (minimaal 1 ontwerper, 1 ontwikkelaar en 1 tester in één team)

· Zelforganiserend team (geen bevel structuur, niet bureaucratisch)

· Samenwerking en communicatie (met elkaar en met de klant)

· Telkens kunnen (her) prioriteren van de eisen en wensen, afhankelijk van de veranderde omgeving

Ik ben hierin natuurlijk niet compleet, laat dat gezegd zijn. Het discours over het wel of niet Agile zijn van een methode of aanpak zal nog wel enige tijd voortduren. Ook zullen nieuwe aanpakken zoals Scrum en de ‘Atern’ versie van DSDM ontstaan, en onderzocht worden of en hoe bestaande project managementmethoden die de hele levenscyclus van een project bestrijken zoals bv. PRINCE2 en PMBoK, zijn te combineren met meer Agile aanpakken. Ondertussen heeft ook het vakgebied marketing het woord Agile opgepakt. Dat komt ervan als je een gewoon, in dit geval Engels, woord als begrip, testament of manifest gebruikt. Hoewel Agile in ICT dus heel serieus is bedoeld wordt ze inmiddels maar al te vaak als sexy marketingkreet gebruikt. De discussie over wat nu wel Agile is en wat niet, wordt daarmee behoorlijk diffuus.

Dat alles bracht mij op de volgende gedachte: “Als ik het zo bekijk, gaat “Agile’, zoals het manifest het uitlegt, over het verschil tussen goed leiderschap en fatsoenlijk managen. De teaser waar ik dit verhaal mee begon….

Mag ik het als volgt onderscheiden?

Goed leiderschap:

· Gedeelde visie, missie & strategie

· Mensen die de organisatie zijn

· Nadruk op menselijke interactie

· Samenwerken en onderlinge afstemming

· Zelforganisatie, ondernemerschap

· Eigen initiatief

· De goede dingen doen, plannen

Fatsoenlijk management:

· Verdeelde verantwoordelijkheden

· Mensen als resources voor de organisatie

· Nadruk op instrumenten

· Werkverdelingstructuur, functionele indeling

· Procedurele afspraken

· Hiërarchische lijnen

· De dingen volgens afspraak doen, planningen

En wat mij ook hogelijk intrigeert , is de vraag of er een soort “vrouwelijke injectie’’ in (een deel van) de ICT wereld is gegeven. Waarom vraag ik me dat af? Ik zie zoveel verbanden.

Misschien herinneren enkele van jullie het college van Iteke Weeda nog. Zij behandelde de ordening in de verschillen tussen als feminien en masculien geclassificeerde aspecten. Als ik die aspecten vertaal naar de ontwikkelingen zoals hierboven beschreven kom ik op het volgende uit:

· Feminien zijn: Wij (samenwerking), Circulair (iteratief), Pluriform (multidisciplinair), Nu (aanpassing), Subject en Context, Systeeminteractie en

· Masculien zijn: Ik (macht), Lineair (algoritmen), Singulier (per discipline), Toekomst (vast plan / planning), Object (georiënteerd), Abstract, Systeemontwerp en -bouw.

(Deze opsomming kan zeker als polariserend worden betiteld en ik daarom krijg ik hier graag commentaar op)

Of is er juist een verschuiving naar ‘gender neutraliteit’ aan de gang omdat de klassieke (‘patriarchaal- mannelijke’) ordening in de Informatica / ICT wereld als problematisch wordt gezien of wordt de in mijn ogen nog heersende monocultuur aan de kaak gesteld? Zonder er een semantische discussie over te willen voeren, zou ik hier graag eens met informatici en technici uit de ICT wereld over van gedachten willen wisselen.

Mary

1 comment

Jij ziet een feminiene ontwikkeling in het ontwikkelproces.
Ik zie een vergelijkbare ontwikkeling in de informatiekunde.
In
mijn blogs
benoem ik dat we van het informatie tijdperk naar het conceptuele
tijdperk verschuiven. Het informatie tijdperk is technologie gedreven,
analytisch, linker hersenhelft georienteerd. In het conceptuele
tijdperk moet daar aan worden toegevoegd innovatief, holistisch,
contextueel en rechter hersenhelft georienteerd.

Rijk van Vulpen
is enterprise architect bij Caerleon.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *