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 Leeuwarde
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