DevOps: Als het toch Nooit Af is

Begin december verscheen het tweede boek van Martijn Aslander en Erwin Witteveen, Nooit Af. In dit boek worden grote en kleine zaken bekeken met het uitgangspunt: het is Nooit Af. Eens kijken wat er gebeurt als we dat doen bij IT-oplossingen. En cloud oplossingen in het bijzonder. Nooit Af Martijn en Erwin stellen dat veel zaken ooit bedacht en gemaakt zijn met het idee dat het Af is. Dat wil zeggen, je zet het neer en hoeft er jaren niet meer naar om te kijken (beetje poetsen en klein onderhoud, dat is alles). Dit heeft betrekking op een breed scala van onderwerpen. Of het nou gaat om technologie, zorg, onderwijs of overheid, we maken zaken eerst Af en gaan het dan gebruiken. Maar wat blijkt nu: steeds vaker zijn deze zaken sneller achterhaald dan ze ooit waren. En moeten dus sneller worden vernieuwd dan we gewend waren. En dat tempo neemt alleen maar toe. Deze nieuwe realiteit stelt eisen aan de manier waarop we de boel aanpakken. Eerst uitgebreid nadenken, dan plannen, uitvoeren, testen of het voldoet en uiteindelijk een keer gaan gebruiken, duurt simpelweg te lang. En is veel te kostbaar. We gaan ervan uit dat iets Af is als we er klaar mee zijn. Dit blijkt dus niet zo te zijn. Als we er nu vanuit gaan dat het resultaat toch Nooit Af is, dan pakken we het waarschijnlijk wel anders aan. Het boek Nooit Af is een absolute aanrader om te lezen, maar voor deze blog volstaat het snappen van het concept: Wat we maken is Nooit Af. IT Oplossingen zijn ook Nooit Af Laten we direct inzoomen op de belevingswereld van Wortell: IT-oplossingen. En als voorbeeld SharePoint (Online) portals. Vijf jaar geleden was het normaal om een portal te ontwikkelen waarbij grofweg de volgende stappen werden doorlopen:

1. Inventarisatie van de (business) behoeften
2. Opstellen RFP (we slaan de RFI even over)
3. Beoordelen beantwoording en selecteren leverancier
4. Opstellen detail functioneel ontwerp

Even een pauze. Bovenstaande stappen kosten vele 100-en uren inzet. Daarnaast is de gemiddelde doorlooptijd pak hem beet 6 maanden. En we hebben nog niets; gebruikers hebben nog geen pixel van de portal op hun scherm gezien. Snel door dus.

5. Bouwen oplossing
6. Testen en goedkeuren
7. In productie brengen en overdracht naar beheer
8. Eventueel: trainen gebruikers, overige adoptie activiteiten, governance inregelen etc.

