De arbetssätt som gruppen utgick från var Kanban och en modifierad version av Scrum. Användandet av en Kanban-tavla i Trello fungerade mindre bra, dels på grund av att det var väldigt svårt att dela upp projektet i konkreta uppgifter som krävdes för att kunna använda Kanban. Om mer grundläggande efterforskningar kring de olika modulerna, dess dokumentation och funktionalitet hade gjorts, så hade det troligtvis varit lättare att skapa konkreta uppgifter och därmed hade Kanban kunnat användas mycket effektivare. I projektets senare skede, när Trello blivit ersatt av en whiteboard, arbetades det nästan enbart med visualiseringen, då fungerade Kanban-tavlan mycket bättre eftersom att kraven på visualiseringen var konkreta och lätta att dela upp.
Kommunikationen med kunden var vital för projektets framsteg. I början av projektet var
kommunikationen väldigt sporadisk och framsteg gjordes långsamt. Efter att gruppen fick tillgång till arbetsrummet i närheten av kundens kontor så förbättrades kommunikationen markant. Detta ledde till att gruppen blev medveten om nya krav och synpunkter från kunden som tidigare var okända när
kommunikationen skedde sporadiskt. Exempelvis gav kunden förslag på alternativa program som kunde användas, när det uppdagades att ett tidigare valt program var inkompatibelt för integration med de övriga modulerna. Kravet på ACID-transaktioner var något som kom fram i ett relativt tidigt skede på grund av den goda kommunikationen. Något som var väldigt givande var att konstant kunna få feedback på det utförda arbetet och detta var något som hjälpte gruppen att styra projektet i rätt riktning, då kunden snabbt kunde ge återkoppling på de lösningar gruppen gjort för att förkasta felaktiga lösningar i ett tidigt skede. Om kommunikationen med kunden hade varit fortsatt sporadisk så som den var i början, hade troligtvis slutprodukten sett annorlunda ut och det finns en stor risk att den inte hade nått upp till kundens
förväntningar, även om den hade uppfyllt de krav som var specificerade till en början i kravspecifikationen.
6.2.1 Modifierad Scrum
Den ursprungliga planen var att använda originalversionen av Scrum, men gruppen insåg fort att det inte passade in för det projektet som utfördes. Gruppen valde att utföra sprintar som var en vecka långa, jämfört med en månad som är normen enligt Scrum, eftersom behovet av att dela gemensamma erfarenheter i gruppen om de nya teknikerna var stor. Detta ledde till att framsteg med hela produkten gjordes snabbt när godtyckliga kunskaper hade införskaffats kring de separata modulerna av systemet. Hade sprintarna varit en månad långa så fanns en risk att utvecklingen hade gått långsammare, då
kommunikation kring funktionaliteten hos de enskilda modulerna och sättet att integrera dem var vital för att skapa slutprodukten.
Projektgruppen tog beslut om att revidera och skräddarsy Scrum för att bättre passa gruppens arbetssätt. Gruppen arbetade nästan enbart tillsammans och kommunikation sinsemellan var väldigt god. Detta ledde till att den hårda strukturen i Scrum löstes upp och ett mer organiskt arbetssätt presenterade sig.
Standup-möten hölls inte varje dag eftersom det ofta inte var nödvändigt, istället hölls de vid behov. Gruppen valde att inte ha en Scrum Master eftersom det kändes överflödigt och inte tillräckligt givande då gruppen arbetade väldigt synergiskt. De kortare sprintarna passade projektet väl då gruppen var liten och träffade varandra nästan dagligen.
6.2.2 Dokumentskrivning
Det arbetssätt som valdes för att skriva dokument var att projektgruppen vid vissa tillfällen träffades och fokuserade på dokumentskrivning gemensamt. Alla satt tillsammans och skrev på dokumenten, vilket gjorde att diskussion kunde ske och hjälp kunde fås snabbt. Vid dessa tillfällen valde projektgruppen att dela upp dokumenten bland medlemmarna, vilket gjorde att detta blev en effektiv process. För att hålla en hög kvalitet på dokumenten valde gruppen även att kontrollera dokumenten. Genom att när dessa var färdigskrivna gick varje gruppmedlem igenom varje dokument och sedan hade gruppen en diskussion om det aktuella dokumentet.
6.2.3 Testning
Som nämns under punkt 5.3 där resultatet av testning beskrevs så användes testplanen till en väldigt liten del och istället så skedde all testning kontinuerligt på egen hand eller i grupp. Då i stort sett alla verktyg som användes av gruppen aldrig hade använts innan så var projektmedlemmarna tvungna att läsa på och testa en hel del för att lära sig. Då utvecklingen av produkten bestod mycket av konfigurering och inte lika mycket kodande så testades det ofta för att se om konfigureringen var rätt. Därav fungerade det bra för hela projektgruppen med att testa kontinuerligt när det väl behövdes utan att följa testplanen. För projektgruppens del så fungerade black-box testningen bra och det var något som hjälpte gruppen i ett tidigt skede för att förstå hur de olika systemen fungerade individuellt. Det var även något som
underlättade när integrationen av olika system gjordes, eftersom att gruppens kunskap om funktionaliteten hos systemen inte var särskilt god. Således kunde mer tid läggas på själva integrationen av systemen, än att lära sig exakt hur varje systems arkitektur och inre funktionalitet såg ut.
6.2.4 Systemanatomi
en god överblick över systemets delar och beroenden sinsemellan. Under projektets gång hade gruppen möjlighet att med jämna mellanrum se över systemanatomin för att se till att utvecklingen av produkten följde dess upplägg. Även då det till en början var svårt att skapa en systemanatomi så blev tillslut alla gruppmedlemmar ense om slutresultatet och kunde enkelt förstå dess upplägg. Systemanatomin följdes under hela projektets gång men eftersom den ej var komplicerad så sågs den över till största del endasts under första iterationen då det senare kom naturligt hur produkten skulle utvecklas utan att behöva kolla på systemanatomin över och över igen.