Baxter är ett globalt medicintekniskt bolag (ca 50 000 anställda) som tar fram produkter och tjänster som räddar och upprätthåller liv. Avdelningen för Critical Care är huvudsakligen baserad i USA, Sverige och Italien De utvecklar bl a dialysmaskiner, en verksamhet som delvis har sitt ursprung i Gambro som förvärvades 2012.
I samband med att Baxter inledde arbetet med en ny dialysmaskin ville de även börja arbeta mer agilt. Att applicera agil utveckling ”by the book” var däremot aldrig ett alternativ. Baxter behövde ta hänsyn till att utvecklingen bedrivs på olika platser och att den inkluderar både mjuk- och hårdvara. De behövde även uppfylla kraven som standarder för cyber- och funktionell säkerhet ställer, krav som inte alls går i linje med agila principer.
Baxter såg en utmaning i hur de skulle kunna skala upp utvecklingen. De hade redan tillämpat scrum i mindre projekt, lokalt, men nu skulle de utgöra åtta team utspridda både i Sverige och Italien. Hur skulle de kunna väva samman två så olika discipliner som system och hårdvara, med sina vitt olika cykler för styrning och beslut. En annan svårighet låg i de implicita kraven på vattenfallsutveckling som ställs i standarden för funktionssäkerhet, IEC 62304.
Addalot bidrog med en agil coach som under perioder även agerade som tillförordnad projekt- och teamledare. Målet var att etablera ett effektivt (och agilt) arbetssätt som levde upp till standarden IEC 62304. Genom utbildning och coachning av scrum masters, linjechefer och utvecklingsteam etablerades en fördjupad och gemensam bild kring agil utveckling, över hela linjen.
Lösningsorienterade som Addalot är, kunde de med sin omfattande erfarenhet av utvecklingsflödet snabbt fånga och ta tag i de problem som fanns.
Ivan Fulöp, Linjechef och projektledare för NextGen SW
Av alla de aktiviteter som förändringsprojektet bedrev var implementationen av följande centrala mekanismer essentiella för projektets framgång:
- Tydliga utvecklingscykler – 12 veckors inkrement med 2-3 veckors sprintar och väl definierade tillfällen för interaktion med andra discipliner.
- Planering på flera nivåer – långsiktigt, inkrementellt och på sprint-nivå
- Inkrementplanering – alla features, beroenden och intressenter för ett inkrement visualiseras fysiskt
- Krav utvecklas löpande – men alltid klara till att en feature skall börja utvecklas. Krav skrivs av arkitekter men granskas av både system och utveckling för att säkerställa korrekthet och framgångsrik överlämning
- Feature-ansvariga – ny roll för att hantera beroenden mellan team som pga kompetens är tvärfunktionella
- Feature-samordning – Gemensamma uppstarts- och stängningsmöten för nya features (med ansvariga från System och Verifiering)
- Dagliga systemmöten – varje dag håller systemavdelningen en informations- och frågestund
- Kontinuerlig integration med krav på kvalitetssäkring – incheckning av kod varje dag. Koden måste ha genomgått utvecklartest, enhetstest, integrationstest och kodgranskning
- Kontinuerliga regressiontester – utforskande och automatiserade tester av huvudgrenen för systemet, innefattade bl a simulerade dialyscykler
- Demo på inkrement-nivå – storskalig demo av ett inkrement där alla intressenter får en gemensam bild av projektets framsteg
Förbättringsprojektet levde upp till målet om ökad effektivitet. Utan att göra avkall på funktionssäkerheten demonstrerades resultat som kortade ledtider från krav till implementerad feature. Framför allt förbättrades dialogen, inte bara mellan de olika mjukvaruteamen utan även med och mellan discipliner som produktledning och verifiering. Detta, i sin tur, ledde till färre problem vid överlämning. Som en positiv följdeffekt inspirerades även andra delar av organisationen (Hårdvara och Verifiering) att påbörja sin resa mot att arbeta mera agilt.