Vad är leveransplaner?
I takt med att utvecklingsorganisationer växer måste de omorganisera sig till mindre team som effektivt kan hantera delar av arbetet. Dessa team har vanligtvis sina arbetsscheman, styrelser och andra processer som uppfyller deras unika behov inom ramen för organisationens större mål. Med tiden kan organisationer upptäcka att de får nätverksfördelar genom att konsolidera sina processer kring ett konsekvent ramverk.
En leveransplan är en visualisering av ett eller flera arbetsscheman. Det är avsett att ge team och ledning en övergripande vy över vad varje team planerar att producera och när. Det gör det möjligt att fatta beslut som optimerar investeringarna i hela organisationen.
Teamen måste regelbundet granska sina leveransplaner för att se till att deras arbetsschema överensstämmer med andra teams scheman. Dessa granskningar bör ta upp frågor som:
- Är vi säkra på att vi kan leverera det vi har åtagit oss enligt vårt nuvarande schema?
- Är vi övertygade om att de team vi är beroende av kommer att leverera det vi behöver enligt deras nuvarande schema?
- Finns det lulls i vårt schema som vi kan fylla med arbete?
- Finns det problem med beroenden i ett team eller mellan team?
Leveransplaner lägger till värde när som helst i ett projekts livscykel. Eftersom de genereras dynamiskt baserat på teamets kvarvarande uppgifter är de alltid uppdaterade och erbjuder de senaste insikterna.
Nu ska vi gå med tailspin-webbteamet i deras diskussion.
Andy: Jag hade just ett bra möte med ingenjörsledningen. Jag demonstrerade det arbete vi gör med Azure Boards, och de är glada över möjligheten att få med andra team.
Mara: Awesome! När kommer de igång?
Andy: Det är det bästa. De har redan gjort det! I går kväll skapade projektledningen för spelmotorn ett team med några sprintar och började lägga till arbetsobjekt. Jag tog en snabb titt i morse, och det formar sig fint. Låt mig visa vad de håller på med.
Andy navigerar till spelmotorns nuvarande sprintbräda. Han och Mara granskar arbetsobjekten med stort intresse.
Andy: Hmm... Jag märkte bara att de inte planerar att distribuera sin beta i slutet av denna sprint. Förväntar vi oss inte att integrera vår topplista med betadatabasen under nästa sprint? Vi kan inte göra det om de inte skickar beta först.
Mara: Det är en bra poäng. Vi är beroende av det teamet för att producera den slutprodukten så att vi kan producera en egen.
Andy: Detta kunde verkligen ha skadat vår produktivitet nästa sprint. Jag ska ringa dem för att ta reda på vad som händer.
Tyvärr kan mer avancerade teamstrukturer resultera i luckor eller fördröjningar i kommunikationen. När ett team blockeras kanske de inte kan producera något som ett annat team är beroende av. Detta kanske inte är ett stort problem för en liten grupp team som har dagliga möten för alla berörda. Men när teamen skalas i storlek och plats kan det bli ohållbart för alla att veta allt som händer överallt. Det är just nu som organisationer måste övergå från en ren "push"-modell (till exempel personliga meddelanden eller e-postmeddelanden) till en "pull"-modell (där team kan granska och spåra varandras scheman).
Jag pratade just med utvecklingsledaren. Hon sa att deras team är blockerat från att skicka beta tills konstteamet återvänder från Cliffchella.
Mara: Bergstoppsmusikfestivalen?
Andy: Ja, tydligen är det en enorm affär i designgemenskapen, och hela deras team bara faller av nätet under en hel vecka för att delta. Spelmotorteamet är ganska upprörd eftersom det halkade deras schema med tre veckor. Om de hade vetat att det skulle komma, skulle de ha se till att få artefakterna de behövde i förväg. De bad också om ursäkt för att de inte lät oss veta tidigare. De insåg inte att vi skulle vänta på deras beta för att skicka vår del.
Mara: Tja, vi kan åtminstone vara glada att spelmotorteamet publicerar sina sprintplaner. Det hjälpte oss att hitta det här beroendeproblemet tillräckligt tidigt för att justera vårt schema.
Andy: Jag önskar bara att det fanns ett sätt att se dessa potentiella risker komma lättare. Våra team har så många beroenden i hela företaget att vi inte kan delta i varje möte och prenumerera på varje distributionsgrupp.
Mara: Vi bör skapa en leveransplan så att vi kan se vårt team sprinta sida vid sida. Detta hjälper båda teamen att lättare identifiera hur våra scheman påverkar varandra.
Rekommendationer för att hantera flera agila team
En flexibel metod, tillsammans med Azure DevOps, kan avsevärt förbättra projektets transparens och förutsägbarhet. Projekt kan dock fortfarande stöta på traditionella utmaningar, ofta relaterade till personal eller kommunikation. Här följer några saker att tänka på när du skalar dina agila ansträngningar.
Skapa förtroende för dina medarbetare och processer
Tidiga belackare av agila implementeringar är ofta skeptiska till deras förmåga att förbättra teamets prestanda. Det är viktigt för tankeledare inom organisationen att skapa förtroende genom att illustrera hur verktygen och processerna ger resultat. Ibland är dessa resultat produktivitetsförbättringar, som är enkla att kvantifiera. Glöm dock inte att markera de lagvinster som uppstår genom att kringgå potentiella problem, till exempel påverkbara schemamissar eller kvalitetsproblem. När människor börjar associera fördelarna med den process som uppnådde dem får du mer entusiasm.
Höja organisationen ovanför teamet (och individen)
Vissa team och individer blir territoriella när nya processer eller principer föreslås. I stället för att utforma nya principer som negativt exponerar prestanda för specifika team eller individer, belyser du hur den nya transparensen i organisationen informerar alla om förväntningarna. Att ha en enda plats där vem som helst kan spåra hur deras arbete relaterar till organisationen som uppfyller dess mål kommer att driva hem vikten av deras engagemang för processen.
Främja en kultur av öppenhet
Tyvärr får termen "öppenhet" en dålig rap. Ingen ber om mer öppenhet när allt går bra. I stället skylls transparens (eller brist på sådan) ofta när lag kämpar. Även med alla möjligheter till transparens som erbjuds för agila team, är det fortfarande föremål för ärlighet hos individer och team. Betona att en av orsakerna till transparens är att kunna identifiera och åtgärda potentiella problem innan det är för sent. Alla förstår att människor ibland stöter på omständigheter som hindrar dem från att uppfylla tidsgränser för mötesscheman. Men om de inte känner sig säkra i att rapportera nedslående nyheter förrän i sista möjliga ögonblick kan det ha en mycket mer destruktiv inverkan. Att skapa en komfortnivå med transparens kan börja med att tacka människor för att de rapporterar förväntade förseningar så tidigt som möjligt.