Dikke-vette-jammer-de-bammer? Deze overtreffende trap van ‘jammer’ kwam mijn leven in via een van de leerkrachten op de middelbare school van mijn dochters. En sindsdien gebruiken we hem thuis vaak als iets ‘heel jammer’ is. Maar ook wanneer ik een training verzorg stuit ik nogal eens op zo’n dikke-vette-jammer-de-bammer moment.
Binnen de PRINCE2® trainingen die ik verzorg gaat het dan om de inbreng van beheer (operations) in projecten waarin software ontwikkeld wordt. Daar is het in het verleden nogal eens iets mis gegaan. Beheer werd niet betrokken, tot het moment dat de software over de hoge schutting tussen ontwikkeling en beheer werd gegooid.
Misschien wel als logische tegenreactie op het negeren van beheer, ontstond in menig bedrijf een cultuur waarin beheer een standaard lijst van niet-functionele requirements ging opstellen. Het project had zich daar maar aan te houden. En beheer ging zich vervolgens gedragen als strenge poortwachter in de, inmiddels in de hoge schutting aangebrachte, poort. Voldoet u niet aan onze requirements? Dikke-vette-jammer-de-bammer en de poort blijft dicht.
Vanuit het oogpunt van beheer niet geheel onlogisch overigens: hun taak is toch vooral om een stabiele omgeving voor de gebruikers (de business) te bieden. Die stabiliteit wil de laatste jaren nogal eens botsen met de steeds meer dynamische en flexibele manier waarop we software ontwikkelen in agile projecten. Wat je dan ziet is dat ontwikkelteams (development) op een agile manier (bijvoorbeeld met Scrum), in kort-cyclische timeboxen (sprints) elke paar weken werkende software opleveren met daarin de features waar de business op dat moment de hoogste behoefte aan heeft. Vervelend alleen dat die software niet snel bij de gebruikers komt: de poort naar beheer wordt in veel organisaties slechts een maal per kwartaal geopend. En weg is je snelle oplevering naar de business.
Mijn collega Dave van Herpen van Sogeti heeft hier een mooie kreet voor: agilus interruptus. Ik zie hier weer een gevalletje dikke-vette-jammer-de-bammer.
Het buzzword dat de oplossing voor deze uitdagingen biedt is momenteel DevOps, een samentrekking van Development en Operations. Geïntegreerde teams van ontwikkelaars en beheerders die samenwerken en samen verantwoordelijk zijn voor ontwikkeling en beheer van een product. Waarbij ik zelf overigens de business mis. Dus wat mij betreft hebben we het liever over BizDevOps.
Om die business continu te leveren waar op dat moment de prioriteit ligt, wordt steeds meer gestreefd naar het op geautomatiseerde wijze integreren van software (continuous integration), het opleveren (continuous delivery) en ter beschikking te stellen aan de business (continuous deployment).
Grootste uitdaging in dit proces is het maken van een cultuuromslag: de ontwikkelteams zullen meer aandacht moeten hebben voor het feit dat de software ook beheerd moet worden, de beheerders zullen de juiste balans tussen stabiliteit en dynamiek moeten vinden en last but not least: de focus van het hele team moet continu liggen op het leveren van business value. Wanneer je er in slaagt BizDevOps teams écht samen te laten werken, dan zou het aantal dikke-vette-jammer-de-bammer momenten wel eens flink kunnen afnemen!