Even Apeldoorn bellen: tips van de scrumteams van Centraal Beheer

Wat is er nou leuker dan in de keuken kijken van iemand anders?

Een van de Product Owners van Centraal Beheer liet me een dagje meelopen. Hij is Product Owner van twee teams, verantwoordelijk voor een deel van de website. Ik heb heel veel interessants opgestoken en de leukste en mooiste inzichten deel ik graag met jullie.

  1. Ook in een beheeromgeving kun je werken met Scrum in plaats van met Kanban. En dat gaat prima! Er zit gewoon geen eind aan. Kan. De wereld blijft tenslotte ook gewoon veranderen.
  2. Als Product Owner twee teams hebben, is flink pittig. Vooral als je teams hetzelfde schema volgen qua iteraties. Het helpt wel in het overzicht bij teams die elkaar raken.
  3. Een DoD kan veranderen door de tijd heen. Neem af en toe de tijd om even te checken of ie nog up-to-date is.  DoD
  4. Pokeren kan natuurlijk ook gewoon digitaal. Met een app op je telefoon. (teveel om op te noemen, zoek op Scrum Planning Poker. Ik vind Pokrum leuk, dan schud je om te laten zien wat je hebt)
  5. pokeren
  6. Je kunt een Sprint Review ook met 11 teams in 1 uur doen, krijgt iedereen gewoon maar 5 minuten. Dan is de insteek heel anders (geen ruimte voor feedback) en het werkt als een tierelier, want zien wat elk team in 3 weken heeft opgeleverd is super inspirerend. Je ziet de stappen vooruit. Ik kan me ook voorstellen, dat als stakeholder van één onderdeel van de website, het ook interessant is om te zien wat andere teams doen. Kun je van leren en zorgen dat alles mooi op elkaar aansluit. Als je met zoveel teams moet reviewen, moet je natuurlijk wel strak timeboxen. Als je af en toe (elke drie weken bijvoorbeeld:) een kijkje neemt op www.centraalbeheer.nl kun je volgen wat er verandert. Let op: dit kan in dit geval alleen omdat de stakeholders zo betrokken zijn in het proces, dat een Review waarin je feedback kunt geven weinig toegevoegde waarde heeft. In de meeste projecten kun je een Review niet vervangen door een demo als deze. review timebox
  7. Bepaal wat voor je team gelijk staat aan één storypoint. Dat maakt het een stuk eenvoudiger om relatief te pokeren.storypoint
  8. Ook al werk je niet aan een project, je kunt nog steeds wel een doel hebben als team. Deze teams zijn verantwoordelijk voor de website. Omdat het de eerste sprint Review van het jaar was, werd er teruggekeken op het hele jaar en dat gaf meteen inzicht in hun doelen. Ze hadden zichzelf (onder andere) voor afgelopen jaar als doel opgelegd: een afname van 25% aan waste: binnenkomende mail en telefoontjes. Dat is in het afgelopen jaar zelfs met meer dan 30% gelukt. Moet je nagaan, 30% minder telefoontjes en mails, omdat mensen zelf hun informatie kunnen vinden op internet, of omdat de informatie nu duidelijker is. Dat is echt een prestatie om trots op te zijn en dat merkte je aan alles.
  9. Vier je succes! Na de Sprint Review was er een lekker, en toch gezond, hapje voor iedereen. Even een momentje om stil te staan bij wat de teams allemaal hadden bereikt.Dit is trouwens de Product Owner in kwestie: Frits Coers. happy Product Owner
  10. De teams werkten hybride: online werd alles vastgelegd, zoals de taken, DoD en details van iedere story. Maar fysiek blijft het scrumbord gewoon staan, zodat je direct als je binnenkomt ziet hoe ver je bent. Scrumbord en Burn Down Chart. En verder blijft het natuurlijk gewoon veel lekkerder om een papiertje te verhangen dan om een item te verslepen op je computer. scrumbord
  11. Maak een mooi bord met hoofdjes. Zo kun je zien wie er allemaal in welk team zit, en kun je ook snel achterhalen wie waarvan verstand heeft. Dat weet je namelijk niet meer precies als iedereen de rol “teammember” heeft. teamhoofdjes

Concluderend: Agile moet je vooral heel flexibel houden, gebruik je gezonde verstand en je eigen best practices. Wanneer mogelijk jat je goede ideeën van anderen. Bij deze weer wat jatmateriaal. Welke tip spreekt jou wel aan?

