Context. Software engineers have been endeavouring to quantify software to obtain quantitative insights into its properties and quality since its inception. As of late, the use of Lean and Agile (LeAgile) methodologies is turning out to be progressively mainstream in the software industries. Managing software life-cycle tasks including planning, controlling and monitoring is primarily done by measurements. This is particularly valid in LeAgile organizations where these are day-to-day activities. On other words, dealing with agile development process like in any process, requires the collection of appropriate metrics to ensure visibility, inspection and adaptation as it is vital to know the effect of these methods and how product development and projects are performing. Are the goals being met? Are there any wastes? Is value being created? All of this is dependent on the ability to measure as correct and as objective as possible. Getting good metrics and interpreting them correctly is central in any product development organization. In agile approaches, the use of any metric needs to be clearly justified to decrease the amount of inefficient work done. This draws the need to discover metrics that are relevant to LeAgile methods to entail the benefits of measurement. Objectives. The main objective of this paper is to understand the current state-of-the-art and state-of-the-practice on the metrics usage in LeAgile methods. Additionally, to identify metrics that are suitable and have a high strength of evidence for their usage in the industries. Likewise, to construct a LeAgile measurement model based on the application of the metric’s context. Methods. This paper presents a two-step study; Firstly, a Systematic Literature Review (SLR) is conducted to present the state-of-the-art on using metrics in LeAgile Software Development. Second, to allow a better understanding of what measures are currently being used in collaboration between industry and academia, we have performed a case study at Telenor. Results. We found that metrics was mainly used to have an efficient flow of software development; to assess, track and improve product quality; for project planning and estimations; for project progress and tracking; to measure the teams and others. Additionally, we present the metrics that have compelling use and are worthy to be used in the industries. Conclusions. We conclude that traditional metrics or besides any metric can be used in an LeAgile context, provided they do not harm the agility of the process. This study identified 4 new metrics namely Business Value, Number of disturbance hours, Team Health check survey and Number of hours spent on IT divisions that are not present in the state-of-the-art. The gaps identified in the LeAgile measurement model built in this study can provide a roadmap for further research pertaining to the measurement model. Any of the topics identified as a means of completing the LeAgile measurement model developed in our study can be a fruitful area for future research.

Context. Global Software Development is software work undertaken at geographically separated locations across national boundaries in a coordinated fashion involving real time or asynchronous interaction. Distributed Agile Development aims at the benefits of both Agile Software Development and Global Software Development aiding the distributed teams to overcome the challenges brought by the distribution. Objectives. In this study the author investigates whether a globally distributed company is prepared to be agile, determining hindrances for agile and providing recommendations to mitigate or overcome the detected hindrances. Methods. In this case study, surveys and interviews were used to study the hindrances for agile and literature was used to provide the recommendations towards the detected hindrances. Results. 4 hindrances were detected. Only 1 was justified as necessary for the good performance of the distributed company. Several recommendations to overcome the hindrances were proposed. Both hindrances and proposed solutions were validated by the company representative. Conclusions. We conclude that the studied individuals are willing to be agile. As agile is built bottom-up, the company is prepared to be agile. However, they will not be able to be agile until they overcome or mitigate the detected challenges. In the study, several solutions for it are proposed.

Syftet med arbetet var att ta reda på om den ökade tidsåtgången som parprogrammeringen leder till uppvägs av de fördelar som den genererar i jämförelse med enskild programmering där arbetet delas mellan två programmerare och sedan integreras. I arbetet presenteras resultatet från en enkätundersökning som sju personer från fyra olika företag i Sverige har besvarat. Samtliga personer som besvarat enkäten har arbetat både med enskild programmering och parprogrammering. Vårt arbete bidrar till forskningsområdet programvaruteknik som intresserar sig för mjukvaruutvecklingsmetoder. På senare tid har detta forskningsområde också intresserat sig för lättrörlig mjukvaruutveckling där utvecklingsmetoden Extreme Programming (XP) ingår. XP tillämpar parprogrammering och är en mjukvaruteknisk metod som har att göra med klassisk mjukvaruteknik som bl.a. utgår ifrån kodkvalite och samspel mellan utvecklare. (Rittenbruch m.fl, 2002) I den litteratur vi läst har det presenterats en undersökning som gjorts i USA om parprogrammering. I den konstaterades att detta arbetssätt ger en ökad tidsåtgång och det framkom också ett antal fördelar med att programmera i par. Vi har utgått ifrån tidsåtgången och fördelarna när vi gjorde vår enkätundersökning. Vi fann att vår undersökning styrker de fördelar som finns med parprogrammering, men däremot bekräftar inte undersökningen att tidsåtgången ökar. Samtliga i undersökningen tycker att kodkvalitén förbättrats, dvs bättre struktur och design samt mindre fel på koden. Sammanhållningen och kommunikationen har blivit bättre och fler programmerare är involverade i samma kod. Detta innebär att projektgruppen inte påverkades så mycket när en person lämnar projektet. Det har också framkommit att parprogrammering inte är lämpligt att använda vid enklare uppgifter.

