Mitt första jobb efter examen var på Kockums Computer Systems AB (KCS). Kockums körde SAAB datorer redan tidigt på 60-talet och under många år framåt. När Kockums varvsverksamhet lades ner i mitten av 80 talet, ungefär samtidigt som jag började på KCS, var man troligen värdsledande avseende hur man tog hjälp av datorer i produktionen av stora fartyg.
Nyckeln till Kockums framgång var det modelleringsverktyg som började tas fram redan på 60 talet och sedan utvecklats successivt och fortfarande används på varv runt om i världen med stor framgång. Systemet utvecklas vidare än idag av Aveva som numera äger fd KCS. Konkurrensen har kommit från stora företag med enorm kapacitet men de har fel arkitektur i mjukvaran. Kockums framgångar grundades i deras syn på hur man skulle styra produktionen och tillverka med bra precision och kvalitet till ett kostnadseffektivt pris. För att göra detta så ritade man inte båtar på ett traditionellt sätt som konkurrenterna gjorde utan i stället byggde man en modell av fartyget i datorn och utifrån den producerades ritningar vid behov. Fördelen var att man också fick ut underlag för när material skulle beställas, hur plåtar skulle brännas, rör krökas osv. Konkurrenterna försökte kopiera idéerna med eftersom de byggde sina CAD/CAM system på ritningar kom de aldrig i närheten av de möjligheter som fanns och fortfarande finns i Kockums system. Här är en bild som visar hur komplicerade dessa konstruktioner var.
Att använda dessa idéer från KCS har länge funnits i mina tankar. Jag har skissat och gjort prototyper på projektledningsverktyg där projektet modellerats och sett vilka fördelar detta har haft jämfört med MS Project eller ärendehanteringssytem som JIRA. Framförallt minskar det behovet av uppföljninsmöte. Informationen är aktuell och inte någon vecka gammal som när man samlar in informationen manuellt. Vidare så främjar det transperans inom företaget. Denna tradition av modelleringsverktyg har spritt sig i Malmö och nu finns det ett färdigt Agile Collaboration Tool (ACT) som ger precis de fördelar som ett modelleringsverktyg i teorin ger jämfört med andra arkitekturer.
Jag har tagit på mig att missionera för verktyget eftersom jag brinner för att effektivisera arbete i projekt med mjukvara. Speciellt intressant är verktyget om man dessutom utvecklar hårdvara då den agila världen inom mjukvara måste ta hänsyn till tillverksningstid för hårdvara. Tillsammans med ett antal personer som arbetar med förändringasarbete och utbildning vill jag lyfta svensk projektledning inom mjukvara ännu ett steg.
För att kunna driva större projekt agilt krävs ett ramverk som stöttar inte bara ett eller ett fåtal team som t ex SCRUM gör. Det finns flera ramverk som SAFe eller less men vilket processverktyg man använder sig av eller om man har tagit fram ett eget spelar mindre roll eftersom vi hjälper er att anpassa processer och verktyget till hur ni vill arbeta.
Några typiska situationer som jag som ledare i ett utvecklingsbolag vill ha stöd för är;
- Om något team planerar att leverera efter den tidpunkt som är absolut sista datum för att releasen skall kunna skeppas i tid enligt roadmappen jag tagit fram.
- Om ett team blir försenat och måste senarelägga ett arbetspaket hur slår det på alla andra team, vilka beroenden har jag att ta hänsyn till.
- Hur ligger teamen till jämfört med varandra. Ligger något team bra till vill jag antagligen antingen flytta resurser till det som ligger efter eller kunna flytta ett arbetspaket till det team som ligger bra till.
- ”What-if” analyser. Vad händer om jag vill leverera denna feature tidigare? Klarar vi det? Eller vad händer om jag minskar/hökar kapaciteten i ett team? Hur slår det på leveranserna? Vilken marginal har vi för de releaser vi vill skeppa? Om jag tidigarelägger en release några dagar eller en SPRINT vilka arbetspaket hinner vi då inte med?
Produktledningen kan alltså sätta ramarna för projektet medan teamen kan prioritera innanför dessa ramar. Så länge de inte går utanför ramarna så har de full frihet att arbeta efter egna beslut. Skulle några konflikter uppstå belyser verktyget dessa och företaget kan ta tag i dessa konflikter.
Några exempel på hur ACT presenterar de två första av ovanstående:
Här ser produktledningen att ett team inte kommer att leverera i tid för release R9:
Samtidigt får teamet en varning om att de inte levererar enligt vad roadmappen förväntar sig:
Ett team har senarelagt en leverans vilket innebär att ett annat team påverkas. Så här ser teamet som är försenat hur det påverkar andra:
Här ser teamet som påverkas att de är beroende av något som de förväntar sig leverans tidigare än de kan få:
En svårighet med att hålla projektplaner uppdaterade är att samla in informationen och uppdatera planerna. Ofta har jag planerat i MS Project men när väl projektet börjat rulla på så övergav jag successivt projektplanerna eftersom de inte hjälpte mig i mitt arbete. Jag vill gärna ha ordning men är för lat för att lägga all den tid som krävs för at hålla dem uppdaterade.
Ett verktyg skall alltså ge stöd för att hålla planerna uppdaterade. Framförallt bör statusen på olika aktiviteter bara behöva anges på ett ställe och sedan vara tillgänglig och användas överallt. Här ser jag fördelar med att integrera projektverktyget med det av företagets använda ärendehanteringssystem som t ex JIRA. Då får ACT kontinuerligt uppdaterad information om statusen på olika ärende och ACT ger då projektledningen en bild av projektet i realtid. Och framförallt detta utan att det krävs en detaljerad daglig uppföljning av allt som händer i bolaget. Ledningen och utvecklarna kan koncentrera sig på strategiska analyser av de problem som alltid uppstår samt på att utveckla programvara.
Jag hoppas att jag lyckats åskådliggöra för er som tagit del av min blogg hur ACT fungerar och varför jag personligen finner verktyget så intressant.