begin, beginnen, devops, overbrug, kloof, agile, sprint, management

Beginnen met DevOps en de kloof overbruggen

Geplaatst door

De grotere vendoren noemen softwarebedrijven vaak een ISV (Independent Software Vendor[5]). Kortom wanneer jij zelf software maakt en dat aan klanten verkoopt ben je een ISV. Weer zo’n afkorting waar je vaak de betekenis niet achter kende. Zeker bij een ISV wil je beginnen met verandering of dat je bedrijf gaat aansluiten bij de veranderende wereld. Dit omdat je gelooft dat dit bijdraagt aan groei. Persoonlijke ontwikkeling van mensen, het creëren van succesvolle teams en de groei van je bedrijf als geheel. Deze signalen zie je als Developer. Je bent immers met gave ontwikkelingen bezig. Hoe krijg je dan je management mee als je die signalen ziet?

Ik geloof dat elk softwarebedrijf aan de vooravond staat van belangrijke strategische keuzes. Ik geloof ook dat Developers die signalen als eerste zien. Alleen al omdat je de druk van life-cycle-management en releasen van nieuwe functies voelt.

In deze blog sta ik stil bij deze zeven signalen:

  1. Gebruikersadoptie van managementconcepten is niet optimaal;
  2. Functionaliteit en updates toevoegen heeft inpakt en duurt lang;
  3. Documentatie of inzicht van de architectuur is lastig te vinden waardoor taken herhaald worden (processen zijn niet zichtbaar);
  4. Gebruikers klagen over onderwerpen die niet worden gemeten (als we dat hadden, dan…);
  5. Bedrijfswaarde, Klantwaarde en IT-waarde worden individueel behandeld (of niet);
  6. Geen tijd om succes te vieren, we zijn druk met brandjes blussen en vinger wijzen;
  7. Het operationele- en het managementteam kennen elkaars agenda niet.

Beginnen aan nieuwe managementconcepten

Al jaren schrijven goeroes over verschillende managementconcepten. En het lijkt ook dat we allemaal beginnen met zo’n concept, alleen het niet afmaken. Of dat we slechts delen van zo’n concept willen implementeren. Zo heb ik het laatste decennium verschillende trends voorbij zien komen. Denk hierbij aan coachend leiderschap, performance management, zelfsturende teams, competitiemanagement en just in timemanagement. Allemaal managementconcepten waarbij de focus op de mens en zijn kennis komt te liggen. Wat positief is! Toch voelt het vaak niet zo, je moet nu samenwerken en dankzij de 360 graden beoordeling, is nu ook de mening van je collega onderdeel van je KPI.

Bij al deze concepten is draagvlak (gebruikersadoptie) van wezenlijk belang. Toch zie en lees ik geregeld dat deze van bovenaf worden opgelegd. Ook zijn er voorbeelden van organisaties die verschillende concepten door elkaar heen gebruiken. Wat je ook ziet is organisaties die nieuwe concepten en processen toevoegen, en nooit afscheid nemen van het oude. Zonder draagvlak mislukt elke oplossing of concept, durf ik te stellen. De negatieve bijwerking kan dan zomaar zijn dat we “managementconcept-moe” worden. En dat men sceptisch kijkt naar verandering. Het nadeel van hypes is dat we allemaal willen meedoen. Tsja…, en daar komt de enigmatische DevOps-cultuur om de hoek kijken. Is dat dan weer zo’n concept? Nee, DevOps is een cultuur en begint bij het samenvoegen van traditioneel gescheiden silo’s. Zo komt de beslissing vanuit het team, niet van bovenaf.

Oké, en waar begin je dan?

Het kan een hele klus te zijn om de kloof DevOps te overbruggen

1. Zorg voor adoptie bij de betrokkenen

Ik schrijf heel consequent dat DevOps geen methodologie is maar een cultuur. Ik geloof dat die nodig is om te kunnen beantwoorden aan de huidige behoeften van bedrijven bij het ontwikkelen van software. De term DevOps is in 2009 ontstaan in België als gevolg van de zogenaamde ‘DevOps-days’. Deze dagen waren bedoeld om IT-experts van zowel de ontwikkelkant als de beheerkant bij elkaar te brengen. En daarmee is de term DevOps in zijn context geplaatst: een multidisciplinair team dat volledig verantwoordelijk is voor het beheer en continue ontwikkeling van de software.

