CMMI förbättrar agila organisationer

Låt oss syna programvaruutveklingen i ett historisk perspektiv för att bättra förstå sammanhanget. I begynelsen - dvs femti-, sextitalet fanns tejp, hålkort och monolitiska system skrivna av ett fåtal programmerare. Allt eftersom systemen växte insåg man behovet av större team, vettig uppdelning av system (idag kallat arkitektur) och en mer eller mindre stabil process för att underlätta kommunikation mellan alla inblandade. Det var i denna period som vattenfallsmetoden såg dagens ljus. Den ursprunglia CMM® (Capability Maturity Model) togs fram och användes i denna miljö. Men teknologin stod inte still, och vi fick timesharing, snabbare processorer, IDEs (integrerade utvecklingsmiljöer) som alla  ledde till att man kunde använda flexibla och snabbare metoder för att utveckla program. Det så kallade ”Agile Manifesto” publicerades i februari 2001. Sedan dess har ”Agile” blivit och är alltjämt ett ”buzzword”. Fler och fler organisationer påstår att de använder agila metoder, men om man synar mer ingående så kan ”agil” betyda i stort sett vad som helst. Tyvärr tog det tid innan flertalet användare av CMMI® (Capability Maturity Model  Integration) kunde släppa de mer rigida tolkningarna. Följaktligen påstod många agil-konsulter att agil var motsatsen till CMMI, vilket i mitt tycke var och är en del av säljsnack och ”hypen” kring agile. (Jag avstår från att kalla det alternativa fakta.)

Numera finns en växande förståelse för vad CMMI är och hur Agile och CMMI kan stödja varandra. CMMI talar om vad man borde ha för effektiv progamutveckling, inte hur saker o ting skall göras. En del av problemet är att många CMMI-konsulter hade (och kanske fortfarande har?) snäva tolkningar av hur CMMI skall implementeras. T.ex. säger CMMI att man bör ha en plan för sitt arbete innan man börjar arbetet. En snäv tolkning av detta har lett till tjocka MS Word-dokument där hela projektutvecklingen är planlagd. Men ur CMMI-perspektivet är det helt OK att successivt planera för korta perioder, en dag, en vecka eller en sprint. 

CMMI Institute (som numera förvaltar CMMI) har nyligen gett ut en guide som heter ”A guide to SCRUM and CMMI: Improving Agile Performance with CMMI”. Syftet med guiden är att belysa vilka agila tekniker som uppfyller CMMI-förväntningarna och hur Agile och CMMI kan stödja varandra. Egentligen är det mer än enbart SCRUM som guiden täcker, men troligen är någon variant av SCRUM den mest spridda agila tekniken.

Guiden skrevs med bidrag från 12 lead appraisers som alla har erfarenhet av att ha genomfört appraisals i agila organisationer. Dessutom skickades den ut till organisationer som har nära samarbete med CMMI Institute (s.k. partners) för granskning.

Ett 20-tal olika agila-begrepp finns förklarade tillsammans med villka CMMI-områden och vilka practices som är relaterade till det agila begreppet. Guiden riktar sig till två olika målgrupper:

• Organisationer som vill införa både Agile och CMMI för att kunna sprida Agile till flera grupper inom organisationen och dra nytta av högre kapabilitet och mognad. SCRUM och de flesta andra agila metoder fokuserar på det enskilda teamet. För 15 år sedan sa många agil-team att de inte kunde tala om när utvecklingen skulle vara klar – ”you’ll get it when you see it”. Det gör samarbetet med andra grupper t.ex. hårdvaruutvecklare, produktion och marknadsavdelning besvärlig. Det har också visat sig svårt att skala upp agila implementationer. CMMI get stöd för  hur dessa problem kan lösas och hur erfarenheter som ett team gör kan spridas till andra team. Med andra ord hur man åstadkommer balans mellan flexibilitet och struktur.
• Lead appraisers som vill veta hur man ska utvärdera vad ett agil-team gör i förhållande till CMMI. Jag  belysar med ett annat exempel: En viktig practice inom CMMI är kodgranskning för att hitta och rätta till logiska fel i koden. Agila tekniker såsom pair programming och eventuellt också daily stand-ups med diskussion om koden, kunde mycket väl vara tillräckligt för att uppfylla CMMI-förväntningar. Men det beror på hur dessa tekniker implementeras. Hur ofta görs pair progamming? Hur bestämmer man när pair progamming ska användas?  Hur ofta genomför man granskning av en kodsnutt under stand-up mötet? Om man bestämmer att några skall köra granskning senare under dagen, kollar man att det blev gjort? 

Ladda gärna ner guiden, den är 132 sidor lång. Men låt inte antalet sidor förskräcka. Den är luftigt utformad med flera bilder, till skillnad från de ”tekniska rapporter” som publicerades förr i tiden. Jag rekommenderar att man först bläddrar igenom guiden och sedan använder den som ett uppslagsverktyg. En bra innehållsförteckning och pdf-formatet gör sökningen enkel.
Trevlig läsning!