Uppskalning: Varför organisatorisk anpassning är kritisk och tips för att uppnå den

I det här webbseminariet tar Al Shalloway, grundare och vd för Net Objectives, upp kostnaderna för felanpassade team i stora och växande organisationer. Al diskuterar hur du kan göra iterativa förbättringar av din organisationsstruktur, vilket underlättar hanteringen av komplexa företagsprocesser och hjälper dig att leverera snabbare.

Den här sessionen ger en djupdykning i:

Uppnå en överenskommelse om prioriteringen av initiativ på portföljnivå.
Anpassning av tekniken till portföljplanerna
Att snabbare uppnå affärsvärde genom att hantera pågående arbete (WIP)
Att övergå från projektmentalitet till produktmentalitet

TITTA PÅ INSPELNINGEN

Om du vill fortsätta prata med Al kan du gå med och ställa frågor till gruppen Agile Product Management på LinkedIn.

Q&A MED AL SHALLOWAY

Tack för att ni ställde bra frågor under livesessionen! Här är Al:s svar på flera av de frågor som vi inte kunde ta upp.

F: Vårt företag har nyligen lagt ut ett ledigt jobb och beskriver vår kultur som "...Snabbt tempo, ständigt föränderlig och samarbetsinriktad". Jag var tvungen att stanna upp och fundera - Hur orsakar kulturen att grupper är anpassade eller inte inom en organisation?

S: Kulturen kan ha stor betydelse för om företaget belönar individer och/eller hjältar eller inte. Om den gör det, tenderar den att skada anpassningen. Men man måste först förstå vad kultur är - en återspegling av organisationens ledningsstrategier. Om du är intresserad av detta ämne bör du läsa Varför man inte bör fokusera på företagskulturen.

F: Hur kan jag skapa acceptans för ett verktyg som hjälper oss att anpassa, prioritera och hantera arbete i hela organisationen?

S: Innan man talar om något verktyg måste man förstå förhållandet mellan att förbättra en organisation och dess användning av verktyg. Många företag vill använda ett verktyg för att lösa sina problem. Deras logik är att om de kan inrätta verktyget på rätt sätt kommer människor att följa en effektiv och väldefinierad process. Tyvärr förutsätter detta att verktyget gör rätt saker. I verkligheten måste företagen först ta reda på vad som behövs och sedan se till att verktyget fyller det behovet. För att få ett verktyg accepterat måste du visa hur det kan skapa synlighet och minska det avfall som din nuvarande process skapar.

F: Bör teammedlemmarna kunna se vad som är uppradat på portföljnivå?

S: Detta är faktiskt en mycket viktig sak att göra. Det är möjligt med ett verktyg som Planview AgilePlace, men de flesta verktyg är inte utformade på detta sätt.

F: Hur anpassar vi oss till WIP-gränserna (work-in-process)?

S: Bestäm gränserna för WIP genom att experimentera. Skapa först en tavla i ett verktyg som Planview AgilePlace som visar arbetsflödet - så att du kan se var saker och ting backar upp. Sätt sedan din WIP-gräns vid dessa punkter - lite mindre än vad de är nu. Om du har "bubblor" i ditt arbetsflöde (det vill säga att folk är redo men att det inte finns något i deras kö) är din WIP-gräns för låg. Du kanske är intresserad av detta webinar från Planview AgilePlace om fastställande och hantering av WIP.

Fråga: Mina C-nivåer kväver oss med ett ledarskap som bygger på kommando- och kontrollfunktioner, men jag tror att de skulle vara effektivare när det gäller att skala Agile om de följde en strategi för tjänande ledarskap. Hur kan jag få dem dit?

S: Ett tjänande ledarskap bör handla om att se vad som behövs och ge stöd till människor. Det innebär inte att ta emot order från lagen. Ledarskapet måste skapa en miljö där de som rapporterar till dem kan arbeta mer effektivt. Om du börjar prata om tjänande ledarskap med personer som historiskt sett har arbetat med kommando- och kontrollarbete kommer de troligen att känna att de inte längre har någon plats och att de inte vet vad de ska göra, även om de hade det. Den här bloggen kan vara intressant för dig: Vikten av ledarskap och förvaltning i Agile.

F: Vad anser du om SAFe (Scaled Agile Framework) för att utveckla agila organisationer?

S: Vi är guldpartners, bidrar till SAFe och jag är tidigare SPC-tränare. Av de definierade metoderna är det den som vi tycker bäst om. Med detta sagt använder vi den inte direkt från början. Vi anser att det är viktigt att använda MVPs/MBIs, och deras betydelse nämns inte uttryckligen i SAFe. Dessutom skiljer sig den uppdelning som vi diskuterade under webbseminariet från SAFe:s episka -> funktioner -> berättelser. Så när vi använder SAFe tenderar vi att överlappa de produkthanteringsbegrepp som diskuterades i webbseminariet med metodiken.

Som bidragsgivare 4 år sedan till SAFe inom områdena ATDD, TDD och Kanban på Shared Services tenderar vi att ligga lite före deras årliga utgåvor. Min poäng här är att man verkligen bör använda SAFe som en ram och lägga till och utvidga den efter behov. De viktigaste aspekterna av SAFe som vi gillar är att det har en holistisk syn, uppskattar Lean, uppskattar management och har en solid planering som behövs för stora organisationer. Du kan läsa mer om hur du anpassar och utökar SAFe för att tillgodose dina behov här.

Vi har ett alternativt tillvägagångssätt till SAFe där vi börjar med ett ramverk som är skräddarsytt för våra kunders behov och som innehåller de bra sakerna i SAFe, men som fokuserar på leverans av affärsvärde och agil produkthantering. När vi gör detta finner vi att det är lättare att anta den för en organisation som vill förändras. I vissa organisationer fungerar endast en färdigpaketerad metod, och då använder vi gärna SAFe.

F: Du nämnde flera sätt som du har använt dig av iterativ utveckling, t.ex. Scrum, XP, Lean, SAFe, TDD, ATDD och emergent design. Kan du utveckla detta?

S: Det skulle kunna ta en hel bok att svara på detta, men låt mig tala om vad jag anser att vart och ett av dessa verktyg är till för och hur jag vill tänka på dem.

Scrum och XP: Jag anser att Scrum är en mycket bra gruppmetod som har överdrivits som ett ramverk som kan fungera utanför gruppen. Scrum och XP skiljer sig mest från varandra genom att XP innehåller tekniska metoder (t.ex. TDD, ATDD och emergent design), vilket Scrum inte gör. Scrum och XP använder båda iterationer för att bygga i etapper.
TDD och ATDD: TDD ger bättre design, kodkvalitet och automatiserad testning av koden ur ett funktionellt perspektiv. ATDD ger klarhet i kraven och gör det möjligt att definiera det önskade beteendet på en hög nivå och förfina det med tiden. För mer information om ATDD/TDD, se Built-In Quality with Test-First. Även om den ingår i webbseminarieserien Tuning SAFe är den i stort sett oberoende av SAFe.
Vår egen strategi är vad vi kallar "team-agility". Även om vi har använt oss av detta i flera år har vi just nu skrivit en mer formell definition. Du kan se början av här.

Lean är i stort sett grunden för allt vi gör på Net Objectives. Jag diskuterar SAFe i svaret på en annan fråga i den här bloggen. Du kan få mer information om både SAFe och emergent design på vår webbsida för webbseminarier .