department of informaticss_thesis.pdf · the agile manifesto [3] states twelve impor-tant...

DEPARTMENT OF INFORMATICSTECHNISCHE UNIVERSITÄT MÜNCHEN

Bachelor’s Thesis in Information Systems

Identifying and Documenting RecurringConcerns and Good Practices of AgileTeams of an IT Consulting Company

Simon Müller

DEPARTMENT OF INFORMATICSTECHNISCHE UNIVERSITÄT MÜNCHEN

Bachelor’s Thesis in Information Systems

Identifying and Documenting Recurring Concernsand Good Practices of Agile Teams of an IT

Consulting Company

Identifizierung und Dokumentation vonwiederkehrenden Herausforderungen und

bewährten Methoden von agilen Teams eines ITBeratungsunternehmens

Author: Simon MüllerSupervisor: Prof. Dr. Florian MatthesAdvisor: Ömer Uludag, M.Sc.Submission Date: September 15, 2019

I confirm that this bachelor’s thesis in information systems is my own work and I havedocumented all sources and material used.

Munich, September 15, 2019 Simon Müller

Abstract

Since the publication of the Agile Manifesto in 2001, project that are applying agilemethods become more and more popular. With the success of small agile teams, largerorganizations become increasingly interested in applying agile methods in large-scaleand modern development environments. This adaption process creates new concerns,like geographical distribution, dependencies or communication issues between differentteams. These concerns are new and not yet fully elaborated, which means that not forevery concern a well-known solution exists.In order to do further research on concerns in agile development and good and badpractices, when addressing these concerns, we conducted 14 semi-structured interviewswith industry experts at a German IT consulting company with about 500 employeesat that time. The collected data was documented by using the Large-Scale AgileDevelopment Pattern Language, that the chair of Software Engineering for BusinessInformation Systems (SEBIS) at the Technical University of Munich developed in 2019.Using a fixed way of documenting the findings allow to compare and collect concernsand patterns from different research projects at different organizations. This offers theopportunity to build a large pattern catalog, which provides an overview of differentstakeholders, their concerns and good and bad practices to deal with these concerns.Such a pattern collection would help organizations to apply agile methods with moresuccess in the future.

iii

Contents

Abstract iii

Outline of the Thesis vii

1. Introduction 11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Research Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Foundation 52.1. Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Agile Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Large-Scale Agile Development . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2. Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Related Work 11

4. Identifying Recurring Concerns and Practices 134.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2. Case Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3. Findings on Recurring Concerns . . . . . . . . . . . . . . . . . . . . . . . . 164.4. Findings on Good and Bad Practices . . . . . . . . . . . . . . . . . . . . . . 27

5. Discussion 395.1. Key Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6. Conclusion and Outlook 416.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A. Appendix 43A.1. Interview Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

v

Contents

B. Appendix 45B.1. Documentation of Good and Bad Practices . . . . . . . . . . . . . . . . . . 45

Bibliography 89

vi

Outline of the Thesis

Chapter 1: Introduction

The first chapter describes the motivation of the thesis. It also introduces the threeresearch objectives and the taken research approach.

Chapter 2: Foundation

The foundation chapter introduces relevant terms and concepts, like patterns, the Large-Scale Agile Development Patter Language and the concepts of agile development andlarge-scale agile development.

Chapter 3: Related Work

The third chapter deals with seven publications related to the field of concerns andpatterns in combination with agile development.

Chapter 4: Identifying Recurring Concerns and Practices

The fourth chapter is the main chapter and presents the case study at a German ITconsulting company. It is divided into four parts: methodology of the case study, casedescription, findings on recurring concerns and findings in good and bad practices.

Chapter 5: Discussion

The discussion chapter emphasizes the key findings of this thesis and discusses the fourprinciples of data collection as proposed by Yin [28], to define the limitation of thisthesis.

Chapter 6: Conclusion and Outlook

The thesis closes by answering the three research question, to conclude the findings. Thelast section is a outlook to possible future work.

vii

1. Introduction

1.1. Motivation

Since the publication of the Agile Manifesto in 2001 [3], applying agile methods inprojects becomes more and more popular. The Agile Manifesto [3] states twelve impor-tant principles and four modern values, that are balanced with four values of traditionaldevelopment. These principles and values were revolutionary for development methods,since most development teams apply agile methods and namely Scrum [1]. Applyingagile methods, one is able to adopt to chances during the project. This offers the flex-ibility modern projects require [27]. Larger development companies, with large anddistributed projects are getting attracted by this potential [11].The agile development approach was originally designed for small and co-located teams[10], nevertheless bigger companies also want to profit from agile development methodsin a scaled environment [1]. By scaling this approach completely new concerns andchallenges raise [10][25][27]. According to Dingsøyr et. al. [12] the most importantchallenges are customer involvement, software architecture and inter-team coordination.Certainly, finding literature about how to address these challenges, is scarce and accord-ing to Dikert et. al. [10], research is relapsed in comparison to the industry. Additionallythere are not only more concerns, but also new stakeholders involved [25].In order to understand concerns, patterns and their relations better, Uludag et. al.proposed a Large-Scale Agile Development Pattern Language (LSADPL) [24]. A uniformpattern language allows to collect data from different industry organization and compareand combine them, to achieve a better understanding of how agile methods are adoptedin the industry and more importantly, which concerns, challenges and solutions comewith it.The larger vision behind this to contribute to a extensive documentation of recurringconcerns in scaled agile development, also containing proven patterns for how to addressthese challenges. The narrower goal of this thesis is to identifying recurring concernsand patterns. All findings shall be documented by using the LSADPL [24].

1.2. Research Objectives

To fulfill the previously presented goal of this Bachelor’s Thesis, we formulated threeresearch questions, which will function as a guidance for the case study. They will comeup again in the conclusion (see Chapter 6) to verify whether the questions are answeredby this thesis or not.

1

1. Introduction

RQ1: What are recurring concerns of agile teams in agile software development?This question aim for identifying recurring concerns of agile teams in agile softwaredevelopment. The goal is to collect already identified concerns from literature and toidentify new recurring concerns with a case study at an industry partner.

RQ2: What are good practices for addressing recurring concerns of agile teams inagile software development?This question asks for good practices that are used by agile teams in agile softwaredevelopment, to address the previously collected recurring concerns.

RQ3:Which bad practices should be avoided in agile software development?This question, on the other hand, asks for bad practices in agile software development.

1.3. Research Approach

To answer the three research questions of the previous section, we applied the Pattern-Based Design Research (PDR) as proposed by Buckl et. al. [6]. This thesis focuses on thefirst steps, namely observe & conceptualize.This means, that we are going to use the LSADPL [24], to conceptualize the observations.In this case we are conducting a case study at a German IT consulting company withabout 500 employees in 2019. Thereby we will collect first, second and third degreedata, through analyzing existing documents, observing the workflow and conductingsemi-structured interviews with industry experts.The other part of the PDR is to make use of guidance and structure given throughgrounding theories. This is going to be the LSADPL [24], a collection of alreadyidentified concerns and patterns, which we collect through a literature review and acommon understanding of agile practices. All three important concepts are discussed inChapter 2.Our concrete research approach is as follows. We are going to start off by conductinga literature review. The goal is to collect already identified recurring concerns of agileteams in agile development and good and bad practices when addressing these concerns.This serves the guide &structure step of the PDR.The second step is to conduct interviews with industry experts and to collect further dataat the case organization. Through the semi-structured we aim for identifying concernsof agile development and good and bad practices when addressing these concerns. Thisis equivalent to the observe & conceptualize step of the PDR.The last step is to combine and evaluate the collected data, in order to get a collection ofidentified and documented concerns of agile development. Furthermore we aim for alist of identified and accordingly to the LSADPL [24] documented pattern candidates.

2

1.3. Research Approach

Figure 1.1.: Pattern-Based Design Research [6][24]

3

2. Foundation

This chapter gives definitions of concepts and terms that are import for this thesis. Atthe beginning, in Section 2.1 the most important information is to understand ’What arepatterns?’ and ’How are patterns written?’ is presented. Followed by Section 2.2, whichgives a basic definition of agile development and especially Scrum. Section 2.3 finishesthis chapter off, with a definition of large-scale agile development and a list of concerns.These concerns are an import part of the case study, described in Chapter 4.

2.1. Patterns

According to Alexander [2] a pattern is a relation of three parts. A problem, the contextof the problem and of course the solution. Patterns that are relevant to this thesis can becategorized into different categories [24]:

• Coordination Patterns (CO-Patterns) describe basic mechanisms to address recur-ring concerns

• Methodology Patterns (M-Patterns) are concrete steps, which can be used toaddress recurring concerns

• Viewpoint Patterns (V-Patterns) are proven visualizations, that are used to ad-dress recurring concerns

• Anti-Patterns (A-Patterns) describe steps to be avoided

• Principles are general and universally valid guidelines

Figure 2.1 shows a "Conceptual model of the large-scale agile development pattern lan-guage" [24], which was developed by Uludag et. al. in 2019. The pattern language alsocontains ’Concerns’ and ’Stakeholders’. Concerns can for example be goals, responsibili-ties or challenges [15]. Stakeholders are the persons who can be brought into connectionwith a concern [24]. Taking a closer look at the Large-Scale Agile Development PatternLanguage (LSADPL), it is easy to detect that a principle or a pattern is connected withthe concern that it addresses. The stakeholder stays in relation to a concern. It is alsoobvious that every object has an identifier and a name for identification. Following thedefinition of Alexander [2], that was mentioned in the beginning, a pattern consistsof a problem in a certain context and an advised solution. The LSADPL extends thisdefinition with the attributes like an example, variants and consequences.The case study, following in Chapter 4 will be using the model of the LSADPL as a

5

2. Foundation

CO-Pattern V-Patterntypedata collection

M-Pattern

LSAD Patternidentifiernamealiassummaryexamplecontextproblemforcessolutionvariantsconsequencesother standardsknown uses

Concernidentifiernamecategoryscaling level

Principleidentifiernamealiassummarytypebinding natureexamplecontextproblemforcesvariantsconsequencesother standardsknown uses

LSAD Anti-Patternidentifiernamealiassummaryexamplecontextproblemforcesgeneral formconsequencesrevised solutionother standards

Stakeholderidentifiernamealias

see also* *

see also* *

see also

*

*see also

*

*see also

*

*

is addressed by

*

*is addressed by*

*is addressed by

*

*

has *

*

Figure 2.1.: "Conceptual model of the large-scale agile development pattern language"by [24]

6

2.2. Agile Development

basis to document the collected data. Unfortunately we can only document patterncandidates, because we are following the concept that was introduced by Coplien [9].It says, that only if a practice is observed at least three times it can be called a pattern.With the case study taking place in only one organization it is not possible to meet therule of three occurrences.

2.2. Agile Development

2.2.1. Definition

Agile development methods slowly developed from the mid-1990s until the publicationof the Agile Manifesto in 2001 [3], and were called lightweight methodologies [27]. TheAgile Manifesto introduced not only the term ’agile’, but also twelve core principles (seeTable 2.1) and four important and modern values (see Table 2.2) [3].

Customer satisfaction through early and continuous software deliveryAccommodate changing requirements throughout the development process

Frequent delivery of working softwareCollaboration between the business stakeholders and developers throughout the project

Support, trust, and motivate the people involvedEnable face-to-face interactions

Working software is the primary measure of progressAgile processes to support a consistent development paceAttention to technical detail and design enhances agility

SimplicitySelf-organizing teams encourage great architectures, requirements, and designs

Regular reflections on how to become more effective

Table 2.1.: The twelve core principle according to the Agile Manifesto [3]

Individuals and Interactions Over Processes and Tools

Working Software Over Comprehensive Documentation

Customer Collaboration Over Contract Negotiation

Responding to Change Over Following a Plan

Table 2.2.: The four values according to the Agile Manifesto [3]

7

2. Foundation

In contrast to the agile approach, traditional development methods start off with a fixedset of requirements [27]. This makes agile development processes able to respond tochanges, which is a frequent demand in modern development projects [27].According to the 13th annual state of agile report [1], the two most popular agilepractices are Scrum and a hybrid between Scrum and XP. Extreme programming itself isused in only 1% of all cases.

2.2.2. Scrum

Scrum is not only the most popular agile method [1], but also the one mainly applied inthe case organization of the following case study.The Scrum process consists of five different events and relies on three core roles and

three artifacts [20]. The core process can be seen in Figure 2.2.Starting off with the three Scrum roles:

