Utifrån vad respondenterna uttryckt framgår det att grundläggande tankegångar gällande roller är betydande för att lyckas skapa enhetlighet och undvika bristande struktur i agila IT-projekt i praktiken. Värdet av rätt personer på rätt roller anses även det som en kritisk utmaning i agila projekt, då det handlar mycket om kunskap och vägledning genom projekt speciellt när det kommer till produktägare eller product owner. Rollen i fråga bör besitta viss kompetens när det kommer till kravanalys, alternativt ha en person nära till hands med kunskapen (Lindblom et al., 2017). Med rätt kompetens på rätt roll i det agila projektets kravhantering ökar möjligheterna för en god struktur samt för att lyckas med resultatet. I teorin kan en potentiell lösning vara att rollerna bör i viss utsträckning planeras i förväg så att rätt personer axlar rollerna utifrån tidigare kunskaper och erfarenheter relaterade till
rollen. Detta är något som även kan appliceras på utmaningen agil obalans som nämnts tidigare. Respondenterna är alla eniga om att agila projekt skiljer sig åt, delvis påstås detta bero på att kund eller beställare utser olika typer av erfarenheter till kravställare.
Fokus kan utan tvekan ses som en viktig del i allt vi gör. Såklart går detta påstående även att applicera på kravhanteringen i agila projekt. Detta innebär att i vissa fall ligger fokus på fel saker, det kan röra sig om designfrågor när det i själva verket är funktionskrav som är viktigare att besvara samt fastställa. Respondenterna är i majoritet eniga om att detta är en grundläggande orsak till varför bristande struktur uppdagas i agila projekt. I och med att kommunikation är en stor del av det agila arbetssättet är det därför viktigt att båda parterna beaktar ett fokus över alla delar i kravställningen som är av värde för att slutprodukten i fråga ska bli så bra som möjligt. Flertalet respondenter uttrycker här att en tydlig agenda bör sättas, och en ledare med erfarenhet och kompetens behöver styra gruppen i rätt riktning för att således minska risken för bristande struktur inom agila IT-projekt. De “lösningar” som presenterats ovan kan appliceras praktiskt i projekt för att förebygga och möta denna form av problematik.
I kategorin överarbete framhävs vikten av samarbete och att båda parter tillsammans måste komma överens om hur arbetet ska fortlöpa. Det gäller att inte förlita sig på att alla kravförändringar ska ske under projektets gång. Detta på grund av att om ett arbete kring ett krav redan inletts och ett nytt krav dyker upp som ogiltiggör det första kravet har onödiga resurser satsats på det tidigare kravet (Hoda & Murugesan, 2016). Cohn (2006) menar att en balans i planering och estimering måste existera för att lyckas. Överarbete leder till slösade resurser och att resultatet blir ofta lika misslyckat som vid underarbete.
Överarbete är ett relativt begrepp i den meningen att det inte existerar någon utnämnd gräns för hur mycket eller lite resurser och tid som bör läggas på kravhanteringen. Vissa krav är absolut viktigare än andra och kräver därför mer tid och omsorg, vilket respondent 2 styrker. Det intressanta är däremot att en obalans är lika förödande oavsett åt vilket håll det sker. Den generella lösningen i praktiken är att följa de agila principerna, att arbeta iterativt med kraven för att hitta den optimala lösningen (Cohn, 2006). Att hitta balansen genom att sätta upp tillräckliga krav i ett tidigt skede för att senare ständigt förfina dem. Det handlar om att i ett tidigt skede inse att “bollen blir inte rundare hur längre man än
håller på med att försöka få den rund” (R7). Samtidigt som bollen bör få en någorlunda
rund form innan den sparkas vidare.
Den tredje utmaningen, agil obalans, är inte identifierad i tidigare forskning, utan här uppvisas en utmaning som anses ny. Det som diskuteras nedan är således endast utifrån resultat och forskning vilket anses korrelera med den givna utmaningen. Agil obalans utmärker sig i studien bland annat+ genom att individer besitter fel roller i agila projekt. Detta uppstår genom att personer inte är motiverade eller inte har tillräcklig kunskap eller erfarenhet av specifika roller. Inom agila projekt existerar inte specifika roller i samma utsträckning som tidigare, men i varje agilt projekt bör ändå någon form av roller vilka besitter kompetens inom specifika områden finnas (Lindblom et al., 2017). Detta är rimligt då alla inte kan vara specialister inom alla områden. Med detta utgångsläge bör den potentiella lösningen på detta problem i praktiken vara att placera varje individ med rätt kompetens på rätt plats för att således undvika dessa problem. Viktigt att notera är att denna lösning inte stärks i vår studie utan diskuteras endast som en potentiell lösning då
det relaterar till utmaningen. Vidare forskning krävs för att med säkerhet kunna hitta svar och lösningar samt styrka det som nu identifierats.
Det är av stort värde i projekt att identifiera agil obalans i ett tidigt skede, detta för att det inte ska gå för långt, att problemet blir mer komplext att lösa än vad det behöver vara (Gustavsson, 2016). Inom agila projekt är inte uppföljning av en tydlig plan i fokus, utan istället satsar man på att göra det som krävs för att skapa värde (Skoogh, 2012). Att följa denna agila princip kan vara en form av lösning när agil obalans uppdagas i projektet, då avvikningar och oförutsedda aktiviteter kan behövas ta i akt. Medvetenhet av utmaningens existens kan absolut bidra till tidiga åtgärder samt att agil obalans minskar på sikt. Studiens resultat indikerar på att agil obalans existerar i många agila IT-projekt och det slår hårt mot kravhanteringen och projektet i stort. Därav är det högst nödvändigt att hitta ett kontinuerligt sätt att arbeta med att förebygga och motverka detta problem genom exempelvis genomgångar och utvärderingar av tidigare projekt Lindblom et al., 2017).
Utöver andra lösningar kan till ytan en enkel lösning sättas i relation till problemet, att alla organisationer måste göra en tydligare övergång mot att arbeta agilt. Det kan innebära att våga utmana sig själva som verksamhet, att faktiskt ta krafttag genom att gå utbildningar och att man således i praktiken kan nå upp till en rimlig agil nivå. Vilket sedan bör följas upp med att inför varje projekt klargöra hur man vill arbeta och vad man har kapacitet till så att båda parter förhåller sig till varandra och således hittar en agil balans. Detta är ett rimligt antagande av oss författare givet den data som samlats in, och hur den tolkats. Den tidigare forskningen styrker däremot inte detta då agil obalans inte upphittats till samma utsträckning som de andra huvudsakliga utmaningarna, bristande struktur och överarbete. Detta bör därför beaktas då vår egen erfarenhet tar mer plats i denna del för att hitta och presentera potentiella lösningar för praktiken. Ytterligare forskning önskas och bör således utföras för att på ett vetenskapligt och trovärdigt sätt ge exempel på praktiska lösningar.
6. Slutsats
Tidigare forskning visar att det existerar utmaningar inom kravhantering i IT-projekt, vilket idag är välkänt. Det agila arbetssättet är numera den mest nyttjade arbetsformen och av rimliga skäl visar forskning (t.ex. Cao & Ramesh, 2008; Lindblom et al., 2017) på att det även existerar utmaningar inom agil kravhantering, vilket leder till en variation av konsekvenser. Resultatet av denna studie styrker detta och visar i viss utsträckning på samma sak. Den agila kravhanteringens största utmaningar är enligt studien till antalet tre,
agil obalans, bristande struktur samt överarbete. Utmaningarna anses vara de främsta
kopplat till agil kravhantering då samtliga respondenter givit uttryck för relaterade faktorer, vilka sedan har analyserats och remonterats till de tre givna utmaningarna. Bristande struktur och överarbete är relativt talande för sig själva vad dessa innebär, de orsakas ofta av bland annat bristande planering och dokumentation. Agil obalans påvisas däremot genom att de olika parterna i ett projekt befinner sig på en ojämn agil nivå i arbetssätt vilket komplicerar kravhanteringsprocessen. Till skillnad från de andra två utmaningarna har agil obalans inte påträffats i tidigare forskning i samma utsträckning, vilket gör studiens resultat unikt och mer intressant.
För att kunna leda ett projekt framåt på ett framgångsrikt sätt är det av stor betydelse att analysera och fastställa, beroende på utmaning, hur denna ska förebyggas och eventuellt hanteras under projektet genom att konstatera en tydlig planering. Av denna anledning har orsaker och flera tillvägagångssätt diskuterats till respektive utmaning för att skapa enhetlighet och ett omfång kring utmaningarna. Bakomliggande orsaker som diskuterats i relation till utmaningarna handlar om allt från att ett traditionellt tankesätt lever kvar i många organisationer till att fel prioriteringar görs inom kravhanteringen. Lösningar som diskuterats handlar i mångt och mycket om ett fungerande samarbete, överenskommelser och styrning av projektet. Studien har i huvudsak inte påvisat några lösningar utan endast diskuterats. Vidare forskning kring mer specifika lösningar på de utmaningar som kan uppstå i kravhanteringen i ett agilt projekt är således bristfälligt och eftertraktat till alla tre utmaningarna. Samtidigt anses området vara uppkommande och mer forskning kring agila projekt ökar.
Krav som ställs i agila projekt betraktas varierande, sett till individ kopplat till dess roll och projekt. Därför varierar också de följande utmaningarna kopplade till kravhanteringen. Utmaningar förekommer ofta och problematiken som de medför önskas undvikas i allra högsta grad om det är möjligt. När kunskap finns gällande huruvida en utmaning kan uppkomma, kan antagandet av den underlättas. Utmaningar kan även upptäckas innan de uppstår vilket kan vara vitalt för kravhanteringen i agila projekt. Det som skapats och tagits fram i denna studie hoppas vi kommer bidra till en ökad förståelse för uppkommande problematik inom kravhantering i agila IT-projekt. Samtidigt som det förhoppningsvis leder till att förebyggande tilltag underlättas och att uppkommande utmaningar således minimeras i framtida projekt.
Referenser
Baker, Lynda M. 2006. Observation: a complex research method (Ethnological methods). Library Trends. 55(1), pp.171–189.
Baruah, N. (2015). Requirement Management in Agile Software Environment. Procedia Computer Science, 62(C), 81–83.
Beck, K. and Andres, C. 2005. Extreme Programming explained: embrace change. 2. ed. Boston: Addison-Wesley.
Boehm, B. 2002. Get ready for agile methods, with care. Computer. 35(1), pp.64–69. Chin, G. 2004. Agile project management: how to succeed in the face of changing project
requirements. New York: AMACOM.
Cohn, M. 2006. Agile estimating and planning. Upper Saddle River, NJ: Prentice Hall Professional Technical Reference.
De Lucia, A., and Qusef, A. (2010). Requirements engineering in agile software
development. Journal of Emerging Technologies in Web Intelligence, 2(3), 212–
220.
Denscombe, M. 2018. Forskningshandboken: för småskaliga forskningsprojekt inom samhällsvetenskaperna. Fjärde upplagan.
Duka, D. 2012. Agile experiences in software development: In 2012 Proceedings of the 35th International Convention MIPRO. IEEE, pp.692–697.
Eriksson, U. (2008). Kravhantering för IT-system. Lund: Studentlitteratur
Gustavsson, T. 2016. Agil projektledning Tredje upplagan. Stockholm: Sanoma utbildning.
Hoda, R. and Murugesan, L.K. 2016. Multi-level agile project management challenges: A self-organizing team perspective. The Journal of Systems & Software. 117, pp.245– 257.
Holtkamp, P. Jokinen, J. and Pawlowski, J. (2015). Soft competency requirements in
requirements engineering, software design, implementation, and testing. The
Journal of Systems & Software, 101(1), 136–146.
IEEE International Standard (1990). Standard Glossary of Software Engineering. 160.12-1990, 1-84.
Inayat, I.S., Salim, S.S., Marczak, S., Daneva, M. and Shamshirband, S. 2015. A systematic
literature review on agile requirements engineering practices and challenges.
Computers in Human Behavior. 51, pp.915–929.
Keegan, S. 2009. Qualitative research: good decision making through understanding people, cultures and markets. London; Philadelphia: Kogan Page.
Cao, L and Ramesh, B. 2008. Agile Requirements Engineering Practices: An Empirical Study. IEEE Software. 25(1), pp.60–67.
Larsson, S. 1986. Kvalitativ analys - exemplet fenomenografi. Studentlitteratur, Lund. Lindblom, A., Blom, K., & Wirén, J. (2017). Agil kravexpert: agilt och krav i praktiken.
Magnusson, E. and Marecek, J. 2015. Doing interview-based qualitative research: A learner’s guide. Cambridge University Press.
Maher, L., and Dertadian, G. (2018). Qualitative research. Addiction, 113(1), 167–172. Merriam, S.B. and Nilsson, B. 1994. Fallstudien som forskningsmetod. Lund:
Studentlitteratur
Paquette, P., and Frankl, M. (2016). Agile project management for business
transformation success (First edition.)
Project Management Institute Corporate Author. (2013). Agile project management: essentials from the Project Management Journal.
Repstad, P. & Nilsson, B. 1993. Närhet och distans: kvalitativa metoder i samhällsvetenskap. 2. uppl. Lund: Studentlitteratur.
Robertson, S. and Robertson, J. (2013). Mastering the Requirements Process: Getting Requirements Right. (3. uppl..). Massachusetts. Pearson Education, Inc.
Sawyer, P., Paech, B., and Heymans, P. (2007). Requirements Engineering: Foundation
for Software Quality: 13th International Working Conference. REFSQ 2007.
Trondheim, Norway. June 11–12, 2007. Proceedings.
Skoogh, P.-M. (2012). Agile for managers: successful teams that deliver. Göteborg: Stockholm: mPeira; Publit [distributör].
Vanderjack, B. 2015. The Agile edge: managing projects effectively using Agile Scrum. First edition.
Vetenskapsrådet. (2002). Forskningsetiska principer inom humanistisk-samhällsvetenskaplig forskning. Stockholm: Vetenskapsrådet.
Widerberg, K. (2002). Kvalitativ forskning i praktiken. Lund: Studentlitteratur.
Wiktorin, L. Utveckling Av IT-system: Krav, Metod Och Arkitektur. Upplaga 1. ed. 2018. Yin, R.K. & Retzlaff, J. 2013. Kvalitativ forskning från start till mål. 1. uppl. Lund: