Wat zijn leveringsplannen?
Naarmate ontwikkelingsorganisaties groeien, moeten ze zich opnieuw organiseren in kleinere teams die gegedeelteerde werkeenheden efficiënt kunnen beheren. Deze teams hebben meestal hun werkschema's, borden en andere processen die voldoen aan hun unieke behoeften binnen de context van de grotere doelstellingen van de organisatie. In de loop van de tijd kunnen organisaties merken dat ze profiteren van netwerkvoordelen door hun processen rond een consistent framework te consolideren.
Een leveringsplan is een visualisatie van een of meer werkschema's. Het is bedoeld om teams en beheer een algemeen overzicht te geven van wat elk team van plan is om te produceren en wanneer. Hiermee kunnen beslissingen worden genomen die de investeringen in de hele organisatie optimaliseren.
Teams moeten hun leveringsplannen regelmatig controleren om ervoor te zorgen dat hun werkschema overeenkomt met de planningen van andere teams. Deze beoordelingen moeten betrekking hebben op vragen zoals:
- Zijn we er zeker van dat we kunnen leveren waar we ons aan hebben verbonden volgens onze huidige planning?
- Zijn we ervan overtuigd dat de teams waarvan we afhankelijk zijn, zullen leveren wat we nodig hebben volgens hun huidige planning?
- Zijn er lullen in onze planning die we kunnen vullen met werk?
- Zijn er problemen met afhankelijkheden binnen een team of in verschillende teams?
Leveringsplannen voegen op elk moment in de levenscyclus van een project waarde toe. Omdat ze dynamisch worden gegenereerd op basis van teamachterstanden, zijn ze altijd up-to-date en bieden ze de nieuwste inzichten.
Laten we deelnemen aan het Tailspin-webteam in hun discussie.
Andy: Ik heb net een geweldige ontmoeting gehad met technisch management. Ik heb het werk dat we doen met Azure Boards gedegradeerd en ze zijn enthousiast over het perspectief van het aan boord krijgen van andere teams.
Mara: Geweldig! Wanneer gaan ze aan de slag?
Andy: Dat is het beste deel. Ze hebben het al! Gisteravond maakte de projectleider van de game-engine een team met enkele sprints en begon met het toevoegen van werkitems. Ik heb vanmorgen een kijkje genomen en het is mooi vormgegeven. Laat me je laten zien waar ze aan toe zijn.
Andy navigeert naar het huidige sprintbord van de game-engine. Hij en Mara bekijken de werkitems met grote interesse.
Andy: Hmm... Ik zag alleen dat ze niet van plan zijn om hun bèta aan het einde van deze sprint te implementeren. Verwachten we niet dat we ons leaderboard tijdens de volgende sprint gaan integreren met de bètadatabase? Dat kunnen we niet doen als ze de bèta niet eerst verzenden.
Mara: Dat is een goed punt. We hebben een afhankelijkheid van dat team om dat product te produceren, zodat we een van onze eigen producten kunnen produceren.
Andy: Dit zou onze productiviteit de volgende sprint echt kunnen kwetsen. Ik ga ze bellen om erachter te komen wat er aan de hand is.
Helaas kunnen geavanceerdere teamstructuren leiden tot hiaten of vertragingen in de communicatie. Wanneer één team wordt geblokkeerd, kunnen ze mogelijk niet iets produceren waarvoor een ander team afhankelijk is. Dit is mogelijk geen belangrijk probleem voor een kleine groep teams die dagelijkse vergaderingen hebben voor alle betrokkenen. Als teams echter in grootte en locatie schalen, kan het onhoudbaar worden voor iedereen om alles overal te weten. Op dit moment moeten organisaties overstappen van een puur pushmodel (zoals persoonlijke aankondigingen of e-mailaankondigingen) naar een pull-model (waar teams elkaars planningen kunnen bekijken en volgen).
Andy: Oké, ik heb net met de dev lead gesproken. Ze vertelde me dat hun team wordt geblokkeerd om de bèta te verzenden totdat het kunstteam terugkeert van Cliffchella.
Mara: Het muziekfestival van de bergtop?
Andy: Blijkbaar is het een enorme deal in de ontwerpcommunity, en hun hele team laat het raster een hele week vallen om bij te wonen. Het team van de game-engine is behoorlijk boos omdat het hun planning met drie weken heeft geslipt. Als ze wisten dat het zou komen, zouden ze ervoor hebben gezorgd dat ze de artefacten krijgen die ze van tevoren nodig hadden. Ze verontschuldigen zich ook voor het niet eerder laten weten. Ze beseften niet dat we op hun bèta zouden wachten om ons deel te verzenden.
Mara: Nou, we kunnen tenminste blij zijn dat het team van de game-engine hun sprintplannen publiceert. Het heeft ons geholpen om dit afhankelijkheidsprobleem vroeg genoeg te vinden om onze planning aan te passen.
Andy: Ik wou dat er een manier was om deze potentiële risico's gemakkelijker te zien komen. Onze teams hebben zoveel afhankelijkheden binnen het bedrijf dat we niet aan elke vergadering kunnen deelnemen en zich kunnen abonneren op elke distributiegroep.
Mara: We moeten een leveringsplan maken, zodat we onze team sprints naast elkaar kunnen zien. Hierdoor kunnen beide teams gemakkelijker identificeren hoe onze planningen van invloed zijn op elkaar.
Aanbevelingen voor het beheren van meerdere Agile-teams
Een Agile-benadering kan samen met Azure DevOps de transparantie en voorspelbaarheid van projecten aanzienlijk verbeteren. Projecten kunnen echter nog steeds traditionele uitdagingen ondervinden, vaak gerelateerd aan personeel of miscommunicatie. Hier volgen enkele aandachtspunten bij het schalen van uw Agile-inspanningen.
Vertrouwen opbouwen in uw personen en processen
Vroege detractors van Agile-implementaties zijn vaak sceptisch over hun vermogen om de prestaties van het team te verbeteren. Het is belangrijk dat gedachtenleiders binnen de organisatie vertrouwen opbouwen door te illustreren hoe de hulpprogramma's en processen resultaten produceren. Soms zijn deze resultaten verbeteringen in productiviteit, die gemakkelijk te kwantificeren zijn. Vergeet echter niet om de overwinningen van het team te markeren die optreden door potentiële problemen te omzeilen, zoals vermijdbare planningsslipten of kwaliteitsproblemen. Naarmate mensen de voordelen gaan koppelen aan het proces dat ze bereikten, krijgt u meer enthousiasme.
De organisatie verhogen boven het team (en individueel)
Sommige teams en personen krijgen territoriaal wanneer nieuwe processen of beleidsregels worden voorgesteld. In plaats van nieuwe beleidsregels in te stellen als negatieve weergave van de prestaties van specifieke teams of personen, markeert u hoe de nieuwe transparantie in de organisatie iedereen informeert over verwachtingen. Met één plaats waar iedereen kan traceren hoe hun werk zich verhoudt tot de organisatie die aan de doelstellingen voldoet, zal het belang van hun inzet voor het proces bepalen.
Een cultuur van transparantie bevorderen
Helaas krijgt de term "transparantie" een slechte rap. Niemand vraagt om meer transparantie als alles goed gaat. In plaats daarvan wordt transparantie (of gebrek daarvan) vaak de schuld wanneer teams moeite hebben. Zelfs met alle mogelijkheden voor transparantie voor Agile-teams, is het nog steeds onderhevig aan de eerlijkheid van individuen en teams. Benadruk dat een van de redenen voor transparantie is om potentiële problemen te identificeren en op te lossen voordat het te laat is. Iedereen begrijpt dat mensen soms omstandigheden tegenkomen waardoor ze niet aan deadlines voor planningen kunnen voldoen. Maar als ze zich niet veilig voelen bij het melden van teleurstellend nieuws tot het laatste mogelijke moment, kan het een veel destructievere impact hebben. Het opbouwen van een comfortniveau met transparantie kan beginnen met het bedanken van mensen voor het zo vroeg mogelijk rapporteren van verwachte vertragingen.