Een nieuwe versie implementeren is een klus. Een hele nieuwe cultuur implementeren is dus een serieuze opgave. Zoals elke transformatie vergt het de nodige inspanningen om mensen aan boord te krijgen. Oftewel draagvlak creëren. Hoe zorg je dat dit DevOps gebeuren waarde gaat toevoegen? Het begint bij educatie. Maak inzichtelijk wat men kan verwachten, wat dit voor waarde met zich mee kan brengen. En wat het betekent voor klanten, mensen en investeringen in IT.

Ik spreek verschillende softwarebedrijven die een nieuwe versie aan het schrijven zijn die geschikt is voor de cloud. Allemaal zeggen ze dat het veel werk is en nog wel even duurt. Ideaal om daar te beginnen. Wat mij betreft zou je die ene grote applicatie kunnen opsplitsen in meerdere applicaties. En begin met het vastleggen van de specifieke- en de gemeenschappelijke broncode in een “repository”. Mooie eerste stap voor continue educatie. Zo kan je straks profiteren van de voordelen van DevOps én later Continuous Delivery.

2. Begin klein met een eerste app

devops,development,software,agile,focus,customer,projectleader,analyst,programmer,beta,tester,business,consultant,documenteren,operatie,installatie,support,marketing

Een zeer bekende uitspraak die deze stap onderbouwd is die van Neil Armstrong: “That’s one small step for man, one giant leap for mankind”. We kunnen sneller een kleine applicatie dan een grotere applicatie bouwen. Een kleine applicatie kan je ook makkelijker testen en onderhouden. Waarom zouden we dan nog steeds applicaties bouwen die veel dingen doen en erg groot worden?

In 2003 had ik mijn eigen startup, ik had een online backup bedrijf. In die tijd ontwikkelde ik zelf een enorme applicatie. Dit platform – bestaande uit portalen, API’s, storagesystemen en betaalsystemen – moest de volledige waarheid zijn. Van order-intake, tot delivery, rapportage, facturatie inclusief verwerken van betalingen tot opzeggen. Er kwam vanuit partners, klanten en intern steeds meer vragen. Doel was om alles te automatiseren en je moest alles met de portal kunnen.

Door de expansiedrift moest de portal ook nog meerdere talen kunnen ondersteunen, waarbij ook uitdagingen ontstonden met adressen en postcodetabellen. Had ik toen maar iedere functie als aparte applicatie geleverd. En er niet een enorm geheel van gemaakt. De afhankelijkheden waren op een zeker moment zo groot dat het platform eigenlijk niet meer te redden was. Natuurlijk lag dat niet aan mij, maar aan de applicatie :-). Vandaag zou ik dat nooit meer zo doen of adviseren. Kleine applicaties zijn naast makkelijk te testen en onderhouden ook makkelijker te adopteren door gebruikers.

3. Maak processen zichtbaar

Persoonlijk omzeil ik het liefst ook moeilijke processen. Uiteindelijk moeten we beginnen allemaal te kunnen bijdragen in het continu verbeteren van deze processen. Transparantie is voor mij enorm belangrijk. Samenwerken is niet een toverwoord of een proces dat je kan aanzetten, maar gewoon kan doen. Dat is hetzelfde dat we communicatie vaak als synoniem voor een e-mail sturen zien. Ik denk dat het handig is als je de sterke en zwakke punten van al je processen in kaart brengt en toegankelijk maakt in bijvoorbeeld Teams voor je hele organisatie. Dan kan je eventuele ontbrekende delen toevoegen of overbodige delen verwijderen. Wat mij betreft zou je dus continu learning ook op je processen kunnen toepassen.