På senare tid har agila systemutvecklingsmetoder trätt fram på marknaden, metoder som värderar flexibilitet, kundmedverkan och fokus på utvecklingsteamet och fungerande mjukvara snarare än fokus på utvecklingsverktygen och dokumentation. Vi vet dock inte vilken typ av systemutvecklingsmetod som verkligen är bättre än den andra. Den här uppsatsen består av en historisk översikt av systemutvecklingsmetoder och en undersökning kring graden av belåtenhet med olika typer av systemutvecklingsmetoder och attityden till de agila värderingarna. Genom en kvantitativ studie har svenska organisationer som utövar systemutveckling tillfrågats angående detta. Resultaten är inte helt säkra, men anspelar på att utövare av mer traditionella systemutvecklingsmetoder var något mer nöjda med sin metod än utövare av agila metoder var, men de agila utövarna var istället mer nöjda med hur deras metod hjälper dem med att tillgodose kundernas behov och önskemål än de traditionella utövarna var. Båda typerna av systemutvecklare var mer positiva till de agila värderingarna än deras motsatser, men de agila metodutövarna var positiva till en större utsträckning. / Recent times have seen the emergence of agile software development methods, valuing flexibility, customer collaboration, and focus on the development team and working software rather than focus on tools and documentation. What is unknown is which type of software development method is really better than the other. This thesis consists of a historical overview of software development methods and an investigation of the level of satisfaction with different types of software development methods and the attitude towards the agile values. Through a quantitative study, Swedish software development organizations have been heard regarding these issues. The results, although not fully statistically supported, indicate that practisers of more traditional software development methods were slightly more satisfied with their methods than practisers of agile methods were, but the agile method practisers were instead more satisfied with how their method helped them in satisfying their customers’ wants and needs than the traditional method practisers were. Both types of software developers were more positive towards the agile values than their counterparts, but the practisers of agile software development methods were so to a greater extent.

Det här arbetet har med hjälp av en kvalitativ undersökning tagit fram framgångsfaktorer för parprogrammering. Detta har genomförts med hjälp av intervju samt enkätundersökningar med sex respondenter. Då litteraturen inte behandlar hur parprogrammering kan bli framgångsrikt har detta arbete haft som syfte för att göra detta. Resultatet har kategoriserats i fyra nivåer. Exempel på framtagna framgångsfaktorer är att: • ledningen måste införskaffa kunskaper om parprogrammering • projektledaren uppmuntrar till byte av par ofta • projektdeltagarna är öppna och mottagbara för konstruktiv kritik

Digitalization and digital technologies is gaining increased influence in today's society and contribute to many societal changes, globally as well as locally. This has a great impact on organizations, as well as the work methods within these. Therefore, the aim of this thesis is to study how the HR function and the role of HR have been altered by the digital transformation and which effects this may lead to. In order to find trends and identify effects, a systematic literature review has been used as a way to gain a deeper understanding of how HR has been affected by digitalization. The study has shown that digitalization has contributed to a major change in HR's role in the organization. Digital technologies open up new ways of working and new focus areas for HR, and contribute to cost-effectiveness as it frees administrative work and creates opportunities for reaching out to broad networks.

Security is today considered as a basic foundation in software development and therefore, the modelling and implementation of security requirements is an essential part of the production of secure software systems. Information technology organisations are moving towards agile development methods in order to satisfy customers' changing requirements in light of accelerated evolution and time restrictions with their competitors in software production. Security engineering is considered difficult in these incremental and iterative methods due to the frequency of change, integration and refactoring. The objective of this work is to identify and implement practices to extend and improve agile methods to better address challenges presented by security requirements consideration and management. A major practices is security requirements capture mechanisms such as UMLsec for agile development processes. This thesis proposes an extension to the popular Scrum framework by adopting UMLsec security requirements modelling techniques with the introduction of a Security Owner role in the Scrum framework to facilitate such modelling and security requirements considerations generally. The methodology involved experimentation of the inclusion of UMLsec and the Security Owner role to determine their impact on security considerations in the software development process. The results showed that overall security requirements consideration improved and that there was a need for an additional role that has the skills and knowledge to facilitate and realise the benefits of the addition of UMLsec.

