Syftet med arbetet är att identifiera svårigheter med att argumentera för den agila projektmetodiken till en beställare. Arbetet har även till syfte att ge rekommendationer på hur en organisation kan stärka sin argumentation för den agila metoden ut mot beställaren. För att uppnå arbetets syfte har den kvalitativ forskningsintervju och en litteraturgenomgång tillämpats. Resultatet visade att svårigheterna är att alla yrkesroller internt inom organisationen inte har en och samma definition över vad den agila metoden innebär. Den nuvarande agila modellen ansågs också av flertalet respondenter inte vara tillräckligt utarbetad. Det behövs utbildning, engagemang och en skräddarsydd prissättningsmodell som är anpassad efter den agila metoden för att stärka argumentationen om val av den agila projektmetodiken.

När man bedriver IT-projekt utgår man ofta från någon form av metod för att underlätta projektarbetet. En projektmetod, som ofta baseras på ett projektramverk, är ett tillvägagångssätt för hur ett visst resultat ska tas fram. Inom IT-projekt kan dessa metoder vara av sekventiell och/eller agil karaktär. Sekventiella projekt kännetecknas vidare av projektfaser som löper stegvis, medan agila projektfaser är mer lättrörliga. En nyckelperson i projekt är vidare projektledaren. Projektledarskap handlar primärt om att lyckas motivera sina teammedlemmar till att uppfylla uppsatta mål. Det kräver vidare förmågan att vara människa, expert och mentor samtidigt, vilket i nästa tur också kräver mellanmänskliga relationsförmågor. Beskrivningar av mellanmänskliga relationsförmågor är dock något som projektramverk tenderar att utesluta. Vidare är dåligt ledarskap en stor faktor för misslyckande under ett projekts framställningsprocess, då det kan skapa förakt eller minska motivation hos medarbetare. Syftet med denna studie har sålunda varit att undersöka hur projektledarskap kan anpassas till IT-projekt som kombinerar sekventiella och agila metoder.I IT-projekt som kombinerar sekventiella och agila faser kan man då ställa frågan vilken projektledning som passar? Syftet med rapporten har sålunda varit att utreda vilka ledarsätt som passar dessa typer av IT-projekt. Det rapporten kommit fram till är att projektledning i sekventiella metoder betonar kontroll och fokuserar på att se till att medarbetare utför sina arbetsuppgifter inom bestämd tidsram och budget. Projektledning i agila metoder är i nästa tur mer pragmatisk och lättrörlig, samt ställer större krav på förmågan att kunna fatta snabba beslut. En projektmetod som kombinerar sekventiella och agila faser behöver en kontrollorienterad projektledare, men som samtidigt kan anpassa sig till olika arbetssituationer. Vidare är det också fördelaktigt om denna typ av projektledare besitter tekniska färdigheter. För att effektivisera projektarbetet ytterligare bör också projektledaren kunna situationsanpassa ledarskapet till medarbetare.­

Covid-19-pandemin har medfört ett skifte från samlokaliserat arbete till distansarbete. Den här studien syftar till att förklara vilka effekter distansarbete har på teamwork i agila teams. Studien genomfördes genom djupintervjuer enligt kvalitativ metod, med teammedlemmar på en svensk bank, och analysmodellen baseras på Dickinson och McIntyres teamworkmodell, där komponenterna delade mentala modeller och förtroende adderats. Resultatet indikerar att respondenterna upplever att teamwork förändrats negativt vid distansarbete genom hela modellen, med undantag för teamorientering och teamledarskap. Där upplevs marginell negativ förändring eller ingen förändring. Den agila strukturen upplevs vara en kritisk faktor för att upprätthålla fungerande teamwork vid distansarbete. Kommunikationen face-to-face har dock minskat, vilket leder till flera teamworkutmaningar. Tidigare uppbyggt förtroende och delade mentala modeller verkar underlätta teamwork vid distansarbete. Eftersom trenden indikerar att distansarbete kommer vara aktuellt även efter Covid-19-pandemin måste dessa utmaningar behandlas. Den utvidgade teamworkmodellen verkar kunna förklara effekten på teamwork vid distansarbete i agila teams.