Een bekende en eenvoudige benadering is om een overzicht te hebben van alle lopende taken en de mensen aan wie ze zijn toegekend. Dit kan met een scrum-bord of taken in je mailprogramma. Ander voorbeeld is, zijn alle betrokkenen bekend hoe we omgaan met een incident bij een probleem in een productieomgeving? We raken volgens mij allemaal wel tijd kwijt aan uitleg over de architectuur, die problemen heeft, in plaats van volledige concentratie op het oplossen van het probleem. Er zijn nog legio taken die telkens terugkomen en handmatig uitgevoerd worden. Veel van deze repetitieve processen zijn nu niet geautomatiseerd. De primaire gedachte achter DevOps is automatiseer zoveel mogelijk.

Kunnen alle betrokkenen informatie over vorige problemen snel vinden?

Luister de Login Techcast podcast over Extreem Samenwerken terug ».

4. Meet zoveel als je kunt

Meten is weten. Een hele oude term die nog steeds relevant is. Bijvoorbeeld wat is de gemiddelde doorlooptijd van je taken vanaf het begin van de ontwikkeling tot oplevering? Wat is de responstijd op je dienstverlening? Hoeveel tijd kost het om een infrastructuur cluster uit te breiden? Als je al je cijfers kent, weet je misschien wat je kan verbeteren.

Stel je voor dat een van je applicaties niet meer reageert vanwege een technisch probleem. Bijvoorbeeld een probleem met de belasting van een processor. Dan krijgt je klantenservice al heel snel telefoontjes en berichten van klanten die problemen ervaren. We meten vaak de beschikbaarheid, niet allerlei details. Kortom ga beginnen met alles te meten! Zo ben je eerder op de hoogte van mogelijke problemen. En ga je het gebruik van je applicatie tot in de puntjes kennen. Dat scheelt veel tijd in het zoeken naar het probleem. Groter voordeel is dat je klanten niet gedupeerd raken. En je kunt relevanter nieuwe functionaliteit toevoegen omdat je weet hoe je gebruiker je applicatie gebruikt. Er zijn verschillende tools beschikbaar die je kunnen helpen bij het krijgen van deze inzichten.

5. Maak waarde zichtbaar

We creëren waarde. Dat zeggen we allemaal. Zo verdienen we ons geld en daarmee onderscheiden we ons. Belangrijk thema dus. Dus als je alles weet over de waarde die je creëert en voor wie, heb je een krachtig instrument in huis. Zodat je waarde kan creëren voor je klanten, om zo ook de waarde van je bedrijf te vergroten. En hoe zit het met het waardevoller maken van IT, waardoor onderhoudskosten dalen en nieuwe producten sneller naar de markt kunnen?

Kortom het is van belang om te beginnen met de data te verzamelen. Met tools kan je inzicht krijgen in deze verzameling van data. Zo kan je filters toepassen en verbanden leggen. Het is net als in de auto, een belangrijk dashboard. Rij je niet te snel, moet je tanken en wat is de temperatuur van de motor. Vroeger waren dergelijke oplossingen kostbaar, ingewikkeld en tijdrovend. Vandaag de dag is het analyseren van data weggelegd voor elk type bedrijf en elk type gebruiker. Dankzij de vele mogelijke visualisaties is het ook nog eens leuk om naar je data te kijken.

meet, inzicht, devops, agile, dashboard, bi, business intelligence

Data waarmee je de drie kernwaarden (bedrijfswaarde, klantwaarde en IT-waarde) kunt vergroten. Laten we deze drie thema’s niet meer afzonderlijk bespreken maar als een geïntegreerd geheel. Er zijn verschillende tools beschikbaar waarmee je data bij elkaar kan brengen en kan beginnen met het verrijken van die data.

6. Vier ieder succes

Misschien wel een van de belangrijkste stappen in ieder verandertraject, is beginnen met het vieren van succes. Bij Microsoft zei Ernestine van Rappard ooit tegen mij “vier elk succes”, maakt niet uit wat maar vier. Dat is sowieso leuk, en als dat in je DNA komt, begrijp je dat het gaat om mensen gaat! Bovendien draagt het bij aan het houden van talenten. DevOps gaat heel erg veel over de mensen met wie we samenwerken. En het gaat erom hoe we samenwerken en dat we elkaar zoveel mogelijk vertrouwen.

