Eindelijk echt Agile werken met Kubernetes

In mijn vorige blog vertelde ik over de voordelen van Kubernetes voor je deploymentproces. Ik had het er ook al even over de cultuurverandering die hierbij hoort. Die cultuurverandering is belangrijk, want de echte winst komt als je de vrijheid die Kubernetes je geeft gebruikt om je proces te veranderen.

Met Kubernetes en containers kun je een DevOps-proces inrichten en sneller waarde leveren. Je kunt die waarde ook in veel kleinere stukjes leveren. Daardoor heb je de mogelijkheid om je los te maken van je releaseschema en andere beperkingen die er in het traditionele proces waren. Je hoeft geen applicaties meer op te leveren die ‘af’ zijn, omdat je niet weet of je later nog dingen kunt veranderen of toevoegen. Je kunt, kortom, eindelijk echt Agile werken.

Bij Agile denken veel meteen aan Scrum. Maar zelfs in een scrumproces kunnen er door het sprintritme en het testproces 4 weken zitten tussen ‘af’ en ‘live’. Dat betekent dat je na het afronden van een nieuwe feature alsnog een maand moet wachten om resultaat te zien. Dat is lang. Vaak te lang. 

Van Scrum naar Kanban 

Gelukkig geven DevOps en tools als Kubernetes je de kans het sprintritme te versnellen. Je kunt features toch opleveren als ze klaar zijn? DevOps kan je daarnaast helpen de stap te maken van Scrum naar Kanban. Bij Kanban werk je niet meer in sprints, maar lever je features continu op. Iedere feature krijgt zijn eigen acceptatie-omgeving en kan na goedkeuring direct live, zonder dat je daarbij op andere features hoeft te wachten. Zo bereiken we wat mij betreft het summum: het continu leveren van maximale waarde voor onze klanten, maar vooral ook voor hun klanten. 

Voorwaarde daarbij is wel dat de klant ook betrokken genoeg is om dagelijks bij het team aan te schuiven, samen met het team de prioriteiten te bepalen en opgeleverde features te testen. Maar met de overgang naar Kanban raak je helaas ook een paar voordelen kwijt van Scrum. Sprints laten je bijvoorbeeld je velocity meten (de snelheid waarmee je nieuwe features ontwikkelt). Daarmee kun je de volgende sprints beter plannen. Dat kan met Kanban minder goed. Kanban geeft ook weinig garanties over wanneer iets af is. Dat vraagt veel vertrouwen van de klant. 

In gesprek blijven 

In veel organisaties is dat nog een stap te ver. Het principe van Agile is duidelijk: je bouwt de best mogelijk app als je steeds het belangrijkste eerst doet, net zo lang tot het budget op is. Maar vaak zie je dat projectleiders toch ‘hogerop’ verantwoording moeten afleggen over de roadmap. Daarvoor hebben ze houvast nodig. Managers die wat verder van het team af staan worden onzeker en wantrouwig als ze geen enkel inzicht hebben in wat ze nou uiteindelijk krijgen. Daar moet je als ontwikkelteam iets mee. Je kunt niet zeggen: ‘Geef ons die zak geld maar, het komt allemaal goed.’ Je moet in gesprek blijven en uitleggen en aantonen wat je doet. 

De conclusie is dat  het belangrijk is samen op zoek te gaan naar een tussenvariant die het team vrijheid en autonomie geeft, maar tegelijkertijd voldoende houvast aan de opdrachtgever biedt. Scrumban is zo’n tussenvariant. Ook Scrumban bestaat in verschillende varianten, maar onze aanpak is een versie van Kanban. Maar dan mét velocity en tweewekelijkse bijeenkomsten.

Vorm je eigen proces 

Dat is onze keuze. Jij kunt daarin je eigen keuzes maken. Je hoeft geen offertes meer aan te vragen voor servers, geen toestemming meer te krijgen voor configuratiewijzigingen en niet meer eindeloos te e-mailen voordat je update live kan. Deployment is met Kubernetes en containers geen ‘ding’ meer. Je hebt dus de vrijheid om je deploymentproces helemaal zo in te richten dat het voor jou ideaal is, zonder de beperkingen van vroeger. Welke keuzes je daarbij maakt, hangt erg af van je bedrijfscultuur. 

Met DevOps en Kanban haal je je als ontwikkelteam veel nieuwe verantwoordelijkheden op de hals en vraag je ook veel van de interne opdrachtgevers. Er blijft heel weinig ruimte over om verantwoordelijkheden af te schuiven, bijvoorbeeld op een hostingpartij.  Als wij organisaties helpen met het invoeren van Kubernetes en DevOps, toetsen we de cultuur vaak aan onze eigen cultuur. Dat klinkt misschien arrogant, maar wij hebben deze transitie al gemaakt. We hebben alle ups en downs op deze reis al een keer gezien en we kunnen vanuit ervaring vertellen wat wel werkt en wat niet. 

DevOps zonder Kubernetes 

Je kunt met Kubernetes werken zonder DevOps te implementeren. Kun je DevOps ook invoeren zonder Kubernetes? Ja! Je kunt in principe ook over naar DevOps met je huidige servers of VM’s. Dat moet dan wel goed worden ingericht en het is belangrijk korte lijntjes met je hostingprovider te hebben. Kleine verschillen tussen test- en productieomgevingen kunnen namelijk grote problemen veroorzaken. 

Development die werkt 

Waar het uiteindelijk om gaat is dat je, met behulp van de techniek, een proces vindt dat voor jou werkt. Voor mij betekent dit, dat iedereen één doel voor ogen heeft en dat je de conflicten en frustraties uit het proces haalt. Natuurlijk heb je in een team discussies, maar als je een visie deelt en hetzelfde doel hebt zijn dat vruchtbare discussies en geen conflicten die steeds terugkomen. Je komt er samen uit en maakt er samen wat moois. Dat maakt ons als developers gelukkig. Zelf aan het roer staan en samen bepalen wat de beste oplossing is. Mijn team kan dat. Mijn team doet dat. En ik gun dit iedere organisatie en developer.

In onderstaande video leg ik meer uit over DevOps en Deployment Automation.