Agil utveckling. detta måste du ha koll på för att överleva. Hur få chefen att fatta? Konsten att involvera kunden Agilt på distans

Transkript

1 Nr 3 december 2012 Ett magasin från Combitech AB Agil utveckling detta måste du ha koll på för att överleva Hur få chefen att fatta? Konsten att involvera kunden Agilt på distans

2 Nr 3 december 2012 Redaktionen Ansvarig utgivare Marie Bredberg Redaktionsråd Nr Charlotte Magnusson Göran Carlzon, Erichs Communications Göran Ekberg Dulce Goncalves Redaktör Stina Svensson Nätvariant av OnTime Läs tidigare nummer av OnTime på Ett magasin från Combitech AB Agil utveckling detta måste du ha koll på för att överleva Hur få chefen att fatta? Konsten att involvera kunden Agilt på distans OnTime är en branschtidning som tar upp olika aspekter av teknik och samhällsutveckling. Varje nummer har ett speciellt tema som sätter lite extra fokus på ett utvalt område. Combitech Linköping Box Linköping (Besöksadress: Universitetsvägen 14) Jönköping Box Jönköping (Besöksadress: Änkhusgatan 9) Växjö Ljungadalsgatan Växjö Övriga orter: Arboga, Borlänge, Enköping, Göteborg, Helsingborg, Hässleholm, Jönköping, Karlstad, Kista, Kristianstad, Linköping, Malmö, Norrköping, Norrtälje, Växjö, Skövde, Sundbyberg, Trollhättan, Uppsala, Västerås, Östersund, Oslo, Stavanger. Temaintro: Konsten att involvera kunden 3 Den agila verktygslådan 5 Case FMV: Den agila resan 6 Vattenfall vi minns 8 Varför ska vi arbeta agilt? 9 Direkt från Scrum Gathering i Barcelona Case Scania: Mellancheferna måste förstå den vardag första linjens chefer lever i 12 Case Saab: Team byggdes upp på två kontinenter utifrån personliga egenskaper 14 Case Linköpings universitet: Driver studenterna att tänka mer självständigt 16 Nyheter från Combitech 18 E-post info@combitech.se Hemsida Produktion Erichs Communications AB, Linköping Text där annat ej anges: Göran Carlzon och Kent Olofsson. Grafisk design Capo Marknadskommunikation AB Tryck Larsson Offsettryck AB Combitech är ett obundet konsultföretag som med hög kompetens och kontinuitet skapar stor kundnytta genom att tillhandahålla värdefulla och innovativa lösningar som kombinerar teknik, miljö och säkerhet. Kunderna finns inom branscherna försvar, flyg, telekom och säkerhet samt myndigheter med ansvar för skydd av flöden i samhället. Närheten till våra kunder är viktig. Därför finns Combitech på ett 20-tal orter i Sverige och Europa. Vi är runt 1200 medarbetare och ingår i Saab-koncernen - ett av världens ledande högteknologiska företag med huvudsaklig verksamhet inom försvar, flyg och rymd.