Dus, hoe doen we dat? Volgens mij hoeft dat helemaal niet heel moeilijk te zijn. Begin eens met uit eten te gaan met het team. Geniet als team van de prestaties. Benoem hoe de reis er uit zag, wat je bent tegengekomen welke kloven je hebt moeten overbruggen en omzeilen. Kortom een duidelijk signaal “Ja, we hebben het gefixt, bedankt allemaal!”.

Bedank elk teamlid persoonlijk. Respect en vertrouwen moet je verdienen, dat kan je niet afdwingen. Dat begint met erkennen en herkennen wat ieder teamlid bijdraagt. Je hebt elkaar nodig, alleen kan je het niet. Die echt gemeende schouderklopje wordt zo gewaardeerd, weet ik uit ervaring.

De beloning zit vaak niet in meer geld of financiële bonussen. Beloon bijvoorbeeld met meer flexibiliteit. Dit geeft een onbetaalbaar gevoel dat je echt vertrouwd wordt. Dat je ertoe doet. Dat je zelf nieuwe initiatieven mag beginnen. En dat je als team de prioriteiten mag indelen.

7. Nodig het operationele-team uit

Je kan het niet alleen, schrijf ik in eerdere DevOps blogs. Ook voor de nodige songteksten is dit een inspirende quote. Natuurlijk je hebt elkaar nodig en als we allemaal de eigen kracht benutten en zo gaan samenwerken begint er iets moois. Bij DevOps is het punt dat we de hele keten van dev naar ops besturen. Haak daarbij het operationele team aan. Ook als het operationele team bij een externe partij ligt. In grotere organisaties zijn dit dikwijls teams die je niet tot nooit ontmoet. Laten we daar eens mee beginnen. Wanneer je elkanders belangen kent en samensmelt ontstaat er een soort magie, met wederzijds begrip voor elkaars standpunten. In plaats van dat je elkaar bevecht strijd je nu gezamenlijk voor het doel om heel snel mooie diensten en software naar de markt te brengen. En dat je blije klanten hebt en houdt.

Is jouw softwarebedrijf gebaat bij frisse wind?

Binnen elk gezond bedrijf begint alles bij draagvlak. Wanneer keuzes niet meer worden gemaakt vanuit de boardroom, maar vanuit de DevOps-cultuur vergroot dit het werkplezier én de concurrentiepositie. Deze cultuur draagt bij aan verbondenheid en synergie. Dit heb ik van dichtbij bij een grote beursgenoteerde uitzendorganisatie mogen meemaken. Twee partijen probeerde hier een groot contract te winnen. De ene partij zat er traditioneel in, zocht alleen contact bij het C-level en negeerde de toekomstige gebruikers. De andere partij deed dat juist wel. Bovendien investeerde ze in gebruikersadoptie voordat het contract was getekend. Toen de CIO intern vroeg welke partij moet ik kiezen, riep iedereen de naam van de partij die in hen investeerde.

Samenvattend kan het adopteren van de DevOps-methode (euh cultuur) een nieuwe wind laten waaien in je bedrijf. Natuurlijk weet ik dat je niet meteen kunt beginnen met alle zeven suggesties die ik hier heb opgeschreven. Kies er gewoon een. Kies die stap je het prettigst vindt en begin er vandaag mee. Morgen is toch al een drukke dag. Zelf vind ik kleine stappen zetten het prettigst, misschien herken je dat.

Credits

Bedankt Luciano Nooijen voor je bijdrage aan deze blog.

Referenties

[1] MT.nl (2001). De 10 belangrijkste managementtheorieën
[2] Dev (2017). How to get started with DevOps
[3] InfoWorld (2018). What is CI/CD? Continuous integration and continuous delivery explained
[4] InfoWorld (2018). What is devops? Transforming software development
[5] Microsoft (2018). Grow Your ISV Business with SaaS Playbook (PDF)
[6] Management Impact (2018). Sta missers toe en vier je successen