Doorgaan naar hoofdcontent

Het belang van het opnemen van beheerwerk in sprints



Een tijd geleden begeleidde ik een DevOps team (Development en Operations) dat werkte volgens de Scrum methodiek. Wat ik nu even ‘standaard werk’ noem van de beheerders, stond lang niet altijd op de backlog. 

Beheer was hier nog onderverdeeld naar applicatie beheer veelal uitgevoerd door beheerders in Amsterdam en platform beheer (ofwel het beheer van onze servers) uitgevoerd in Leeuwarden. 

Wegens de grootte van het hele voor het product verantwoordelijke team, waren beheerders grotendeels opgesplitst naar een tweede team. De backlog van beide teams bestond vrijwel alleen uit stories nodig voor de bouw van nieuwe functionaliteiten. In het team met vrijwel alleen beheerders waren de beheer activiteiten opgehangen aan deze stories. Hierdoor was er geen beheerwerk dat los stond van ontwikkelwerkzaamheden opgenomen in de sprints. Niet zo vreemd met een Product Owner vanuit de business.

 De beheer werkzaamheden op de platforms werden uitgevoerd door beheerders in Leeuwarden. Het beheerwerk in Amsterdam besloeg meer de werkzaamheden vanuit ITIL service level management en de werkzaamheden behorende bij de andere ITIL processen. Vaak ging de Daily scrum meeting van dit team niet door. Onduidelijk was veelal wie er eventueel ook thuis aan het werk was die dag en ook belden collega’s gewoon niet in.


Er is een probleem met een van de servers


Een van de beheertaken uit Leeuwarden, zo kwam men er op zeker moment achter, bestond uit een controle van de servers en de logfiles. Meestal werd dit vroeg in de ochtend door een van de beheerders in Leeuwarden uitgevoerd. Het moment dat heel het team hierachter kwam, je begrijpt het al, was toen er problemen waren ontstaan met de beschikbaarheid van de applicatie omdat er een queue was volgelopen. Het controlewerk dat niet had plaatsgevonden wegens ziekte van een van de collega’s uit Leeuwarden was onbekend bij anderen uit het team, meestal aan het werk in Amsterdam.

Dit was een gelegenheid die ik niet voorbij kon laten gaan zonder iedereen over het volgende in te lichten:

“Als team maken we gebruik van het Agile Scrum framework en volgens de scrum guide moet al het toekomstig werk van de sprint opgenomen worden in de sprintbacklog. Een mogelijke uitzondering op deze regel vormt werk dat wordt uitgevoerd door een ander team of werk dat volledig geïntegreerd is geautomatiseerd. Aangezien de dagelijkse handmatige controlewerkzaamheden van de servers in ons team zijn belegd, dient dit werk te zijn opgenomen op de sprintbacklog.”

Inventarisatie van deze keer al het werk


Toen deze conclusie echt geland was bij het hele team kwamen er levendige discussies los. Er ontstond een lijst vol met epics en userstories op het gebied van de werkzaamheden van beheer. De ontwikkelaars kregen meer inzicht in beheerwerk en de beheerders in het werk van elkaar. Er kwam een gedrevenheid en nieuwsgierigheid naar het werk over en weer met een oprechte noodzaak om werk over locaties heen van elkaar over te kunnen nemen.  De aandacht hiervoor ontging ook niet onze Product Owner en er ontstond breed gedragen bereidheid om te investeren in sprints die zelfs veel van dit werk konden gaan automatiseren!

Vergaand automatiseren en een grote stap vooruit


De sprints erna waren door de afwisseling van het werk aan het automatiseren van beheerwerkzaamheden, gewoon weer leuker. Doordat openheid over de beheertaken mogelijk werd gemaakt, was het vertrouwen tussen de mensen in het team gegroeid. Niet alleen leerden van oorsprong beheerders hierdoor ook programmeren, ook veel dagelijks terugkerend en saai werk hen hierdoor uit handen genomen. 


Tips voor opnemen van beheerwerk in sprints:

  • Train heel het team op het Agile Scrum framework en belicht hierin het belang van het plannen van al het teamwerk in de sprints
  • Help de Product Owner met een complete backlog door epics en stories voor beheer duidelijk te krijgen en hierin op te nemen
  • Onderzoek waar beheertaken kunnen worden geautomatiseerd
Heb jij ervaringen met werk vanuit beheer in sprints of nog tips hoe dit werk zichtbaar  gemaakt kan worden? Laat dan een reactie achter hieronder. Dankjewel!

Reacties

Populaire posts van deze blog

De beste manier om een bemiddelingsgesprek tot een succes te krijgen

In deze blog wil ik je meenemen in een verhaal waaruit blijkt dat je als team het niet altijd met elkaar eens hoeft te zijn om op de kortst mogelijke termijn, de best mogelijke oplossing te bereiken. Er is iets mis aan de kwaliteit van het product Als Scrum Master faciliteerde ik eens een refinement sessie die niet lekker liep. Refinement sessies kunnen plaatsvinden met een team en de Product Owner bij het gebruik van het scrum framework. Dit om gezamenlijk de backlog voor te bereiden op de komende sprints. Bas en Alexander waren het duidelijk oneens over een nieuw in te bouwen functionaliteit die te maken had met rollen en applicaties binnen de applicatie. Deze functionaliteit is sterk bepalend voor de kwaliteit van de applicatie. Binnen Scrum wordt de kwaliteit van het product of de applicatie in dit geval, bewaakt met de zogeheten Definition of Done. De Definition of Done bevat regels waaraan elke oplevering van het product moet voldoen.  Alexander pretendeerde de invul

Hoe Agile scrum vertrouwen verhoogt in virtuele teams

Team vertrouwen is vaak besproken als uitdaging maar ook als eis voor de effectiviteit van met name virtuele teams. (Breuer, Hüffmeier, & Hertel, 2016). Hieronder zal uiteen worden gezet hoe in de Agile scrum werkwijze antwoorden liggen die de team effectiviteit ook in virtuele teams verhogen. Breuer et al., 2016 komen bij hun onderzoek tot de conclusie dat juist bij virtuele teams documenteren van de teaminteractie een goede aanvulling is voor de op vertrouwen bouwende activiteiten. De documentatie van teaminteractie is binnen Agile scrum onder andere vindbaar in de binnen het team overeengekomen 'Definition of done'. Hierin is door het team vastgelegd aan welke eisen een voltooid product moet voldoen. De onderzoekers geven als voorbeeld van andere factoren die ingrijpen op de risicoperceptie van een team, de demografische of functionele diversiteit onder de teamleden. De risicoperceptie in teams zou toe kunnen nemen als gevolg van misverstanden, stereotypering en het