DevOps: Een Nooit Af organisatie
Blogs
19-1-2016
In mijn vorige blog heb ik uitgelegd waarom de oplossingen die we bedenken en realiseren Nooit Af zijn. Het is dus beter hier vanaf het begin van uit te gaan. Dus niet eerst uitgebreid ontwerpen en bouwen, maar realiseer zo snel mogelijk een Minimal Viable Product (MVP) en breng dit live. Vervolgens gaan we de MVP uitbreiden, aanpassen en beheren. De manier waarop we de MVP maken is bekend terrein. Dat kan op de manier waarop we altijd projecten deden. SCRUM is hiervoor het meest aangewezen, maar een andere methode kan ook. Het resultaat telt, de manier waarop is hieraan ondergeschikt. Maar dan. We moeten vanaf nu een situatie in waarin tegelijk wordt beheerd (Operations) en ontwikkeld (Development). Van Projectteam naar laten we het DevOps team noemen. Hoe ziet dat DevOps team er dan uit?
Als ontwikkeling en beheer samenkomen
Bovenstaande illustratie komt uit een DevOps presentatie van Microsoft. Een oneindige loop dus, iets wat Developers traditioneel uit alle macht proberen te voorkomen. Apple zag er blijkbaar al eerder de kracht van in. Het adres van de Apple Campus is 1 Infinite Loop, Cupertino.
In mijn blog Wat komt er na SCRUM heb ik al het een en ander verteld over DevOps. Zoals gezegd bestaat het team dus uit alle rollen die nodig zijn om een oplossing door te ontwikkelen en de continuïteit te waarborgen (dus: beheren). Dit betekent dus dat ontwikkelaars, technisch beheerders, functioneel specialisten, ontwerpers etc bij elkaar in één team komen te zitten. Vaak zitten deze mensen nu verspreid over de organisatie in aparte afdelingen. Dat is ooit bedacht om efficiënt te werken. Als er onvoldoende werk is om een full time developer aan Office 365 te laten werken, is het nodig om deze developer ook aan andere oplossingen te laten werken. Developers worden dan samen in één afdeling samengevoegd en de eigenaren van de oplossingen claimen dan de resources die ze nodig hebben bij deze afdeling. Dit kan alleen als de eigenaar ver vooruit plant wat hij wanneer nodig heeft. En dat is nu net niet mogelijk in een Nooit Af organisatie. We moeten veel kort cyclischer werken.
Er gebeurt iets geks als mensen in een team of afdeling komen. Medewerkers voelen zich vrijwel direct verbonden met de mensen binnen het team (of we gaan een weekendje naar de Ardennen) en mensen van andere teams zijn buitenstaanders. Beetje een “klaverjas-effect”: het eerste wat je doet is een streep trekken met aan de ene kant Wij en aan de andere kant Zij. Ineens gaat samenwerken buiten je eigen team niet meer vanzelf, maar moet worden georganiseerd. Een collega uit je eigen team kun je simpelweg vragen je even te helpen. Heb je iemand nodig uit een ander team, moeten er resource aanvragen worden gedaan en urencodes of budgetten beschikbaar worden gesteld. Raar effect, geen manager zal zeggen dat dit de bedoeling is, maar toch gebeurt het. Als je wilt dat mensen effectief samenwerken, moeten ze blijkbaar bij elkaar in één team zitten. En als mensen niet fulltime in één team zitten? Simpel: ze zitten in meerdere teams. Voor medewerkers geen probleem, maar in een hiërarchische organisatie vooral een probleem voor managers. Want wie is dan de baas? In een volgende blog zal ik ingaan op de gevolgen voor management. Nu gaat het vooral om de teams en hoe we die samenstellen en hoe ze werken.
Hoe werken we samen
Stel: we hebben inmiddels het MVP van onze SharePoint Online portal in gebruik genomen. Het projectteam welke deze heeft gemaakt heeft nog een behoorlijk gevulde backlog overgehouden. De beheerders hebben het MVP geaccepteerd en zorgen voor de continuïteit. Vroeger zouden de ontwikkelaars doorgaan met de backlog en handelen de beheerders de verstoringen af. Maar wat doen we met de verstoringen die door ontwikkelaars moeten worden afgehandeld? Zij zijn druk bezig met het realiseren van functionaliteiten waar de gebruikers om vragen en soms zelfs schreeuwen. Geen tijd dus om fouten in de productieversie af te handelen. Zij worden immers aangesproken op het leveren van nieuwe zaken. De beheerders zijn verantwoordelijk voor de bestaande versie. En het zijn twee teams, dus samenwerken gaat niet vanzelf. Wat als we deze ontwikkelaars en beheerders nou eens samenvoegen tot één team met één doelstelling: voeg zoveel mogelijk waarde toe aan de organisatie. Eén backlog waarop zowel nieuwe features als aanpassingen en bugs staan. En die backlog wordt als geheel geprioriteerd door de eigenaar van de oplossing. Dan kan het heel goed zijn dat die fout in de productieversie eerst wordt opgelost en dat nieuwe component op de homepage pas daarna. Waarom? Omdat dat de meeste waarde toevoegt. Maar het kan ook heel goed zijn dat een bug er nog even in blijft zitten omdat een nieuwe functionaliteit op dit moment even belangrijker is. En als een ontwikkelaar tegen een probleem met de inrichting van Office 365 aanloopt stelt hij de vraag om hulp in zijn eigen team. De beheerder die hem moet helpen zal hem een stuk makkelijker helpen dan als het over teams gevraagd moet worden. Raar maar waar.
Eén team dus waarin alle rollen vertegenwoordigd zijn om de totale oplossing te ontwikkelen en beheren. Welke rollen dat zijn, hangt sterk af van de oplossing. Hebben we geen maatwerkcode gebruikt, dan hoeven er geen ontwikkelaars in te zitten. En het kan goed zijn dat we Exchange Online ook gaan gebruiken, dus zal die kennis ook moeten worden toegevoegd. De samenstelling van het team zal van geval tot geval moeten worden bekeken. En staat zeker niet vast. Het is immers Nooit Af. Daarnaast is het goed mogelijk dat enkele teamleden in meerdere teams zitten. De SharePoint developer kan prima een deel van zijn tijd besteden aan het ontwikkelen van mobiele apps.
Dan is er nog een uitdaging: we kunnen er niet vanuit gaan dat het het hele jaar door even druk is. Het loont dus om flexibel op en af te kunnen schalen. En snel. Als we bij iedere drukte eerst een aanvraag moeten uitzetten voor resources, deze moeten selecteren en inwerken gaat er veel kostbare tijd en geld verloren. Beter is het om één of twee partners te zoeken om resources te kunnen leveren aan het team. Op deze manier kan worden geïnvesteerd in een pool van mensen die snel kunnen bijspringen. Uiteraard kan Wortell die partner zijn. Wil je meer weten over het werken met een DevOps team, neem dan even contact met me op.
Blijven een aantal uitdagingen over: wat betekent dit voor de aansturing en het management en, niet onbelangrijk, hoe budgeteer je deze werkwijze. Welke tooling zet je in om het DevOps team te ondersteunen? Hoe ziet de werkwijze er dan uit? Wat betekent een werkwijze van continu verbeteren en veranderen voor de adoptie door eindgebruikers? In volgende blogs ga ik (of een collega) hier verder op in.
Andere blogs over DevOps:
Wat komt er na SCRUM
DevOps: Als het toch nooit af is
DevOps: Ook management is Nooit Af
DevOps: Budgetteren in een DevOps organisatie
DevOps: Werkwijze van een DevOps team
Bovenstaande illustratie komt uit een DevOps presentatie van Microsoft. Een oneindige loop dus, iets wat Developers traditioneel uit alle macht proberen te voorkomen. Apple zag er blijkbaar al eerder de kracht van in. Het adres van de Apple Campus is 1 Infinite Loop, Cupertino.
In mijn blog Wat komt er na SCRUM heb ik al het een en ander verteld over DevOps. Zoals gezegd bestaat het team dus uit alle rollen die nodig zijn om een oplossing door te ontwikkelen en de continuïteit te waarborgen (dus: beheren). Dit betekent dus dat ontwikkelaars, technisch beheerders, functioneel specialisten, ontwerpers etc bij elkaar in één team komen te zitten. Vaak zitten deze mensen nu verspreid over de organisatie in aparte afdelingen. Dat is ooit bedacht om efficiënt te werken. Als er onvoldoende werk is om een full time developer aan Office 365 te laten werken, is het nodig om deze developer ook aan andere oplossingen te laten werken. Developers worden dan samen in één afdeling samengevoegd en de eigenaren van de oplossingen claimen dan de resources die ze nodig hebben bij deze afdeling. Dit kan alleen als de eigenaar ver vooruit plant wat hij wanneer nodig heeft. En dat is nu net niet mogelijk in een Nooit Af organisatie. We moeten veel kort cyclischer werken.
Er gebeurt iets geks als mensen in een team of afdeling komen. Medewerkers voelen zich vrijwel direct verbonden met de mensen binnen het team (of we gaan een weekendje naar de Ardennen) en mensen van andere teams zijn buitenstaanders. Beetje een “klaverjas-effect”: het eerste wat je doet is een streep trekken met aan de ene kant Wij en aan de andere kant Zij. Ineens gaat samenwerken buiten je eigen team niet meer vanzelf, maar moet worden georganiseerd. Een collega uit je eigen team kun je simpelweg vragen je even te helpen. Heb je iemand nodig uit een ander team, moeten er resource aanvragen worden gedaan en urencodes of budgetten beschikbaar worden gesteld. Raar effect, geen manager zal zeggen dat dit de bedoeling is, maar toch gebeurt het. Als je wilt dat mensen effectief samenwerken, moeten ze blijkbaar bij elkaar in één team zitten. En als mensen niet fulltime in één team zitten? Simpel: ze zitten in meerdere teams. Voor medewerkers geen probleem, maar in een hiërarchische organisatie vooral een probleem voor managers. Want wie is dan de baas? In een volgende blog zal ik ingaan op de gevolgen voor management. Nu gaat het vooral om de teams en hoe we die samenstellen en hoe ze werken.
Hoe werken we samen
Stel: we hebben inmiddels het MVP van onze SharePoint Online portal in gebruik genomen. Het projectteam welke deze heeft gemaakt heeft nog een behoorlijk gevulde backlog overgehouden. De beheerders hebben het MVP geaccepteerd en zorgen voor de continuïteit. Vroeger zouden de ontwikkelaars doorgaan met de backlog en handelen de beheerders de verstoringen af. Maar wat doen we met de verstoringen die door ontwikkelaars moeten worden afgehandeld? Zij zijn druk bezig met het realiseren van functionaliteiten waar de gebruikers om vragen en soms zelfs schreeuwen. Geen tijd dus om fouten in de productieversie af te handelen. Zij worden immers aangesproken op het leveren van nieuwe zaken. De beheerders zijn verantwoordelijk voor de bestaande versie. En het zijn twee teams, dus samenwerken gaat niet vanzelf. Wat als we deze ontwikkelaars en beheerders nou eens samenvoegen tot één team met één doelstelling: voeg zoveel mogelijk waarde toe aan de organisatie. Eén backlog waarop zowel nieuwe features als aanpassingen en bugs staan. En die backlog wordt als geheel geprioriteerd door de eigenaar van de oplossing. Dan kan het heel goed zijn dat die fout in de productieversie eerst wordt opgelost en dat nieuwe component op de homepage pas daarna. Waarom? Omdat dat de meeste waarde toevoegt. Maar het kan ook heel goed zijn dat een bug er nog even in blijft zitten omdat een nieuwe functionaliteit op dit moment even belangrijker is. En als een ontwikkelaar tegen een probleem met de inrichting van Office 365 aanloopt stelt hij de vraag om hulp in zijn eigen team. De beheerder die hem moet helpen zal hem een stuk makkelijker helpen dan als het over teams gevraagd moet worden. Raar maar waar.
Eén team dus waarin alle rollen vertegenwoordigd zijn om de totale oplossing te ontwikkelen en beheren. Welke rollen dat zijn, hangt sterk af van de oplossing. Hebben we geen maatwerkcode gebruikt, dan hoeven er geen ontwikkelaars in te zitten. En het kan goed zijn dat we Exchange Online ook gaan gebruiken, dus zal die kennis ook moeten worden toegevoegd. De samenstelling van het team zal van geval tot geval moeten worden bekeken. En staat zeker niet vast. Het is immers Nooit Af. Daarnaast is het goed mogelijk dat enkele teamleden in meerdere teams zitten. De SharePoint developer kan prima een deel van zijn tijd besteden aan het ontwikkelen van mobiele apps.
Dan is er nog een uitdaging: we kunnen er niet vanuit gaan dat het het hele jaar door even druk is. Het loont dus om flexibel op en af te kunnen schalen. En snel. Als we bij iedere drukte eerst een aanvraag moeten uitzetten voor resources, deze moeten selecteren en inwerken gaat er veel kostbare tijd en geld verloren. Beter is het om één of twee partners te zoeken om resources te kunnen leveren aan het team. Op deze manier kan worden geïnvesteerd in een pool van mensen die snel kunnen bijspringen. Uiteraard kan Wortell die partner zijn. Wil je meer weten over het werken met een DevOps team, neem dan even contact met me op.
Blijven een aantal uitdagingen over: wat betekent dit voor de aansturing en het management en, niet onbelangrijk, hoe budgeteer je deze werkwijze. Welke tooling zet je in om het DevOps team te ondersteunen? Hoe ziet de werkwijze er dan uit? Wat betekent een werkwijze van continu verbeteren en veranderen voor de adoptie door eindgebruikers? In volgende blogs ga ik (of een collega) hier verder op in.
Andere blogs over DevOps:
Wat komt er na SCRUM
DevOps: Als het toch nooit af is
DevOps: Ook management is Nooit Af
DevOps: Budgetteren in een DevOps organisatie
DevOps: Werkwijze van een DevOps team