3 Temaintro Konsten att involvera kunden En av de grundläggande idéerna bakom agila metoder är att skapa värde för kund. Detta är delvis ett arv från Lean-konceptet som också sätter kunden i fokus för att därigenom skapa värde. Så varför är det då så viktigt att involvera kunderna? Jo, bättre service till kunder resulterar ofta i högre omsättning, högre vinster och ett högre värde i de långvariga kundrelationerna. det finns flera olika agila metoder man kan använda sig av. Gemensamt för de agila metoderna är dock det agila manifestet ( Individer och interaktioner framför processer och verktyg Fungerande programvara framför omfattande dokumentation Kundsamarbete framför kontraktsförhandling Anpassning till förändring framför att följa en plan När man läser det agila manifestet märks en tydlig kundorientering och det går att koppla det till ett antal viktiga fördelar: iteration, ständigt lärande och elimination av waste. Iteration Kunden har möjlighet att påverka inriktningen på projekten kontinuerligt, vilket ökar möjligheterna att kunden blir nöjd med resultatet. Ständigt lärande Det är viktigt att man är öppen för feedback både från kunden och internt. Feedback bidrar till att utveckla och internt förmedla kompetensen inom bolaget, samt kritiskt granska den egna insatsen i projekt. Genom att kunden ges tillfälle att lämna feedback på arbetet skapas ett förtroende och en känsla av engagemang. Kollaboration i arbetet sprider kunskap internt och leder i högre grad till en gemensam syn. Elimination av waste Att eliminera aktiviteter och arbete som inte skapar värde för kund visar på ett ansvarsfullt sätt att hantera resurser vilket ökar kunders förtroende. Huvudsyftet är att leverera värde snabbt och tidigt i projekten. Men hur vet man vad som är av värde? Förutom att ha en god kommunikation med uppdragsgivaren är det slutanvändarna som kan avgöra om det som levereras i projektet är av värde. Genom att minska skuldbeläggandet av slutanvändarna och betona att systemen finns där för att serva dem och inte tvärtom finns det en större sannolikhet att systemen kommer att användas oftare och effektivare. Fördelarna med att anpassa produkter leder också till minskade support- och utbildningskostnader. Agilt behovsarbete Varifrån kommer de riktigt goda idéerna? Idéerna som ger upphov till produkter och tjänster som vi sedan inte vill leva utan, fastän vi från början inte var medvetna om att vi behövde dem? Att kläcka en riktigt bra idé kan verka handla mest om tur, men gemensamt för alla goda idéer är att de skapar nytta och mervärde. Nyttan uppstår i användandet, och för att vi ska tycka om, eller till och med

4 älska, en produkt eller tjänst måste den tillfredsställa våra behov. Och det är aldrig så enkelt att man kan nöja sig med att fråga människor vad de vill ha för att få veta deras behov. Det finns explicita behov som vi är medvetna om och kan berätta om, men det finns också synliga och latenta behov som vi oftast inte själva är medvetna om. I agil systemutveckling, liksom i all annan typ av utvecklingsarbete, måste man förstå behoven för att kunna skapa produkter och tjänster som ger nytta. En av utmaningarna med att arbeta agilt är att hitta snabba och smidiga metoder som fungerar när man arbetar i korta iterationer. För att få reda på människors explicita behov finns olika typer av intervjutekniker som man kan använda sig av, men för att få en komplett bild av behoven räcker det inte att bara prata med människor. Oftast ger det mer att ge sig iväg från sitt kontor och gå till den fysiska platsen där nyttan ska uppstå för att observera. Inom Lean Manufacturing kallas detta för att gå till Gemba. De japanska tecknen för Gemba Platsen där det händer Gemba är ett japanskt uttryck som direkt översatt betyder platsen där det händer eller den verkliga platsen. Toyota är ett av de företag som praktiserar Lean Manufacturing och där genomför ledningen regelbundet s.k. Gemba walks på fabriksgolvet som ett led i arbetet med ständiga förbättringar av produktionsprocessen. Principen är att problem är synliga och måste observeras för att kunna åtgärdas, vilket går att applicera även på systemutveckling. Då blir Gemba platsen där produkten eller tjänsten används och det är dit man måste gå för att identifera problem och förstå behoven hos sina användare. Gemba walks är ett enkelt sätt att öka förståelsen för användningssituationen och främja kreativiteten för att kunna komma på nya smarta lösningar. Effektkarta ger tydlig målbild När man fått en god översikt av behovsbilden och eventuella problem i ett utvecklingsprojekt är det nödvändigt att stanna upp och fundera över vad syftet med arbetet är och vad man vill uppnå. Ett bra verktyg för detta arbete är en effektkarta, den ger en tydlig målbild som är lätt att förstå för alla intressenter. I centrum på en effektkarta finns syfte och effektmål som svarar på varför man ska genomföra utvecklingen och vilka effekter man vill skapa. Skillnaden mellan effektmål och traditionella projektmål är att ett projektmål syftar till det som projektet ska leverera, t.ex. ett IT-system, medan effektmålen beskriver förväntad effekt i verksamheten, såsom lönsamhet, kvalitet eller kundnöjdhet. Underlättar kommunikationen Under syfte och effektmål kommer målgrupperna som beskriver vem man genomför förändringen för. Målgrupperna kompletteras med användningsmål som beskriver vad målgrupperna har för behov. Man kan sedan komplettera kartan med åtgärder som handlar om hur man ska kunna tillfredsställa målgruppernas behov och skapa de effekter man önskar. I effektkartan visualiseras såväl kundens som slutanvändarens behov på ett tydligt vis, vilket ger samsyn och underlättar kommunikationen i arbetsgruppen. Den här tidningen är fylld med tips, råd och berättelser om hur andra har gjort när de gått över till att arbeta agilt. Sådant som du helt enkelt behöver veta för att överleva i en agil miljö. o Sara Lerén User Experience Specialist Certifierad Scrum Product Owner Sara Edling Agile Coach Certifierad Scrum Product Owner Dulce Goncalves Manager JidokaQ Agile Coach Några av medlemmarna i Combitechs JidokaQ-enhet. Gruppen arbetar bland annat med agila åtaganden, coachning, utbildningar, inspiration och nätverkande. Carmen Perezic User Experience Specialist Certifierad Scrum Master 4 OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva.

5 Test Krav Fortran COBOL BASIC SIMULA PASCAL ADA C C++ JAVA.NET C# J2EE talet Objekt- 80-talet UML (1994) RUP (1998) talet Den agila verktygslådan Vill du läsa mer om grunderna i agil utveckling? Ta då en titt på tidigare temanummer i samma ämne, Den agila verktygslådan. du hittar numret på se/ontime. Där finns alla gamla nummer och en hel del extramaterial som aldrig är publicerat i tidningen. Här är några smakprov från nummer 2, 2009: Ett magasin från Combitech AB Ger insikt i tid Tema: Den agila verktygslådan Nr 2 juni 2009 Agila metoder skapar ett oslagbart engagemang Text: Göran Carlzon Hitta balansen i Scrum-arbetet reportage från Motorola När Scrum infördes på Motorola blev det nästan som en religion och helt plötsligt skulle allt lösas med den metodiken. Efter hand har en mer balanserad syn infunnit sig. Läs intervjun med Henrik Gidmark för att se hur Motorola gjorde för att hitta rätt väg. För oss har det varit jätteeffektivt att arbeta agilt, konstaterar Fredrik löving, som är projektledare på spelutvecklaren Dice. Fredrik och hans utvecklingsteam har lång erfarenhet av utveckling i Scrum och kan idag inte tänka sig att arbeta på något annat sätt. VI JOBBAr JuST nu med ett alldeles inte någon som står och skriker vad vi nytt spel. Det är så hemligt att jag inte måste hinna, som det ofta kan vara i ens kan berätta vad det handlar om, Dice börjar med att sätta upp en så mer traditionella metoder, utan teamet berättar Fredrik Löving. Men jag kan kallad Product Backlog. Det är helt lovar att de ska ha färdigt en viss del från förklara exakt hur vi arbetar och varför enkelt en todo-lista som börjar med todolistan till nästa gång. det är så viktigt för oss att arbeta agilt. vad som är mest värdefullt för kunden Teammedlemmarna avgör alltså Ett nyckelbegrepp inom Dice är Fun och slutar med det som är minst viktigt. själva vad de kan klara på en iteration. Factor. Om någon del av spelet inte är Sedan genomför Dice något de kallar för Det är projektledarens ansvar att se till spännande eller roligt för spelarna har Planning Poker. De samlar 4-5 personer, att inget eller ingen stör. det inte något berättigande. Med succéer som Battlefield och Mirror s Edge och en projektledare och läser upp alla som utövar påtryckningar, exempelvis till exempel en kodare, en animatör - Ibland kan det vara externa faktorer bakom sig är förväntningarna stora på todo-punkter. Några punkter väljs ut kunden. Men då måste jag säga nej. den internationellt välrenommérade och poängsätts i förhållande till hur De måste vänta tills iterationen är klar. studion i Stockholm. komplexa de är relativt varandra. Sedan Arbetssättet är väldigt flexibelt när det Det är lätt att säga i förväg att något fortsätter gruppen med att relatera alla gäller vad vi ska göra, men när vi väl kommer att bli kul, men en annan sak todo-punkter tills hela Backlogen är bestämt oss för en iteration får inget att prova, känna och klämma när det väl poängsatt utifrån sin komplexitet. komma emellan innan den är klar. Det är framme. Då kanske det inte alls känns När hela listan är estimerad börjar arbetet på riktigt. Fredrik Löving berättar: skulle skapa osäkerhet och störa rytmen. lika roligt längre. Om man i det läget har lagt ner tre års utveckling så kan det - Vi jobbar i tvåveckorscykler. Det vara ganska tufft att få kasta allt i papperskorgen. Därför jobbar vi istället med vecka per iteration är för lite, då tycker på 15 minuter. Alltid samma tid varje är något vi har provat ut noggrant. En - Varje dag har vi ett Daily Scrum-möte tvåveckors iterationer, vilket innebär att jag att det läggs för mycket tid på att planera. Vi har även provat att ha fyraveck- vi går laget runt. Alla ska svara på tre morgon. Det är ett stående möte där vi i värsta fall inte skulle behöva slänga mer än två veckors jobb. orscykler, men vi gick över till två veckor, frågor: vad gjorde jag igår, vad ska jag Vattenfallsmetoden har fungerat i för då kan vi testa tillräckligt ofta utan göra idag och viktigast: är det något som en värld som inte är så föränderlig, fortsätter Fredrik Löving. En stol förändras annans arbete hänger på dig, eller vad att ha för mycket administration. hindrar mig? Alla ska veta om någon inte så mycket från skiss till slutprodukt. du behöver av andra för att själv komma Om vi på Dice skulle arbeta så skulle planerna inte höra ihop med verkligheten. iteration bryts varje todo ner i detalj för På planeringsmötet som inleder varje vidare. Inom spelvärlden händer så mycket och första gången. Teamet benar ut exakt vad så snabbt att något som är nytt och hett som ska göras och sätter sedan timmar - Efter två veckor har vi Iteration Review. blir gammalt och tråkigt på kort tid. på det. Det låter mer formellt än vad det är. Att utveckla ett nytt spel kan ta mellan två och fyra år. I var och en av alla teamet som committar. Det är inte dator. Alla får visa upp vad de har gjort - Det är viktigt att säga att det är Det kan vara att vi samlas runt någons faserna (se separat faktaruta) används jag som projektledare som säger vad och alla kommer med feedback. Utifrån Scrum. som ska göras. För mig är det en otrolig synpunkterna kan vi göra urval och dra I praktiken går det till så här: skillnad. Och en stor fördel. Det är lärdomar. Det är också här vi presenterar måndag vecka 1: Planning Poker spelet där alla vinner under tiden Fredag vecka 2 för kunden de framsteg vi har gjort. I en så kallad Sprint Retrospective går teamet igenom vad som kan förbättras och vad som var bra. - Vi lyfter fram det positiva, poängterar Fredrik Löving. Det är viktigt att det här blir en rolig stund. Vi ska få känna stolthet över vad vi har gjort. Efter genomförd review och retrospective är det dags för en ny Planning Session på måndagen. Skapar ett otroligt engagemang Antalet poäng som klaras av i varje iteration går snabbt upp i början. Alla lär sig hur mycket de kan ta på sig, processerna blir bättre och man arbetar allt effektivare tillsammans. Risken för att någon teammedlem ska ta på sig för lite uppgifter, för att sedan sova bort halva tiden, är däremot liten, enligt Fredrik Löving. Alla vet vad du har gjort och kommer att göra. Om du varje morgon säger samma sak så blir det ganska uppenbart om du inte tar din del. Dessutom är risken liten att hamna där. Den här Dice spelutveckling genomförbart och vilken teknik är uppdelad i fem faser. som ska användas. Här kollas också spelets Fun Factor är Allt inleds med en konceptfas, det kul? Värt att satsa på? Om där den grundläggande idén det blir grönt ljus följer sedan presenteras, men utan att gå produktionsfasen, där ett större närmare in på detaljer, en vision. team samlas och alla tänkbara I nästa fas, Design and Planning tar man fram en plan på hur helt enkelt om att iterera och frågetecken rätas ut. Det handlar man kommer att leverera produkten. Här är det också viktigt - Sedan skulle många säga göra färdigt. att man benar ut mer exakt vad att de var klara, hävdar Fredrik produkten är. Löving. Men då går vi över i Därefter inleds First Production, där en liten, men helt som en ledande studio i världen Polish-fasen. Eftersom vi vill ses spelbar del av spelet byggs. så fortsätter vi ytterligare en nivå Här granskas om konceptet är innan vi släpper spelet. Man vill varje morgon kunna säga att man avslutat något. Det är lite prestige i det. Metoden att arbeta agilt är faktiskt som starkast när det är tufft, med tight deadline. Folk jobbar längre och sitter kvar på kvällarna om det krävs. Finns det då inte en stor risk att teammedlemmarna istället bränner ut sig själva? Projekten är otroligt långa, konstaterar Fredrik Löving. Det är nödvändigt att det fungerar hela vägen. Det du gjort klockan tre på natten blir dessutom inte lika bra. Därför är det min roll som projektledare att se till att teammedlemmarna inte hamnar i en sådan situation. lätt att beräkna tiden för hela projektet Det blir efter ett tag en väldigt tydlig trend hur många poäng teamet presterar per iteration, därför blir det också lätt att beräkna tidsåtgången för hela projektet. Frå n spelet Mirror s Edge utvecklat av svenska DICE. Det är viktigt att varje Iteration Review innebär ett avslut, enligt Fredrik Löving. - Vi ska ha en potentiellt skeppbar produkt i slutet av varje iteration. Inget fulhackande är tillåtet. Det funkar lokalt på min dator är inte godtagbart. I princip ska vi se det som en slutleverans var fjortonde dag. 8 OnTime nr 2/09 Agila metoder - Vi levererar exempelvis 14 stories Säg att vi då får poäng. Genom att dela med 37 får vi fram hur många iterationer vi behöver för att genomföra projektet som det ser ut just då. Eftersom varje iteration är två veckor vet vi metoden skapar ett otroligt engagemang. på totalt 37 poäng under en normal också hur lång tid det tar. Detta är något som konstant måste uppdateras då det Spelutvecklaren Dice måste arbeta agilt För Fredrik Löving och hans utvecklingsteam har Scrum blivit en absolut självklarhet. I reportaget fick vi veta i detalj hur arbetet planerades och lades upp. Teamet arbetade som mest intensivt med ett nytt spel som snart skulle lanseras. OnTimes reportageteam fick strikta order om att inte avslöja vilket spel det var. Kan du så här i efterhand identifiera spelet? TEmAInTrODuKTIOn Den agila verktygslådan Agila metoder Text: Erik narby / magnus Skoog Att utveckla mjukvara är svårt. Sedan mjukvaruutvecklingens begynnelse har utvecklare, projektledare och företag bittert fått erfara detta faktum. mjukvaruutvecklingsprojekt blir ofta försenade, kostnaderna skenar och många projekt lyckas inte leverera det kunden vill ha. lika länge som detta har varit ett faktum har man försökt att komma till rätta med problemet. under ÅrEnS lopp har en lång rad av verktyg, programmeringsspråk och metoder presenterats som den avgörande lösningen. Värda att nämna är bland andra FORTRAN, strukturerad programmering, objektorienterad programmering, RUP och UML. Alla dessa har bidragit till att förändra hur vi utvecklar mjukvara idag men ingen av dem har visat sig vara Lösningen med stort L. I detta nummer av OnTime reflekterar Ivar Jacobson kring dessa frågor på ett träffsäkert sätt. Senast i raden av metoder är de agila metoderna som är den hetaste trenden inom system- och mjukvaruutveckling just nu. Agila metoder är en reaktion på klassiska arbetssätt inom system och mjukvaruutveckling. Att jobba agilt är att vara mer lättrörlig. Man försöker höja gruppens effektivitet och frigöra kreativiteten. Man ser till människan snarare än till tunga processer och verktyg. Så vad innebär egentligen agil utveckling? För att förstå det krävs en liten tillbakablick. Vattenfallsmodellen Vattenfallsmetodiken togs inledningsvis fram under slutet av 60-talet för mjukvaruutveckling inom aerospaceindustrin. Att jobba enligt en vattenfallsmodell kan göras mer eller mindre strikt. Tanken är att man har hela kravbilden klar för sig innan man går vidare. Enligt de klassiska projektstyrningsmodellerna ska alla artefakter göras i en sekvens. Det betyder att inför viktiga beslutspunkter så finns allt material färdigt. Ändringshantering behövs i princip inte. Detta synsätt fungerar sällan i stora projekt. Orsakerna till det är flera: Kraven är svåra att fånga. Många krav som är kostnadsdrivande kommer fram senare. Det betyder att man analyserar endast en del av kravmängden. Ändringshantering har visat sig behövas. Krav, tidsramar och andra förutsättningar förändras oftast under projektet. Detta betyder ofta att många av de krav som man från början ämnade ha med stryks under projektets gång samtidigt som nya kommer till. Det är sällan lämpligt att implementera och testa allt på en gång, s.k. big bang. Detta angreppssätt innebär att fel ofta upptäcks sent vilket leder till att den totala utvecklingstiden ofta blir längre än om man jobbar i små steg. Ett annat skäl att undvika big bang har med komplexiteten att göra. Det är svårt att överblicka allt på en gång. Faktum är att det är under utvecklingen av produkten (eller prototypen) som man faktiskt lär sig att formulera de rätta kraven. Detta betyder att systemutveckling i själva verket är en lång läroprocess. Nu skulle man kunna tro att vattenfallsmodellen är under utdöende. Men så är icke fallet. I flertalet projekt så finns den med, åtminstone med som dåligt exempel. Vattenfallsmetoden har fungerat i en värld som inte är så föränderlig menar t ex Fredrik Löving i artikeln om DICE. Redan under de tidiga mjukvaruprojekten på 60 och 70-talet insåg man att något var fel. Så länge projektens krav kunde styras inifrån projekten och projektgrupperna var små så fungerade Spelutvecklaren Dice måste arbeta agilt Ivar Jacobson om vår största utmaning Beslutspunkt Krav Design Implementation Vattenfallsmetodiken togs fram under 1960-talet. Beslutspunkt Beslutspunkt Test 4 OnTime nr 2/09 Agila metoder summerar vi hela vår Product Backlog. frekvent läggs till och tas bort saker från backlogen. OnTime nr 2/09 Agila metoder 9 Programmeringsspråk Formella metoder Utvecklingsmetoder Maskinkod Assembler Smalltalk det hjälpligt.. Men ganska snart kom det nya tankesätt Agila metoder är ett samlingsnamn för en hel familj av metoder. Flertalet av dessa är inte nya utan har använts sedan länge. De har alla inspirerats av spiralmodellen. Gemensamt för dessa är dock de grundläg- Inkrementplanering Design Feedback Spiralmodeller Implementation Spiralmodellen reducerar riskerna genom utveckling i små steg. Av flera skäl är projekten mycket mer komplexa idag. T ex så ställer kunderna högre Strukturerad Programmering orientering Under årens lopp har en lång rad av verktyg, programmeringsspråk och metoder presenterats som den avgörande lösningen. krav, produkterna innehåller mycket mer programvara och kravbilden är föränderlig. Att jobba inkrementellt innebär att man utvecklar systemet i små steg Inkrement. Dessa inkrement kan ses som små vattenfall. Genom att utveckla i små steg så kan man reducera några av de risker som finns inbyggda i vattenfallsmodellen. Framförallt så slipper man big bang effekten. Då systemet tas fram i små steg så innebär det att man kör hela cykeln från krav till test. Man kan då hitta problem tidigare och med hjälp av denna feedback planera och genomföra resten av projekten bättre. En iterativ modell har stora likheter med en inkrementell, men här har man ofta kortare tidshorisont för planeringen. Man gör i stället ständiga förbättringar. - Om vi har en begränsad tid kapar vi helt enkelt listan nerifrån, eftersom Vattenfall Parallell utveckling (~1980) Spiralutveckling Inkrementell/Iterativ utveckling (1984) Prototyping Agila metoder: Scrum (1995) *ref [3] FDD (1997) *ref [4] XP (1999) *ref [5] LEAN (2003) *ref [6] Dessa modeller har också en del problem: När blir man färdig? Ofta behövs det fler inkrement än man först tänkte. Hur hanterar man fel som har upptäckts i föregående inkrement? Risken är att man springer vidare och att felen först rättas senare (om de inte glöms bort helt). Det finns ju en viss overhead för varje gång man löper hela linan ut. Så hur långt ska man gå med dokumentation och test i varje inkrement? mot en Agilare Värld? OnTime nr 2/09 Agila metoder 5 interation. Det är ett grundvärde. Sedan Så påverkas organisationen Westermo provar att jobba agilt Namnet Westermo är kanske inte känt för alla, men företaget levererar industriella datakommunikationsprodukter, främst egenutvecklade. Efter att nyligen ha provat på att arbeta agilt har företaget gjort ett antal intressanta lärdomar som de förmedlar. Scrum ger Hercules nytt liv Genom att använda Scrum i utvecklingen av ett nytt system lyckades Saab arbeta både snabbare och billigare. Faktum är att projektet gav nytt liv åt det gamla transportflygplanet Hercules, som kände luft under vingarna för mer än ett halvt århundrade sedan. Från Ivar Jacobson till bildbehandlingssystem inom medicinen Kan agila metoder gå hand i hand med hög kvalitet och god dokumentation? Svaret gavs i ett reportage hos Context-Vision, som berättade om hur de utvecklade bildbehandlingssystem för medicinska tillämpningar. Vi tog oss också en närmare titt på riktigt komplexa säkerhetssystem för flygindustrin. Hur går man tillväga när kvaliteten på utvecklingen är säkerhetskritisk och systemen aldrig får fallera? Numret avslutas med ett debattinlägg av Ivar Jacobson. Legendaren, som bland annat är en av upphovsmännen till UML (Unified Modeling Language), håller inte tillbaka på synpunkterna. Läs hans tuffa förklaring till varför vi är i desperat behov av en teori för mjukvaruutveckling. o OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva. 5

6 Från vattenfall till Scrum Den agila resan I mitten av 2000-talet ville FMV (Försvarets materielverk) effektivisera hanteringen av grunddata för att göra det enklare för olika delar inom försvaret att samverka och för att förbättra omvärldsbilden. Uppdraget gick till Combitech som i början av 2006 påbörjade ett projekt att utveckla en ny produktionsmiljö - ett projekt som till en början inte alls gick som planerat. tanken var att slå ihop verksamheter som sysslade med snarlika saker och för det behövdes en gemensam produktionsmiljö, JBaSS, som Combitech skulle skapa. Utvecklingen skulle ske enligt vattenfallsmodellen och allt startade med ett stort planeringsarbete som utmynnade i en väldigt omfattande kravspecifikation. Men snart nog dök det upp problem. Det var svårigheter med kommunikationen mellan olika delar i projektet och det bildades snart läger som inte alls kom överens. På hösten 2006 hade arbetet i stort sett kört fast och projektledningen insåg att något måste göras. Vi var tvungna att göra något Combitecharna Anders Sandblad, konsult, och Christina Björnfot, sektionschef Grunddata berättar hur det gick till. Projektet stod nästan stilla, tidplanen bara gled iväg och beställarsidan var missnöjd så under vintern 2007 blev det klart att vi var tvungna att göra något, säger Anders Sandblad. Den gamla planeringen höll helt uppenbart inte så de började om från början med en ny planering. Istället för att skapa en ny mastodontplan med långa milstolpar var idén att sätta upp mål med ganska kort horisont så att man snabbt kunde se hur arbetet utvecklade sig. Det var egentligen då vi började tänka agilt även om vi just då inte förstod att det var det vi höll på med, säger Anders Sandblad. Att arbeta mot korta mål fungerade bättre och även om det inte blev någon revolutionerande förbättring så började arbetet ändå gå framåt. Så man arbetade på det här sättet i ungefär ett år, men det behövdes något mer för att verkligen få fart på arbetet. Vid det här laget hade teamet förstått vad det innebar att arbeta agilt och man började nu snegla på Scrum. Scrum infördes stegvis Till att börja med infördes olika delar i Scrum stegvis. En backlog sattes upp, planeringsmöten hölls oftare, en Scrumtavla sattes upp och så vidare. Runt sommaren 2008 var det mesta på plats och då hände det plötsligt saker. Det var rena ketchupeffekten. På drygt ett halvår lyckades vi leverera det vi skulle och som vi inte lyckats med på de förgående två åren, säger Anders Sandblad. En av de stora orsakerna till framgången var att man med Scrum lyckats 6 OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva.

7 skapa en helt annan delaktighet och synlighet i projektet än tidigare. Just att vi lyckades öka synligheten var mycket viktigt. Det fanns inte längre en person som såg helheten och som sedan talade om för alla andra vad de skulle göra. Nu såg alla vad som behövde göras och det resulterade i att alla började dra åt samma håll, säger Christina Björnfot. Beställaren van vid långsiktiga planer Något motstånd mot att införa Scrum var det inte heller frågan om, inte inom projektet i alla fall. Utvecklarna var nyfikna och mötte nyordningen med entusiasm. Användarsidan berördes inte direkt av övergången till Scrum, men hade heller inga invändningar. Det enda som var lite känsligt var att ta upp det nya arbetssättet med beställarsidan. Beställarsidan var van att arbeta med långsiktiga planer och att få information varje halvår om vad som skulle göras under kommande halvår. Eftersom vi redan låg efter tidplanen så var det inte riktigt läge att förklara att vi skulle jobba på ett nytt sätt och att de gärna skulle gå en kurs för att verkligen förstå vad nyttan med det var, säger Christina Björnfot. Istället lät man resultaten tala för sig själva. När vi började med Scrum gjorde vi ingen stor affär gentemot beställarsidan av att vi använde just det arbetssättet. När vi hade allt på plats, några månader innan vi var färdiga med projektet, så började vi prata i de här termerna och talade om för beställarna hur vi arbetat. När de såg resultatet hade de inga problem med det nya arbetssättet, säger Anders Sandblad. Projektet är nu avslutat och systemet är överlämnat, men arbetet med systemet fortgår. Idag underhåller och vidareutvecklar Combitech systemet och nu är Scrum det naturliga arbetssättet vid utvecklingsarbetet. Vad skulle ha gjorts annorlunda? Så vad kan vi då lära oss av det här projektet? Vad skulle de inblandade ha gjort annorlunda om de fick börja om från början? När vi började med Scrum så star- Anders Sandblad och Christina Björnfot. tade vi helt på egen hand. Vi läste lite böcker och provade oss fram. Nu råkade vi missuppfatta en del saker som exempelvis hur vi skulle genomföra sprintgranskningar och skriva user stories. Nu har vi blivit riktigt bra på det, men om vi hade tagit hjälp av någon som kunde Scrum när vi började så hade vi säkert kommit igång snabbare, säger Anders Sandblad. Att övertyga beställarsidan om fördelarna med att arbeta agilt istället för att smyga in förändringarna under projektets gång hade också varit att föredra. I det här projektet hade vi inte tid, men om man har tid så ska man absolut försöka ta med beställaren från början. Lägg några dagar i början på att utbilda alla inblandade även från beställaren om vad det innebär att arbeta agilt. Det blir mycket enklare att hålla en dialog med kunden om de förstår hur vi jobbar, säger Christina Björnfot. Då funkar inte Scrum så väl Även på användarsidan testades Scrum, men där gick det inte lika bra. Användarsidan har många fler kontaktytor än utvecklarna och kan inte på samma sätt själva styra vad som händer utan styrs mer av yttre händelser. Deras arbete kan mer ses som ett flöde än som en rad iterationer och då fungerar inte Scrum så väl. Vi testade, men det blev mest en Scrum-tavla som var täckt med lappar. De har många aktiviteter som löper över lång tid och där man kanske jobbar en timme i stöten på en viss sak. Det gjorde att inget blev färdigt snabbt och att lapparna bara blev fler och fler så det gav inte så mycket i slutänden, säger Christina Björnfot. Vill ogärna gå tillbaka På utvecklarsidan har dock Scrum varit en stor framgång och många som väl börjat arbeta agilt vill ogärna gå tillbaks. Jag fick faktiskt en kommentar från en som jobbade i projektet, men som nu jobbar i ett annat projekt som inte använder Agila metoder och han sa att han saknar att få jobba agilt. Det var helt enkelt inte lika roligt när man inte hade samma delaktighet som man får när man jobbar agilt, säger han. Så på det hela taget har övergången till agilt varit en solskenshistoria. Mycket blev bättre efter att vi infört Scrum och inget blev sämre så jag kan faktiskt inte se några nedsidor utan det här var väldigt lyckat på alla sätt. Därmed inte sagt att det inte finns saker att förbättra. Ett sådant här förändringsarbete blir man i praktiken aldrig helt klar med, säger Anders Sandblad. o OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva. 7

8 Vattenfall vi minns... Victoria Falls Stora Sjöfallet, ca Traditionell vattenfallsmodell Niagara Vattenfall som färre minns... Trollstigen, Norge Forsakar, Skåne 8 OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva.

9 Varför ska vi arbeta agilt? Måste man arbeta agilt? Ska man överge det traditionella arbetssättet som fungerar? Självklart måste man inte arbeta agilt, eller lättrörligt det är bara det att det oftast ger så mycket bättre resultat nöjda kunder, billigare i slutänden, färre ändringar mm. Det finns områden där det lättföränderliga arbetet inte alls är lämpligt, t ex vid brobyggen har man väl börjat gjuta brofästena så är det inte särskilt lämpligt att flytta på bron eller göra en annan konstruktion. Däremot kan det finnas andra delar i ett sådant projekt som kan tillämpa agila metoder, såsom Scrum eller Lean. vilka projekt är det då som lämpar sig för det agila arbetssättet? Att jobba agilt fungerar både för hård- och mjukvaruutveckling. Ofta går företag över till det här arbetssättet för att man har problem av något slag och behöver hitta verktyg för att komma vidare. Det agila sättet att utveckla medför total transparens och det är lättare att i ett tidigt skede upptäcka eventuella frågetecken. Det är också ett bra sätt att sprida erfarenheter och kunskaper i och med att man jobbar i team och att teamet tillsammans når målen. Aha-upplevelse att se verkligheten Att jobba agilt medför inte med automatik att t ex utvecklarna kan koda snabbare eller att testarna kan testa bättre. Däremot är intressenter och/eller kunder med kontinuerligt i processen och har möjlighet att i ett tidigt skede flagga för att något inte är som man har tänkt sig eller att en funktion behöver fungera på ett annat sätt. I det agila arbetssättet ingår att produktägaren har god insikt i slutkundens avsikter med produkten som utvecklas, men det är också bra om flera medlemmar ur teamet (t ex utvecklare och testare) följer med till slutkund i syfte att personen ska få komma ut och se verkligheten. Det ger oftast både en och två aha-upplevelser, eftersom personen innan dess oftast har en föreställning om hur det ska fungera där ute, vilket kanske inte överensstämmer med hur det faktiskt är. Det underlättar också för produktägaren och teamet när man ska förstå vad som ska utvecklas. Fokus på värdet för kunden Hur avgörs då vad och hur mycket som ska utvecklas? Istället för att uppskatta tid och resurser för att nå ett särskilt mål som i det traditionella sättet att utveckla är det istället affärs- och effektmålen som kan varieras beroende på tid och resurser (se modellen på nästa sida). Det gör det naturligt att i första hand OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva. 9

10 Scope Time Cost (resources) Fix Agile Traditional Estimate Time Cost (resources) Scope Target business goals & outcomes Det agila arbetssättet skiljer sig radikalt jämfört med traditionella utvecklingsprojekt. Det blir naturligt att enbart ta fram de funktioner som är direkt värdeskapande. ta fram de funktioner som ger Minimal Viable Product (MVP), dvs att utveckla endast de saker som behövs för att ge kunden en produkt som har ett värde. Hur kommer man dit? För att nå framgång i det agila arbetssättet är det en förutsättning att ledningen inom utvecklingsbolaget inser vad som krävs av dem. I reportaget från Scania kan vi läsa om hur cheferna på olika nivåer har upplevt övergången till agila metoder (eller Lean som är motsvarande begrepp inom hårdvaruutvecklingen). En av de viktigaste ingredienserna är också att teamet fungerar bra tillsammans. Att redan vid sammansättningen tänka på att teamet och dess medlemmar ska bilda ett vinnande koncept skapar en viktig förutsättning för att lyckas. I artikeln om agil utveckling på distans kan du läsa om hur det gick till när utvecklingsteamet satt både i Sverige och i Indien parallellt. En nyckel till framgång är att medlemmarna kompletterar varandra såväl kunskapsmässigt som socialt. Genom pairing, dvs att två personer utvecklar tillsammans, skapas dels högre kvalitet på det som tas fram och det gör också att man sprider sina kunskaper inom teamet. Passar bra i svenska företag Det agila arbetssättet fungerar ofta bra i svenska företag, då vi är vana att jobba i platta organisationer. Förmågan att kunna anpassa produkter i dagens samhälle med den allt snabbare konkurrensen är ett tungt argument för att gå över till en lättföränderlig utvecklingsprocess. Vem har då mest att vinna på att börja jobba agilt? Brobyggaren som nämns ovan bör nog undvika det agila inom vissa områden. I organisationer där man utvecklar komplexa produkter kan man däremot ha mycket att vinna genom att gå över till detta arbetssätt. Likaså i organisationer där man behöver ändra arbetssätt för att bli mer effektiva, eller kanske lösa problem inom utvecklingsprocessen. Är man ute efter ökad effektivitet och kvalitet är det agila tankesättet absolut värt att studera! o 10 OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva.

11 Dulce Goncalves rapporterar Direkt från Scrum Gathering i Barcelona 2012 Vad händer ute i världen inom det agila området? Är det fortfarande bara mjukvaruföretag som arbetar agilt? Jag har precis landat efter en vecka i Barcelona och har fått med mig en hel del inspiration, nya idéer samt nya metoder och verktyg för kreativitet och effektivisering. Det var väldigt roligt att lyssna på bolag som arbetar som underleverantörer till fordonsindustrin och se hur de har lyckats att mer än halvera sina leveranstider samt även höja kvaliteten. Johnson Controls berättade några av sina stories från deras verklighet på Scrum Gathering i Barcelona 1-3 oktober De började med att införa agila metoder redan 2007, idag har de utbildat 300 anställda i Scrum världen över. Förändring är inte lätt, och även de har tagit hjälp av agila coacher för Europa samt Nordamerika. De berättade om ett kritiskt projekt av en mekanisk funktion till en bilstol som skulle ha tagit ca nio månader att utveckla, men som av olika anledningar var på väg i diket. Integration varje kväll Genom att arbeta agilt samt köra Nano Scrum, dvs tredagars Scrum, lyckades Johnson Controls leverera hela funktionen i tid samt med hög kvalitet. Anledningen till att man arbetade med Nano Scrum var att kravbilden var för vag och alla teammedlemmar var nya i teamet samt i projektet. Det var kul att se hur de hade arbetat med lean visualisering samt kontinuerlig integration (varje kväll) och detta för hårdvara. Det var också intressant att de genomfört Nano Scrum utan avkall på sprintplanering, retrospective eller demo. Jag kommer att ta med mig detta till framtida projekt, oavsett om det är mjukvara eller hårdvara. Efter föredraget var det förresten många deltagare som undrade hur man kunde söka jobb hos Johnson Controls! Extreme manufacturing Wikispeed berättade om extreme manufacturing (XM). I det här fallet hur de bygger fysiska bilprototyper som är ul- Nyckelord från Scrum Gathering: agila värderingar samt principer, platta organisationer, riktiga produktägare, tvärfunktionella team, kontinuerlig integration, kontinuerliga feedback-loopar från slutkunder samt brainstormsmetoder för ökad kreativitet. traeffektiva, säkra, har låg underhållskostnad, är snabba och roliga. Detta på tre månader mot industrins sex år. Wikispeed avslöjade hur detta var möjligt genom att arbeta agilt. De arbetar i tvärfunktionella Dulce Goncalves team, har korta iterationer (en veckosprint) samt kontinuerlig integration. Med andra ord bygger de något som kunden senast ville ha för sju dagar sedan. Nödvändigt för att få de fina resultaten Ericsson Irland var ett annat bolag som berättade om sin resa och omorganisation för att fungera med Scrum. Precis som alla andra bolag som talade på konferensen var det, enligt dem, extremt viktigt att få på plats följande för att verkligen få de fina resultaten: viktigt att verkligen ha riktiga produktägare, eftersom hela tanken med denna roll går ut på att korta avståndet mellan marknad/slutkund och R&D kontinuerlig integration kontinuerlig feedback från nyckelkunder (interna/externa) Förutom innovation var coachning det som upptog den mesta delen av konferensen. Det agila arbetssättet kräver platta organisationer, ett annat ledarskap samt effektivare inlärningsmetoder och verktyg. o OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva. 11

12 På Scania har Lean införts med farfarsprincipen Mellancheferna måste förstå den vardag första linjens chefer lever i I 15 år har Scania använt sig av Lean-tänkandet i form av Scania Production System, SPS, och då skulle man kunna tycka att de borde vara färdiga snart. Men då har man helt missuppfattat vad Lean egentligen är menar Gert Frick som är ansvarig för SPS på Scania. lean är inte en metod utan ett sätt att leda verksamheten. Det är ett sätt att tänka och att vara, och det handlar om en ständigt pågående förändring. Man blir aldrig klar med Lean, säger Gert Frick. Syftet med SPS är att effektivisera Scanias produktion och eliminera allt slöseri. En förutsättning för det är engagerade medarbetare, men för att lyckas med Lean så måste man börja i toppen. Ska man rulla ut det här konceptet i ett större företag så måste det komma direkt från företagsledningen. Man kan göra som alla andra och stjäla grundkonceptet från Toyota, men ledningen måste ändå skriva om det med sina egna ord så att de sedan kan gå ut och sälja konceptet till hela verksamheten. För att kunna sälja in Lean krävs det i första hand att man vet vad det är man vill sälja in. Så första steget är att den högsta ledningen måste ta reda på vad det är de egentligen vill åstadkomma, vad är syftet med att använda Lean? Se slöseriet och eliminera det Här är det viktigt att man verkligen utgår från nuläget och en variant är att ha en workshop på någon vecka. Där kan ledningen titta på hur arbetet utförs i verkligheten och inte bara hur det borde utföras enligt planerna. När man har sett grundläget tillräckligt bra har man också sett mycket av lösningen, för då har man sett slöseriet och det här arbetet handlar om att hela tiden se slöseriet och eliminera det, säger Gert Frick. Nu kan det vara lite svårt att veta exakt hur man ska göra denna analys. Då kan det vara idé att besöka företag som redan jobbar enligt Lean, för att få en bättre bild av vad det innebär i praktiken och vad som krävs för att få det att fung- 12 OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva.

13 era. Det kan också vara värdefullt att få in folk med erfarenhet av Lean i organisationen. Det kan röra sig om en erfaren konsult eller att anlita någon som jobbat med Lean i ett annat företag. Ett resultat av detta arbete blir att ledningen kommer fram till ett antal grundvärderingar som ska ligga till grund för verksamheten. På Scania har de tre grundvärderingar och de är: Kunden först. Respekt för individen. Eliminering av slöseri. Använder farfarsprincipen Efter det gäller det att sälja in konceptet till resten av organisationen och här har Scania använt sig av farfarsprincipen. Det innebär att ledaren lär sin underordnade vad vi vill uppnå och hur vi ska uppnå det, säger Gert Frick. På så sätt sprider sig tänkandet ner i organisationen och resulterar i effektivare produktion, bättre konkurrenskraft, nöjdare medarbetare och lägre sjukfrånvaro. I varje fall om man gör det rätt, men det finns många utmaningar och fallgropar. En utmaning är att våga ifrågasätta det man gjort tidigare och att våga sätta tillräckligt höga mål. För att lyckas måste vi göra något som vi inte gjort tidigare och då måste vi också göra det på ett annat sätt än tidigare. Sätter man då målen för lågt så behövs det kanske inga direkta förändringar för att nå dit. Målet måste vara så högt satt att man inte riktigt vet hur man ska ta sig dit, säger Gert Frick. En annan stor utmaning är att lära sig leva med konstant förändring. För att bli framgångsrik måste man hålla en högre förändringstakt än konkurrenterna och det innebär att verksamheten måste försättas i ett tillstånd av ständig förändring. Nu är det så att många vill ha förändring, men de vill inte nödvändigtvis vara med under tiden den genomförs. Så det är en jätteutmaning att få alla att inse att förändring är det normala i fortsättningen, säger Gert Frick. Speciellt tryck på mellancheferna Det här sätter speciellt tryck på mellancheferna. Det är de och inte högsta ledningen som måste övertyga de som i slutänden ska göra jobbet att det här är rätt sätt att jobba. Det kan lätt bli motstånd bland första linjens chefer som kan mena att de redan har svårt att hinna med det de gör och att det inte finns tid och resurser till några förändringar. Mellancheferna måste förstå den vardag som första linjens chefer lever i för att kunna vinna över dem. Det kan vara mycket krävande och det är viktigt att de hela tiden känner att de stöttas av högsta ledningen och att högsta ledningen verkligen förstår vilka utmaningar mellancheferna står inför, säger Gert Frick. För högsta ledningen innebär det bland annat att de måste vara ute mycket i verksamheten för att se hur arbetet med att införa Lean-tänkandet uppfattas. Det krävs mycket kommunikation för att få konceptet att verkligen genomsyra hela verksamheten. Lyckad pilot kan glädja de flesta ledningsgrupper Ska man lägga ner allt detta jobb så vill man förstås också veta när man kan förvänta sig att få se resultat. Gör man en pilot så går det att se resultat i form av högre produktivitet och mindre slöseri inom ett par månader och det lär glädja de flesta ledningsgrupper. Risken finns då att man tycker att målet är uppnått Risk att högsta cheferna inte är beredda på insatsen Det krävs en hel del arbete från högsta ledningen under hela processen, som alltså är ständigt pågående. Inte alla är beredda på det. Den största fallgropen i det här arbetet är att de högsta cheferna inte är beredda på vilken resursinsats det krävs av dem. De måste själva lägga ner tid på arbetet för det går inte att delegera och så måste de ta sig tid att kommunicera så att alla märker att det här är något som ledningen prioriterar och tar på allvar, säger Gert Frick. och att allt kommer att rulla på av sig självt i fortsättningen. Det finns ett stort intresse för det här och många håller på, men det är få som lyckas över tiden. Det beror dels på att ledningens engagemang kan svikta efter ett tag och dels på att man inte är tillräckligt uthållig. Risken finns att man ser det här som en metodfråga och att man tror att arbetet är färdigt så fort man infört metoden. Lean är ett sätt att leda verksamheten och är något man måste jobba med varje dag, säger Gert Frick. På Scania har man lyckats med detta, men inte ens där kan man luta sig tillbaks. Vi började för 15 år sedan, vi ser resultat varje dag och Lean ingår i vårt DNA nu törs jag säga. Men ändå ser vi det mest som att vi har lagt en bra grund under den här tiden och att vi nu kan fortsätta jobba vidare. Färdig blir man aldrig, säger Gert Frick. o OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva. 13

14 Agil utveckling på distans Team byggdes upp på två kontinenter utifrån personliga egenskaper Agil utveckling bygger mycket på täta kontakter och bra kommunikation mellan medlemmarna i utvecklingsteamet. Så hur fungerar det när en del av teamet sitter i Sverige och en annan del sitter i Indien? när Saab och Indiska konsult- och IT-företaget Mahindra Satyam startade ett samägt företag, Saab India Technology Centre, ville de ha ett utvecklingsprojekt där svenskar och indier skulle samarbeta. Valet föll på ett projekt för att utveckla system för avancerade skjutbanor, och utvecklingen skulle ske med agila metoder. Att ha utvecklingsteamet utspritt över två kontinenter är inte helt trivialt, men det har ändå fungerat riktigt bra tycker produktägaren Anders Olofsson. Anders Olofsson Det har fungerat förvånansvärt bra måste jag säga. Visst har det varit en utmaning, men resultatet blev att vi nu har ett team som presterar väldigt bra hela tiden, säger han. Inga färdiga team En av nycklarna till framgången hittar vi redan i själva rekryteringsprocessen av utvecklarna. Det fanns inte färdiga team i Sverige och Indien som skulle slås ihop utan hela teamet byggdes från grunden och vid rekryteringen var det inte ämneskunskaperna som låg i fokus. Givetvis behöver utvecklarna kunna sina saker, men i det här fallet krävdes det mer för att projektet skulle bli lyckat. Vi specade inte så mycket ämneskunskaperna utan mer de personliga egenskaperna hos utvecklarna. Vi ville ha utvecklare som kunde jobba självständigt, ville ta ansvar och som hade lite humor. Genom att handplocka de utvecklare vi ville ha har vi lyckats få ett team som fungerar väldigt bra ihop, fast vi sitter så långt ifrån varandra, säger Anders Olofsson. Umgicks inte bara yrkesmässigt När man väl hittat rätt personer så gällde det att få dem att känna varandra. Så när projektet började fick två utvecklare från Indien komma till Sverige under en månad och arbeta under två utvecklingssprintar. De lärde då känna den svenska delen av teamet och fick praktisk kunskap om produkten samt hur agil utveckling går till. Efter det åkte de och den svenska delen av teamet ner till Indien och träffade resten av teamet. Här var det viktigt att inte bara umgås yrkesmässigt utan vi åt middagar, åkte på sightseeing med mera som en grupp. Det gjorde att vi alla fick en förståelse för vilka de andra personerna i teamet verkligen är och det underlättade mycket senare eftersom vi sköter mycket av kommunikationen via videokonferenser och chatt, säger Anders Olofsson. Vi ville dra nytta av deras idéer Huvudparten av utvecklingen sker i Indien medan Sverige bidrar med Scrum Master, produktägare och arkitekt. Den uppdelningen skulle kunna leda till att den indiska delen av teamet bara väntar på order från svenskarna. Det visade sig också att det var ett problem i början. I början var det mer som att de väntade på att vi skulle tala om för dem exakt vad de skulle göra medan vi ville ha en diskussion för att kunna dra nytta av deras idéer och erfarenheter. Utmaningen var att få dem att se sig själva som likvärdiga medlemmar i teamet 14 OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva.

15 som kan ta egna beslut och inte fråga oss om allting. Det har blivit mycket bättre efterhand och nu förstår de att vi inte har alla svar utan att vi verkligen vill veta vad de tycker, säger Anders Olofsson. Det här skulle man kunna se som en kulturkrock, men Anders Olofsson menar att det snarare rör sig om en krock mellan olika arbetssätt än mellan olika kulturer. Det är samma sak i Sverige när folk ska jobba agilt för första gången. Många är då vana vid att få bestämda uppgifter att lösa och tar inte så mycket egna initiativ. Så det är just ingen skillnad mellan att få ett indiskt team och svenskt team att lära sig arbeta agilt, säger Anders Olofsson. Den stora utmaningen var något helt annat Så vare sig kulturskillnader eller teknik har varit den stora utmaningen i projektet. Det visade sig istället att det var mer interna organisationsfrågor som var det största farthindret. Till exempel ville teamet använda så kallade smart boards. Det kan beskrivas som digitala white boards med tryckkänsliga skärmar. Du kan då skriva på en smart board i Sverige och det visas direkt på en annan smart board i Indien. Det är ofta enklare att visa exempelvis en ny design om du kan rita medan du förklarar och vi skulle kunna använda den som ett scrum board också, säger Anders Olofsson. Det var dock inte så enkelt att köpa två smart boards till två olika platser i ett företag som ägs av två olika bolag. Teamet ville ha dem i våras, men efter ett halvår är de fortfarande inte på plats. Skulle vi ha gjort något annorlunda så är det just detta. Hade vi redan från början haft klart med infrastrukturen i vårt företagsnät, när det gäller utvecklingsmiljö, kommunikation mm, så hade det varit otroligt bra. Underskatta inte den sociala biten Sedan har det också märkts att organisationen inte är van vid team som sitter i olika länder, vilket orsakat en del huvudvärk. Ibland har det verkat som att de Svenskarna och indierna umgicks flitigt, vilket underlättade kommunikationen. som ska supportera oss inte har förstått våra behov. Att få med dem från början hade också varit bra. Men med det här projektet så har vi krattat manegen för kommande projekt som förhoppningsvis kommer att slippa många av de problem som vi råkat ut för, säger Anders Olofsson. På det hela taget har det varit en väldigt positiv upplevelse och om Anders Olofsson ska ge ett tips till de som ska jobba på liknande sätt så blir det att inte underskatta den sociala biten. Det vi verkligen gjorde rätt var att vi tog upp några utvecklare från Indien hit och sedan åkte ner och umgicks med utvecklarna I Indien. De här resorna gjorde att vi lärde känna varandra och det har gjort det mycket enklare att kommunicera under projektets gång, säger han. o Nyckfull trafik omöjliggör morgonmöten Det finns vissa områden där kulturskillnaderna märks. Ett exempel är att vi ofta tycker om att komma in tidigt till jobbet för att kunna gå hem tidigt. I Indien är det precis tvärtom och det är ofta svårt att veta exakt när folk kommer till jobbet. Något som har en helt naturlig förklaring visar det sig. Trafiken i Indien kan vara väldigt nyckfull så det är svårt att veta hur lång tid det tar att komma till jobbet. Att lägga möten tidigt på morgonen, indisk tid, fungerar därför inte, säger Anders Olofsson. Nu är den skillnaden snarast en fördel eftersom det är natt i Sverige när det är morgon i Indien och eftermiddag här när det är kväll där. Så att utvecklarna i Indien kommer in lite sent och sedan jobbar långt in på kvällen passar rätt bra med de svenska arbetstiderna. Några större kulturkrockar som kunde störa arbetet har alltså inte dykt upp. Då har kommunikationen varit mer utmanande, men även det har fungerat riktigt hyggligt. För de obligatoriska mötena används videokonferens medan den övriga dagliga kommunikation sköts via telefon och chatt. Det är väl kanske inte helt idealt, men det fungerar rätt bra. Just videokonferenserna är viktiga för det är alltid enklare om man ser den man pratar med, säger Anders Olofsson. OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva. 15

16 Linköpings universitet satsar agilt Driver studenterna att tänka mer självständigt Det agila arbetssätet sprider sig nu bland företag och organisationer, men hur ser det ut på utbildningsfronten? Ingår agil utveckling som en del i dagens datautbildningar? svaret på den frågan är ett klart ja, bland annat på Linköpings universitet. Där har man kört agil utveckling lite i vågor under flera år, men för 4-5 år sedan startade ett program som från början är uppbyggt för att vara agilt. Programmet heter Innovativ programmering och en av de ansvariga är Erik Berglund. Det finns ingen på universitetet som inte tittar på agil utveckling idag och därför verkade det naturligt att ta in det direkt när vi startade Innovativ programmering, säger han. Här får studenterna lära sig att lösa programmeringsproblem, skriva effektiv kod och att arbeta både enskilt och i projektgrupper. Målet är att varje Erik Berglund, Linköpings universitet student ska skapa en samling av kreativa programmeringsprojekt inom exempelvis spel, databassystem och webbapplikationer som de sedan kan visa upp när de ska söka jobb. Studenterna måste tänka mer självständigt Ett exempel på det hur det agila tänkandet kommer in i utbildningen är att studenterna får lära sig att själva definiera vad som behövs. Hela strategin för den här utbildningen är att den ska vara självorganiserande. Vi vill lära studenterna definiera problemet och bryta ned det i mindre delar för att sedan lösa det. Det handlar inte längre om att ge studenterna en uppgift som sedan ska implementeras på ett visst sätt utan de måste tänka mer självständigt, säger Erik Berglund. I praktiken kan det till exempel innebära att studenterna själva får välja programmeringsspråk och spelmotor om de ska göra ett datorspel i en kurs. Olika språk och motorer passar olika bra för olika typer av spel och här är det upp till studenterna att komma fram till vad de tror passar bäst för det de vill göra. Parprogrammering visar vikten av kommunikation Mycket av programmerandet sker också med parprogrammering eller i projektgrupper så att studenterna ska bli vana vid att samarbeta och lära sig hur viktigt det är med kommunikation i agil utveckling. Vi kör ibland en hel klass som ett företag så att de får känna på hur det är när man måste hantera storskaliga kommunikationsfrågor, säger Erik Berglund. Ett problem som då kan uppstå är att studenterna får uppleva ett knivigt problem som förekommer ute i arbetslivet. Nämligen att sälj- och utvecklingsavdelningarna inte riktigt har samma idé. I agil utveckling säger vi ofta att vi vill prioritera kvalitet framför funktionalitet, men ska du sälja en produkt så framhåller du ofta funktionerna i den produkten. Nyckeln här är att få säljdelen att förstå vad det innebär att arbeta agilt och att det avgör vad de kan lova kunden, säger Erik Berglund. Bättre förberedda på arbetslivet Den här utbildningsmetoden gör förhoppningsvis studenterna mer självständiga och bättre förberedda på att jobba i agila projekt när de kommer ut på arbetsmarknaden, men det finns en del utmaningar med att jobba så här istället för att köra traditionell utbildning. En sådan utmaning är hur man bedömer individer när de får arbeta så fritt. Om studenterna till exempel väljer olika tekniker för att lösa en uppgift kan det bli lite som att jämföra äpplen och päron när resultaten ska jämföras. En 16 OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva.

17 teknik kanske gör det enklare att lyckas bra inom ett delområde medan en annan teknik ger fördelar inom ett annat. Har man en traditionell tenta där alla får svara på samma fråga är det enkelt för studenterna att förstå varför vår bedömning ser ut som den gör. Det är inte lika enkelt för dem att förstå det när de har arbetat med olika lösningar. Så det är lite av en kommunikationsutmaning att få dem att förstå varför vi gör de bedömningar vi gör, säger Erik Berglund. Snäv bild av kreativitet Som namnet antyder, Innovativ programmering, är ett av målen med utbildningen att få studenterna att vara innovativa i sina lösningar. Många studenter har dock en lite snäv bild av vad det innebär att vara kreativ i ett utvecklingsprojekt, något som säkert är vanligt förekommande även i ute i arbetslivet. Kreativitet ses ofta som förmågan att kunna hitta på nya intressanta funktioner, men ibland är det lika viktigt att tänka kreativt på vad man kan skära bort, säger Erik Berglund. När de kommer ut i arbetslivet kommer studenterna säkert att hamna i projekt där ändringar och omprioriteringar är vardagsmat och då måste man kunna se vad man kan skära bort för att kunna lägga resurserna på det som nu prioriterats upp. Att simulera det är inte helt lätt i en universitetskurs. Studenterna läser ofta fyra kurser samtidigt och då finns det helt enkelt inte tid för dem att omvärdera kraven och definiera vilka ändringar som behöver göras. Vi har funderat på att ha en kedja med kurser där koden följer med från en kurs till nästa, men problemet med det är att om studenten misslyckas med koden i första kursen blir det väldigt tungt i de efterföljande kurserna, säger Erik Berglund. Svårt att budgetera tiden Att visa hur viktigt det är att budgetera sin tid på ett realistiskt sätt är också något som är viktigt, men som kan vara svårt att simulera under utbildningen. Att avgöra hur mycket man hinner utveckla på en viss tid i en projektgrupp är viktigt, men det kommer vi sällan i kontakt med under utbildningen där vi har fasta tidsformat för varje kurs. En utmaning att bedöma studenterna En utmaning är att veta hur mycket olika studenter bidragit med när de samarbetat i ett projekt. I projektkurserna blir man bedömd som grupp i en delmängd av arbetet och det finns ju inga garantier att alla bidragit lika mycket. Till viss del får lärarna då förlita sig på att de andra eleverna flaggar för om någon i gruppen inte bidragit alls. Men det går också att lösa med ett samtal. Vi bedömer ju kunskap och inte produktion så en individuell muntlig examination kan vara väldigt värdefull om man vill se hur mycket en enskild student verkligen kan. Man ser mognadsgrad och teknisk förmåga mycket lättare när man sitter och pratar än om man bara ska bedöma ett inlämnat arbete, säger Erik Berglund. I förlängningen är det dock bra att de lär sig arbeta agilt för det visar snabbare när tidplanen inte fungerar, säger Erik Berglund. Så hur ser då studenterna på att arbeta agilt? Studenterna får fatta egna beslut om hur de ska arbeta i sina projekt, men de flesta väljer att arbeta agilt så det agila har definitivt slagit igenom bland studenterna, säger Erik Berglund. o OnTime nr 3/2012: Agil utveckling detta måste du ha koll på för att överleva. 17

18 nyheter från Unga ingenjörer blir erfarna snabbare Nyligen utexaminerades en kull Jönköpings ingenjörer från Combitech Talent Program, som de genomgått de senaste ett och ett halvt åren. Programmet syftar till att ge nyutexaminerade ingenjörer en rivstart på yrkeslivet och att göra dem erfarna snabbare. Denna omgång har genom förts i sam arbete med vsm Group, Husqvarna och Saab. Ny HR-chef på Combitech 1 oktober tillträdde Kristin Widell som hr chef på Combitech. Kristin har mångårig hr erfarenhet från konsultbranschen och kommer närmast från en roll som hr chef för en av Tietos största affärsenheter. Kundprojekt: Trafikverket Höjd säkerhet på Centralstationerna samverkan ger ökad trygghet för resenärerna Samhällets hotbild har förändrats. Terrorhändelser runt om i världen har satt krisberedskapen i nytt ljus. Platser där väldigt många människor samlas har blivit mer utsatta så också i Sverige. EftEr att självmordsbombaren vintern 2010 utlöste sin bomb i centrala Stockholm, beslutade Trafikverket och Jernhusen att öka beredskapen på de tre stora centralstationerna Stockholm, Göteborg och Malmö. Combitech engagerades för att identifiera förbättrings områden och kartlägga behovet av samverkan mellan alla aktörer. Vi alla, inom Trafikverket och övriga aktörer på de stora centralstationerna i Sverige, har genom projektet fått en samlad och klar bild av de risker och utmaningar som finns i den aktuella miljön. Vi har erbjudits möjlighet att diskutera och pröva olika scenarier. Projektet har helt enkelt skapat tydlighet, säger Bengt Olof Svensson, Trafikverket. på bilden. Kristin Widell De svenska stationerna har varit förskonade från större hot och terrorattacker jämfört med exempelvis Madrid, London eller Moskva, säger Susan Bergman på Combitech. Men risken finns och därför är ett gemensamt förebyggande arbete viktigt. En klar och samlad bild Arbetet år 2011 genomfördes i flera steg där huvudaktiviteten var ett antal workshops med uppföljningsmöten på respektive ort. Deltagare var representanter för samtliga berörda aktörer: Trafikverket, Jernhusen, polisen, räddningstjänsten, sjukvården, kommun, länsstyrelse, trafikoperatörer och bevakningsbolag för respektive station. Resultatet sammanställdes i en rapport AllvArligA händelser på större stationer (som finns tillgänglig på nätet). Men allt är inte slut i och med den lämnade rapporten. Projektet, som i år går under namnet AllvArligA händelser på större kommunikationsnoder syftar nu till att ta fram beredskapsplaner som har samverkan i fokus. Nu tar vi fram samverkansplaner och förhoppningsvis blir det övning nästa år, säger Susan Bergman, Combitech. Allt för att öka tryggheten bland de resenärer som varje dag besöker någon av de tre stationerna. på bilden. Susan Bergman, som också tagit bilderna på centralstationerna ovan

19 Bayes Risk Management Combitech växer i Norge Combitech har fått ytterligare ett tillskott i sin kombinationspalett av tjänster. Genom köpet av 70 % av Bayes Risk Management kan vi nu erbjuda kvalificerad risk analys och bättre stötta våra kunder på plats i Norge. En verksamhet är ExponErad för många risker, som kan kosta mycket pengar eller försämra ryktet. Men genom att identifiera och kvantifiera dessa risker kan du hantera dem och minska dem innan de skapar skada för ditt företag. Det är just riskhantering som är grundidén i det norska konsultföretaget Bayes Risk Management. Företaget, som startades 2005, har haft en fantastisk utveckling och har bland annat blivit utsett till Gasellföretag. Kunderna finns framför allt inom den norska olje och gasindustrin, men också På bilden: Riskhantering på hög nivå besteg Bayes konsulter den m höga bergväggen Kjerag. mer info. En längre version av artikeln finns på: inom bank och finanssektorn. Bayes har utvecklat metoder och plattformar för riskhantering som bygger på egen forskning. Vi får nu ett tydligare fotfäste i Norge och vi kan bättre stötta våra kunder på plats. Bayes specialistkunskap inom risk kompletterar också vårt övriga tjänsteutbud, säger Combitechs vd Marie Bredberg. Projektstyrning MAPS koordinerar komplexa projekt Med Combitechs modell för projektstyrning får du överblick och kontroll över projektets aktiviteter och resurser. Modellen syftar till att öka kundnyttan samtidigt som den möjliggör balans mellan uppgifter och resurser. Därtill bygger den relation genom kontinuerlig kommunikation med intressenterna. CombitECh har, tillsammans med en av sina större kunder, utvecklat en modell för styrning av komplexa projekt. Den ger extremt god överblick, delaktighet samt en smidig och flexibel hantering av uppgifter och resurser genom hela projektet. Vi har inspirerats av SCRUM samt följer CMMI* i den styrningsmodell vi skapat, säger Tore Bergman, konsult, projekt- och kursledare på Combitech. Förhållningssättet är agilt Modell för agil projektstyrning därav MAPS. KoordinEring och ErfarEnhEtsåtErföring. Genom olika team som arbetar scruminspirerat blir arbetet lättrörligt och anpassningsbart. Man sätter en inriktning, inte ett definierat slutmål, ristat i sten. Kunden ingår som en aktiv part i det pågående projektet där sakkunniga på olika nivåer föder projektet med information. Med det vinner vi delaktighet och kontinuerlig överblick över genomförda uppgifter, vilka som ska göras i kommande sprint samt en prioritering av de återstående. Koordinering och kommunikation är själva nyckeln. Genom dialogen bygger vi relation vilket är en förutsättning för att kunna skapa något tillsammans med kunden, berättar Tore Bergman vidare. Utifrån sprintgenomgångar och demos kan justeringar göras under projektets gång vilket ökar sannolikheten för att resultatet vid leverans verkligen överensstämmer med det verksamheten behöver. Alla har med andra ord full kontroll och insyn, säger Tore Bergman avslutningsvis. Combitech rekryterar Sony-ingenjörer Sony Mobile Communications drar ner personal styrkan i Lund. I nära samarbete med Sony erbjuder Combitech därför utbildning och anställning till en del av de uppsagda ingenjörerna, främst konstruktörer, som ska kunna stötta våra övriga kunder i Skåneregionen. Kockums väljer Combitech som konsultleverantör För att effektivisera sin verksamhet minskar nu Kockums antalet konsultleverantörer. Combitech blir en av fyra utvalda leverantörer som får förtroendet att fortsätta utveckla företagets system. Avtalet gäller alla delar av Kockums verksamhet och innebär sannolikt ny rekryteringar hos Combitech i Sydsverige. Företaget har under lång tid anlitat Combitech för konsulttjänster inom bland annat informationssäkerhet, kommunikation, system arbete, tekniknformation och mekanik. bild. Kockums * SCRUM är en metodik för systemutveckling och ett sätt att fördela arbetsuppgifter med bibehållen affärsnytta. Genom CMMI mäter man mognadsgrad i olika processer. på bilden Tore Bergman Combitech på IDLS i Aten I oktober samlades mer än 450 personer från 35 nationer i Aten för ett årligt symposium på temat taktiska datalänkar, International Data Link Symposium. Combitech, som har landets största samlade kompetens inom området, deltog som sponsor och utställare och nät verkade bland den övriga expertisen i världen.

20 avsändare Combitech AB Box Linköping Porto Betalt Combitech Training Institute: Aktuella kurser MBSE design, kodgenerering & exekvering 29 nov & 12 dec Linköping Certifierad testare grundnivå enl. ISTQB 4-6 dec Göteborg Testdriven utveckling.net 4 dec Stockholm Usability 4-5 dec Linköping Interaktionsdesign 6 dec Linköping Embedded Linux 11 dec Stockholm Problemlösning med C jan Linköping Effektiv granskning 29 jan Linköping combitech.se/utbildning»spara tid med papperslöst Tre frågor & tre svar utvecklingsarbete«produkten är tillverknings och monterbar, istället för att bygga fysiska prototyper. För 3. delen med mbd är att man kan reducera både Glöm 2d-ritningar på papper som skickas genom företaget. Genom att samla information om en produkt i en 3d-modell kan du reducera utvecklingstider och kostnader väsentligt. Allt fler företag upptäcker fördelarna, berättar Tomi Uimaniemi, mbd-expert på Combitech. Vad är Model Based Definition? Model Based Definition (mbd) är en metod som innebär att all information om en produkt samlas i en 3d modell. Det kan vara data kring material, mått och toleranser, men även tillverknings och fastsättningsmetoder. Med mbd etableras produkten en gång och informationen återanvänds i processer nedströms, exempelvis verktygs konstruktion, beredning, tillverkning och underhåll. Traditionellt har man jobbat med 2d ritningar som skrivs ut, vilket är tids ödande vid bland annat ändringshantering. En pappersritning blir dessutom väldigt platt och ger inte samma möjlighet att säkra kvaliteten på produkter som 3d baserade underlag medför. mbd är nära besläktat med virtuell produktutveckling, där man också använder sig av simuleringar för att bland annat verifiera att ledtider och kostnader i utvecklingsprojekt. Vilka råd kan du ge till företag som funderar på att börja införa ett mbd-arbetssätt? Framför allt ska man ha respekt för att det tar tid att införa nya system och arbetssätt. mbd ställer krav på organisationen och medför nya sätt att arbeta och samarbeta. Exempelvis kan gamla roller försvinna, nya kan tillkomma, vissa kan få ett utökat arbetsinnehåll. Det är viktigt att tidigt försöka få med blivande användare, så att system och arbetssätt kan anpassas för att matcha de olika verksamheternas krav. Jag tycker inte att man ska uppfinna hjulet, utan försöka lära sig av andras framgångar och misstag inom området. Men man ska också komma ihåg att införande av ett mbd arbetssätt kan se olika ut på olika företag. I slutändan är det alltid företagets önskan om ambitionsnivå på lösning som avgör omfattningen på ett införande. Vilka trender finns inom mbd-området? Vi ser att fler och fler företag börjat intressera sig för metoden. Tidigast ute var flyg och fordonsindustrin. Men nu börjar även många mindre företag upptäcka fördelarna med mbd. Just nu pågår det mycket arbete kring arbetsinstruktioner i 3d och nya forskningsprojekt startar inom det området. Andra områden där det pågår mycket forskning och utveckling är simulering, där utveckling sker för att tekniken ska kunna användas inom fler tillämpningsområden än tidigare och då på ett mer effektivt sätt. Samtidigt finns en strävan att öka användarvänligheten och på så sätt göra tekniken tillgänglig för fler än tidigare. Kalender: Här möter du Combitech: 10 dec Frukostseminarium, Växjö:»Agil testning«12 feb Säkerhetsdagen, Stockholm feb World ATM Congress, Madrid 21 mar Rakeldagen, Stockholm För fler evenemang, combitech.se nästa nummer ute mars 2013 Detta och äldre nummer hittar du som pdf-filer på vår webbplats. KorTAre utvecklingstid och allt mer komplexa produkter. Kraven för att hänga med i konkurrensen är höga idag inom hela tillverkningsindustrin. Men det finns metoder för att utveckla både snabbare och till bättre kvalitet. I nästa nummer fokuserar vi på just produktutveckling och reder ut begrepp som cfd, MBd och fem. combitech.se/ontime