Introduktion av Jon Terry, COO för Planview AgilePlace
Ett av våra nyårslöften på Planview AgilePlace är att bättre dela idéer för att effektivt använda Kanban med våra kunder. Vi hämtar en del bra idéer från vårt samarbete med kunderna, och vi lovar att vi kommer att ta med några av dem i blogginläggen då och då. Vi är också välsignade med många riktigt smarta vänner i Lean/Agile-communityt, och ett antal av dem har gått med på att dela med sig av sin visdom till oss och er som gästbloggare.
Det första av dessa gästinlägg kommer från Yuval Yeret från Agile Sparks. Vi har känt Yuval i flera år nu och respekterar och gillar honom verkligen. Han är en duktig Kanban-utbildare och konsult och en flitigt anlitad talare på Lean/Agile-konferenser. Du bör definitivt kolla in hans blogg yuvalyeret.com. och hans presentationer på Slideshare.
Att använda Kanban för att förbättra revisionshanteringen
Varje gång vi på AgileSparks får en chans att lämna vår komfortzon av teknikleverantörsorganisationer blir vi glada. Vi tror att det tänkande, de principer och den praxis som vi använder för teknikleverans är mycket relevanta även inom andra kunskapsintensiva områden, och vi fortsätter att leta efter möjligheter att testa denna övertygelse. Vårt arbete med teknikleverantörsorganisationer exponerar oss för andra stödverksamheter i organisationer. Jag skrev nyligen på min blogg om en HR-grupp som vi arbetade med (och jag har fler uppdateringar om den gruppen som jag måste skriva om...). Den här gången vill jag tala om en annan typ av verksamhet - revision.
En Audit grupp inom en organisation har till uppgift att granska system och processer, främst som en del av riskhanteringen. Låt oss titta på vad Agile/Kanban kan betyda i detta sammanhang.
Revisionen i sitt sammanhang
Arbetet i en revisionsgrupp kan sträcka sig från revisioner med manuskript för att kontrollera att standarderna följs till aktiviteter av typen undersökande forskning för att utforska vad som händer och identifiera risker. När jag pratade med några personer från en sådan organisation blev jag påmind om Scripted Testing och Exploratory Testing, och om att det som gör en bra granskare är att köra många, många inlärningsloopar som en del av undersökningen.
Revisionsgrupper kan vara mycket kraftfulla i en organisation. Friska organisationer försöker bevara deras oberoende och låter dem därför rapportera mycket högt upp i organisationsplanen, ibland direkt till styrelsen. Med denna makt följer ett stort ansvar. Du måste verkligen se till att du gör saker och ting på rätt sätt. Dina resultat måste vara korrekta. Men framför allt vill du få den granskade gruppen att godkänna dina resultat. Om du driver en ensidig show blir det svårt att upprätthålla förtroendet och öppna kommunikationslinjer. Allt detta innebär vanligtvis många interaktioner mellan högre chefer, särskilt när resultaten granskas och förbereds för publicering, och mycket uppmärksamhet på detaljer och kvalitet.
Vilka är utmaningarna i revisionen?
En av de stora och unika utmaningarna är arbetets trattform. Föreställ dig en grupp med 20 revisorer. Var och en av dem arbetar med sitt eget revisionsprojekt. De första stegen med avgränsning, forskning och utarbetande av en rapport kan de göra ganska självständigt. Men när de närmar sig milstolpar som "första utkastet skickas till den granskade gruppen" och "publicering" behöver de mer och mer involveras av de högre revisorerna och cheferna i gruppen. Detta beror på den känsliga karaktär som jag nämnde tidigare. Detta kan skapa en flaskhals eller åtminstone en stor variation när du behöver en resurs som inte är omedelbart tillgänglig, t.ex. en vice vd för gruppen eller dess GM.
En annan utmaning är att revisorn naturligtvis måste arbeta med den granskade gruppen. Hon behöver dem för att dela dokument, fördela tid, ge tillgång till IT-system och flera andra aspekter. Kom ihåg att även om hon tjänar en herre som står högt över den granskade gruppen, är de fortfarande huvudsakligen fokuserade på sin dagliga verksamhet och betraktar vanligtvis granskningen som en oönskad inblandning. Även om de har bjudit in till revisionen har de fortfarande sin dagliga verksamhet att ta hand om, så revisorn kan behöva hantera många resurser som inte är tillgängliga omedelbart - och måste vänta.
Sidanmärkning: Detta är förresten mycket likt de utmaningar som Agile-konsulten har när han eller hon arbetar med en grupp. Oavsett vem som bjudit in oss, om vi är verksamma enligt ett direktiv på mycket hög nivå eller om vi är inbjudna av gruppen själv, är det ganska svårt att få gruppen att ägna uppmärksamhet åt oss mitt i de dagliga utmaningarna som uppslukar den. Om vi tittar på vad vi talar om med Kanban och Lean, syftar vi faktiskt till att bygga organisationer som vet hur man effektivt balanserar det viktiga (att förbättra kapaciteten) och det brådskande (att leverera det pågående arbetet). Kanske kommer fler organisationer att göra detta effektivt om några år, men för närvarande bör vi inte bli förvånade över att se de problem som vi kommer in för att hjälpa organisationer med...
Dessa utmaningar när det gäller att få tid och uppmärksamhet från de grupper som granskas och de chefer som måste granska resultaten, vilket leder till mycket arbete med stopp och start, tenderar att tvinga många organisationer att belasta revisorerna med många projekt för att hålla dem sysselsatta.
Och mitt i allt detta är det oundvikligt att prioriteringarna ändras - händelser som utlöser ett behov av en särskild revision, ändrade affärsmässiga intressen och prioriteringar osv. Detta kan leda till att en årlig revisionsplan blir förödande. Med alla dessa variationer är det svårt för cheferna att veta när de kan förvänta sig att projektet ska vara färdigt, eller att förstå vilka projekt som går bra och vilka som har problem.
Hur skulle en bra revisionsgrupp se ut?
Med tanke på ovanstående utmaningar skulle en bra revisionsgrupp ha följande egenskaper:
- Gruppen har ett bra arbetsflöde. Revisorerna har i allmänhet en enda uppgift, har ett bra flöde i sitt huvudprojekt, får snabb återkoppling och stöd från vem de än behöver, inklusive den granskade gruppen, sina chefer/överordnade, och kan publicera en uppföljningsbar granskning med minimal tidsspillan på grund av avbrott, väntan och omarbetning.
- Minimalt slöseri på grund av omarbetning - Även om viss omarbetning och vissa ändringar kan förväntas om nya bevis/fakta dyker upp som leder till ändringar i revisionen, anser revisionsgruppen att onödig omarbetning är minimal.
- Alla upplever att processen blir smidigare från månad till månad, från revision till revision, att det blir färre problem och att vi hela tiden kan förbättra våra huvudmål.
- Gruppen kan hantera förändringar utan att tappa tempo. Intressenterna vet att koncernen kan leverera både när det är bråttom och när det gäller de strategiska planerna. Gruppen kan samla sina krafter kring det mest prioriterade arbetet.
- Tiden går åt till att utföra arbetet eller till att förbättra det. Minimal tid går förlorad på omplanering och andra aktiviteter som inte ger något mervärde.
Hur kan Kanban hjälpa till?
Du kan säga att min vision av en bra grupp är mycket influerad av Lean/Kanban och du har förmodligen rätt. Men om du ser ovanstående som positivt, låt oss försöka se hur Kanban-metoden kan bidra till att uppnå detta.
Kanban-metoden hjälper dig att förbättra dig på ett evolutionärt sätt genom att använda flödeskontroll som en av de viktigaste principerna. Du börjar med ditt nuvarande arbetssätt utan att göra några förändringar. Det första du gör är att visualisera arbetsflödet och integrera denna visualisering i ditt sätt att hantera ditt dagliga arbete och din planering. När du börjar tillämpa flödeskontroll med hjälp av "Work in Progress Limits" kommer du att stöta på utmaningar och tvingas göra något åt dem. Du kommer att se omarbetning i form av små biljetter som återkommer till tidigare skeden av arbetet, på samma sätt som vi beskriver defekter/buggar i software development kanban.
Kanban i sig talar inte om hur du ska åtgärda saker och ting. Men den kommer bland annat att få dig att börja tänka på effektiv cykeltid och inte bara på resurseffektivitet. Genom att visualisera arbetet tvingas du göra den nuvarande politiken tydlig. Policys, t.ex. förväntningar från granskade grupper, förväntningar från chefer. Hur ni för närvarande fördelar chefernas tid på de olika projekten - är det efter revisionens prioritet? Genom dess ålder i systemet? En kombination? Även diskussionen om politiken kommer att ge upphov till frågor och idéer om förbättringar. Välj noga vad du vill experimentera med.
Kanban-metoden ger dig alltså inte en färdigpaketerad lösning på förhand. Långt därifrån. Istället kommer det att inrätta ett diagnostiskt system som visar var du befinner dig för närvarande och ger dig ett system som du kan använda för att utvecklas. För att den verkligen ska tjäna dig måste du definiera vart du vill gå, vilka konkreta förmågor du vill förbättra. Sedan kan du använda något som Mike Rothers förbättringskata för att arbeta i små steg mot dessa mål.
Någon gång, kanske till och med tidigt, kommer du att säga något i stil med "Kanban ger inga lösningar". Det är delvis sant. Du kommer att få flödeskontroll. Du kommer att få något som ger dig möjligheter/utlösare att tänka på hur arbetet går till, inte bara göra arbetet. Du kommer att bli tipsad om de områden som för närvarande utgör de största hindren för ytterligare förbättringar av Flow. Men du kommer inte att få alla de lösningar du behöver för att hantera dessa hinder. Detta är avsiktligt.
I Kanban-metoden talas det om förbättringar i samarbete med hjälp av modeller. Förbättring i samarbete innebär att personer som är involverade i systemet deltar i utformningen av förbättringsförsöken, vilket ökar engagemanget. Samarbetet kan också handla om att välja vilken modell man ska prova nästa gång. Det finns ingen spelbok som ger dig en perfekt lösning, men om flera andra grupper har provat Kanban för en revisionsgrupp eller i ett liknande sammanhang tidigare kan du ha några bra idéer att utgå från. Men det finns ingen garanti för att de kommer att hjälpa. En av de viktiga modeller vi använder är att betrakta våra sammanhang och system som komplexa. I komplexa miljöer måste man prova saker och ting, se om de hjälper och sedan besluta om man ska förstärka eller kasta bort dem och prova något annat.
Du kanske kan prova Theory of Constraints's fem fokuseringssteg kring flaskhalsar som kan ge dig idéer som att underordna revisorerna under de externa grupperna - Vad skulle krävas för att påskynda svarstiden? Rapportens tydlighet? Något annat? Vad skulle det betyda om du underordnade dig GM, som är den ultimata interna flaskhalsen? Försöker minimera omarbetning och passerar genom sin granskning?
När du försöker underordna dig kan du hitta användbar vägledning i det arbete som görs inom IT med Specification by Example och Test-Driven Approach (testdrivna metoder). Om vi betraktar granskningar som steg för att inspektera kvaliteten i revisionen, kanske metoder som bygger in kvalitet genom att specificera förväntningar och tester i förväg och involvera granskarna tidigare är mer effektiva? Ja, det kan kräva tid av granskaren tidigare, men mot din intuition kan det vara det optimala alternativet.
Du kan försöka dela upp en revision i mindre delar, även kallade Small Batches. Kanske kan du börja betrakta revisionen som en backlog med områden att arbeta med, och utgå från resurser och tid snarare än omfattning. Även om omfattningen är fastställd kanske du kan minska ansträngningen om du får snabbare feedback på de första resultaten. Kanske kan du förbättra flödet om du behöver den granskade gruppen och de interna granskarna för mindre delar av tiden i stället för långa granskningar?
Sammanfattning
Detta är inte en fallstudie om Kanban för revisionsgrupper. Kanske någon gång i framtiden. Den viktiga punkten är att även om det var så skulle det inte nödvändigtvis vara något du kan kopiera även om din miljö låter exakt som det jag beskrev.
Vad du kan kopiera är tillvägagångssättet för att förbättra. Identifiera utmaningar. Föreställ dig den ideala situationen. Använd Kanban för att visualisera var du befinner dig, skapa flödeskontroll och sedan börja experimentera tillsammans med dina medarbetare genom att använda små evolutionära steg av dina uttalade policyer som styrs av modeller som du väljer att prova och tillämpa.
Du kan ha tur och få bra resultat genom att använda de modeller/experiment som beskrivs ovan. Om så är fallet är det bra. Vi kanske upptäcker att en viss uppsättning modeller passar utmärkt i en viss miljö. Inom programvaruutveckling har vi till exempel en rad modeller som vanligtvis är mycket framgångsrika (Feature Teams, Extreme Programming Engineering Practices, Test/Behaviour-Driven Approaches etc.).
Du kommer också att märka att ordet revision förmodligen kan ersättas med någon annan typ av kunskapsarbete i den här artikeln. Kanban-metoden har en bred användbarhet. Modellerna har också en bred användbarhet. Det finns modeller som är domänspecifika, men jag tror att en noggrann undersökning även av dessa kommer att ge insikter om andra områden. Det är det här som är det häftiga med Kanban-metoden. Det finns inga gränser för vad vi kan göra med den, och vi har knappt börjat skrapa på ytan...
Kanske kommer vi en dag att tillämpa Kanban på Agile Consultants arbete. Vi är verkligen en kunskapsarbetsdomän med många variationer. Vi har verkligen problem med flödeskontroll. Kanske i 2012.
![En global plan för hantering av samarbetsarbete [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