Empati mellan interaktionsdesigners och utvecklare är viktigt för att samarbetet ska fungera och för att parterna ska kunna kommunicera med varandra. Detta tillsammans med förmågan att se situationer ur varandras perspektiv är något som påverkar samarbetet avsevärt. Empati bygger på förståelse, förstår man andra personers perspektiv kan man också känna empati för andra personers prioriteringar och ta hänsyn till dessa. Det är också av stor vikt att interaktionsdesigners och utvecklare har en gemensam bild av situationen och de projekt de arbetar med. En förstudie som genomfördes under hösten 2013 visade att interaktionsdesigners upplevde att utvecklare inte känner empati för deras arbete vilket de upplevde har skapat problem i samarbetet. För att få en djupare förståelse för detta genomfördes en fenomenologisk studie där nio interaktionsdesigners intervjuades. Resultatet visade att interaktionsdesigners upplevde att utvecklare ibland ändrar i en design utan att diskutera detta med dem vilket gör att syftet med designen kan falla bort och i vissa fall känner interaktionsdesigners inte igen sin design i den färdiga produkten. De upplevde även att utvecklare ser på design som något onödigt eller lyxigt som inte behövs för att ta fram bra produkter. Utvecklingen har istället varit det som ses som viktigt och prioriterats i projekten. Interaktionsdesigners har även upplevt denna bristande förståelse på organisatorisk nivå, exempelvis när kunder inte köpt deras tjänster fram tills att produkten är färdig. Därför har det inte funnits möjlighet till avstämning mellan interaktionsdesigner och utvecklare under tiden utvecklare implementerar designen. Missförstånd har då uppstått och produkten har inte nått sin fulla potential. Vissa anser att en stor del av problemet grundar sig i detta, att utvecklare inte i sitt arbete uppmuntras diskutera designen eller följa upp implementationen med den som skapat designen. / Empathy between interaction designers and developers is important in order for the collaboration to work and for them to be able to communicate with each other. This, as well as the ability to see situations from other persons perspective, is something that affects collaboration significantly. Empathy builds on understanding, if one understands other persons perspective one can also feel empathy for other persons priorities and take these in to consideration. It is also of great importance that interaction designers and developers have a common picture over the situation and the projekts they are working with. A pre study was carried out in the fall of 2013 and showed that interaction designers felt that developers does not have empathy for their work, which they experienced has created collaboration problems between them. In order to create a deeper understanding for this, a phenomenological study was carried out where nine interaction designers were interviewed. The result showed that interaction designers felt that developers sometimes changes a design without discussing it with them, which can lead to deviations from the purpose of the design and in some cases the designers does not recognize their design in the developed product. The interaction designers also felt that developers think design is something unnecessary or luxury that is not needed in order to create successful products. The development is instead seen as what is important and what is prioritized in the projects. Interaction designers have also experienced this lack of understanding at an organizational level, for example when customers have not bought their service all the way, until the product is done and ready for release. Because of this there has not been possible for the interaction designers and the developers to talk to each other during the development process. Misunderstandings have then occured and the product has not lived up to its full potential. Some believe that a big part of the problem originates from this, that developers in their work is not encouraged to discuss the design with the interaction designer that created it.

This study explores stakeholder analysis and requirements engineering within an agile project at a system development company requesting a case management system. Stakeholder analysis is commonly explored in traditional project planning studies, such as the waterfall model. In agile projects, on the other hand, it is not common to have a project-planning phase or to carry out a stakeholder analysis, often due to that a stakeholder analysis entail a long and extensive documentation. Our study explores how Soft Systems Methodology can be used in an agile project-planning phase as well as how rich pictures from the SSM support requirements engineering. The study is based on an agile method in which the project-planning phase is expected to deliver a product log, and hence a requirements list. Requirements are collected, modelled and validated together with users in the form of user stories where role, goals and purpose are expressed in a sentence. Stakeholders and roles are identified and analyzed using methods in Soft Systems Methodology, like "finding-out" analyses. The result is then presented in so called rich pictures of the current situation and in a future desired situation. The data collection is carried out together with informants at the case company in the form of observations and semi-structured interviews. The result of the study indicates how rich pictures from SSM can support the start-up of an agile project. / Denna studie utforskar intressentanalys och kravinsamling inom ett agilt projekt på ett systemutvecklingsföretag som efterfrågar ett ärendehanteringssystem. Intressentanalyser är vanligt förekommande och utforskade i traditionella förstudier så som enligt vattenfallsmodellen. I agila projekt är det däremot vanligt att en förstudie inte utförs eller att förstudien inte innehåller en intressentanalys, ofta på grund av att intressentanalyser innebär lång och omfattande dokumentation. Vår studie utforskar hur Soft Systems Methodology kan användas i en agil förstudie samt hur rika bilder från SSM stöttar kravhantering. Studien utgår från an agil metod där förstudien förväntas leverera en produktlogg, där studiens fysiska bidrag blir en kravlista. Krav samlas in, modelleras samt valideras tillsammans med användare i formen av användarhistorier där roll, mål och syfte uttrycks i en mening. Intressenter och roller identifieras och analyseras med hjälp av metoder inom Soft Systems Methodology, som exempelvis ”finding out”-analys. Resultatet presenteras därefter i så kallade rika bilder över nuvarande situation samt i en framtida önskad situation. Datainsamlingen görs tillsammans med informanter på ett fallföretag i form av observationer och semistrukturerade intervjuer. Utfallet av studien visar hur den rika bilden från SSM kan stödja uppstarten av ett agilt projekt.