De nieuwe trend DevOps heeft eigenschappen waar Agile teams veel van kunnen leren. Als zodanig is DevOps een mooi vervolg op de Agile verbeterslag. In deze blogpost een aantal DevOps lessen voor Agile-teams waarin ze uit kunnen stappen en meer Agile en DevOps aan hun organisatie kunnen gaan toevoegen.
Les 1: Je bent pas een multidisciplinair team als ook beheer vertegenwoordigd is
Agile drijft op zelforganisatie en zelforganisatie drijft op teams waarin de teamleden elkaar aanvullen. Maar veelal beperkt zich het Agile team tot ontwerpers, bouwers en testers. De cruciale partij in het beoordelen van de producten – beheer – is hierin niet actief vertegenwoordigd. Vaak wel bij de demo, maar daar vind slechts toetsing plaats en geen interactie rondom interpretatie en volledigheid van de user stories. En dus is de kans groot dat producten afgekeurd worden omdat het niet aan de beheereisen voldoet. Denk bijvoorbeeld aan non-functionele eisen als inzicht in stabiliteit van het systeem, of performancetest resultaten. Een Agile-team zonder beheerders is als een voetbalteam zonder verdedigers: wie bewaakt de poort?
Het draait hierin vooral om eigenaarschap: voelt het team zich verantwoordelijk voor de hele lifecycle van het product? En natuurlijk krijgt het team ook de mogelijkheden om die verantwoordelijkheid te dragen? In een team zonder beheerders is dat bijzonder moeilijk en werkt men dus minder effectief. De traditionele Ops-taken horen er gewoon bij en het zijn geen randvoorwaarden die een buitenstaander kan opleggen.
Les 2: Goede deployment tools zijn noodzakelijk om de gewenste snelheid te behouden
DevOps heeft onder meer een focus op tooling, en dan specifiek deployment tools. Onder meer principes als Continuous Delivery en Continuous Deployment zijn typisch DevOps. Wat die principes en die tools doen is focussen op het frequent, snel, beheerst en gecontroleerd (!) in productie van software. Snelheid is essentieel voor het tegelijk kunnen leveren van kwaliteit en waarde. Als je focust op snelheid dan ontdek je vanzelf dat je tools nodig hebt om de kwaliteit hoog te krijgen, want snelheid dwingt je om variatie uit te sluiten. Geautomatiseerd testen en deployen worden dan de norm. Doe je dat niet, dan gaat het ten koste van je snelheid en dat maakt je altijd minder effectief en kost dus geld.
Les 3: Een demo heeft pas echt waarde als het gerealiseerde ook direct in productie genomen wordt
Daarnaast zie ik vaak demo’s van Agile-teams vanuit een testomgeving, waarbij er gesuggereerd wordt dat er veel waarde is gecreëerd, maar waarbij het deployen van de software naar productie nog maanden op zich laat wachten. Maar dat is het creëren van voorraden en dus waste. Het goede van een demo is dat er feedback wordt gegeven en gegenereerd, en dat er inzicht wordt verschaft in de voortgang van het project. Maar binnen de DevOps-beweging zijn er technieken voor handen (zoals blue green deployment, dark launching, et cetera) die je in staat stellen om zonder al te veel omhaal beheerst te kunnen gaan deployen (zie les 2).
In het Agile Manifesto staat dat we werkende software waarderen, en Scrum benoemt het resultaat van een sprint als potentieel productierijp systeem. Maar veel Agile-teams zijn hierin te weinig ambitieus en de DevOps-beweging kan zeker helpen. Agile-teams: pak die handschoen op!
Les 4: Reageren op veranderingen die uit productie komen
DevOps kijkt naar het geheel van de softwareontwikkeling; er wordt geen onderscheid gemaakt tussen nieuwbouw (ontwikkeling) en onderhoud (beheer). Daaruit volgt dat dat wat er in productie gebeurt, nu van het hele team is. En dat betekent dus ook dat voortschrijdend inzicht niet alleen komt vanuit het interpreteren en prioriteren van nieuwe user stories, maar dat er ook gereageerd moet worden vanuit de gemelde incidents, problems en events. Want die komen ook op de Product Backlog te staan, als onderdeel van het reguliere beheerwerk. Daarmee wordt de Product Owner ook verantwoordelijk voor wat er nu in productie staat en hoe het team daarop reageert. Ergo: hij wordt daarmee de bewaker van de total cost of ownership van resultaat. Reageren op veranderingen is vanuit het Agile Manifesto een belangrijke waarde voor Agile-teams, maar neem in het vervolg dus ook feedback uit productie mee.
Les 5: Wil je het goed doen, betrek dan de hele organisatie bij de verandering
Omdat DevOps draait om snelheid, beheersing en lerend vermogen dient er een gezamenlijk doel te zijn dat de verschillende partijen bindt. Het gaat dus niet meer om eilandjes of los verspreidde Scrum-teams, maar om integratie en gezamenlijke benadering. Het gaat om de flow in en door de organisatie: end-to-end throughput is de norm. Dat betekent dat de beweging achter DevOps niet alleen draait om ontwikkeling en beheer. Andere relevante organisatie aspecten zijn de mensen, kwaliteit, werkwijze, financiën, strategie en beleid, het management en de structuur van de organisatie. Bedrijven en organisaties die de Agile-beweging tot hun volle recht willen laten komen, gaan daarmee aan de slag.
Conclusie
DevOps is het vervolg op Agile en biedt organisaties handvatten om daarmee meer impact te hebben. Vanuit het DevOps paradigma worden Scrum-teams getriggerd om verder te kijken dan het eigen team. En om verder te kijken dan werkende software op een testomgeving, of uitsluitend te reageren op veranderingen op nieuwe user stories. Frequent beheerst deployen is de nieuwe norm want alleen op productie wordt de echte strijd gestreden – die met klanten en concurrenten. Focus op de context waarin je als Agile-team opereert en stroop je mouwen op.
Beste Anko,
Ik ben het met vrijwel alles eens in je artikel, behalve je eindconclusie. Je noemt dat DevOps het vervolg is op Agile. Naar mijn mening is DevOps echter “the missing piece of the puzzle” om Agile ook werkelijk Agile te maken, door met name de aansluiting buiten software development mogelijk te maken.
Daarnaast heeft DevOps ook diverse elementen in zich vanuit cloud, ITIL, Lean en ToC, die niet per definitie ook in Agile zitten. Het is dus vooral een combinatie van diverse denkwijzen, waar Agile natuurlijk wel de belangrijkste van is.
@Anko Ik leg mijn reactie hier maar even neer in plaats van je vorige artikel. Als ik naar de wikipedia pagina kijk over DevOps dan gaat het wel degelijk over ontwikkeling en beheer en wordt er niet van alles bijgehaald.
http://en.wikipedia.org/wiki/DevOps
De randvoorwaarden vanuit beheer meenemen in ontwikkeling is zeer verstandig en daar niet op moment van opleveren achter komen. Naar mijn mening is dat eerder een organisatorisch probleem.
Wat betreft Continous Delivery en Integration, dat is leuk en aardig, ik kan me voorstellen dat het soms wel kan om snel wijzigingen in productie te nemen maar bij bedrijfskritische software is dat een ander geval. Je moet er toch niet aan denken om daar steeds nieuwe versies van in productie te krijgen. Ik spreek dan als beheerder, iedere release is een risico. Moet ook zeggen dat het een slecht teken is als je continu wijzigingen in productie moet nemen. Dan is het of niet af of het deugt niet. Continous delivery en integration voor een test / ontwikkelomgeving daar kan ik me al iets meer bij voorstellen. Ik ben ook van de afdeling, wees zorgvuldig met wat je in productie neemt.
Agile is trouwens geen methode maar meer een filosofie en dan nog een hele onduidelijk ook, zo helder vind ik dat Agile manifesto eigenlijk niet. Werkende software boven documentatie, dat is toch eigenlijk niet te geloven? Specificaties gereduceerd tot een todo lijstje? Nee, je leest het al ik ben een agile (+ methoden) scepticus.
@Dave: grosse modo met je eens. Inderdaad heeft DevOps ook ToC in zich (lees The Phoenix Project!).
@Louis: Ik vind dat als je DevOps goed doet (continuous delivery etc) dat je wel degelijk meer impact op de organisatie hebt, of kunt hebben, dan alleen IT versnellen en verbeteren. Daarbij moeten we in de nieuwe economie steeds meer met steeds minder doen, dus als je toch DevOps doet, denk dan niet te klein, is mijn credo.
Ik denk dat er geen enkele reden hoeft te zijn om met bedrijfskritische applicaties weerstand te hebben tegen DevOps. Als iedere release een risico is, dan heb je dus iets niet onder controle. En DevOps draait juist om zaken onder controle te hebben. Wat ik niet expliciet heb belicht maar wel erbij hoort, is dat een flinke set aan geautomatiseerde testsuites (unit tests, systeem test, ketentest) noodzakelijk is voor CD. En hoe belangrijker de applicatie, hoe uitgebreider dat moet zijn. Zoals je op Wikipedia hebt kunnen lezen deployt Flickr.com meerdere keren per dag. Maar hun wesbite is toch redelijk kritisch voor hen 😉
Daarbij is het dus essentieel (!!!) dat frequent deployen geen feest van ontwikkelaars is, maar een gezamenlijke inspanning van Ontwikkeling en Beheer. Dus de vraag die jij als ervaren beheerder gaat krijgen is: gegeven jouw beheeractiviteiten, wat moeten wij als team met elkaar doen om beheerst frequent te deployen zonder dat dit ten koste gaat van de huidige kwaliteitseisen. Dat is DevOps 🙂
@Louis: de wikipedia definitie is wellicht een van de slechtst denkbare definities van DevOps. Volgens wikipedia is DevOps een “software development method”. Nou, als DevOps iets niet is, dan is het een software development method. Er zijn veel betere bronnen beschikbaar, zoals de reeds door Anko genoemde bestseller The Phoenix Project. Ik snap dat je skeptisch bent, maar steeds meer organisaties benutten de waardevolle good practices vanuit CD en DevOps ook binnen hun kernsystemen. De samenwerkingscultuur waar de DevOps beweging synoniem voor staat is van groot belang voor een toekomstvaste IT dienstverlening.
@Anko Geautomatiseerd testen, automatisch uitrollen, het zal allemaal helpen bij het uitsluiten van risico maar dat neemt niet weg dat je altijd risico’s loopt op het moment dat je veranderingen in je software aanbrengt. Je denkt dat je software en machines in de hand kan houden, de praktijk is weerbarstiger. Dat is een feit, dat is niet alleen een kwestie van denken je zaken in de hand hebben. Ik ga nog eens op zoek naar dat Flickr verhaal, 9 deployments per dag. Wat zijn die gasten aan het doen daar? Of om wat voor software gaat dat? Vandaar had ik ook graag commentaar gelezen op mijn opmerking dat het een slecht teken is als je zo frequent nieuwe software in productie moet gooien: dan is het niet af of het deugt niet niet.
Nu ken ik beide kanten, ontwikkeling en beheer en daar is de ervaring dat je elkaar wel nodig hebt maar dat de organisatorische/fysieke afstand groot kan zijn. Wat wel altijd prettig is als je wat zaken op papier hebt staan, installatieinstructies bijvoorbeeld. Doet DevOps daar ook aan, of wordt daar ook wat over gezegd? Welke deliverables zijn vereist bedoel ik eigenlijk. Of gaat het allemaal de grote brei in van de gelukkige DevOps familie met alleen maar loyale medewerkers die open en eerlijk zijn, elkaar het licht in de ogen gunnen en samen werken en verantwoordelijk zijn voor het eindresultaat? En zelflerend uiteraard. Het klinkt als een sprookje. Soms zijn helder interfaces tussen Dev en Ops misschien wel meer gewenst in plaats van de grote brei zonder duidelijk verantwoordelijkheden. Na overleg, daar gaat DevOps naar mijn mening om.
@Dave Dat is niet zo mooi dat de DevOps definitie op Wikipedia niet deugt. Ben het met je eens dat geen methode is maar het is natuurlijk een slecht teken dat er geen eenduidige definitie van DevOps bestaat. Dat is mijn kritiek op trends als DevOps, Agile, Scrum etc etc, vaag gedefinieerd, je kan er alle kanten mee op en vooral ict inhoudelijk biedt het geen handvaten. Wel een hele industrie van opleidingen en rollen.
Maar, ik sluit niet uit dat er nog een hele wonderlijke wereld voor meligt dus ik ga op zoek naar het boek over het Phoenis Project. Op zoek naar de ware DevOps. Het lijkt wel een religie. Ook al zitten er aardige dingen in.