Lean och dess principer är något som mer och mer branscher och företag börjar titta på, allt ifrån tjänstesektorn, sjukvården men även systemutvecklingsbranschen. Flertalet företag inom systemutveckling har gjort försök med att kombinera lean och agila principer i deras systemutvecklingsprocess, detta har skett med varierande framgång. Denna studie har som syfte att undersöka vilka fördelar och utmaningar som finns med att kombinera lean och agila principer i systemutveckling. Frågan som undersökningen har som syfte att besvara är: ”Hur kan principer ifrån Lean production och Agil kombineras för att skapa en uppsättning principer som är mer användbara för systemutveckling?” För att besvara denna fråga tillämpas en systematisk litteraturstudie och intervjuer som datainsamlingsmetoder. Detta för att kunna analysera litteraturen som tar upp hur dessa principer har kombinerats, och vilka fördelar och utmaningar som uppstod vid kombination. Men även att ta fram vad personer med kunskap och insyn inom dessa områden anser om en kombination, vad de anser en kombination kan bidra med och vilka svårigheter som kan uppstå med en kombination. Undersökningen visar att fördelar kan uppnås genom att kombinera principerna ifrån lean och agil, jämfört mot att bara följa de agila principerna. Några av dessa fördelar är kontinuerligt förbättrande, kontinuerligt lärande, mindre defekter och snabbare leverans tider. Samtidigt hade vissa av organisationerna svårigheter med att få ett kontinuerligt flöde, där team eller projekt setup hävdas vara orsaken för detta. Genom att använda lean principerna som ett ”plugin” ihop med de principer som finns i det agila manifestet, förstärks de agila principerna. Men det bidrar även till att organisationen lättare vet vad deras kund anser är värde och utifrån det, kan de sen effektivisera sina processer.

Context. Continuous delivery deals with concept of deploying the user stories as soon as they are finished rather than waiting for the sprint to end. This concept increases the chances of early improvement to the software and provides the customer with a clear view of the final product that is expected from the software organization, but little research has been done on the quality of product developed and the ways to measure it. This research is conducted in the context of presenting a checklist of quality metrics that can be used by the practitioners to ensure good quality product delivery. Objectives. In this study, the authors strive towards the accomplishment of the following objectives: the first objective is to identify the quality metrics being used in agile approaches and continuous delivery by the organizations. The second objective is to evaluate the usefulness of the identified metrics, limitations of the metrics and identify new metrics. The final objective is to is to present and evaluate a solution i.e., checklist of metrics that can be used by practitioners to ensure quality of product developed using continuous delivery. Methods. To accomplish the objectives, the authors used mixture of approaches. First literature review was performed to identify the quality metrics being used in continuous delivery. Based on the data obtained from the literature review, the authors performed an online survey using a questionnaire posted over an online questionnaire hosting website. The online questionnaire was intended to find the usefulness of identified metrics, limitations of using metrics and also to identify new metrics based on the responses obtained for the online questionnaire. The authors conducted interviews and the interviews comprised of few close-ended questions and few open-ended questions which helped the authors to validate the usage of the metrics checklist. Results. Based on the LR performed at the start of the study, the authors obtained data regarding the background of continuous delivery, research performed over continuous delivery by various practitioners as well as a list of quality metrics used in continuous delivery. Later, the authors conducted an online survey using questionnaire that resulted in ranking the usefulness of quality metrics and identification of new metrics used in continuous delivery. Based on the data obtained from the online questionnaire, a checklist of quality metrics involved in continuous delivery was generated. Conclusions. Based on the interviews conducted to validate the checklist of metrics (generated as a result of the online questionnaire), the authors conclude that the checklist of metrics is fit for use in industry, but with some necessary changes made to the checklist based on the project requirements. The checklist will act as a reminder to the practitioners regarding the quality aspects that need to be measured during product development and maybe as a starting point while planning metrics that need to be measured during the project.

Testing in agile software development is important to ensure that the rightproduct is being developed. Is it possible to include everyone in agilesoftware development by using a business readable DSL and also createtest cases based directly on that DSL?Observations, interviews, a study of literature, third degree collectedartifacts and an implementation has been performed to analyse the processof introducing Gherkin as a tool in agile software development projects.The process of performing and conducting tests has been examined at Accedoto understand how Gherkin together with CucumberJS can be usedin projects, with the purpose of increasing collaboration between dierentroles and create a ubiquitous way of referring to the same piece of softwarewithout the need to specifying implementation details.To include the entire project team in the whole process of developingsoftware is essential for a usage of Gherkin to be successful. Since thepurpose is that everyone should be able to contribute as well as understandthe progress of development in projects and share an agreement on whatis being developed. A business readable DSL provides a uniform formatto specifying tasks causing the internal communication to be improved inprojects.