• The Scrum Master is a servant-leader, who functions as a facilitator, who supportsthe team with their Scrum process [20].

• The Development Team is the core of a Scrum team and consists of cross-functional professionals. They are working self-organized in order to have successwith the development [20].

• The third role is the Product Owner, who is responsible for the development result[20]. He can be seen as the customer of the scrum master and development team.

Additionally there are three artifacts, that are created and managed by the Scrum team:

• Product Backlog is a set of specified requirements, that are currently not workedon, but are possibly future tasks. It is maintained by the product owner [20].

• Then there is the Sprint Backlog, which is also a set of specified requirements,which in contrast are currently developed by the development team [20].

• The last Scrum artifact is the Product Increment, which is an increment that fulfillsall requirements of a sprint backlog [20].

With knowing about the artifacts and roles used in Scrum, one is able to understand theevents, that build the core process:

• The main event is the Sprint, that takes a period of 2-4 weeks, in which thedevelopment team tries to create a product increment that fulfills all requirementsof the sprint backlog [20].

• A sprint always starts off with a Sprint planning meeting, where the Scrum teamdecides on which items of the product backlog are taken into the sprint backlogfor the next sprint [20].

8

2.3. Large-Scale Agile Development

Figure 2.2.: The Scrum process according to [16]

• During a sprint every day starts off with a Daily Scrum meeting, in which everyteam member briefly talks about what he managed to do yesterday, what heplanned for today. This meeting also offers the opportunity to mention impedi-ments, that have to be dealt with [20].

• At the end of a sprint, first the sprint is closed together with the product owner.This meeting is called Sprint Review in which the development team presents thedeveloped product increment to the customer [20].

• The last event is the Sprint Retrospective, where the Scrum team reflects on thelast sprint, to improve the team performance for the next sprint [20].

2.3. Large-Scale Agile Development

Since agile methods were originally developed for small and co-located teams, it isnecessary to adopt them to the needs of modern projects [27][17].

2.3.1. Definition

There is not the one and only definition for large-scale according to literature. But apopular approach is to define large-scale by the number of participants in a project.According to Dingsøyr et. al. [11], large-scale is in the range of 2-9 collaborating teams.Projects with more teams are named very large-scale projects.

9

2. Foundation

Level Number of teams Coordination approachSmall-scale 1 "Coordinating the team can be done using ag-

ile practices such as daily meetings, commonplanning, review and retrospective meetings."[11]

Large-scale 2-9 "Coordination of teams can be achieved in anew forum such as a Scrum of Scrums forum."[11]

Very large-scale 10+ "Several forums are needed for coordination,such as multiple Scrum of Scrums." [11]

Table 2.3.: "A taxonomy of scale of agile software development projects." [11], accordingto Dingsøyr et. al.

2.3.2. Concerns

By analyzing large-scale agile development projects many concerns have been identifiedand documented in existing literature. The foundation for the case study in this thesis,is a list of 78 concerns of large-scale agile development, that were published in the paper"Identifying and Structuring Challenges in Large-Scale Agile Development based on aStructured Literature Review" by Uludag et al. from 2018 [25]. In Table 4.3 one can seethese concerns with the IDs C-1 until C-78.

10

3. Related Work

This chapter deals with already existing research in the field of concerns and patterns incombination with agile development. The following seven publications are presented inthe chronological order, starting with Dikert et. al. (2016) [10] and finishing off withSchüll (2019) [19].

Dikert et. al. (2016): Challenges and success factors for large-scale agile transforma-tions: A systematic literature review [10]Dikert et. al. [10] identified 35 challenges, which they grouped into nine categories.Furthermore they present 29 success factors, which can be grouped into eleven categories[10]. Dikert et. al. [10] also argues, that based on the existing literature, research is notup to date with practitioners.

Dingsøyr et. al. (2018): Exploring software development at the very large-scale: arevelatory case study and research agenda for agile method adaptation [12]Dingsøyr et. al. [12] conducted a revelatory case study on a very large Norwegiansoftware project, where scaled agile methods were applied.Dingsøyr et. al. [12] provide a very detailed description of how large-scale agiledevelopment was applied in practice. They also present the result from interviewswith practitioners about customer involvement, software architecture and inter-teamcoordination, which are important concern categories, when adopting agile methods toa very large scale [12].

Uludag et al. (2018): Identifying and Structuring Challenges in Large-Scale AgileDevelopment Based on a Structured Literature Review [25]In this paper [25] Uludag et al. presents 14 stakeholders of large-scale agile development,namely: Development Team, Product Owner, Scrum Master, Software Architect, TestTeam, Product Manager, Program Manager, Agile Coach, Enterprise Architect, BusinessAnalyst, Solution Architect, Portfolio Manager, Support Engineer and UX Expert.They also provide a list of 79 identified concerns, which served as a starting point forthe case study presented in the next chapter, Chapter 4. Thereby, this paper representsan important part of the foundation of this thesis.

11

3. Related Work

Harders (2019): Identifying and Documenting Recurring Concerns and Best Practicesof Agile Coaches and Scrum Masters in Large-Scale Agile Development [13]Harders’ master’s thesis [13] proposes the Large-Scale Agile Development Pattern Lan-guage (LSADPL). Furthermore Harders puts the LSADPL into practice, by conducting14 interviews with industry experts, questioning Agile Coaches and Scrum Mastersabout recurring concerns and good and bad practices. The results were documentedusing the LSADPL, which ended up in 23 identified concerns and 76 pattern candidates.15 of those candidates could already be proven to be patterns [13].

Uludag et. al. (2019): Documenting Recurring Concerns and Patterns in Large-ScaleAgile Development [24]This paper presents a evaluation of the Large-Scale Agile Development Pattern Lan-guage (LSADPL), by interviewing 14 industry experts [24]. As a result, the LSADPLwas adapted according to the received feedback. Uludag et. al. [24] also describes howto use their pattern language, by documenting one principle, one coordination pattern,one viewpoint pattern and one anti-pattern as an example.

Buchholz (2019): Empirical Studies to Identify Challenges and Probe Good Practicesin the Adoption of Scaled Agile Methods in the Field of Vehicle Dynamics Develop-ment of an OEM [4]This bachelor’s thesis aimed for identifying concerns and good and bad practices, whenadopting agile development methods. Buchholz’s research approach is similar to theone of Schüll [19] and to the one of this thesis. Among other results, Buchholz identified25 new concerns and 17 good practices, when adopting agile methods [4].

Schüll (2019): Empirical Studies to Identify Coordinationand Methodology Patternsin Large-Scale Agile Development [19]Schüll’s research approach is similar to the approach of Buchholz’s thesis [4] and thisthesis. Also the goals are structured similarly, but Schüll [19] focuses coordination andmethodology patterns, especially in the scope of large-scale agile development. As aresult, Schüll provides 28 new concerns and proves 34 already documented concerns asrecurring [19]. He also identifies 38 good and 4 bad practices for addressing recurringconcerns in large-scale agile development [19].

12

4. Identifying Recurring Concerns andPractices

This chapter is about the case study, which is the main point of this thesis, thus thischapter can be considered the main chapter.

4.1. Methodology

We collected first, second and third degree data from the case organization, which isdescribed in the following. First degree data was collected from analyzing documentsfrom an internal wiki, Jira documentations and presentation slides. Second degree datawas gathered by participating in meetings and analyzing the workflows. The thirddegree data was collected trough 14 semi-structured interviews at the case organization.In the Table 4.1, we listed all interview partners, with their assigned alias, their role,their experience in years and their team or project. For the interviewees number 8, 12and 14 there is no team documented, as described at the end of the case descriptionbelow.The semi-structured interviews started off with questions to the personal backgroundand were then split into two main phases. In the first phase the interviewee was askedto describe the most important concerns in his role, which were then connected with thesolution approach that is applied right now to address these concerns. In the secondphase we showed a list of concerns, which were collected in previous work done in thisfield. The list was filtered for each individual role, so that a Requirements Engineer doesnot see the concerns usually raised by a Product Owner. This was done to make theInterviews shorter and to keep the interview partner more focused. If a listed concernsalso applied on the interview partner is was marked and connected to the solutionapproach. The interviews took about one hour each.

4.2. Case Description

The case organization where the data was collected is a German IT consulting companywith around 500 employees in 2019. All seven projects are independent and were formedthrough a customer’s order. All of the observed teams are applying an agile workflow,which is always the same for a single project, but not necessarily the same for differentprojects. We assigned aliases to the projects and the teams.

13

4. Identifying Recurring Concerns and Practices

No. Alias Role Experience Team / Project1 RM Rollout Manager >6 years Team 12 PL Project Lead >6 years Team 13 SM1 Scrum Master 3 - 6 years Team 24 Dev1 Lead Architect 3 - 6 years Team 15 RE1 Requirements Engineer 1 - 3 years Team 16 RE2 Lead Requirements Engineer 3 - 6 years Team 17 Dev2 Software Engineer 1 - 3 years Team 18 SM2 Scrum Master 1 - 3 years Project E9 SM3 Scrum Master 3 - 6 years Team 310 RE3 Requirements Engineer 1 - 3 years Team 311 SM4 Scrum Master 3 - 6 years Project C12 SM5 Scrum Master 3 -6 years Project F13 SM6 Scrum Master 1 - 3 years Project D14 SM7 Scrum Master >6 years Project G

Table 4.1.: Overview of the interview partners

Project A

Team 1

Team

2

Team

3

Project B

Team

4

Team

5

Project C

5 teams

Project D

Figure 4.1.: The team situation as it was in August 2019

14

4.2. Case Description

Project AProject A consists of only one agile team with about 23 members in August 2019, eventhough there are smaller subteams for individual services and features. The team isapplying a mix of Scrum and Kanban, which they continuously improve on their own.This also includes changes in the team structure. The whole project team is geographi-cally distributed across 5 different location in two countries, all in the same time zone.Therefore all meetings are held remote.The Project Owner is provided by the customer. There is no explicit Agile Coach orScrum Master, but a Project Lead. He takes care of the Scrum Master’s tasks and allnecessary controlling tasks. The requirements engineering is done in close cooperationwith the end users. Therefore one Lead Requirements Engineer and four additionalRequirements Engineers are assigned. For the development there is one Lead Architectand eleven Software Engineers. For testing the software, there is one Test Manager andone Test Engineer in charge. It has to be mentioned that there are constantly membersjoining and leaving in Team 1.

Project BProject B consists of two Scrum teams, namely Team 2 and Team 3, on the side of thecase organization. On the customers side, there is one additional agile developmentteam, though it must be mentioned, that these teams do not collaborate closely. Onthe other side, Team 2 and Team 3 have to collaborate very closely, because it was notpossible to split the project in to independent feature teams. Both teams are sharinga single office. Each of the two teams has an individual Scrum Master. RequirementsEngineers and Software Engineers belong to only one team and are not shared.

Project CProject C consists of two Scrum teams, with a single shared Scrum Master. Team 4 has 6members and Team 5 has 15 members. Both teams are located in the same office. It hasto be mentioned, that in both teams all developers are highly experienced.

Project DProject D consists of five feature teams. All of them are applying Scrum, with a singleshared Scrum Master. The Product Owner is provided by the customer. Three of thefive feature teams are small, with only two members each. The other two teams have 4members each. Most of the project members are at one location, but some are distributedto other locations.

Additional IntervieweesAdditionally there were three interview partners, where there was no further contactwith the project team. We assign them to the projects E, F and G. All three intervieweeswere recommended by previous interview partners.

15


4.3. Findings on Recurring Concerns

The following section lists the results found by the first identification and descriptionphase of the interviews, observations during meetings and analyzing documents. Weidentified 33 new concerns and documented the occurrence of 56 of the listed 78 concerns,which serves as an input to the case study. The 33 new concerns are displayed in theTable 4.2 below.

Table 4.2.: All 33 new concernsID Name Category

C-101 How to ensure participation in agile meetings (e.g.daily, retrospective)?

Methodology

C-102 How to create an overview of tasks, responsibilitiesand deadlines, which are not user story related?

Project Manage-ment

C-103 How to plan sprints in different project situations? Project Manage-ment

C-104 How to ensure participation of distributed team mem-bers in the Daily?

Geographical Dis-tribution

C-105 How to estimate the finish date of a task or user story? Project Manage-ment

C-106 How to visualize the sizes of different user stories onthe agile board?

Methodology

C-107 How to document the actual effort for each userstory?

Project Manage-ment

C-108 How to visualize the status of multiple user storiesand compare them easily?

Knowledge Man-agement

C-109 How to visualize external impediments? Communication& Coordination

C-110 How to visualize dependencies between different ag-ile teams?

Software-Architecture

C-111 How to visualize holidays for each team member ona physical board?

Knowledge Man-agement

C-112 How to define high-level requirements above epics inJIRA to archive more structure?

Tooling

C-113 How to deal with diffusion of responsibility? Project Manage-ment

C-114 How to deal with a huge impact in case of a buggydeployment?

Quality Assur-ance

C-115 How to deal with complex test cases and unknowncorner cases?

Quality Assur-ance

C-116 How to deal with very long and big sprint planningand review meetings with the customer?

Communication& Coordination

16


ID Name CategoryC-117 How to shorten meetings? Communication

& CoordinationC-118 How to shorten the Daily meeting? Communication

& CoordinationC-119 How to make boarding new team members easier

and faster?Knowledge Man-agement

C-120 How to ensure a good a constant structure of theDaily meeting?

Communication& Coordination

C-121 How to avoid refactoring user stories often? Requirements En-gineering

C-122 How to deal with a bad input or situation, created byprevious projects (e.g. exploration phase)?

Culture & Mind-set

C-123 How to deal with lacking sense of ownership in agiledevelopment on the customer side?

Project Manage-ment

C-124 How to categorize the status user stories during theirlifetime?

Methodology

C-125 How to deal with internal and external dependences? Software-Architecture

C-126 How to synchronize work and speed between Re-quirements Engineers and Developers?

Methodology

C-127 How to deal with teams that are still in the ’forming’or ’storming’ phase?

Project Manage-ment

C-128 How to measure confidence to reach goals during asprint?

Methodology

C-129 How to understanding interfaces of other systems? Software-Architecture

C-130 How to make milestones and deadlines obvious? Knowledge Man-agement

C-131 How to visualize the target environment of a systemwith all related workflows?

Requirements En-gineering

C-132 How to visualize the state of different user stories onan agile board?

Methodology

C-133 How to deal with insufficient work of the ProductOwner?

Methodology

Consolidation:

Several concerns are not primarily regarding agile development and were thereforsorted out. These are the following:

• C-111: has no connection to an agile approach.

17


• C-112: is a concern about a special project management tool.

• C-116, C-117, C-118 and C-120: are more about timeboxing and meetings ingeneral.

• C-122: is about a general project situation, but has no connection to agile develop-ment.

Some other identified concerns are very similar or the same as already existing onesand therefore considered as duplicates and merged. These are the following:

• C-101 and C-104 were merged to C-7, because both aim for the not participationin agile meeting, which we consider to be a incorrect agile practice.

• C-106 and C-108 were to C-132.

• C-109 and C-125 were merged to C-2, which combines internal and externaldependencies.

• C-113 is all about defining roles and responsibilities and was therefore merged toC-56.

After removing duplicates and concerns that are not necessarily regarding agile devel-opment, there are 19 concern left. In the following these 19 concerns are described inmore detail:

• C-102: How to create an overview of tasks, responsibilities and deadlines,which are not user story related?Most of the development tasks are documented within user stories. Without hav-ing another concept it can be hard to overview tasks, responsibilities or deadlines,that cannot be directly linked to a user story. This concern is categorized as aProject Management concern at the program level.

• C-103: How to plan sprints in different project situations?Planing sprints is always dependent of the expected capability of the developmentteam. During different project situations this capability has to be calculateddifferently. For example in a sprint right after a big release, it is most likely toreceive many bug tickets. Aligning these two things can be challenging. Thisconcern is categorized as a Project Management concern at the team level.

• C-105: How to estimate the finish date of a task or user story?When estimating user stories only the expected workload is estimated. Even ifthis estimation is accurate, it is challenging to determine when a user story will befinished on the calendar, because a estimated workload of 5 days can be done by 5developers on one day, or by one half-time developer in 10 days. This concern iscategorized as a Project Management concern at the program level.

18


• C-107: How to document the actual effort for each user story?For controlling reasons and for future estimations it is interesting to know howmuch effort was spent on a specific user story in the past. To ensure havingthis data can be a challenge. This concern is categorized as a Project Managementconcern at the team level.

• C-110: How to visualize dependencies between different agile teams?When multiple agile teams collaborate it is unavoidable to have dependenciesbetween these teams. A challenge is to visualize these dependencies. This concernis categorized as a Software-Architecture concern at the program level.

• C-114: How to deal with a huge impact in case of a buggy deployment?When deploying to a required environment, where downtime would have a hugeimpact it is advisable to develop a plan on to deal with this situation. To determinethe measures to take can be challenging. This concern is categorized as a QualityAssurance concern at the program level.

• C-115: How to deal with complex test cases and unknown corner cases?In some environments it is not possible to write complete test cases. This mightbe, because there are very complex cases or even unknown corner cases. Itis a challenge to develop measures dealing with this concern. Therefore it iscategorized as a Quality Assurance concern at the program level.

• C-119: How to make boarding new team members easier and faster?When new members join a project it can be expected, that their performance willincrease over time, because they have learned about the project, the workflow andmainly the people they collaborate with. The challenge is to speed this process up,in order to have a better performance earlier. Therefore this concern is categorizedas a Knowledge Management concern at the team and the program level.

• C-121: How to avoid refactoring user stories often?When developing software for a costumer it is often the case, that user stories,that were specified in the past, have to be refactored, because the requirementschanged. This process is time and cost intensive. Therefore it is a challenge toavoid this. This concern is categorized as a Requirements Engineering concern at theteam level.

• C-123: How to deal with lacking sense of ownership in agile development onthe customer side?Because the case organization is an IT consultant, there is always a customerinvolved, e.g. for the requirements engineering process this is essential. If thecustomer is not feeling responsible for certain tasks, the collaboration can bechallenging. This concern is categorized as a Project Management concern at theprogram level.

19


• C-124: How to categorize the status user stories during their lifetime?When working with user stories these can be in a certain state of their lifetime, e.g.one story is completely specified and is ready for implementation. Categorizingthe state of a user story can be a challenge. This concern is categorized as aMethodology concern at the team and the program level. If there is a standardizedconcept of categorizing user stories for the whole enterprise, it can also be seen asa concern at the enterprise level.

• C-126: How to synchronize work and speed between Requirements Engineersand Developers?This concern was raised by SM2, who sees this a main task of Scrum Masters.Otherwise one of the two sides might become stressed, which can have a negativeresult on the performance of the whole team. This concern is categorized as aMethodology concern at the program level.

• C-127: How to deal with teams that are still in the ’forming’ or ’storming’phase?According to Tuckmann [23] every newly formed team runs trough four stages ofperformance. In the first two stages ’forming’ and ’storming’, teams are not yetperforming very well. It can be a challenge to deal with teams in early stages. Thisconcern is categorized as a Project Management concern at the program level.

• C-128: How to measure confidence to reach goals during a sprint?This concern was raised by SM3, who was seeking for a solution to measure theperformance of an agile team during a sprint. This is also a concern, which canhave impact on the sprint planning. This concern is categorized as Methodologyconcern at the team level.

• C-129: How to understand interfaces of other systems?When developing software for a customer, it is often the case that there areinterfaces to already existing systems. In order to work with these interfaces, it isan essential part to understand them first. Therefore this concern is categorized asa Software-Architecture concern at the program level.

• C-130: How to make milestones and deadlines obvious?For an IT consulting company it is important to stay on schedule in project.Therefore one concern is, how to visualize milestones and deadlines in orderto make them obvious. This concern is categorized as a Knowledge Managementconcern on the team or the project level.

• C-131: How to visualize the target environment of a system with all relatedworkflows?This concern was raised during the interview with RE3, who had the current taskto create a documentation of the target environment of the software. Therefore

20


he was seeking for a visualization. This concern is categorized as a RequirementsEngineering concern on the program level.

• C-132: How to visualize the state of different user stories on an agile board?This concern was merged from multiple concerns mentioned in several interviews,which were all related to visualizing a certain status of a user story on an agileboard, e.g. how one could make a blocked user story obvious. This concern iscategorized as a Methodology concern at the team level.

• C-133: How to deal with insufficient work of the Product Owner?In the case organization this concern is often closely related to C-123, but notnecessarily the same. We decided to add this concern, because it can occur evenif the Product Owner is feeling responsible for all of his tasks, which means thatC-123 is then not the case. This concern is categorized as a Methodology concernon the program level.

From these 19 new identified and documented concerns of agile teams in agile devel-opment, six were categorized as a Project Management concern, five as a Methodologyconcern and two each of the remaining categories (see Figure 4.2).Looking at the scaling level, one can notice, that all new concerns are located at team orprogram level. There are also three concern, where it was not possible or reasonable todistinct between them.

2

5

6

2

22

Knowledge Management Methodology

Project Management Quality Assurance

Requirements Engineering Software-Architecture

(a) Categories of new concerns

5

11

3

Team Level Program Level Team/Program Level

(b) Scaling levels of new concerns

Figure 4.2.: Overview of categories and scaling-level of new concerns

This section on the findings regarding recurring concerns closes with a table (see Table4.3) showing all identified concerns, sorted by the number of interviews a concernoccurred in. There is also one additional column showing the number of different teamsa concern occurred in.

21


Table 4.3.: Overview over concerns, their category, source and the number of occurrencesID Name Category # interviews # teams

C-56 How to define clear roles and re-sponsibilities?

Project Man-agement

8 7

C-23 How to establish a common scopefor different stakeholder groups?

KnowledgeManagement

7 6

C-5 How to facilitate shared context andknowledge?

KnowledgeManagement

7 5

C-3 How to coordinate geographicallydistributed agile teams?

GeographicalDistribution

6 6

C-31 How to deal with geographical dis-tance between agile teams?


6 6

C-4 How to deal with doubts in peopleabout changes?

Culture &Mindset

6 5

C-75 How to form and managing au-tonomous teams?

Communication& Coordina-tion

6 5

C-50 How to deal with lacking sense ofownership responsibilities for devel-oped services?

Culture &Mindset

5 5

C-7 How to deal with incorrect practicesof agile development?

Methodology 5 5

C-33 How to build trust of stakeholdersin agile practices?

Culture &Mindset

5 4

C-119 How to make boarding new teammembers easier and faster?

KnowledgeManagement

5 3

C-32 How to deal with lacking team co-hesion at different locations?


5 3

C-39 How to establish a culture of con-tinuous improvement?

Culture &Mindset

5 3

C-47 How to deal with higher-level man-agement interferences?

Culture &Mindset

4 4

C-12 How to provide sufficient tools andinfrastructure for remote communi-cations?

Tooling 4 3

C-24 How to create team spirit and trustamong agile teams?

Culture &Mindset

4 3

C-59 How to establish a common under-standing of agile thinking and prac-tices?

Methodology 4 3

22


ID Name Category # interviews # teamsC-78 How to synchronize sprints in the

large-scale agile development pro-gram?


4 3

C-22 How to balance short-term andlong-term goals?

RequirementsEngineering

4 2

C-11 How to obtain management buy-in? Culture &Mindset

3 3

C-46 How to deal with closed minded-ness?

Culture &Mindset

3 3

C-55 How to create a teamwork centricrewarding model?

Project Man-agement

3 3

C-132 How to visualize the state of differ-ent user stories on an agile board?

Methodology 3 2

C-15 How to elcitate and refining require-ments of end users?


3 2

C-53 How to ensure traceability of testsand requirements?

Quality Assur-ance

3 2

C-74 How to empower agile teams tomake decisions?

Culture &Mindset

3 2

C-10 How to create precise requirementspecifications for the developmentteam?


3 1

C-2 How to consider integration issuesand dependencies with other sub-systems and teams?


3 1

C-60 How to create and estimate a userstory?


3 1

C-102 How to create an overview oftasks, responsibilities and dead-lines, which are not user story re-lated?

Project Man-agement

2 2

C-110 How to visualize dependencies be-tween different agile teams?


2 2

C-121 How to avoid refactoring user sto-ries often?


2 2

C-133 How to deal with insufficient workof the Product Owner?

Methodology 2 2

C-28 How to communicate business re-quirements to development teams?


2 2

C-35 How to define clear and visible pri-orities?


2 2

23


ID Name Category # interviews # teamsC-38 How to facilitate standardization

across agile teams?Enterprise Ar-chitecture

