Bakgrunden till Agile 360
I början på 90-talet så skapades en rörelse som en reaktion på den enorma ledtiden från att man definierat krav och behov till leveransen av de tekniska lösningar som skulle lösa problemen. Den vanligaste projektmodellen kallades för vattenfall och innebar att man först definierade kraven, därefter skapade designen för att sedan påbörja utveckling och test. Många gånger så hade kraven förändrats under den långa ledtiden och ofta så lades projekten ned eller så visade det sig vid leveransen att den slutliga produkten inte uppfyllde dagens krav.
Den rörelse som kom att kallas “The Agile movement” ville definiera ett nytt sätt att hantera hela processen och definierade därför ett antal grundläggande principer.
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan“That is, while there is value in the items on
the right, we value the items on the left more.”
Det agila synsättet vann snabbt mark och många företag satte en ära i att vara “Agila” och snabbfotade. Med tiden började man dock se sprickor i metoden, eller kanske snarare hur man använde den.
Jag har stött på många projekt där man förenklat och hoppat över grundläggande spelregler i det agila ramverket (på engelska kallar man det för “Scrum-but” till exempel “Yeah, we do Scrum BUT we don’t do daily stand-ups”). I vissa projekt har det till och med gått så långt att man kastat hela regelboken överbord och snarare arbetar ad-hoc än agilt och så fort man ställer några som helst frågor om t ex dokumentation så möts man av motargument som “App, app app..working software over comprehensive dokumentation….” Eller som en projektledare uttryckte det “vi har inga dokumenterade krav, vi har jobbat agilt..” båda exemplen är rejäla vantolkningar av det agila manifestet.
Resultatet av cowboy-mentaliteten blir ofta sena leveranser, problem med skalbarhet och dessutom en enorm teknisk skuld som oftast inte märks förrän det är alldeles för sent, eller som Alistair Cockburn uttrycker det:
“If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit.”
Alistair Cockburn –Initiator of the Agile Movement, 2003
Agilt med ordning och reda
Tanken på en Agil leveransmodell föddes under en period då jag arbetade med att migrera integrationsplattformar. Det man fick börja med var alltid att leta efter aktuell systemdokumentation. Ibland hittade man brottstycken av information på någon gemensam filarea eller någon Sharepointsite. När man väl hittade dokumentationen så insåg man ofta att den skrevs av införandeprojektet för 5 år sedan och inte uppdaterats sedan dess, den praktiska nyttan var noll även om man vid överlämnandet hade haft en hög ambitionsnivå.
Agile 360 skapades med en idé om en leveransmodell som innebar “Agilt med ordning och reda” en lättviktig leveransmodell utan en enorm massa komplexa mallar och dokumentation som ändå ingen läste eller orkade uppdatera. Modellen skulle också hantera hela livcykeln från krav och behov till test och implementering samt överlämning till förvaltning. Den skulle dessutom fungera ihop med andra ramverk som ITIL, CMMI och PM3 etc.
Vad innehåller Agile 360
Agile 360 är en modell för att driva effektiva agila projekt genom att använda Atlassians produktsvit och verktyg som Confluence och Jira, modellen består av:
- Konfigurering av JIRA och Confluence
- Koppling till CMMI, Cobit och andra ramverk
- Integrerade verktyg för krav, test och utveckling
Genom att använda modellen uppnår ni följande:
- Kortare startsträcka för nya projekt
- Erfarenhetsutbyte mellan projekt
- Ständig förbättring (Kaizen)
- Mindre administration med integrerade verktyg
- Tydligt ägarskap och ansvar
- Spårbarhet och kvalitetssäkring i utvecklingsprojekt
Bärande principer
Den grundläggande principen (och anledningen till att modellen heter Agile 360) är att du oavsett var du står någonstans skall kunna ha en 360-graders vy av informationen. Med det menas att du alltid skall kunna ha full spårbarhet, från krav till stories och tasks, till incheckad kod, till testfall och rapporterade defekter , kort sagt, vart du än vänder dig så skall du kunna spåra artefakter till varandra.
För att möjliggöra detta utan att drunkna i dokumentation och processer finns ett antal grundläggande principer.
- Information existerar i ett sammanhang
- Dokumentation är en del av produkten
- Information skapas EN gång på EN plats
- Informationen är lättillgänglig
- Dashboard och vyer skapas för olika informationsbehov
Agile 360 införande
Agile 360 är en lättviktig modell och du behöver inte införa alla delar på en gång men för att börja i rätt ände så rekommenderar jag verkligen att du bokar något som kallas för en “assessment interview” där vi går igenom styrkor, svagheter och utmaningar som ni har idag. Därefter får ni en plan för vad det är ni i första hand bör fokusera på att förbättra.
Agile 360 finns både som självstudiematerial i form av digitala kurser och man kan även köpa stöd för införande och coachning. Oftast blir en mix av båda delar bäst.
Läs mer om kurserna på kurssajten