Planview-bloggen

Din väg till smidighet i affärsverksamheten

Work Management för team

Hantera grupper vars problem ger dig problem

Publicerad Av Dominica Degrandis

Introduktion av Jon Terry, COO för Planview AgilePlace

Vi vet - vi är mycket intresserade av att folk använder oss för konstruktion, tillverkning, logistik, bilreparationer, talanghantering eller vad som helst. Vår verksamhet på Planview AgilePlace har vid det här laget spridit sig en hel del bortom våra rötter software development management. Men vi är fortfarande medvetna om att vår kärnverksamhet (och våra hjärtan och vårt arv) finns på IT-avdelningen. Och inom detta breda område är några av de mest framgångsrika Kanban-implementeringarna (av Planview AgilePlace eller någon annan typ) IT-driftsgrupper.

Kanban är helt enkelt en naturlig lösning för de som arbetar med operativ verksamhet och som vill vara Lean-Agile, men för vilka tanken på Scrums fasta iterationer helt enkelt inte är meningsfull. Vi har faktiskt sett hur Scrums ökade hastighet faktiskt orsakar problem för driftteamen när de kämpar för att balansera snabbt föränderliga konkurrerande krav. De blir slagpåse i Scrum of Scrums!

Dagens gästbloggare, Dominica DeGrandis, är en av de ledande tankarna inom Kanban for Operations. Hon är själv en långvarig operatör och en långvarig medarbetare till David Anderson, pionjär inom Kanban. Dominica talar ofta på Lean/Agile/Kanban-konferenser och erbjuder Kanban-utbildning riktad till personer inom Ops. Hon är också redaktör för Kanban Weekly Roundup på bloggen David J. Anderson & Associates. Vi är glada att välkomna Dominica till bloggen!


Hantera grupper vars problem ger dig problem

Jag har funderat en hel del på sistone på hur man ska hantera externa beroenden.  Jag har kommit fram till att a) "Extern" måste definieras noggrant och b) "Risk" måste undersökas grundligt.

Om vi definierar external som något som ligger utanför vår avdelnings kontroll, innebär det då en annan avdelning längre ner i korridoren på samma företag? Eller betyder det en 3rd partysäljare i en annan tidszon som inte kan komma ihåg namnet på vårt företag? Det kan faktiskt finnas situationer där det är lättare att arbeta med en 3rd partleverantör i Polen än att arbeta med försäljningsavdelningen i korridoren.

Nyckeln verkar ligga i att förstå den risk som är förknippad med beroendet. Vad kostar det om beroendet inte kommer in i tid? Vilken typ av resultat har den externa enheten?  Exemplen skulle kunna fortsätta i oändlighet. Här är ett urval:

  • Den grupp som "bidrog" till att vår avdelning missade datumet för utgivningen av ett lagstadgat krav lovade ekonomichefen företagets ägare. Strategi? Kanske bör framtida beroenden som är beroende av den här gruppen (om de fortfarande finns kvar) inte läggas in i Kanban-styrelsens färdigkö förrän den här gruppen bekräftar att deras del är klar.
  • Eller den grupp som i allmänhet håller sina tidsfrister, men som tenderar att optimera lokalt? Strategi? Kanske kan du placera den här typen av risk för beroende i ett separat "Waiting For"-område på kanban-tavlan med servicenivåavtal (SLA) så att ledningen kan ta itu med dem.
  • Eller gruppen som regelbundet skickar en medlem av sitt team till vår standup. De är med på att "optimera hela organisationen" i stället för att fokusera sin energi på den egna avdelningens funktion. Strategi? Kanske kan ett beroende av denna grupp betraktas som en låg risk och vi kan tillåta att ett beroendekort hänger med det tillhörande kortet i vårt standardarbetsflöde. Men kanske skulle vår policy bara tillåta detta när det inte finns några problem.

När ett problem uppstår kan beroendekortet få ett rosa klistermärke som indikerar blockering. Men är detta tillräckligt för att signalera en upptrappning till rätt person? Även om teamet skulle omvandla beroendekortet till en expeditfil, vad skulle det tjäna till om problemet endast kan lösas av någon som inte tillhör teamet? Externa frågor som ligger utanför vår avdelnings kontroll behöver sannolikt ledningens uppmärksamhet för att minimera riskerna.

Vi kan betrakta externa beroenden som olika risknivåer. Ett riskområde för beroenden, om du så vill, där beroenden med hög risk är mer uppenbara än beroenden med låg risk. I idealfallet finns det tillräckligt med information på kortet så att teamet kan omvärdera risknivån vid behov - en praktisk förmåga i en värld i ständig förändring när tidigare prioriterade beslut om risk kan ha ändrats - och alla inte var informerade.

Externa beroenden kräver insyn i riskerna. Vi kan demonstrera denna risk genom att införa ett riskområde för externa beroenden i vår design av kanban-systemet. Kanbankort som innehåller kriterier för att avgöra risker bör ge poäng.

Relaterade inlägg

Skrivet av Dominica Degrandis

Dominica lär ut Kanban till DevOps-entusiaster. Som Executive Consultant på LeanKit kombinerar Dominica erfarenhet, praktik och teori för att hjälpa organisationer att öka sin kapacitet. Hon vill gärna ge synlighet och transparens i olika team för att avslöja kritisk information för båda parter. Följ henne på Twitter på @dominicad.