2 2

C-42 How to rearrange physical spaces? Tooling 2 2C-57 How to decompose agile teams in

smaller independent teams?Enterprise Ar-chitecture

2 2

C-65 How to deal with office politics? Culture &Mindset

2 2

C-67 How to encourage developmentteams to talk about tasks and im-pediments?

Culture &Mindset

2 2

C-69 How to establish requirements veri-fication?


2 2

C-77 How to build an effective coachingmodel?

Methodology 2 2

C-9 How to find the right balance be-tween architectural improvementsand business value?


2 2

C-6 How to manage technical debts? Software-Architecture

2 1

C-61 How to deal with cultural dif-ferences between cross-shore agileteams?


2 1

C-103 How to plan sprints in differentproject situations?

Project Man-agement

1 1

C-105 How to estimate the finish date ofa task or user story?

Project Man-agement

1 1

C-107 How to document the actual effortfor each user story?

Project Man-agement

1 1

C-114 How to deal with a huge impact incase of a buggy deployment?

Quality Assur-ance

1 1

C-115 How to deal with complex testcases and unknown corner cases?

Quality Assur-ance

1 1

C-123 How to deal with lacking sense ofownership in agile development onthe customer side?

Project Man-agement

1 1

C-124 How to categorize the status userstories during their lifetime?

Methodology 1 1

C-126 How to synchronize work andspeed between Requirements Engi-neers and Developers?

Methodology 1 1

24


ID Name Category # interviews # teamsC-127 How to deal with teams that are

still in the ’forming’ or ’storming’phase?

Project Man-agement

1 1

C-128 How to measure confidence toreach goals during a sprint?

Methodology 1 1

C-129 How to understanding interfaces ofother systems?


1 1

C-13 How to share a common vision? KnowledgeManagement

1 1

C-130 How to make milestones and dead-lines obvious?

KnowledgeManagement

1 1

C-131 How to visualize the target environ-ment of a system with all relatedworkflows?


1 1

C-14 How to create a proper upfront ar-chitecture design of the system?


1 1

C-16 How to deal with increasing work-load of key stakeholders?

Project Man-agement

1 1

C-20 How to facilitate communication be-tween agile teams and other teamsusing traditional practices?


1 1

C-25 How to manage and integrating het-erogeneous subsystems of differentdevelopment teams?


1 1

C-27 How to manage and sharing knowl-edge about system components andtheir dependencies with stakehold-ers?

Enterprise Ar-chitecture

1 1

C-37 How to create lightweight docu-mentation?

KnowledgeManagement

1 1

C-40 How to apply agile practices for de-veloping or maintaining legacy sys-tems?


1 1

C-43 How to enforce customer involve-ment?

Culture &Mindset

1 1

C-44 How to deal with communicationgaps with stakeholders?


1 1

C-45 How to deal with black and whitemindsets?

Culture &Mindset

1 1

25


ID Name Category # interviews # teamsC-49 How to deal with increased efforts

by establishing inter-team commu-nication?


1 1

C-54 How to make a cost and scheduleestimation?

Project Man-agement

1 1

C-58 How to deal with loss of manage-ment control?

Culture &Mindset

1 1

C-64 How to define a lightweight formalreview process for new technolo-gies?


1 1

C-66 How to foster technical excellence Software-Architecture

1 1

C-68 How to write understandable auto-mated tests?

Quality Assur-ance

1 1

C-70 How to define high-level require-ments a.k.a. epics?


1 1

C-1 How to coordinate multiple agileteams that work on the same prod-uct?


0 0

C-17 How to establish self-organization? Communication& Coordina-tion

0 0

C-18 How to split large and complexrequirements into smaller require-ments?


0 0

C-19 How to deal with internal silos? KnowledgeManagement

0 0

C-21 How to manage dependencies toother existing environments?


0 0

C-26 How to align and communicatingarchitectural decisions?


0 0

C-29 How to facilitate agile teams to par-ticipate at cross-shore meetings?


0 0

C-30 How to synchronize working hoursof cross-shore agile teams?


0 0

C-34 How to ensure the reuse of enter-prise assets?


0 0

C-36 How to establish automated test-ing?

Quality Assur-ance

0 0

C-41 How to deal with unplanned re-quirements and risks?

Project Man-agement

0 0

26

4.4. Findings on Good and Bad Practices

ID Name Category # interviews # teamsC-48 How to demonstrate the value of

architecting?Software-Architecture

0 0

C-51 How to ensure that agile teams ad-here to architecture-related activi-ties?


0 0

C-52 How to provide agile teams appro-priate automation and scalable in-frastructure?

Tooling 0 0

C-62 How to deal with fixed price con-tracts in agile software develop-ment?

Project Man-agement

0 0

C-63 How to explain requirements tostakeholders?


0 0

C-71 How to measure the success of thelarge-scale agile development pro-gram?

Project Man-agement

0 0

C-72 How to consider required compe-tencies when assigning teams totasks?

Project Man-agement

0 0

C-73 How to deal with decreased pre-dictability?

Project Man-agement

0 0

C-76 How to coordinate tests and deploy-ment with external parties?

Quality Assur-ance

0 0

C-8 How to ensure that non-functionalrequirements are considered by thedevelopment team?


0 0


In the Table 4.4 we listed all identified pattern candidates. Coordination patterns arenoted as CO, methodology patterns as M, viewpoint patterns as V, anti-patterns as Aand principles as P.Overall, there were 30 pattern candidates collected, one of those was a coordinationpattern candidate, 15 methodology pattern candidates, ten viewpoint pattern candidatesand three anti-pattern candidates. Furthermore there was one principle identified.

In the following one combined Figure (see Figure ??), showing how the identifiedpattern candidates relate to the recurring concerns and to other pattern candidates, ispresented. Subsequent one pattern documentation of each pattern type is presented. All

27


other pattern documentations are placed in the Appendix B.1.

ID NameCO-106 Community of Practice

CO-107 SYNC Meeting

M-102 Involve customer in requirements engineering

M-103 Anonymous Surveys and Feedback

M-104 Define the simplest user story that can possibly work

M-105 Establish a proxy product owner

M-106 Use Smart Hubs for remote communication in meetings

M-107 Directly log spent effort for each user story

M-110 Definition of XM-111 LEGO Retrospective

M-112 Origami Retrospective

M-113 Design Sprint

M-114 Architecture Spike

M-115 Extending user stories by mockups

M-116 Pair Programming

M-118 Peer-to-Peer Communication

V-106 Dependency Wall

V-109 User Story Template

V-110 Cumulative Flow Diagram

V-112 Project Roadmap

V-113 Kudo Cards

V-117 Architectural Guideline

V-118 Visualization of different user story states on a user story board

V-119 Task Board

V-120 Modeling processes and workflows

V-121 Data model for system data

A-101 Avoid larger distance or even stairs between co-located teams

A-102 Avoid pressure on newly composed teams

A-103 Avoid dual roles

P-102 Keep development, staging, and production as similar as possible

Table 4.4.: Overview of the identified pattern candidates and principles

28


CO-106

CO-107

C-5C-66

C-1C-78

M-106

M-114

V-106

C-38

(a) Coordination-Pattern candidates

A-101

A-102

A-103

C-16

C-32

C-42

C-49

C-56

C-127

(b) Anti-Pattern candidates

M-102

M-103

M-104

M-105

M-106

M-107

M-110

M-111

M-112

M-113

M-114

M-115

M-116

M-118

C-3

C-5

C-10

C-12

C-13

C-23

C-31

C-39

C-54

C-60

C-69

C-107

C-121

C-124

C-133

V-109

CO-106

C-123

C-66

C-24

C-32

(c) Methodology-Pattern candidates

V-106

V-109

V-110

V-112

V-113

V-117

V-118

V-119

V-120

V-121

C-5

C-66

C-1

C-78

C-38

C-110

C-8

C-10

C-60

C-121

C-126

C-22

C-130

C-39

C-55

C-9

C-14

C-2

C-25

C-56

C-132

C-102

C-37

M-104

M-110

CO-106

(d) Viewpoint-Pattern candidates

29


Pattern OverviewID CO-106Name Community of Practice

Alias CommunitySummary A group of collaborating coworkers with the same field of interest.

their goal is to foster technical excellence.

ExampleMultiple developer from Team 1, Team 3 and some more developers from Project D areinterested in augmented and virtual reality. To gather more knowledge about this topicand in order to foster their technical excellence, they collaborate a found a Communityof Practice called XR. They meet at least once a week to exchange newly gatheredknowledge.

ContextEmployees are interested in a certain topic and want to advance their skills and increasetheir knowledge about it. To found a community of practice, multiple interested cowork-ers are necessary.

ProblemC-5: How to facilitate shared context and knowledge?C-38: How to facilitate standardization across agile teams?C-66: How to foster technical excellence?

Forces

• It can be hard to find interested people, who want to be active in a community ofpractice.

• Only an active community of practice is efficient.

SolutionA community of practice can be founded by any person from the whole organization,that is interested in a certain topic or field. Others, who are also interested in the sametopic can then join. Thereby a group of interested and motivated people develops,which enhances the exchange and increase of knowledge about a certain topic. Becauseof active members being most likely from different teams and projects, knowledge isdistributed across the whole organization. If a development team is struggling with afield, where a active community of practice is working, the development team gets incontact with the community of practice, in order to get their tasks solved.Because being active and spending time in such a community of practice is necessary tokept it alive and effective. It is a challenge to handle the balance between the workingtime spent for communities of practice and working on creating business value and

30


earning money. One possible solution is to give every employee a fixed amount of timehe or she can spend on working in communities of practice.

ConsequencesBenefits:

• The standardization across the whole organization can be increased.

• Fostering technical excellence.

Liabilities:

• Actively taking part in a community of practice takes time, which then cannot beused for other work.

See Also:

• M-114: Architecture Spike

31


Pattern OverviewID M-110Name Definition of XAliasSummary A concept to define states for user stories. By connecting these

states with steps to do and and a group of possible assignees aworkflow concept is created.

Figure 4.3.: Overview of theDefinition of Xstates and work-flow

ExampleIn Project C this methodology pattern is ap-plied to create a clear definition of a user storystatus. Since Project C is a project for acustomer, the Definition of X helps to coor-dinate the collaboration with the customer, bydefining clear roles for each step of the work-flow.

ContextThe context where the Definition of X is helpful, isthe workflow of agile teams, that are not yet hav-ing a well working workflow, or are having prob-lems to define states for their user story lifecy-cle.

ProblemC-123: How to deal with lacking sense of own-ership in agile development on the customerside?C-124: How to categorize the status user stories duringtheir lifetime?

SolutionThe Definition of X starts off by defining names forall states a user story can possibly pass. These statesare then connected to the tasks that have to be doneto reach the next state. By adding a group of pos-sible assignees, like requirements engineers, a work-flow concept is created. The workflow looks as fol-lows:

DoE is the ’Definition of Entry’ and specifies what has to be known about a userstory from the very first moment on. A user story that does not fulfill the DoE is not

32


going to be worked on by requirements engineers on the contractor side.The next step is functional DoR which describes the definition of a story that is fullyspecified on the functional side. ’Functional DoR’ also means, that the customer checkedall requirements and confirmed them. It is even possible to specify the first test cases inthis step.The next step leads to the tag DoR or ’Definition of Ready’, which describes a userstory that is fully specified and accepted by the customer. Before a user story can become’DoR’ it has to be extended by GUI mockups, acceptance criteria and an estimation,which can be done in a collaboration of Requirements Engineers, Software Engineersand Architects.After a user story has reached the ’Definition of Ready’ it is ready for implementationand the first phase with involvement of the customer ends. The next step is to implementand test the specified feature. The customer comes again into place, when it comes to afinal check of an implemented user story.If the customer accepts an implemented feature, the user story reaches DoD, the ’Def-inition of Done’. This means, that the user story is resolved and ready for a futurerelease. After the release, the lifespan of an user story ends and it can be closed.


• Clearly defined workflow.

• A clearly defined assignee for each step of the workflow.

• Very helpful when collaborating with other teams, because workflow and assigneesare defined.

33


Pattern OverviewID V-118Name Visualization of different user story states on a user story

board

AliasSummary There are many option to visualize the state of different user

stories on a board. Examples are red dots to mark blocked userstories, or attaching a portrait to make the assignee obvious.

ExampleTeam 2 uses an analog user story board in the office, which is updated by all teammember frequently. By using this visualization, they are able to keep track of deadlinesand overview integration dependencies to other subsystems easily.

