Multifunctionele teams vormen het DNA van DevOps

Multifunctionele teams waren er in de beginjaren van de ICT, de jaren 1950, 1960 nog niet, er was zelfs nog geen standaard ontwikkelmethoden voor software. Binnen organisaties die in het bezit waren van een computer werden applicaties ontwikkeld door programmeurs die een soort machtspositie in namen binnen de organisatie. Deze positie heeft nog lang in het DNA van de IT-ers gezeten.

Omdat er niet gewerkt werd volgens een methode wist niemand precies wat er opgeleverd zou worden of hoeveel het ging kosten. De zogenaamde JBF (Jan Boeren Fluitjes) methode. De behoefte aan informatie over het automatiseringsproces groeide en men probeerde het meer en meer te sturen. De OHZ (Op Hoop van Zegen) methode bracht een kleine verbetering want deze methode kende 2 zekerheden: Je weet dat het schip strandt en dat de vis duur betaald wordt. Een kostbare periode van automatiseringsprojecten die vaak nergens toe leidden.

Een nieuw DNA: ICT Ontwikkelmethoden

Zo ontstond er meer en meer behoefte aan software ontwikkelmethoden. Hierbij werken programmeurs volgens vooropgestelde processen aan de ontwikkeling van maatwerksoftware. Inmiddels zijn er heel veel methoden die sturing op ontwikkeling van software beogen. En even zo veel methoden zijn al weer ter ziele. Al deze methoden richten zich op het realiseren van deliverables. D.w.z. plannen, ontwerpen, programmatuur, procedures, manuals, etc. Deze gestructureerde werkwijzen zat in het DNA van veel IT-ers.

In grote lijnen zijn er twee soorten methoden onderscheiden; watervalmethoden en iteratieve (Agile) methoden. Waterval methoden kennen een aantal fases waarbij iedere fase een mijlpaalproduct kent dat de projectgroep eerst moet goedkeuren voordat men met de volgende fase kan starten. Hierdoor kan het gebeuren dat een project pas na jaren wordt opgeleverd. In die jaren stond de tijd niet stil en bleek de software niet aan te sluiten op de actuele bedrijfsvoering. De watervalmethoden kenmerken zich door een verscheidenheid aan specialisten die vaak niet echt samenwerken, multifunctionele teams passen hier dan ook niet bij.

Agile methodes lossen dit probleem op door telkens binnen enkele weken een klein stukje werkende software op te leveren (de Sprint). Daardoor blijft aansluiting op de actuele bedrijfsvoering bestaan. Nadeel van de Agile methoden is dat het vaag is of een systeem echt af is. Hierdoor is het lastiger om zo’n systeem vooraf te begroten. De Agile aanpak zit tegenwoordig in het DNA van de meeste IT-ers.

Waar dienen ontwikkelmethodes feitelijk voor?

Ik weet niet of jullie ooit in een groot project hebben gewerkt maar meestal is het zo dat de spanning enorm oploopt tegen de tijd dat het deadline in zicht komt. Ruzies over wie nu eigenlijk wel of niet wat had moeten doen en wie het dan alsnog moet doen. Oververhitting en overwerk. Dit ondanks de bewezen ontwikkelmethodes. Of is het juist dankzij de ontwikkelmethodes?

Binnen een traditioneel project heeft iedereen een eigen gen in zijn DNA, zijn eigen rol, en doet enorm zijn best om zijn fase en mijlpaal zo goed mogelijk af te ronden. Daarop wordt je tenslotte beoordeeld. Door de methode ligt de focus vooral bij de eigen rol en de eigen prestatie, alsof je op een eiland zit. Dit is niet goed want de focus zou moeten liggen bij de effort van multifunctionele teams omdat het succes vooral afhangt van het gezamenlijke resultaat.
De deliverables die we maken zijn bedoelt als communicatiemiddel, input voor de volgende fase of voor de beheerders na oplevering. Het zijn vaak documenten die men over de schutting gooit. De business analist uit fase 1 is allang vertrokken als het systeem wordt opgeleverd.

Met multifunctionele teams kan het anders

Moeten we het denken in methodes niet over boord gooien? Weer terug naar het JBF maar dan met de kennis en tools van nu? Gewoon je gezonde verstand gebruiken? Want waar gaat het nu echt fout? Juist op de overdrachtsmomenten. Het uitvragen van de requirements, het uitwerken van een functioneel ontwerp, het informeren van gebruikers. Communicatie is het smeermiddel binnen een IT project. Door multifunctionele teams samen te stellen is het voor alle betrokkenen gemakkelijker om elkaar op de hoogte houden. Het DNA van ieders rol is bekend en je verplaatst je gemakkelijker in een ander.

DevOps beidt die mogelijkheid. Bij het realiseren van mijn product kan ik me een voorstelling maken wat die ander er mee gaat doen. Het gat tussen welke informatie hij echt nodig heeft en welke informatie ik aan hem geef wordt kleiner. Het grote gevaar dat je een eigen invulling geeft aan zijn informatiebehoefte wordt ineens een stuk kleiner in multifunctionele teams. Het eindproduct is een gezamenlijke verantwoordelijkheid, pak het dan ook samen op.

Multifunctionele teams zijn daadwerkelijk het DNA van DevOps, maar slecht een klein onderdeel van het hele concept. Op ITpedia vind je een artikel over alle aspecten van DevOps teams.

Communicatie: Smeermiddel voor de organisatie

Dat communicatie belangrijk is geldt niet alleen voor ICT projecten. Het geldt uiteraard voor de gehele bedrijfvoering.

• Vertel finance wat je met de klant hebt afgesproken zodat ze een juiste factuur kunnen maken.
• Zeg systeembeheer waarvoor die job op een bepaalde tijd moet draaien zodat ze geen aanmeldingen missen.
• Vertel de gebruiker dat we zijn systeem het volgende weekend moeten migreren zodat hij maandag niet voor verrassingen komt te staan (hoe vaak gaat dit niet mis?)
• Communiceer waarvoor de reorganisatie nodig is zodat men zich er op kan voorbereiden.
• Vertel AnsaldoBreda dat het weer in Nederland hogere eisen aan een trein stelt.
• Vertel je aandeelhouders over het teruglopen van het aantal orders.

Het DNA van DevOps in de rest van de organisatie..

Tegenwoordig wordt de Agile gedachte sterk binnen het domein van de ICT omarmt maar breidt zich nu ook uit naar andere disciplines binnen de organisatie. Zo kennen we inmiddels Agile Marketing (wel apart om als ICT-er bij zo’n workshop te zitten) en Agile Sales teams.
Mijn voorspelling is dat we straks multifunctionele DevOps Marketingteams (Dev) en DevOps Sales teams (Ops) krijgen. De time to market wordt nog kleiner dankzij Continuous commercial campagnes en Operational Selling. De consument krijgt het nog lastig nu DevOps het DNA van bedrijven binnendringt.

Discussieer mee op LinkedIn.