Wil jij net zo goed worden in Agile en Scrum als Centraal Beheer? Zo effectief waarde toevoegen met je team?

Kom dan een dagje met mij meelopen in de Agile Bootcamp. Een dag lang leren over wat dat nou is, wat dat betekent en wat je ervoor moet doen. En vooral zien hoe gaaf het is, Agile. Ook voor jou. Meer info vind je hier. 15 maart, tegen kostprijs (99 euro). Ik zie je dan!

6 Responses to Even Apeldoorn bellen: tips van de scrumteams van Centraal Beheer

  1. Evert 31 januari 2017 at 09:13 #

    Hoi Gerdy,
    Een puntje waar ik het in jouw verhaal niet helemaal mee eens ben, is dat je vastlegt wat 1 storypoint is. Dit moet in de loop der tijd kunnen wijzigen. Anders zou je net zo goed kunnen plannen als bij de waterval methode.
    Wel leuk om te lezen hoe een ander bedrijf omgaat met Agile / Scrum.

    • Gerdy 2 februari 2017 at 22:42 #

      Hoi Evert, Alles kan vanzelfsprekend wijzigen. Alleen wat ik me dan wel afvraag: hoe meet je dan dat je snelheid verandert? Als je METERlat verandert van een meter naar 80 centimeter, hoe weet je dan dat die meneer van 1.85 langer is dan de mevrouw van 1.75? (als je ze niet naast elkaar kan zetten). MAW als je snelheid omhoog gaat (die je meet in story points), maar je definitie van een story point is verandert, hoe weet je dat dan?

      • Evert 3 februari 2017 at 11:09 #

        Hoi Gerdy, De snelheid verandering meet je doordat je meer storypoints per sprint gaat doen in de loop der tijd. Dit omdat het team op elkaar ingespeeld raakt. Het product backlog item (PBI) dat je in sprint 1, 1storypoint toekent is dan de referentie. Als je goed Agile werkt blijf je dit PBI niet als referentie gebruiken. Doe je dit wel dan kun je de PBI’s net zo goed in uren uitmeten. Het gaat om de relatieve waarde ten opzichte van elkaar en niet de absolute waarde. Als je een projectmanager bij het Agile team hebt die willen dit graag zo meten. Wat aan het begin van het project 2 uur werk is, willen ze zo tot het einde van het project door plannen. Maar in Agile zou je geen projectmanager moeten hebben en plan je niet zoals je in een waterval project zou doen.

        • Gerdy 8 februari 2017 at 09:54 #

          Hoi Evert, Ik zie nog niet helemaal waarom het geven van een referentie voor een Story Point ervoor zorgt dat je net zo goed in uren uit kan meten, ik denk dat het niet per sé aan elkaar is gerelateerd. Als je als story point zegt “het opleveren van één pagina” dan verandert qua uren de inhoud wel, want in het begin heb je daar een dag voor nodig en mss na een half jaar maar een halve dag. Je kunt er dan voor kiezen om de story point inhoud te veranderen, wat m.i. dan juist meer richting uren is. Of je kiest ervoor de beleving van een story point hetzelfde te houden, en hem relatief te doen. Dan zul je ook merken dat het verwerken van meer story points sneller gaat (je velocity gaat omhoog)

          Ik merk wel dat veel teams sowieso veel in uren meten, en dan toch nog relatief plannen. Soort mengvorm. Zolang het werkt is dat goed toch? Of het echt zo hoort is een tweede, maar het belangrijkste is dat je goede inschattingen kunt maken die ook nog eens overeenkomen met de praktijk. En daar zoek je m.i. de manier bij die bij jou past.

          PS ik kom graag eens aanschuiven bij een Sprint Planning bij jouw project!

  2. Wouter van den Eerenbeemt 31 januari 2017 at 10:29 #

    Leuk dit inkijkje bij anderen, ik heb het meteen even naar onze Product Owners geforward!

  3. Gerdy 2 februari 2017 at 22:42 #

    Dankjewel Wouter, ik ben benieuwd wat hij er van vindt!

Geef een reactie

Download nu het gratis e-book

7 eigenschappen van een Agile organisatie

ebook-cover-7-eigenschappen-van-een-agile-organisatie

Je hebt het ebook succesvol aangevraagd!