ContextWhen working with user stories it is important to know not only the specifications theycarry, but also the state respective to the applied workflow. This can be visualized byusing a user story board in the office, without using a proper structure display thedifferent information items in it, it is not very useful.

ProblemC-2: How to consider integration issues and dependencies with other subsystems andteams?C-25: How to manage and integrating heterogeneous subsystems of different develop-ment teams?C-56: How to define clear roles and responsibilities?C-130: How to make milestones and deadlines obvious?C-132: How to visualize the state of different user stories on an agile board?

Forces

• There might not be enough space for a big enough analog board.

• When not properly maintained, it becomes not only useless, but it might lead towrong information on the board.

• Too many user stories on the board might lead to detailed information beingoverseen.

SolutionOn a user story board many information can be displayed. By structuring this boardproperly, it becomes easier to find the information one is looking for. The Figure 4.4gives some possible options of structuring a user story board and marking user stories

34


and their individual states according to the applied workflow on it.

• The estimated workload of a user story can be symbolized by the actual size ofthe user story card.

• The assignee can be marked by attaching a portrait of the assignee directly to thecard.

• If no work can be done to a user story, because it is blocked, a marker like a reddot can be placed.

• It is also advisable to note the subsystems or services, that are influenced by thisuser story. This is helpful when dealing with integration issues.

• Another option is to mark the deadline explicitly for time critical user stories. Thisgives extra awareness of time critical, leftover tasks.

To Do

Team 1

Team 2

In Progress In Review Done

ID: NameUser story withID and name

83: Color scheme

29: ID identification

96: Fix Button

Marks a blocked user story

Portrait of the assignee

Influenced subsystem

DMS

Core

UI

Deadline Deadline with explicit date

73: Survey tool

DMS

UI

16.09.19

32: Store user data

DMS

13: network interface

Core

54: Interface

95: Fix Log Out

UI

68: User profile

DMS

UI

73: Migration

DMS

11.09.19

Map Symbols Visualization rules

ID: Name

Horizontal Alignment

Ver

tica

l Alig

nm

en

t Current status

Team in charge

All other mapsymbols belong tothe user story theyare attached to

UI

Core

Figure 4.4.: Example of an agile board with several possible markers

VariantsSuch a user story board can be set up analog in the office, but with some tool supportalso digitally, which offers most of the benefits to geographically distributed teams aswell. A lighter, but not that effective option is to only set tags in a project managementtool. The positive effects might be less, because one is not able to make use of theoverview an analog board creates and the intuitive representation of information.

35



• Intuitive and easy to understand.

• The estimated workload is easy to see.

• Blocked user stories are obvious.

• The assignee of a user story is obvious.

• Subsystem or services that are influenced on deployment are marked.

• Time critical tasks are marked with an explicit deadline, to make them moreobvious.

See Also

• M-110: Definition of X

36


Pattern OverviewID A-101Name Avoid larger distance or even stairs between co-located

teams

AliasSummary A larger distance or stairs between collaborating teams in the

same office building is worse than having a full remote team, thatis used to remote communication.

ExampleTeam 2 and Team 3 are sitting in the same office building, but not on the same flooror even in the same room. Both Scrum Masters can observe, that the communicationbetween the development teams is not working well, because the teams are not used toremote communication, but are not close enough to each other, to communicate directly.

ContextA team or multiple teams, that are not used to remote communication, because theyare not geographically distributed, might face a challenge, if their workplaces are inthe same building, but not in the same office or at the same floor. This would lead tomeetings being not held remote, but it is still effortful to leave the workplace at walk toanother room or floor for communication.

ProblemC-32: How to deal with lacking team cohesion at different locations?C-42: How to rearrange physical spaces?C-49: How to deal with increased efforts by establishing inter-team communication?

Forces

• There might not be enough space to co-locate all teams, that want to be co-located.

Revised SolutionIf collaborating teams are located in the same office building it is advisable to have alarger distance or even stairs between their offices. This might be worse than a fullremote team, that is then used to using remote communication at all time.

ConsequencesLiabilities:

• Less communication between the teams.

• Slower communication between the teams.

37


Pattern OverviewID P-102Name Keep development, staging, and production as similar as

possible

AliasSummary Keeping development and staging environment as similar as pos-

sible to the production environment helps during developmentand testing.

Type Software ArchitectureBinding Nature Recommended

ExampleTeam 1 uses multiple deployment environments for their development process. All ofthem are copies of the production system.

ContextWithout knowing what the target environment of software looks like, developing andtesting is challenging. For example this could lead to many bugs and integration issueson release.

ProblemC-21: Managing dependencies to other existing environmentsC-114: How to deal with a huge impact in case of a buggy deployment?

Forces

• It can be hard to recreate complex production environments.


• Developing and testing in an environment, that is similar to the productionenvironment is beneficial.

• Test coverage can be increased.

• Less bugs and problems on releases.

38

5. Discussion

This chapter presents the key findings of this bachelor’s thesis. The second sectionargues why this thesis follows the four principles of data collection as proposed by Yin[28]. Namely these are construct validity, internal validity, external validity and reliability.

5.1. Key Findings

Through the conducted case study we identified 19 new concerns and confirmed theoccurrence of 56 of the 78 concerns from Uludag et al. [25], which we used as an input.Furthermore we identified and documented 30 pattern candidates:

• one coordination pattern candidate

• 15 methodology pattern candidates

• 10 viewpoint pattern candidates

• 3 anti-pattern candidates

• 1 principle

Apart from these concerns and pattern candidates there are more findings:

• All of the identified concerns are on team level, program level or could not beassigned to only one scaling level, because it depends on the project environment.None of the participant mentioned concerns above the program level, whicherroneously suggest strong hierarchical structures. In fact, the case organizationsworks actively against hierarchies, which can be noticed all over the everydayoffice life.

• The case organization is a role-model for corporate culture, which might explainwhy none of the newly identified concerns is categorized as a culture & mindsetconcern.

• The general interest in the case study, of most of the participants and contactpersons at the industry partner, was high. That could be explained by the possi-ble positive influence a extensive agile development pattern catalog has on thecompany.

39

5. Discussion

5.2. Limitations

• Construct validity questions whether the correction methodology has been used[28]. This principle is met, because we used data of three different degrees andfollowed a fixed process to evaluate the collected data. Unfortunately it is notpossible to publish single interview results.

• Internal validity measures if the results of the study are what the case study aimedfor [28]. Therefore informed every interviewee about the subject of the interviewbeforehand and started every interview with a detailed description of the LSADPL,the structure and goal of the following interview to establish a common ground.Never the less, it was only possible to conduct 14 interviews, which allows for anincomplete result for this case organization.

• External validity describes whether the findings of the case study are in generalvalid or not [28]. Since the results were documented in form of a pattern language,we are aiming for general validity. Unfortunately and due to the limitation to oneindustry partner, we were only able to collect pattern candidates.

• Reliability questions whether a repetition of the case study under the same cir-cumstances would lead to the same result [28]. In our case, this principle is notfully fulfilled, because the main part of the data was collected trough interviewsand interviewees might give different answers, due to being in another project orworking situation.

40

6. Conclusion and Outlook

6.1. Summary

This section will present the overall results for the research objectives introduced in thebeginning of this Bachelor’s Thesis (see Section 1.2).

RQ1: What are recurring concerns of agile teams in agile software development?We started off with a literature review, to collect already identified recurring concerns ofagile team in agile software development. These concerns served as an input for theinterviews conducted during the case study at a German IT consulting company. Overall we identified 33 new concerns and documented the occurrence of 56 of the listed 78concerns.

RQ2: What are good practices for addressing recurring concerns of agile teams inagile software development?The interviews were also conducted to answer the second research question. Over all,we identified and documented 27 good practices for addressing recurring concerns ofagile teams in agile software development (see 4.4). Of those 27 good practices, one wascategorized as a coordination practice, 15 as methodology practices, ten as viewpointsand one as a principle.

RQ3:Which bad practices should be avoided in agile software development?Furthermore, we identified three bad practices, which were documented as anti-patterns.

6.2. Outlook

For future work it is possible to conduct similar case studies at different organization,to collect more concerns and pattern candidates and to increase the number of actualpatterns by fulfilling the rule of three [9]. Another case study at the same organizationis not excluded, because selecting new interview partners and teams might end in adifferent result.As presented in Section 1.3 about the research approach, this thesis only implemented thefirst two steps of the Pattern-Based Design Research (PDR) approach, namely ’observe& conceptualize’. Proceeding the steps of the PDR approach is also promising futurework.

41

A. Appendix

A.1. Interview Questions

During the semi-structured interviews, the interview partners were asked the followingquestions:

Introduction: General Questions about the Interviewee

• How is your role called in your company? (open ended question)

• Which of the following roles fit most to you? (The options were: Agile Coach,Scrum Master, Developer, Tester, Requirements Engineer, Architect, Product Ownerand an empty field for individual inserts)

• How long are you working in the field of agile development? (The options were:<1 year, 1 - 3 years, 3 - 6 years and >6 years)

• How many agile teams are working on your project? (open ended question)

• How many members does your team have? (open ended question)

First Main Phase: Identification of recurring Concerns and Practices

• What are the recurring concerns you face in your role? (open ended question)

• On which level do these concerns occur? (The options were: enterprise, organiza-tion, program and team)

• How are these concerns categorized? (The options were: culture & mindset,communication & coordination, enterprise architecture, geographical distribution,knowledge management, methodology, project management, quality assurance,requirements engineering, software architecture and project management)

• How do you address these concerns? (open ended question)

• What are steps to be avoided while addressing these concerns? (open endedquestion)

43

A. Appendix

Second Main Phase: Identification of recurring Concerns and Practices(by using a list of already identified concerns)

• Which of the listed concerns did you already face in your role? (open endedquestion)

• How do you address these concerns? (open ended question)

• What are steps to be avoided while addressing these concerns? (open endedquestion)

Conclusion

• Are there any open points you want to talk about?

44

B. Appendix

B.1. Documentation of Good and Bad Practices

B.1.1. SYNC Meeting

Pattern OverviewID CO-107Name SYNC Meeting

AliasSummary A weekly meeting to enhance information exchange between

collaboration agile teams.

ExampleThe Scrum Master of Project D, has to facilitate 5 agile teams. Thereby, synchronizingsprint between these team is a challenge. Therefore he introduces a weekly meeting, toenhance the information exchange.

ContextHaving multiple teams collaborating in a large-scale agile development program, it is achallenge to adjust the sprints of each team in a way, that is optimal for the overlyingprogram.

ProblemC-1: How to coordinate multiple agile teams that work on the same product?C-5: How to facilitate shared context and knowledge?C-78: How to synchronize sprints in the large-scale agile development program?

Forces

• It is a challenge to maintain an overview, when trying to synchronize the sprintsof multiple teams.

SolutionA SYNC Meeting is a meeting of representatives, for example a developer or the ScrumMaster, of collaborating agile teams. In is held on a regular basis, for example weeklyor once in a sprint. The goal is to bring teams closer together and providing a goodopportunity to talk about dependencies or in general, exchange information.

45

B. Appendix


• A better overview of the whole program.

• Improves the information exchange between agile teams.

Liabilities:

• Another meeting type is introduced.

See Also:

• V-106: Dependency wall

• M-106: Use Smart Hubs for remote communication in meetings

46


B.1.2. Involve customer in requirements engineering

Pattern OverviewID M-102Name Involve customer in requirements engineering

AliasSummary Supporting the requirements engineering process with a respon-

sible customer for each user story.

ExampleThe requirements engineers of Team 1 have problems with having a good flow ofcommunication with the end users for the requirements elicitation. Together with theProduct Owner they decide on setting an end user and a requirements engineer incharge of each user story.

ContextA software product is developed for a customer and the contractor is responsible for therequirements engineering process. The requirements elicitation is done together withend users. Thereby it can be challenging to have a good communication flow. It can alsobe hard to elicitate the correct requirements from the end users.

ProblemC-10: How to create precise requirement specifications for the development team?C-60: How to create and estimate a user story?Forces

• The customer might not understand why this can be helpful.

• The customer might not have capacity for this.

SolutionFor every user story there is not only a requirements engineer in charge, but also aresponsible person on the customer side.


• Fixed flow of communication with possible end users.

• End users are the best contact to elicitate requirements.

• End users are very interested in a good result, why they probably support therequirements engineering process as good as possible.