Nu hebben we eindelijk onze portal af en kunnen we de vruchten plukken. De portal is immers Af. Ten minste, 2 á 3 jaar later gaan we ons ergeren aan de portal, er werken toch een aantal dingen niet als verwacht. Bovendien heeft Microsoft een nieuwe versie van SharePoint uitgebracht die veel beter is (logisch, daar heeft een groot team 3 jaar aan gewerkt, het zal vast een stuk beter zijn). Tijd om budget te regelen voor een nieuwe portal en te starten met een nieuwe cyclus vanaf stap 1. Bovenstaand is gebaseerd op de ouderwetse waterval methode en die hebben we inmiddels afgezworen. We werken inmiddels allemaal Agile en SCRUM is de nieuwe tovermethode. Maar wat is het verschil? SCRUM voegt de stappen 4, 5 en 6 samen en hakt dat vervolgens op in verschillende sprints. Stuk beter, maar niet meer dan een (forse) optimalisatie van de oude aanpak. Het gaat er namelijk nog steeds vanuit dat het eindresultaat Af is. En dat is ze niet. En bovendien: de nieuwe versie bouwen we waarschijnlijk in Office 365. En laat Microsoft Office 365 als Nooit Af bestempelen. Sterker nog: het wordt wekelijks voorzien van vernieuwingen en updates. De aanpassingen aan onze aanpak zullen wat radicaler moeten. Als we ervan uit gaan dat het resultaat Nooit Af is, dan betekent dat dat we altijd met onze portal aan het werk zijn. Mooi, we kunnen missende zaken, foutjes en nieuwe inzichten na de livegang nog oppakken. Sterker nog: we gaan gewoon live als het nog helemaal niet af is. Martijn en Erwin hebben het over Permanent Bèta. Ik vind dat zelf niet zo'n goede term, het wekt de indruk dat dingen waarvan we denken dat ze werken toch niet blijken te werken (het is immers een test versie waar geen rechten aan mogen worden ontleend). Nou zitten er altijd fouten in software, maar het is niet handig daarvan uit te gaan. We moeten de gebruikers vertellen dat ze weldegelijk kunnen aannemen dat wat er in zit ook werkt. Microsoft spreekt tegenwoordig over Minimal Viable Product (MVP) als ze iets lanceren. Kortweg: dat wat er in zit werkt prima, maar er missen nog veel functionaliteiten. Het is dus nog Niet Af. Ik denk dat als we een bestaande portal kritisch bekijken we erachter komen dat zo'n 50% (of misschien wel minder) van de functies die erin zitten vallen binnen wat we MVP zouden noemen. Dat is goed nieuws: we kunnen veel sneller live en toch waarde toevoegen. Bovendien krijgen we direct feedback van gebruikers of het wel echt doet wat we verwachten. En de versie die live gaat heeft de helft gekost van wat we anders hadden uitgegeven aan een portal. En hebben geld en mensen over om de oplossing te verrijken en aan te passen. Direct, zonder grootschalige cyclus. Het gaat niet om versie 1.0, dan begint het pas Je kunt stellen dat de oplossing nooit versie 1.0 zal worden, het is immers Nooit Af. Of juist dat versie 1.0 heel klein is dan zal groeien en verbeteren met iedere kleine update erna. Hoe dan ook, nadat MVP live is gegaan, moeten we niet ophouden met ontwikkelen. En tegelijk de boel beschikbaar houden. Het is dus verstandig ontwikkelaars en beheerders samen te voegen in één team (zie ook de blog Wat komt er na SCRUM). In dit team zitten alle rollen die nodig zijn te bedenken wat er moet gebeuren, te bepalen wat het meest belangrijk is, het te maken, te testen, te releasen en te beheren. Een multi-disciplinair team waar iedereen zijn specialisme bijdraagt. Uiteraard kan één persoon meerdere rollen vervullen. En de kans is groot dat de leden van het team niet fulltime aan deze oplossing werken en dus lid zijn van meerdere teams. Ook dit is goed nieuws, want kennis en ervaring die elders binnen de organisatie wordt opgedaan, wordt het team in gehaald. En wellicht vullen we een deel van het team in met mensen van buiten onze organisatie. Hiermee wordt de diversiteit aan kennis nog meer vergroot. Om teams op deze manier te laten werken, moeten wat bestaande structuren verlaten worden of in ieder geval aangepast. De organisatie moet worden aangepast van afdelingen naar flexibele teams. De tooling die wordt gebruikt moet worden herzien. Het budgetteren van deze aanpak zal anders moeten, de werkwijze worden aangepast, de vaardigheden van medewerkers worden ontwikkeld en niet in de laatste plaats: het management zal moeten veranderen. In mijn volgende blogposts zal ik ingaan op deze onderwerpen. Ten minste, dat denk ik nu. Mijn blogposts zijn ook Nooit Af. Andere blogs over DevOps: Wat komt er na SCRUM DevOps: Een Nooit Af organisatie DevOps: Ook management is Nooit Af DevOps: Budgetteren in een DevOps organisatie DevOps: Werkwijze van een DevOps team