In elke organisatie waar meerdere teams samenwerken aan een product of applicatie-landschap is er behoefte aan afstemming. De aanpassingen van het ene team mogen de stabiliteit of de werking van systemen van een ander team niet in de problemen brengen. Voor sommige wijzigingen moeten meerdere teams misschien wel iets aanpassen in hun code. Je kunt dit uiteraard aan het toeval overlaten, of je kunt vertrouwen op de teams, dat ze die afstemming wel zullen doen. Je kunt ook een uitgebreide integratietest inplannen om achteraf te controleren of alles tezamen nog werkt.
Je kunt ook proberen de problemen voor te zijn, en de teams ‘forceren’ om vooraf met elkaar het werk en de afhankelijkheden af te stemmen. Een Big Room Planning is een geweldig instrument om dit voor elkaar te krijgen.
Verschillende scaling frameworks
De verschillende scaling frameworks in het Agile werkveld hebben allemaal hun eigen variant van een Big Room Planning met hun eigen karakteristieken:
- SAFe heeft de PI Planning. Die duurt twee dagen en is met alle teams van de Agile Release Train. Er wordt dan een aantal sprints vooruit gepland.
- In LeSS gebruiken ze de term Sprint Planning 1 voor het overleg met (vertegenwoordigers) van alle teams. Dit gebeurt elke sprint opnieuw maar duurt bij een goede voorbereiding maximaal twee uur.
- Bij Nexus heeft men de Nexus Sprint Planning en die is goed vergelijkbaar met wat er in LeSS gedaan wordt. De teams pakken elk een aantal items op uit de overkoepelende backlog en gaan dat vervolgens in een eigen sprint planning verder uitwerken.
- Het Spotify model beschrijft een meer organisch proces waarbij afhankelijkheden tussen teams continu in kaart worden gebracht en op basis daarvan afstemming wordt gezocht.
In het vervolg van dit artikel volg ik in grote lijnen de SAFe variant. SAFe is op dit moment het meest gebruikte scaling framework.
Wat heb je nodig voor een Big Room Planning?
Het lijkt dus echt wel een goed idee om met meerdere teams de afstemming te gaan regelen maar heb je daar dan nog iets speciaals voor nodig? Waar moet je allemaal aan denken?
In de basis is het niet zo ingewikkeld. Als je weet waar je naar toe wilt met je product of applicatie-landschap, en dat hebt vastgelegd in een visie en roadmap, dan ben je al een eind op weg. Dan kun je de backlog, waar het werk voor de teams in wordt vastgelegd, gaan vullen en prioriteren. In de meeste gevallen zal dit een centrale backlog zijn ‘over de teams heen’ met wellicht wat grotere items dan op de backlogs van ieder individueel team. De visie is wat je wilt eten, de roadmap is het recept, en de backlog de lijst met ingrediënten die je nodig hebt.
Het tweede wat nodig is, dus naast de visie en roadmap, is betrouwbare teams. Je gaat met elkaar afspraken maken over wie wat en wanneer gaat doen. Het plan en het succes van elk team wordt mede afhankelijk van een ander team. Het gezamenlijke succes is afhankelijk van alle teams. Naast dat de teams elkaar kunnen vertrouwen, verwachten we van elk team dat ze volwassen genoeg zijn om hun eigen werk goed te kunnen inschatten en plannen. Als het plan van één team niets waard is dan geldt dat helaas ook voor het gezamenlijke plan… De ketting is zo sterk als de zwakste schakel.
Het is ook belangrijk dat teams ongeveer op hetzelfde moment aan het gemeenschappelijke doel werken. Anders ligt het werk van één team te wachten en ontstaat er een groot risico op rework omdat er natuurlijk toch van alles verandert in de tussentijd.
Wat mij betreft zijn dat de twee belangrijkste ingrediënten voor een succesvolle Big Room Planning. Natuurlijk moeten er nog een paar smaakmakers worden toegevoegd maar het is voldoende basis om uit de voeten te kunnen.
De essentie van Big Room Planning
De essentie van de Big Room Planning is uiteraard om het werk dat in de volgende timebox gedaan moet worden, over de verschillende teams te verdelen en in kaart te brengen waar de risico’s en afhankelijkheden zitten. Het maakt voor het concept niet zo veel uit of die timebox één of meerdere sprints bevat. Zoals eerder gemeld volg ik hier de SAFe aanpak en is die timebox een PI die uit een aantal sprints bestaat.
De verdeling van het werk is voor een groot deel afhankelijk van de aard van de teams. Zijn het feature teams die vrijwel onafhankelijk nieuwe functionaliteit kunnen implementeren of zijn er component en platform teams waardoor er juist veel onderlinge afhankelijkheden zullen zijn? Dit onderwerp, hoe teams te organiseren, is in veel organisaties een uitdaging op zich waar ik in een ander artikel graag een keer op in ga.
Goed. De items op de centrale backlog zullen tijdens de Big Room Planning in kleinere stukken op de backlogs van één team (in het geval van feature teams) of meerdere teams (in het geval van component en platform teams) terecht gaan komen. Om dit geheel transparant te maken presenteert elk team hun plan aan de andere teams om zo de gezamenlijkheid te bevorderen. Bovendien komen er dan toch vaak weer items aan het licht die verdere afstemming nodig hebben.
De tweede output van de Big Room Planning is het ‘bord der afhankelijkheden’. Dit bord is een visualisatie van de elementen en volgordelijkheid daarvan om aan het einde van de timebox de overall doelstellingen op te leveren:
Smaakmakers
Ik noemde het al eerder, een Big Room Planning heeft ook een aantal smaakmakers nodig. Dat geldt voor fysieke meetings maar zeker ook voor virtuele meetings. We willen dat iedereen betrokken is en blijft en er zijn diverse manieren om dat voor elkaar te krijgen.
Een eerste categorie smaakmakers zijn (business) presentaties. Let wel goed op wie je dat laat doen want als het saaie en langdradige verhalen zijn dan doet het meer kwaad dan goed. Een korte en bondige presentatie over de visie, over de toekomst van het bedrijf of over hoe goed de vorige release van het product is geweest en wat dat met de business heeft gedaan, zorgt vaak wel voor trots en saamhorigheid.
De tweede categorie zijn meer team-building activiteiten. Gebruik een deel van de tijd om de marshmallow challenge te doen of een onderwerp met behulp van Lego Serious Play uit te werken. Of doe een pub-quiz aan het einde of gewoon een borrel. En als de meeting virtueel is, kun je een speurtocht in huis doen waarbij bijvoorbeeld de opdracht is om buitenlandse valuta te vinden en aan elkaar te laten zien met een leuke anekdote over het land van herkomst.
Tot slot
Het lijkt misschien een heel gedoe, zo’n Big Room Planning. En deels klopt dat ook wel maar dat is geen reden om het niet te doen. Er zijn veel variaties mogelijk en er is al snel sprake van enorme toegevoegde waarde. Daarmee is het in ieder geval nuttig. Of het ook noodzakelijk is hangt af van hoe het gaat zonder Big Room Planning. Als er geen problemen zijn dan blijft het wellicht alleen nuttig. Maar als de afhankelijkheden tussen teams steeds tot problemen leiden dan is het misschien toch bittere noodzaak…
Deze blog is geschreven door IT-professional Sander Bosma.