Liabilities:

47

B. Appendix

• It can be costly for the customer to support the requirement s engineering processwith additional manpower.

48


B.1.3. Anonymous Surveys and Feedback

Pattern OverviewID M-103Name Anonymous Surveys and Feedback

AliasSummary Anonymous surveys and feedback give the opportunity to voice

feedback freely and to enhance retrospective meetings. But thereis also the possibility of one exploiting the given anonymity forpersonal and nonconstructive feedback.

ExampleThe Scrum Master of Team 3 has the feeling, that not all team members are open duringthe retrospective meetings. In order to address this concern he introduces a tool, whichallows everybody to give feedback anonymously.

ContextWhen holding retrospective meetings one might not voice criticism freely, because hefears consequences. It is also possible that some feedback is overseen, because of thegroup focusing on different points to improve.

ProblemC-39: How to establish a culture of continuous improvement?

Forces

• All team members have to be open to feedback, which is not always the case.

• The team has to be open to changes, which might be derived measures fromfeedback.

SolutionThe idea is to offer a anonymous feedback and survey portal, were everybody can voicecriticism and feedback freely. Everybody is able to see and upvote previous feedback.The collected entries can then for example be addressed in the daily meeting or aretrospective. A additional feature can be, that the survey tool also logs the derivedmeasures and who is responsible for putting these into practice.It also an option to enhance retrospective meetings, by conducting a short and anony-mous survey about the wellbeing of everybody in the team. The results can then beanalyzed together in the meeting.


49

B. Appendix

• Feedback can be given at any time.

• Feedback can be given freely.

• Measures that were derived from previous feedback are logged.

• Retrospective meetings can be enhanced.

Liabilities:

• Anonymity can lead to personal and nonconstructive feedback.

• Another tool has to be implemented and maintained.

50


B.1.4. Define the simplest user story that can possibly work

Pattern OverviewID M-104Name Define the simplest user story that can possibly work

AliasSummary To account for constantly changing requirements one can work

with not in detailed specified requirements.

ExampleTeam 1 is eliciting requirements directly from end users. Because of collaborating withend users, it is most likely to have changes in requirements details over time. To avoidrefactoring these details often, requirement engineers aim to define a user story that isas simple as possible. Therefore details are specified as late as possible.

ContextIn agile development, requirements are specified during the development process.Thereby it is likely to have changes in specifications at some point. If a fully specifieduser story has then to be refactored, this can be cost and time intensive. In the worst casethere is a connection to already implemented features, which then have to be refactoredas well, which increases cost and needed time considerably.

ProblemC-121: How to avoid refactoring user stories often?

Forces

• It is counter intuitive to leave some question during the requirement engineeringprocess open.

• Some changes in specification can not be foreseen.

• The specification must not be too imprecise.

SolutionThe user story is kept as simple as possible, without risking to miss any importantspecifications. In case of a change in specification, refactoring the affected user story isless costly. Never the less, it is important no to weight simplicity over completeness.


• Less cost and time intensive refactoring of user stories.

Liabilities:

51

B. Appendix

• The is a risk of important specification missing.

See Also

• V-109: User Story Template

52


B.1.5. Establish a proxy product owner

Pattern OverviewID M-105Name Establish a proxy product owner

AliasSummary An additional role, called the proxy product owner is established,

to support the product owner at the customer. This might beuseful if the product owner is not 100% competent in the fieldthe development takes place.

ExampleThe customer of Team 1 chose an experienced product owner, but who is new to thecase. In coordination with the product owner, Team 1 then established a proxy productowner who will support the product owner when needed.

ContextThe Product Owner who is located at the customer and/or is not 100% competent inthe field the development takes place, can be hard to work with for the developmentteam. This can be caused by the distance, the missing competences, or missing time ofthe Product Owner to deal with a certain topic.

ProblemC-10: How to create precise requirement specifications for the development team?C-133: How to deal with insufficient work of the product owner?

Forces

• A product owner might not want any support.

• There might be not enough capacity to support the product owner.

SolutionA competent Proxy Product Owner, who is part of the development team, supports theProduct Owner in questions where he might be not competent enough, or does not haveenough time to deal with.

VariantsThe established support for the Product does not have to be called ’Proxy ProductOwner’. It can also be enough to support the Product Owner in certain questions withcompetent people from the development team.

53

B. Appendix


• The results of Product Owner tasks get immediately better.

• The results of the original Product Owner’s work becomes better over time.

• The development team has an easier to reach contact partner.

Liabilities:

• The original Product Owner might feel supervised.

54


B.1.6. Use Smart Hubs for remote communication in meetings

Pattern OverviewID M-106Name Use Smart Hubs for remote communication in meetings

AliasSummary Using a smart can improve the way communication in remote

meetings takes place.

ExampleTeam 1 often holds remote meetings, because it is geographically distributed to fivedifferent locations. To enhance their meetings, the project lead organizes one Smart Hubfor every meeting room that participates in remote meetings regularly.

ContextIf a team is geographically distributed, they have to hold most of their meetings remote.It can be challenging to hold meetings with results, that are as good as if everybodyworld work at the same office.

ProblemC-12: How to provide sufficient tools and infrastructure for remote communications?C-31: How to deal with geographical distance between agile teams?

Forces

• Tools and infrastructure can be expensive.

SolutionUsing a technical infrastructure like Smart Hubs for remote meetings, enhances com-munication between several meeting rooms. A Smart Hub is a small device placed inthe table, that holds a microphone and a speaker, which is then used for all partici-pants in a room. It can start and participate in the remote call automatically, because itis part of the meeting organizing process. One Smart Hub is necessary per meeting room.

VariantsThere are also products where the described function are combined with a big screenand cameras, to support screen sharing and video chat.


• Automated connection to the remote call.

55

B. Appendix

• Better audio quality when connection meeting rooms with several participants ina single room.

56


B.1.7. Directly log spent effort for each user story

Pattern OverviewID M-107Name Directly log spent effort for each user story

AliasSummary A tool is used to log the spent effort directly for a user story. This

gives more options for controlling and the possibility to improveestimations.

ExampleIn Team 4, every Developer and Requirements Engineer logs their time spent for aspecific user story.ContextIt is hard to asses and improve the estimations without knowing how much effort wasspent for a user story in total until it was finished. It might also be a challenge to takethe requirements engineering effort into account when estimating a user story.

ProblemC-54: How to make a cost and schedule estimation?C-60: How to create and estimate user stories?C-107: How to document the actual effort for each user story?

SolutionBy using a tool based solution, requirements engineers and developer directly log theirspent effort for a specific user story.


• Estimations can be evaluated after a user story is finished, which can improvefuture estimations.

• The effort spent for the requirements engineering process can now be directlylogged for each user story.

Liabilities:

• Another tool has to be used, which can increase cost and time spent.

57

B. Appendix

B.1.8. LEGO Retrospective

Pattern OverviewID M-111Name LEGO Retrospective

AliasSummary A creative way of holding a retrospective, derives action items in

a playful process.

ExampleThe Scrum Master of Team 3 uses a LEGO Retrospective to find out about problemswithin the collaboration of his team. One exemplary interpretation of a tall and strongfigure is that the builder feels is comfortable and feels empowered to make decisions.

ContextHolding a retrospective meeting after a sprint, to find out about how everybody feltduring the last sprint and what can be improved for the sprint.


Forces

• To achieve good results from retrospectives, everybody has to be open to voiceand accept feedback.

SolutionA LEGO Retrospective uses LEGO bricks to support the meeting. At the beginning ofthe meeting everybody is asked to use LEGO bricks to build a figure that represents thelast sprint. After everybody has build a figure it is time to present them to the groupand have small discussion about why a figure looks like it does. The second phase ofthis retrospective is, that everybody builds a second figure that represents the steps thathave to be taken in order to become a better team. The next step is again to talked aboutthe created figures in the group. This last steps leads to the measures that are derivedfrom the LEGO Retrospective.

VariantsAnother creative retrospective, that uses the same basic scheme, but offer more optionto derive action items, is M-112: Origami Retrospective.


• This method is creative and may help introvert people to speak freely.

58


• The action items of the retrospective are derived in a playful process.

Liabilities:

• The participants have to be open for creative methods.

59

B. Appendix

B.1.9. Origami Retrospective

Pattern OverviewID M-112Name Origami Retrospective

AliasSummary A creative way of holding a retrospective, derives action items

in a playful process. It also offers the possibility for the scrummaster to observe how the team solves problems.

ExampleThe scrum master of Team 2 uses a Origami Retrospective to find out about problemswithin the collaboration of his team. One team members folded a small rabbit, whichcould be a symbol for him being unhappy and feeling as a weak part of the team.

ContextHolding a retrospective meeting after a sprint, to find out about how everybody feltduring the last sprint and what can be improved for the sprint.


Forces

• To achieve good results from retrospectives, everybody has to be open to voiceand accept feedback.

• Observing the whole process of how a team solves problems is hard to observe. Itis especially hard, if a team work with remote methods.

SolutionThe Origami Retrospective is supported by folding Origami animals. The Scrum Masterhas to prepare enough paper and optional some instruction on how to fold Origamianimals. At the beginning everybody is asked to create a Origami animal, that representsthe last sprint. When all animals are finished, the animals are presented to the groupand a discussion about possible measures to improve the team performance, takes place.Folding Origami animals is usually a challenge for most of the people. The ScrumMaster can use this situation to observe how the team work when solving problems.Some action items can also be derived from this observations.

VariantsAnother creative idea to design retrospectives is the LEGO Retrospective documentedin the methodology pattern M-111. This method follows the same basic scheme.

60



• This method is creative and may help introvert people to speak freely.

• The action items of the retrospective are derived in a playful process.

Liabilities:

• The participants have to be open for creative methods.

61

B. Appendix

B.1.10. Design Sprint

Pattern OverviewID M-113Name Design Sprint

Alias Sprint ZeroSummary A kind of workshop to establish a common vision with end users

of the future system in early stages.

ExampleThe project of Team 1 starts of with a Design Sprint to create the best possible commonvision of the system in the early stages.

ContextStarting a project without sharing a common vision with the end users can lead to a badcollaboration with end users, which again can lead to weak requirements specifications.Wrong specifications can lead to a lot of refactoring in the future, which can be cost andtime intensive.

ProblemC-13: How to share common vision?C-23: How to establish a common scope for different stakeholder groups?C-60: How to create and estimate user stories?C-69: How to establish requirements verification?C-121: How to avoid refactoring user stories often?

Forces

• Eliciting requirements from end users can be challenging.

SolutionA Design Sprint takes place at the very beginning of a project. It can be seen as a firstsprint, that fully focuses on building a common vision for all stakeholders and elicitatekey requirements as early as possible. One possible way of designing a Design Sprintis to have an extensive workshop with a representative group of end users. Such aworkshop takes multiple day and can be repeated in increasing intervals during thewhole project.


• Good connection to end users.

• Establishes a common vision of the future system.

62


• Many requirements can be collected directly from end users.

Liabilities:

• Takes a lot of time and can be expensive.

See Also

• V-109: User Story Template

63

B. Appendix

B.1.11. Architecture Spike

Pattern OverviewID M-114Name Architecture Spike

AliasSummary Developers spent some time to expand their knowledge about

new technologies.

ExampleTeam 1 is aiming to implement state of the art code, wherefore new and beneficialtechnologies have to be used. Unfortunately the developers are not yet familiar withvirtual reality, which forces them to expand their knowledge about this topic. To do so,one developers spends 6 hours to familiarize himself with the topic. Afterwards he isable to teach the other developer what he learned.

ContextWhen aiming for state of the art and highly elaborate source code, Architects andSoftware Engineers are required to have a wide and in depth understanding of newtechnologies.

ProblemC-60: How to create and estimating user stories?C-66: How to foster technical excellence?

Forces

• Gathering knowledge about new technologies requires time and patience.

SolutionIn an Architecture Spike one or two Developers spend time to make themselves familiarwith a new technology. Usually this takes less than one day. Afterwards the Developeruses his newly gathered knowledge to explain new technologies or concepts to hiscolleges. This serves the purpose, that overall less time is spent for gathering knowledgeduring the sprint.


• Expands the knowledge about a new technology.

• Future estimation can profit from the expanded technical knowledge.

Liabilities:

64


• While a Developer is learning about a new technology, he is not able to activelycontribute to the project.

See Also

• CO-106: Community of Practice

65

B. Appendix

B.1.12. Extending user stories by mockups

Pattern OverviewID M-115Name Extending user stories by mockups

AliasSummary Extending user stories by mochups improves the flow of commu-

nication about requirements between end users, RequirementsEngineers and Developers

ExampleBecause Team 1 is collaborating closely with end users, the Requirements Engineersdecide on extending as many user stories as possible by mockups. This helps to explainthe specification to all stakeholders. For Team 1 the most value is created by the endusers being now able to understand specification easier.

ContextWhen specifying user stories it can be difficult to establish a common understandingbetween end users, requirements engineers and software engineers.

ProblemC-10: How to create precise requirement specifications for the development team?C-23: How to establish a common scope for different stakeholder groups?C-60: How to create and estimate user stories?C-121: How to avoid refactoring user stories often?

SolutionThe proposed solution is to extend user stories with mockups, whenever it makes sense.The mockup can be developed in collaboration of an end user with a requirementsengineer. Afterwards a developer uses the mockup to understand the specification better.


• The risk of imprecise requirements for the front-end developers lower.

• Can help to establish a common understanding of requirements.

• Might lead to less refactoring of user stories, because the specification qualityincreases.

Liabilities:

• Creating mockups can be time intensive.

66


B.1.13. Pair Programming

Pattern OverviewID M-116Name Pair Programming

AliasSummary Two software engineers are working together on one workstation,

to increase team spirit and code quality.

ExampleIn order to deal with the geographical distribution an the thereby lacking team spirit,Team 1 often uses Pair Programming to compensate for that. They are implementingPair Programming by video chatting and sharing they screens to each other.

ContextIn geographically distributed teams, where team members do not meet each other often,but also at co-located teams. As long as two developers are able to work on the user story.

ProblemC-24: How to create team spirit and trust among agile teams?C-32: How to deal with lacking team cohesion at different locations?C-66: How to foster technical excellence?

Forces

• Not everybody is willing to do pair programming, but prefers to write code alone.

SolutionPair Programming is a development technique. Usually two developers work togetheron a single workstation. One is writing code, while the other reviews the written codein real time. After some time the roles switch. It is also possible to enable this methodfor distributed teams, by using any communication channel. It is necessary to be abletalk to each other and to share the screen of the developer writing the code.


• Increased team spirit.

• Increased code quality.

• Less bugs.

Liabilities:

67

B. Appendix

• The increased man-power might not lead to equally increased performance.

68


B.1.14. Peer-to-Peer Communication

Pattern OverviewID M-118Name Peer-to-Peer Communication

AliasSummary Pairing two team members at different locations to improve team

spirit and knowledge transfer.

ExampleTeam 1 is geographically distributed. To improve team spirit and knowledge transfer, ateam member at location A is paired with a team at location B.

ContextThe context of this method is the daily routine of distributed agile teams.

ProblemC-3: How to coordinate geographically distributed agile teams?C-5: How to facilitate shared context and knowledge?C-32: How to deal with lacking team cohesion at different locations?

Forces

• Creating team spirit in distributed team is a challenge.

• Communication in distributed teams can be costly.

SolutionThe concept is to pair distributed team members from different locations. They alwayshave to know what their buddy is doing and how he is feeling right now. This can alsobe included in the daily meeting, so that one can share knowledge about the work of hisbuddy at a different office.


• Increased team spirit.

• Enhances knowledge transfer.

Liabilities:

• This approach might lead to higher communication effort.

69

B. Appendix

B.1.15. Dependency Wall

Pattern OverviewID V-106Name Dependency Wall

AliasSummary A board that makes dependencies, for example between two agile

teams, as obvious as possible. This can support things like theSprint Planning.

ExampleTeam 2 and Team 3 are not cut into feature teams, thereby there are often dependenciesbetween both teams. To avoid blocking each other, the scrum masters introduced aDependency Wall, which is used for planning future sprints.

ContextIf multiple agile teams are collaborating it is usual to have dependencies between them.Managing these dependencies is critical to avoid blocking each other during a Sprint.

ProblemC-1: How to coordinate multiple agile teams that work on the same product?C-78: How to synchronize sprints in the large-scale agile development program?C-110: How to visualize dependencies between different agile teams?

Forces

• Some dependencies might not be known upfront.

• Such a board is only effective, when properly maintained.

SolutionBy establishing a connection for every dependency between user stories, as in FigureB.1, it is easy to overview dependencies. For example when looking at the bright reddependency, one can easily realize, that the user story 83:Fill database is planned forsprint 10, but cannot be finished earlier than sprint 11. This is the case, because userstory 42:Setup database logically must be finished beforehand. Finding out that the reddependency is a critical one a would lead to a block situation cannot be seen at theDependency Wall, but by analyzing the user stories.

70


Sprint 10

Team 1

Team 2

Sprint 11 Sprint 12

ID: nameUser story withID and name

32: Store user data

83: Fill database

68: User profile

96: Fix Button

83: Color scheme

42: Setup database

95: Fix Log Out

73: Survey tool

13: network interface

29: ID identification

A dependencyMap Symbols Visualization rules

ID: Name

Horizontal Alignment

Ver

tica

l Alig

nm

en

t Assigned sprint

Team in charge

01: A

02: B

User stories „01:A“ and „02:B“ have a dependecy

Figure B.1.: Example of a dependency wall


• Dependencies between agile teams are obvious.

• Sprint planing can be enhanced, which might lead to less block situations duringa sprint.

71

B. Appendix

B.1.16. User Story Template

Pattern OverviewID V-109Name User Story Template

AliasSummary An User Story Template, ensures a common structure for a good

documentation of requirements.

ExampleA good template could include the following points:

• Background

• Connections

• Triggering event

• Roles

• Postcondition

• Flowchart

• Description of the Flowchart

• User interface

• Alternative sequence of events

• Case of failure

• Non-functional requirements

• Important attributes like frequency, complexity, criticality and execution time

• Open questions and future requirements

ContextA development team uses user stories to specify and keep track of what to implement.The user stories are also used to transfer knowledge from Requirements Engineers toDevelopers. When writing user stories a User Story Template can be used.

ProblemC-8: How to ensure that non-functional requirements are considered by the developmentteam?C-10: How to create precise requirement specifications for the development team?

72


C-60: How to create and estimate user stories?C-121: How to avoid refactoring user stories often?

Forces

• It can be challenging to create a good documentation of all requirements for a userstory.

• It can be challenging to write well structured user stories.

SolutionEvery user story is based on the same User Story Template. The template offers ahighly developed structure, to ensure a precise documentation of requirements. Using atemplate also makes sure that all necessary criteria are mentioned in the specification.After designing such a template it has to be stored at an easily accessible place.


• Good and structured documentation of requirements.

Liabilities:

• Is is costly to create such extensive and detailed specifications.

See Also

• M-104: Define the simplest user story that can possibly work

73

B. Appendix

B.1.17. Cumulative Flow Diagram

Pattern OverviewID V-110Name Cumulative Flow Diagram

AliasSummary A diagram to give an overview over the ratio between tasks in

different states of the workflow.

ExampleTeam 1 maintains a Cumulative Flow Diagram, to keep track of how many user storiesare fully specified and ready for implementation, in comparison with how many userstories are finished.

ContextSynchronizing working speeds between Requirements Engineers and Developers canbe challenging. It can also be hard to overview the number of user stories in differentstates of the workflow.

ProblemC-1: How to coordinate multiple agile teams that work on the same product?C-126: How to synchronize work and speed between Requirements Engineers andDevelopers?

SolutionA cumulative flow diagram is a diagram that can be used to show the number of userstories or tasks in a certain state. The x-axis is a timeline and the y-axis notates thenumber of item is a certain state. By using different colors for the different states abasic line diagram is created. Accumulating the different states now a cumulative flowdiagram is created. In combination with a properly maintained project managementtool, the generation of the diagram can be automated. In Figure B.2 the lines run parallel,which means, that the process is stable.


• Offers a great overview over the ratio between tasks in different states of theworkflow.

• Can give indicators, when the process is unstable.

• Can be automated in combination with a project management tool.

74


0

50

100

150

200

250

300

350

400

450

01.01.2019 01.02.2019 01.03.2019 01.04.2019 01.05.2019 01.06.2019 01.07.2019 01.08.2019 01.09.2019 01.10.2019 01.11.2019 01.12.2019

Nu

mb

er o

f u

ser

sto

ries

Done In Progress To Do

Figure B.2.: Example of a Cumulative Flow Diagram

Liabilities:

• It is only significant, when maintained properly.

• It cannot give information, why the process is unstable.

75

B. Appendix

B.1.18. Project Roadmap

Pattern OverviewID V-112Name Project Roadmap

AliasSummary A Project Roadmap creates an overview of upcoming project

milestones and deadlines.

ExampleThe rollout manager of Team 1 designed a Project Roadmap, to create a better overviewof the upcoming project releases. This helps the team to plan accordingly.

ContextIn long-term project it can be hard to align sprint goals with the milestones of the project.When doing planing it can be handy to have an overview of of upcoming milestonesand deadlines.

ProblemC-22: How to balance short-term and long-term goals?C-130: How to make milestones and deadlines obvious?

SolutionA Project Roadmap is simply a kind of timeline with milestones, deadlines or otherimportant events marked. Additionally it can be extended, by adding deadlines forevents like code-freeze or final review to the specific milestone. This enhances the usage.

Project Kick-Off

MVP after Sprint 6

Test release after Sprint

10

Go-Live after Sprint

16

Presentation;Testing with

end usersSprint Zero

Code freeze:23.07.19

Code freeze:15.10.19

Figure B.3.: Example of a simple Roadmap

76



• Easy to set up.

• Creates a great overview overview of project milestones and deadlines.

77

B. Appendix

B.1.19. Kudo Cards

Pattern OverviewID V-113Name Kudo Cards

AliasSummary Cards that can be filled with feedback one wants to give to

someone else. These cards can improve the rewarding model in ateam.

ExampleTo establish a rewarding model, the scrum master of Team 2 introduces Kudo Cards. Itis now part of the office life to reward coworkers by placing a Kudo Card at their desk.

ContextKodu Cards can be introduced to the everyday office life. Furthermore, collecting themcan extends their context to retrospective meetings.

ProblemC-39: How to establish a culture of continuous improvement?C-55: How to create a teamwork centric rewarding model?

Forces

• Praising the work of someone else in person might be uncomfortable for somepeople.

SolutionKudo Cards are cards, where one can write feedback or compliments on and place themat the desk of someone else. It is also possible to introduce a wall or a box were all KudoCards are collected. The Kudo cards can also be used to enhance retrospective meetings.This can be done by filling them during the meeting or talking about already collectedcards.

VariantsV-17: KUDOS Board, as described in Nina Harders Master’s Thesis [13]


• Might lead to more feedback, which can lead to improvement.

• Increases team spirit.

• Creates one way of a rewarding model.

78


B.1.20. Architectural Guideline

Pattern OverviewID V-117Name Architectural Guideline

AliasSummary A single and easy to find collection of universally valid architec-

tural guidelines.

ExampleIn the internal wiki of the case organization, there is one section where different archi-tectural guidelines are collected. This site is well known to all architects and softwareengineers.

ContextWhen designing software it is a challenge to choose a good and state of the art architec-ture. A architectural guideline can help, whenever someone is seeking for informationon architectural design.

ProblemC-5: How to facilitate shared context and knowledge?C-9: How to find the right balance between architectural improvements and businessvalue?C-14: How to create a proper upfront architecture design of the system?C-38: How to facilitate standardization across agile teams?C-66: How to foster technical excellence?

Forces

• Making guidelines universally valid can be challenging.

SolutionThe proposed solution is to maintain a document collection, for example a section in theinternal wiki, which is accessible for everyone in the company. For example this canbe done by a Community of Practice, according to CO-106. The goal is to collect alluniversally valid concepts about architectural design at a single place, which is easyto find for everyone, who is looking for information, when it comes to architecturaldecisions.


• Might offer quick help for architectural decisions.

79

B. Appendix

• Helps fostering technical excellence.

• Establishes standardization across the whole organization.

Liabilities:

• Another data collection, that has to be maintained.

See Also

• CO-106: Community of Practice

80


B.1.21. Task Board

Pattern OverviewID V-119Name Task Board

AliasSummary A simple board to create a overview of tasks and their assignees.

ExampleThe Scrum Master of Team 3 creates a Task Board, where all important tasks and theirassignees are shown. The Task Board helps the team to keep track of these tasks.

ContextWhen developing software, there are always tasks, that can not be documented andvisualized as a user story (see ??: Visualization of different user story states on a

user story board). Without another form of documentation and visualization it can behard to keep track of these tasks.ProblemC-102: How to create an overview of tasks, responsibilities and deadlines, which are notuser story related?

SolutionThe proposed solution is a simple Task Board. Is is structured in 4 section. The ’Backlog’where all future tasks, that are not yet dealt with are located. The ’To Do’ section, whichcontains all tasks that have to be done, but the assignee did not start working on it. The’Doing’ section, which contains tasks that are being processed right now. And lastly the’Done’ section, which gives a overview of what tasks have already been resolved.

81

B. Appendix

Backlog To Do Doing Done

Task Assignee

Figure B.4.: Example of a simple Task Board

VariantsOne is able to find many varying documentations of task boards in literature, for exam-ple these two [21] [22].


• Creates a overview of tasks and their assignee.

• It is easy to set up and maintain.

82


B.1.22. Modeling processes and workflows

Pattern OverviewID V-120Name Modeling processes and workflows

AliasSummary Modeling project related processes or workflows help to under-

stand them.

ExampleTeam 2 is struggling to understand the process environment, in which their system willbe integrated. To obtain a better understanding, a requirements engineer models theprocess environment and all related workflows with the help of an Event-driven ProcessChain.

ContextUnderstanding a complex process environment or a complex workflow without anymodeling is challenging.

ProblemC-60: How to create and estimate user stories?C-131: How to visualize the target environment of a system with all related workflows?

Forces

• Creating an model requires in depth knowledge about the process.

• Creating an model requires knowledge about the chosen notation.

SolutionModeling a project related business process or workflow, using well known and easilyreadable notations like the Event-driven Process Chains.

Variants

• Event-driven Process Chain (EPC), developed by Scheer and documented withinthe Architecture of Integrated Information Systems (ARIS) framework [18].

• Business Process Model and Notation, developed by the Object ManagementGroup [7]

83

B. Appendix

Figure B.5.: Describtion of an EPC, source: [5]


• A modeled process or workflow is easier to understand.

• The created model can serve as documentation.

• In case of an changing process, a model is easy to adapt.

84


B.1.23. Data model for system data

Pattern OverviewID V-121Name Data model for system data

AliasSummary A structured way to simplify and document system data.

ExampleThe system data of Team 1’ project is large and complex. To achieve better understandingand create a proper documentation, the architect creates a data model by using an EntityRelationship Model.

ContextWhen systems become larger and more complex, the complexity of the concept behindthe stored system data also increases. Having such a complex concept makes is hard tounderstand and document properly.

ProblemC-5: How to facilitate shared context and knowledge?C-14: How to create a proper upfront architecture design of the system?C-37: How to create lightweight documentation?

Forces

• Creating data models can be challenging.

• Understanding the concept of how system data is stored can be challenging.

SolutionA Data Model is a model of the processed data in a specific context [14]. By using acertain annotation the underlying concept of the system data is simplified and docu-mented. The created model should be adapted to future changes.Two exemplary notations are:

• Unified Modeling Language diagram as specified by the Object ManagementGroup [26].

• Entity Relationship Model as proposed by Chen [8].


• Understanding the data model becomes easier.

85

B. Appendix

• Extending a data model becomes easier.

• The data model is documented.

86


B.1.24. Avoid pressure on newly composed teams

Pattern OverviewID A-102Name Avoid pressure on newly composed teams

AliasSummary Newly composed teams are not performing perfectly from the

beginning on. Pressuring teams in early stages, to perform better,might lead to a decrease in performance.

ExampleProject B used to be one big Scrum team and was now split into two smaller teams,namely Team 2 and Team 3 with some additional new members in Team 3 now. Team 2is performing even better than before, but Team 3 is not yet performing very well.

ContextA newly composed team might not perform as good as expected, because the employeesare not yet used to each other or not yet used to the workflow.

ProblemC-127: How to deal with teams that are still in the ’forming’ or ’storming’ phase?

Forces

• A new team is often then composed when more performance is needed.

• A newly composed team needs time to increase performance. The process of teamdevelopment cannot me accelerated as one would like.

Revised SolutionThe well performing team needs a good team spirit and trust in each other. This evolvesover time, which makes the suggested solution, to not pressure them and give themsome time to increase their performance.


• Pressuring teams might lead to a decrease in performance.

87

B. Appendix

B.1.25. Avoid dual roles

Pattern OverviewID A-103Name Avoid dual roles

AliasSummary Combining the two roles overloads a the capability of a single

person.

ExampleA agile development program contains of multiple small agile teams. To save staff costs,the Scrum master of each team also has another role, like being a part time developer.This exceeds the capability of the Scrum master and will lead to an increasing stresslevel or some unsolved tasks.

ContextAgile teams are dependent of their defined roles

ProblemC-16: How to deal with increasing workload of key stakeholders?C-56: How to define clear roles and responsibilities?

Forces

• Hiring an extra person instead of combining two roles looks expensive at first.

Revised SolutionThe advised solution is to simply not combine different roles in a single person. Everyrole is usually a full time job, whereby it is not recommended to spend time for tasks ofother roles. Otherwise it might overload the capability of one team member.Sometimes it can be an option to combine the roles Scrum Master and Agile Coach ina single person. This is not a unsolvable challenge, because some tasks might be verysimilar.


• Less staff required.

• There is the risk, that the assigned tasks cannot be fulfill by person.

• Increasing stress level.

88

Bibliography

[1] 13th Annual State Of Agile Report. Tech. rep. CollabNet VersionOne, 2019.

[2] C. Alexander. A Pattern Language: Towns, Buildings, Construction. New York, USA:Oxford university press, 1977.

[3] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler,J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin,S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas. Manifesto for Agile SoftwareDevelopment. 2001. url: https://agilemanifesto.org/iso/en/manifesto.html(visited on 09/09/2019).

[4] C. L. Buchholz. “Empirical Studies to Identify Challenges and Probe Good Prac-tices in the Adoption of Scaled Agile Methods in the Field of Vehicle DynamicsDevelopment of an OEM.” Technische Universität München, 2019.

[5] S. Buckl, A. M. Ernst, J. Lankes, and P. D. F. Matthes. Enterprise ArchitectureManagement Pattern Catalog. Tech. rep. Technische Universitat Muenchen, 2008.

[6] S. Buckl, F. Matthes, A. W. Schneider, and C. M. Schweda. “Pattern-Based DesignResearch – An Iterative Research Method Balancing Rigor and Relevance.” In:Design Science at the Intersection of Physical and Virtual Design. Ed. by J. vom Brocke,R. Hekkala, S. Ram, and M. Rossi. Berlin, Heidelberg: Springer Berlin Heidelberg,2013, pp. 73–87. isbn: 978-3-642-38827-9.

[7] Business Process Model and Notation. Object Management Group. Object Manage-ment Group, 2014.

[8] P. P.-S. Chen. “The Entity-relationship Model&Mdash;Toward a Unified View ofData.” In: ACM Trans. Database Syst. 1.1 (Mar. 1976), pp. 9–36. issn: 0362-5915. doi:10.1145/320434.320440.

[9] J. O. Coplien. Software Patterns. 1996.

[10] K. Dikert, M. Paasivaara, and C. Lassenius. “Challenges and success factors forlarge-scale agile transformation: A systematic literature review.” In: Journal ofSystems and Software 119 (2016), pp. 87–108. issn: 0164-1212. doi: https://doi.org/10.1016/j.jss.2016.06.013.

[11] T. Dingsøyr, T. E. Fægri, and J. Itkonen. “What Is Large in Large-Scale? A Tax-onomy of Scale for Agile Software Development.” In: Product-Focused SoftwareProcess Improvement. Ed. by A. Jedlitschka, P. Kuvaja, M. Kuhrmann, T. Männistö,J. Münch, and M. Raatikainen. Cham: Springer International Publishing, 2014,pp. 273–276. isbn: 978-3-319-13835-0.

89

https://agilemanifesto.org/iso/en/manifesto.html

https://doi.org/10.1145/320434.320440

https://doi.org/https://doi.org/10.1016/j.jss.2016.06.013

https://doi.org/https://doi.org/10.1016/j.jss.2016.06.013

Bibliography

[12] T. Dingsøyr, N. B. Moe, T. E. Fægri, and E. A. Seim. “Exploring software de-velopment at the very large-scale: a revelatory case study and research agendafor agile method adaptation.” In: Empirical Software Engineering 23.1 (Feb. 2018),pp. 490–520. issn: 1573-7616. doi: 10.1007/s10664-017-9524-2.

[13] N.-M. Harders. “Identifying recurring Challenges and Best Practices of AgileCoaches and Scrum Masters and Documenting them as a part of a Large-ScaleAgile Development Pattern Language.” MA thesis. Technische Universitt München,2019.

[14] P. D. R. Lackes and D. M. Siepermann. Datenmodell. Gabler Wirtschaftslexikon. url:https://wirtschaftslexikon.gabler.de/definition/datenmodell- 28093/version-251730%EF%BF%BD.

[15] May. Systems and software engineering–architecture description. Tech. rep. TechnicalReport. ISO/IEC/IEEE 42010, 2011.

[16] Mountain Goat Software - Scrum. Mountain Goat Software. 2005. url: https://www.mountaingoatsoftware.com/agile/scrum.

[17] M. Paasivaara and C. Lassenius. “Scaling Scrum in a Large Globally DistributedOrganization: A Case Study.” In: 2016 IEEE 11th International Conference on GlobalSoftware Engineering (ICGSE). Aug. 2016, pp. 74–83. doi: 10.1109/ICGSE.2016.34.

[18] A.-W. Scheer and M. Nüttgens. “ARIS Architecture and Reference Models forBusiness Process Management.” In: vol. 1806. Jan. 2000, pp. 376–389. doi: 10.1007/3-540-45594-9_24.

[19] M. Schüll. “Empirical Studies to Identify Coordinationand Methodology Patternsin Large-Scale Agile Development.” Technische Universität München, 2019.

[20] K. Schwaber and J. Sutherland. The Scrum Guide. The Definitive Guide to Scrum: TheRules of the Game. 2017.

[21] Scrum Task Board. Mountain Goat Software. url: https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards.

[22] Task Board. Agile Aliance. url: https://www.agilealliance.org/glossary/taskboard/#q=~(infinite~false~filters~(postType~(~’page~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’task*20board))~searchTerm~’~sort~false~sortDirection~’asc~page~1).

[23] B. W. Tuckmann. “Developmental Sequence in Small Groups.” In: PsychologicalBulletin 63.6 (1965), pp. 384–399. doi: 10.1037/h0022100.

[24] Ö. Uludag, N.-M. Harders, and F. Matthes. “Documenting Recurring Concernsand Patterns in Large-Scale Agile Development.” In: 1.1 (2019), p. 15.

[25] Ö. Uludag, M. Kleehaus, C. Caprano, and F. Matthes. “Identifying and StructuringChallenges in Large-Scale Agile Development Based on a Structured LiteratureReview.” In: Oct. 2018. doi: 10.1109/EDOC.2018.00032.

90

https://doi.org/10.1007/s10664-017-9524-2

https://wirtschaftslexikon.gabler.de/definition/datenmodell-28093/version-251730%EF%BF%BD

https://wirtschaftslexikon.gabler.de/definition/datenmodell-28093/version-251730%EF%BF%BD

https://www.mountaingoatsoftware.com/agile/scrum

https://www.mountaingoatsoftware.com/agile/scrum

https://doi.org/10.1109/ICGSE.2016.34

https://doi.org/10.1007/3-540-45594-9_24

https://doi.org/10.1007/3-540-45594-9_24

https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards

https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards

https://www.agilealliance.org/glossary/taskboard/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'task*20board))~searchTerm~'~sort~false~sortDirection~'asc~page~1)





https://doi.org/10.1037/h0022100

https://doi.org/10.1109/EDOC.2018.00032

Bibliography

[26] Unified Modeling Language. Object Management Group, 2009.

[27] L. Williams and A. Cockburn. “Agile Software Development: It’s about Feedbackand Change.” In: IEEE Computer (2003).

[28] R. K. Yin. Case Study Research: Design and Methods. 5th ed. SAGE Publications Inc.,2014.

91

department of informaticss_thesis.pdf · the agile manifesto [3] states twelve impor-tant...

Documents