Managing Projects Agile

Yaron Hendriks
4373006
Construction Management and Engineering
Delft University of Technology
9 October 2019
Photo by İrfan Simsar on Unsplash
Managing projects Agile

How Agile can contribute to successfully completing projects in high-tech organizations
Colophon
Research title: Managing projects Agile
how Agile can contribute to successfully completing projects in high-tech organizations.
Date: October 9, 2019
Writer: Yaron Hendriks

+31 627520087
Yaronhendriks@gmail.com
Student number: 4373006
University: Delft University of Technology
Faculty: Civil Engineering and Geosciences
Master study: Construction Management and Engineering (CME)
Graduation committee:
Prof. Dr. H.L.M. Bakker – Chair of the graduation committee

Professor of Management of Engineering projects, Faculty of Civil Engineering and
Geosciences at the Delft University of Technology
Dr. ir. M.G.C. Bosch-Rekveldt – First supervisor

Assistant professor of Prjoject Management, Faculty of Civil Engineering and
Geosciences at the Delft University of Technology
Dr. G. de Vries – Second supervisor

Assistant professor of Public Management and Organization, Faculty of Technology,
Policy and Management at the Delft University of Technology
Dr. ir. H.G. Mooi – External supervisor

2
Project and Program management expert at ASML

Page
Page
3
Preface
This thesis ends my 5-year education in Delft. It completes my master of ‘Construction Management and
Engineering’ and builds on my bachelor ‘Systems Engineering, Policy Analysis and Management’.
The past 7 months have been a great experience.
First and foremost, my internship at a large high-tech company gave me understanding of corporate life.
I would therefore like to express my gratitude to my corporate supervisor Herman Mooi for making the
internship possible and providing me with valuable insights. I really appreciated the fact that he made
time for me during the weekly meetings, it helped a lot in writing my thesis. Or as he would say: “Schrijven
is schrappen.”
The internship company made me feel welcome and I enjoyed the talks with the team members and
(many) employees. It would be pleasant to return at some point in time.
I would like to thank the rest of my graduation committee. Hans Bakker for leading the committee
meetings and providing clear feedback. Gerdien de Vries for the methodological feedback and the
enjoyable time working with you. A special thanks to Marian Bosch-Rekveldt who initiated the internship
and helped me through the graduation journey in our weekly meetings in Delft. She never told me what I
had to do but made me realize why some shifts in direction would be better, making the graduation
approach Agile too.
Of course I thank all the 15 interviewees at 6 different organizations. It was always interesting to discuss
the topic of Agile and see the different perspectives. It is appreciated that they spend their scarce time in
helping me with my research.
At last, but not least, I would like to thank my family, friends and girlfriend for supporting me during the
graduation process. They were all interested in the research and wanted to read my thesis during the
process and could also give me the distraction when needed.
I am looking forward to increase my experience as the next personal and career adventures are awaiting
in moving to Utrecht with my girlfriend and becoming a part of the Witteveen+Bos company.
Yaron Hendriks,
Delft, September 6th 2019

4
Page
Summary
In general, projects still fail at a high rate. New project management approaches have been found to try
and do something about the high rate of failing projects. One of these promising modern approaches is
Agile project management. It has been practiced increasingly since recent years in many sectors, most
evident in the ICT sector. Though initiatives have started in the high-tech sector, it has not been used to
the fullest yet. Therefore, it was worth to find out how the Agile philosophy helps successfully completing
a project. The following research question is answered in this thesis: HOW CAN AN AGILE WAY OF WORKING
HELP TO SUCCESSFULLY COMPLETE HIGH-TECH PROJECTS?
Literature study
A literature study was executed to find theoretical evidence of Agile practices, success and maturity.
Considering Agile success, the literature study found that success in an Agile environment is covered by
process and project success. Process success consists of project team satisfaction and Agile
implementation. Project success consists of project constraints (organizational satisfaction), quality and
value (customer satisfaction). It was concluded that project success criteria in an Agile environment are
not much different compared to a traditional environment. However, more weight is given to quality of
the product and value for the customer than to cost, scope and schedule.
Exploring literature found a complete list of practices which cover Agile. It was found that these practices
are covering all values and principles of the Agile manifesto (Martin, Fowler, & Beck, 2001).
After exploring different Agile maturity measurement models, it was concluded that the
Comparativeagility survey is of best use for this research because it gives objective results and the data is
easy to use and analyze. Also, it was supported by literature that this survey portrays agility in teams
better than other surveys (Jalali, Wohlin, & Angelis, 2014). It was also concluded that the
Comparativeagility survey can measure improvement of these success criteria, compared to the situation
before a project was working Agile.
Case study
A case study is performed because of the explorative nature of this research. A selection of 5 cases, by
means of projects, was made from one organization and 5 other cases were selected from 5 different
organizations. For the latter 5 cases, two respondents were interviewed. This resulted in 15 interviews of
10 cases at 6 different organizations. The respondents were asked to fill in a contextual survey together
with a Comparativeagility survey to find the Agile maturity and improvements on success of the case.
After having obtained the survey data, interviews were held to go in depth on the Agile practices and their
effect on success.
The practical findings can be categorized into four themes which influence the success of the Agile way of
working. These themes are: Team configuration, Transparency, Roles and Management support and have
different implications for various stages of Agile working. Another theme which should be kept in mind
for high-tech companies are the characteristics of technical employees. These themes will come back
when discussing the best practices found in this research.
5
Page
Context of cases
Differences in the effect of an Agile initiation were found between cases which initiated Agile bottom-up
or top-down. Support of both the teams and higher management is required in order to further mature.
When support of teams lacks, resistance will occur. This can make it harder to further mature as a team.
When support of higher management lacks, respondents mentioned that the team cannot further mature
as alignment with other teams is harder to realize.
Best practices
The cross-case analysis found five practices which have been mentioned most frequently as most
important Agile practice to influence success and are mentioned most by cases which have improved
success most. These are:
• Daily standup meeting
• Transparency
• Team ownership
• Sprint planning
• Stable team
Of the above-mentioned important practices, three stand out. Daily standup meeting, transparency and
team ownership are most frequently mentioned as important practice to increase success by the cases
which were highly successful. This indicates that these practices have the biggest influence on increasing
success and are thus regarded as best practices.
It is found that the daily standup meeting is mentioned most frequently as a best practice. Transparency
is mentioned often as a best practice and also as an effect of Agile which helps to reach success. The daily
standup meeting helps teams being transparent.
Having a stable multidisciplinary team results, besides having all required functions in one team, in a
feeling that a team is working on the project instead of people working on small tasks. This caused the full
team being responsible for the project. Making the team autonomous enhances the feeling that the
project is their project. This brings along the responsibility of delivering and is said to ultimately make the
team self-organizing. This autonomy should arise from trust in the team by management.
It is noticeable that frequent communication with the customer is only mentioned once by the
interviewees as an important practice which influences project success. This practice is one of the main
principles of Agile and is mentioned often in literature. The practice being mentioned only once does not
say the practices is not important, it only says that all respondents except one found three practices more
important to influence success. The assumption can be made that frequent communication with the
customer is not mentioned often as important because technical employees tend to have an inward focus
by nature, they mainly think of their own team and tasks instead of the external stakeholders. This means
that
Even though quantitative analyses showed that functional and usability customer satisfaction improves in
any case when implementing Agile, high-tech companies should keep the above mentioned assumption
in mind and try to make technical employees better aware of the importance of customer involvement.
6
Page
Effect of introducing Agile
Respondent mentioned in the interviews that transparency, team ownership and better communication
as the top-3 effects of how introducing Agile helps in improving success. Other effects mentioned are
quick problem identification, calmness for engineers and teamfeeling.
The results of the Comparativeagility survey showed that on average, all seven dimension of success are
improved. Team morale was improved most due to an introduction of Agile. Usability customer
satisfaction and economic value increased least. However, a box plot of usability customer satisfaction
showed that scores range from 3.00 to 4.00, meaning that it increases in any case. Economic value and
quick and often delivery show variability which ranges from a decrease to increase in success. This says it
is unsure whether Agile causes an increase in success on these dimensions. All other success dimensions
show box plots indicating improvement in any case. So it can be concluded that on all dimensions except
quick and often delivery and economic value success is increased when introducing Agile.
Agile maturity
A maximum level of maturity might not be required to improve success most as it was found that success
increased from low to medium maturity but did not increase from medium to high maturity. High
increases of success were seen in medium to highly mature teams while low improvements were seen in
low mature teams. However, the case study also showed that low mature teams do not show a decrease
in success. This tells that no case has seen a decrease in success after implementing Agile.
Considering the influence of the Agile maturity level on the importance of best practices, it is seen that
the daily standup meeting is mentioned as best practice for all three categories of maturity and is
therefore said to be important for all maturities. Sprint planning is mentioned in low and high mature
cases. Team ownership, transparency and stable teams are only mentioned in medium to high maturity
cases. This suggests that these three practices play a more important role in higher mature teams. The
scrum board is only mentioned in cases which have low to medium maturity. This suggests that this
practice plays a more important role in lower mature teams. However, it is not mentioned by highly
successful cases. For this reason, this practice is not mentioned as best practices.
Embedding Agile in an organization

Management support was found to be essential in embedding Agile within an organization. Creating
management support can be done by showing successful pilots and having transformational leadership
roles. This leadership role should convey to the workers and higher management why and how Agile can
help them. It was said alignment problems can be prevented by openly telling you work Agile and by
communicating who needs what when. A standardized method for an organization is beneficial because
it gives something to hold on to and it created a shared language so that everyone can understand and
align with each other. It is believed to be beneficial only when presenting such a process on high level. It
is important to leave freedom to the teams on how to practice Agile as they are the ones who know best
what works for them.
Recommendation
The recommendations in Figure 1 are advised to follow to ensure improvements on success by help of
Agile. They are derived from the cross-case analysis. The first column is applicable to teams which have
just started out with Agile or low mature Agile teams. The second column is for teams who want to further
7
mature to a higher level. The third column are recommendations to make scaling possible throughout a
Page
department or organization as it helps creating management support and alignment between teams.
Initiating Agile
Maturing Agile
Embedding Agile
•Just do it •Have everyone •Have a shared process on
understand the basics Agile within a
•100% framework department or an
•Have dedicated and organization
•One team at the time experienced scrum
masters and product •(transformational)
•Convey why Agile works owners on board Leadership roles
•Create team ownership •Share successes and

lessons learnt (of pilots)
•Take the time
•Argue whether to strive

for maximum maturity
Figure 1 - Overview recommendations
Conclusion
This thesis concludes that Agile is promising in helping to successfully complete Dutch complex projects
in the high tech sector as nine out of ten cases have shown improvements in success since their Agile
initiation. Applying Agile did not decrease average success in any case. All dimensions except quick and
often delivery and economic value success is increased when introducing Agile.
8
Page
Samenvatting
Over het algemeen wordt een groot deel van projecten niet succesvol afgerond. Veranderingen in de
aanpak van project management, om iets aan het hoge percentage falende projecten te doen, zijn te zien.
Een van de nieuwe aanpakken is Agile. Hier wordt steeds meer gebruik van gemaakt in de afgelopen jaren,
met name in de ICT sector. Er hebben ook initiatieven plaatsgevonden in de high-tech sector, al wordt
hier nog niet optimaal gebruik van gemaakt. Daarom is het van waarde om uit te zoeken hoe de Agile
filosofie geïmplementeerd moet worden zodat het tot een verbetering leidt van het succesvol afronden
van projecten. De volgende hoofd onderzoeksvraag is beantwoord in deze thesis: HOE KAN EEN AGILE
MANIER VAN WERKEN BIJDRAGEN AAN HET SUCCESVOL AFRONDEN VAN PROJECTEN IN DE HIGH-TECH SECTOR?
Literatuur studie
De literatuur studie vond plaats om theoretisch bewijs te vinden over de samenhang van Agile
toepassingen, succes en volwassenheid. Wat betreft Agile succes, de literatuur studie vond dat dat succes
in een Agile omgeving omvat wordt door proces en project succes. Proces succes bestaat uit project team
tevredenheid en de mate van Agile implementatie. Project succes bestaat uit de projectrestricties
(organisatie tevredenheid), kwaliteit en waarde (klanttevredenheid). Er is geconcludeerd dat project
succes criteria in een Agile omgeving niet veel verschillen van de traditionele omgeving. Echter, er wordt
meer gewicht gegeven aan de kwaliteit van het product en de waarde voor de klant dan kosten, scope en
tijd.
Het verkennen van de literatuur heeft een lijst met toepassingen gevonden die de term Agile dekken.
Deze toepassingen dekken alle vier de waarden en alle twaalf de principes van het Agile manifesto
(Martin, Fowler, & Beck, 2001).
Na het verkennen van verschillende Agile volwassenheid meetmodellen, is gebleken dat de

Comparativeagility vragenlijst het beste van toepassing was op dit onderzoek aangezien het objectieve
resultaten geeft en de data is gemakkelijk te gebruiken en analyseren. Daarnaast wordt er in literatuur
besproken dat deze vragenlijst agility beter portretteert dan andere vragenlijsten (Jalali, Wohlin, &
Angelis, 2014). Bovendien heeft het literatuuronderzoek gevonden dat de vragenlijst de verbetering, ten
opzichte van voor de Agile introductie, van project succes kan meten.
Case studie
Een case studie is uitgevoerd vanwege de exploratieve aard van dit onderzoek. Een case studie is het juiste
detailniveau voor het vinden van kwalitatieve antwoorden. 5 cases, gedefinieerd door projecten, zijn
geselecteerd van 1 organisatie en 5 andere cases zijn geselecteerd uit 5 andere verschillende bedrijven.
Voor de laatste 5 cases zijn er twee respondenten per case geïnterviewd. Dit resulteerde in 15 interviews
van 10 cases bij 6 bedrijven. The respondenten werden gevraagd om een contextuele vragenlijst en een
Comparativeagility vragenlijst in te vullen. Hiermee werden de selectie criteria getoetst en de
volwassenheid en verbetering van succes gemeten. Na het verkrijgen van deze data werden interviews
gehouden om dieper op de effecten van de Agile toepassingen op succes in te gaan.
De praktische bevindingen kunnen gecategoriseerd worden in vier thema’s die invloed hebben op het
succes van de Agile manier van werken. Deze thema’s zijn: Team configuratie, transparantie, rollen en
management draagkracht. Een ander thema dat van belang is voor high-tech bedrijven zijn de
9
karakteristieken van technische werknemers. Deze thema’s hebben verschillende implicaties voor
Page
verschillende stadia van de Agile manier van werken.

Context van de casussen
Verschillen in effect van een Agile initiatie waren gevonden tussen casussen die Agile bottom-up en top-
down geïnitieerd hebben. Draagkracht van zowel teams als hoger management zijn vereist om
volwassener te worden. Wanneer draagkracht van een team ontbreekt, zal het lastig worden om een hoog
genoeg volwassenheidsniveau te behalen. Wanneer management draagkracht ontbreekt, zal een team
tegen een glazen plafond van volwassenheid komen aangezien het lastig is om af te stemmen met andere
teams.
Beste toepassingen
De analyse over de tien casussen vond vijf toepassingen van Agile die het vaakst werden genoemd als
meest belangrijke toepassingen die project succes beïnvloeden. Bovendien zijn ze genoemd door de
casussen die de hoogste verbeteringen in succes liet zien. Deze toepassingen zijn:
• Dagelijkse standup meeting
• Transparantie
• Team ownership
• Sprint planning
• Stabiele teams
Van de bovengenoemde toepassingen zijn drie extra belangrijk. De dagelijkse standup meeting,
transparantie en team ownership worden het meest genoegd als belangrijke toepassing door de
respondenten van cases met hoog succes. Dit laat zien dat deze toepassingen het meeste invloed hebben
op het verbeteren van success en worden dus gezien als beste toepassingen van Agile.
Het is gebleken dat de dagelijkse standup meeting het meest wordt genoemd als beste toepassingen.
Transparantie wordt vaak als beste toepassingen genoemd maar ook als reden waarom Agile bijdraagt
aan success. Een dagelijkse standup meeting helpt teams transparant te worden.
Wanneer een team multi-disciplinair is, zorgt het naast dat alle benodigde functies in een team zitten ook
voor het gevoel dat het team aan een project werkt in plaats van individuen aan een taak. Dit zorgt ervoor
dat het gehele team verantwoordelijk voor een project wordt. Wanneer een team autonoom is, vergroot
dit het gevoel dat het hun project is. Dit brengt de verantwoordelijkheid om te leveren en er is gezegd dat
dit leidt tot een zelf organiserend team. De autonomie moet voortkomen uit het vertrouwen dat
management in het team heeft.
Het valt op dat het vaak communiceren met de klant maar een keer genoemd is als belangrijke toepassing
van Agile. Deze toepassing is een van de belangrijkste principes van het Agile manifesto en wordt vaak
genoemd in de literatuur. Het feit dat deze toepassing maar een keer is genoemd zegt niet dat het niet
belangrijk is, maar respondenten vinden drie toepassingen belangrijker. De aanname is gemaakt dat deze
toepassing niet vaak genoemd is als belangrijk aangezien technische werknemers een focus naar binnen
hebben. Dat wil zeggen dat ze vooral aan hun eigen taken en team denken en minder rekening houden
met externe partijen zoals de klant. Dit betekend dat high-tech bedrijven aandacht moeten besteden aan
het bewust maken van technische werknemers dat de klant erg belangrijk is.
10
Effect van Agile

Respondenten noemden in de interviews dat transparantie, team ownership en verbetering van de
Page
communicatie de top 3 effecten zijn van het introduceren van Agile op verbetering van project succes.
Het sneller herkennen van problemen, rust voor de ingenieurs en het team gevoel zijn andere effecten
die genoemd zijn.
Het resultaat van de Comparativeagility vragenlijst liet zien dat gemiddeld alle zeven dimensies van succes
zijn verbeterd door het introduceren van Agile. Het team moraal was het meest verbeterd.
Gebruiksklanttevredenheid en economische waarde waren het minst verbeterd. Echter, een box plot van
deze data liet zien dat de gebruiksklanttevredenheid in geen enkel geval vermindert. De succesdimensies
economische waarde en het snel en vaak leveren lieten variabiliteit zien die varieerde van vermindering
tot verbetering van succes. Dit betekend dat het onzeker is of Agile zorgt voor een verbetering op deze
dimensies. Alle andere succesdimensies lieten box plots zien die verbetering laat zien in alle gevallen. Er
kan geconcludeerd worden dat alle dimensies van succes, behalve economische waarde en het snel en
vaak leveren, verbeteren wanneer Agile is geïntroduceerd.
Agile volwassenheid
Het onderzoek vond dat de volwassenheid dimensies ‘cultuur’ en ‘kennis creatie’ van de
Comparativeagility vragenlijst veel meer invloed hebben op het volwassenheidsniveau dan andere
dimensies. Er werd gezien dat cultuur scores hoger zijn voor casussen die eerder begonnen zijn met Agile.
Dit is benadrukt door een kwantitatieve analyse van de 10 casussen die liet zien dat het tijd kost om de
Agile volwassenheid te verhogen.
Daarnaast werd er bevonden dat een maximaal Agile volwassenheidsniveau niet vereist is om maximale
verbetering van project succes te behalen. Hoge verbetering van succes werd gezien in cases met
gemiddeld tot hoge volwassenheid en lage verbetering werd gezien in casussen met lage volwassenheid.
De case studie liet ook zien dat casussen met lage volwassenheid geen verslechtering van project succes
liet zien. Geen van de casussen liet dus een verslechtering van het project succes zien. Er kan dus gesteld
worden dat een bepaald volwassenheidsniveau behaald moet worden om tot een verbetering van project
succes te komen terwijl streven naar maximale volwassenheid niet efficiënt is.
Agile borgen in organisatie

Er werd bevonden dat draagkracht van management essentieel is om Agile te borgen in een organisatie.
Het creëren van deze draagkracht van door het laten zien van succesvolle proefprojecten en door
transformationele leiderschapsrollen in de organisatie te hebben. Het hebben van een gedeelde methode
van verschillende manieren van Agile werken brengt zekerheid in een transitie. Daarnaast helpt het een
om verschillende teams af te stemmen aangezien ze dezelfde taal delen. Het is belangrijk om vrijheid aan
de teams te laten door ze zelf te laten bepalen hoe ze Agile toepassingen gebruiken aangezien het team
het beste weet wat bij hen past.
11
Page
Aanbevelingen
De aanbevelingen in Figure 2 worden geadviseerd te volgen om te verzekeren dat succes wordt verbeterd
door het introduceren van Agile. Ze zijn voortgekomen uit de cross-case analyse van dit onderzoek. De
eerste kolom is van toepassing op teams die net gestart zijn met Agile of dit nog willen doen. Dit komt
vaak overeen met een lage volwassenheid. De tweede kolom is voor teams die meer volwassen willen
worden. de derde kolom zijn aanbevelingen om Agile schalen mogelijk te maken voor een gehele afdeling
of organisatie aangezien het helpt om management draagkracht en afstemming tussen teams te
verkrijgen.
Initiating Agile
Maturing Agile
Embedding Agile
•Gewoon doen •Zorg dat iedereen de •Heb een gedeeld proces
basis van Agile begrijpt van Agile binnen een
•100% framework afdeling of organisatie
•Heb toegewijde en
•Een team per keer ervaren scrum masters en •(transformationele)
product owners aan Leiderschap rollen
•Waarom Agile werkt boord
overbrengen •Deel succesen en
•Creeer team ownership geleerde lessen (van test
projecten)
•Neem de tijd
•Ga na of maximale
volwassenheid nodig is
Figure 2 - Overzicht aanbevelingen
Conclusie
Dit onderzoek heeft geconcludeerd dat Agile veelbelovend is om bij te dragen aan een verbetering van
project succes in complexe Nederlandse projecten in de high-tech sector. Dit kan geconcludeerd worden
aangezien negen van de tien cases verbetering lieten zien in succes sinds het introduceren van Agile. Het
toepasssen van Agile heeft in geen geval voor een vermindering van succes geleidt. Alle success dimensies
behalve economische waarde en het snel en vaak leveren zijn verbeterd sinds het introduceren van Agile.
12
Page
Content
Colophon ....................................................................................................................................................... 2
Preface .......................................................................................................................................................... 4
Summary ....................................................................................................................................................... 5
Samenvatting ................................................................................................................................................ 9
Content ....................................................................................................................................................... 13
List of figures ............................................................................................................................................... 16
List of tables ................................................................................................................................................ 17
1. Introduction ....................................................................................................................................... 18
1.1 Research goal and questions ...................................................................................................... 19
1.2 Research approach...................................................................................................................... 20
1.3 Research outline ......................................................................................................................... 21
2. Literature study .................................................................................................................................. 22
2.1 The Agile approach ..................................................................................................................... 22
2.1.1 Background ......................................................................................................................... 22
2.1.2 Agile approach defined and scoped .................................................................................... 22
2.1.3 Agile vs. traditional project management........................................................................... 23
2.1.4 Program and portfolio management in an Agile approach ................................................ 24
2.2 Successfully completing a project in an Agile environment (SQ1) ............................................. 26
2.3 Agile project management elements (SQ2) ................................................................................ 29
2.4 Measurement of Agile maturity.................................................................................................. 32
2.4.1 Literature vs. Comparativeagility ........................................................................................ 33
2.5 Conclusion literature study ......................................................................................................... 35
3. Preliminary results ............................................................................................................................. 36
3.1 Findings exploratory interviews .................................................................................................. 36
3.2 New insights in Agile practices.................................................................................................... 40
3.3 Towards the case study .............................................................................................................. 41
4. Case study .......................................................................................................................................... 43
4.1 Motivation of case studies as a research method ...................................................................... 43
4.2 Case study design ........................................................................................................................ 44
4.3 Preparing the interviews ............................................................................................................. 45
4.4 Analyzing the surveys and interviews ......................................................................................... 46
5. Results case study .............................................................................................................................. 48
13
5.1 Case 1.1: Delivery of a technical component.............................................................................. 48

Page
5.2 Case 1.2: Software integration.................................................................................................... 51

5.3 Case 1.3: Agile transformation.................................................................................................... 53
5.4 Case 1.4: Sustaining of technical component ............................................................................. 55
5.5 Case 1.5: IT value stream ............................................................................................................ 57
5.6 Case 2: Surveillance solution for nature reservation .................................................................. 59
5.7 Case 3: Support and improvement of wafer production ............................................................ 61
5.8 Case 4: Migration of software system ........................................................................................ 63
5.9 Case 5: Website migration .......................................................................................................... 64
5.10 Case 6: Delivering software and hardware for parcel transport systems............................... 66
6. Cross-case analysis ............................................................................................................................. 68
6.1 Agile Maturity ............................................................................................................................. 68
6.1.1 Categorization maturity ...................................................................................................... 69
6.1.2 Maturity dimensions ........................................................................................................... 70
6.1.3 Maturing takes time ............................................................................................................ 71
6.2 Case success ................................................................................................................................ 73
6.2.1 Categorization success ........................................................................................................ 73
6.2.2 Success dimensions ............................................................................................................. 75
6.2.3 Maturity vs. success ............................................................................................................ 76
6.3 Agile way of working ................................................................................................................... 78
6.3.1 Effect of Agile ...................................................................................................................... 78
6.3.2 Agile practices ..................................................................................................................... 79
6.3.3 Agile best practices ............................................................................................................. 87
6.4 Organization and Agile ................................................................................................................ 90
6.4.1 Top-down or bottom-up ..................................................................................................... 90
6.4.2 Program and portfolio management .................................................................................. 91
6.4.3 Alignment with other teams ............................................................................................... 92
6.4.4 Leadership roles .................................................................................................................. 92
6.5 Towards the conclusion .............................................................................................................. 94
7. Discussion ........................................................................................................................................... 95
7.1 Discussing the findings ................................................................................................................ 95
7.1.1 Team configuration ............................................................................................................. 95
7.1.2 Transparency....................................................................................................................... 96
7.1.3 Roles .................................................................................................................................... 96
7.1.4 Management support ......................................................................................................... 97
14
7.1.5 Characteristics of technical employees .............................................................................. 97

Page
7.2 Discussing the limitations ........................................................................................................... 99

7.2.1 Interviews............................................................................................................................ 99
7.2.2 Analysis ............................................................................................................................... 99
7.2.3 Maturity and success scores ............................................................................................... 99
8. Closure .................................................................................................................................................. 100
8.1 Conclusion ................................................................................................................................. 100
8.2 Recommendations .................................................................................................................... 106
8.2.1 Future research ................................................................................................................. 106
8.2.2 Recommendations for practice ......................................................................................... 108
8.3 Relevance of research ............................................................................................................... 112
8.3.1 Relevance for theory ......................................................................................................... 112
8.3.2 Relevance for practice ...................................................................................................... 112
8.4 Personal reflection .................................................................................................................... 113
References ................................................................................................................................................ 114
Appendices................................................................................................................................................ 119
Appendix A – Twelve principles of Agile project management ............................................................ 119
Appendix B – Agile vs. traditional project management ...................................................................... 120
Appendix C – Comparing scaled Agile methods ................................................................................... 123
Appendix D – Agile elements ................................................................................................................ 124
Appendix E – Testing compartiveagility survey .................................................................................... 128
Appendix F – Interview protocol .......................................................................................................... 129
Appendix G – Comparativeagility survey questions ............................................................................. 133
Appendix H – Overview interview ........................................................................................................ 135
15
Page
List of figures
FIGURE 1 - OVERVIEW RECOMMENDATIONS ................................................................................................................8
FIGURE 2 - OVERZICHT AANBEVELINGEN ....................................................................................................................12
FIGURE 3 - RESEARCH APPROACH ...............................................................................................................................20
FIGURE 4 - RESEARCH METHODS .................................................................................................................................20
FIGURE 5 - RESEARCH OUTLINE ...................................................................................................................................21
FIGURE 6 - PHASES TRADITIONAL PROJECT MANAGEMENT .......................................................................................23
FIGURE 7 - PHASES AGILE/SCRUM ...............................................................................................................................23
FIGURE 8 - TRANSFORMATION OF SUCCESS TRIANGLE (HIGHSMITH, 2009) ..............................................................27
FIGURE 9 - VALUE & COST COMPARISON ....................................................................................................................27
FIGURE 10 - LITERATURE VS. COMPARATIVEAGILITY ..................................................................................................33
FIGURE 11 - CASE STUDY APPROACH (YIN, 2018) ........................................................................................................43
FIGURE 12 - ANALYSIS OVERVIEW ...............................................................................................................................47
FIGURE 13 - AVERAGE MATURITY SCORES ..................................................................................................................69
FIGURE 14 - MATURITY SCORES PER DIMENSION .......................................................................................................69
FIGURE 15 – AVERAGE MATURITY SCORES AND CATEGORIZATION............................................................................70
FIGURE 16 – BOX PLOT OF MATURITY SCORES PER DIMENSION ...............................................................................71
FIGURE 17 - MATURITY SCORE VS. MONTHS SINCE INITIATION .................................................................................72
FIGURE 18 - AVERAGE SUCCESS SCORES .....................................................................................................................73
FIGURE 19 - SUCCESS SCORES PER DIMENSION ..........................................................................................................73
FIGURE 20 - BOX PLOT SUCCESS SCORES PER DIMENSION (RANKED BY AVERAGES) .................................................75
FIGURE 21 - MATURITY CATEGORIZATION VS. SUCCESS SCORES ................................................................................76
FIGURE 22 - MATURITY VS. SUCCESS ...........................................................................................................................76
FIGURE 23 - FREQUENCY REASONS AGILE IMPROVES SUCCESS ..................................................................................78
FIGURE 24 - FREQUENCY SPRINT DURATION CATEGORIZED BY SUCCESS ...................................................................84
FIGURE 25 - FREQUENCY BEST PRACTICES ..................................................................................................................87
FIGURE 26 - FREQUENCY BEST PRACTICES PER SUCCESS CATEGORY ..........................................................................88
FIGURE 27 - FREQUENCY BEST PRACTICES PER MATURITY CATEGORY .......................................................................89
FIGURE 28 - COMPARISON SUCCESS LITERATURE AND COMPARATIVEAGILITY .......................................................101
FIGURE 29 - BOX PLOT SUCCESS SCORES PER DIMENSION (RANKED BY AVERAGES) ...............................................105
FIGURE 30 - OVERVIEW RECOMMENDATIONS ..........................................................................................................108
FIGURE 31 - AGILITY TEST PROJECT ...........................................................................................................................128
16
Page
List of tables
TABLE 1 - SYNTHESIS SUCCESS CRITERIA .....................................................................................................................28
TABLE 2 - SYNTHESIS AGILE PRACTICES .......................................................................................................................31
TABLE 3 - AGILE PRACTICES FROM LITERATURE, NOT COVERED IN SURVEY...............................................................34
TABLE 4 - PRACTICES WHICH COVER THE TERM ‘AGILE’ .............................................................................................35
TABLE 5 - INFORMATION RESPONDENTS EXPLORATORY INTERVIEW .........................................................................36
TABLE 6 – COMPLETE LIST OF AGILE PRACTICES FOUND IN EXPLORATORY RESEARCH ..............................................40
TABLE 7 - FINAL SELECTION OF PRACTICES..................................................................................................................41
TABLE 8 - REPLICATION DESIGN...................................................................................................................................44
TABLE 9 - OVERVIEW DATA SOURCES..........................................................................................................................45
TABLE 10 - PILOT RESPONDENT INFORMATION ..........................................................................................................45
TABLE 11 – INFORMATION RESPONDENTS CASE STUDY .............................................................................................48
TABLE 12 - CASE INFORMATION ..................................................................................................................................68
TABLE 13 - CATEGORIZATION CASES BY SUCCESS .......................................................................................................74
TABLE 14 - VARIABLE-BY-VARIABLE MATRIX ...............................................................................................................79
TABLE 15 - RESULTS AGILE PRACTICES ........................................................................................................................86
TABLE 16 - LIST OF PRACTICES FULLY COVERING AGILE ............................................................................................101
TABLE 17 - AGILE VS. TRADITIONAL APPROACH (HEEMSTRA, KETEL, & VAN DAALEN, 2015) PAGE 33-35 ...............120
TABLE 18 - TRADITIONAL VS. AGILE APPROACH (JALALI SOHI, 2018) P. 43. ..............................................................120
TABLE 19 - AGILE VS. TRADITIONAL APPROACH (VERBRUGGEN, 2017) ....................................................................121
TABLE 20 - COMPARING SCALED AGILE METHODS (ALQUDAH & RAZALI, 2016) ......................................................123
TABLE 21 - AGILE ELEMENTS (A GUIDE TO AGILE PRACTICES, 2019).........................................................................124
TABLE 22 - AGILE ELEMENTS (SCHWABER & SUTHERLAND, 2013) ...........................................................................124
TABLE 23 - AGILE ELEMENTS (SLETHOLT ET. AL., 2011).............................................................................................124
TABLE 24 - AGILE ELEMENTS (PETRILLO AND PIMENTA, 2010) .................................................................................125
TABLE 25 - AGILE ELEMENTS (JALALI & WOHLIN, 2010) ............................................................................................125
TABLE 26 - AGILE ELEMENTS (JALALI, 2018) ..............................................................................................................125
TABLE 27 - AGILE ELEMENTS (WILLIAMS, 2012) ........................................................................................................126
TABLE 28 - AGILE ELEMENTS (FLORENCIO, SAMBINELLI AND BORGES, 2017) ..........................................................126
TABLE 29 - AGILE ELEMENTS (SOARES & BRODBECK, 2017) .....................................................................................126
TABLE 30 - AGILE PRINCIPLES FOUND IN LITERATURE...............................................................................................127
TABLE 31 - INTERVIEW DETAILS .................................................................................................................................130
TABLE 32 - INTERVIEW QUESTIONS AND GOALS .......................................................................................................130
17
Page
1. Introduction
A problem in today’s project management world is that projects keep on failing in all sectors. A worldwide
study performed by PMI with insights from over 5.000 project management practitioners, executives and
directors states that 30 to 40 percent of projects have not met their original goals in the period from 2007
to 2017 (PMI, 2017). A failure rate of 40% is seen in the process industry (McKenna, Wilczunski, &
Vanderschee, 2006; Bakker, 2008). The subsequent 2018 report of PMI shows that around 15% of all
projects are deemed failures, more than 30% failed to remain within budget and a bit more than half of
the projects completed on time (PMI, 2018). Studies do show an increase in the success rates of projects.
The Standish group studies over 50,000 projects around the world annually. Their 2018 report mentions
an improvement from 31,1% to 19% failure rates between 1992 and 2017 (The Standish Group, 2018).
Despite the improvement, these rates remain high. The organization shows that the failure rate has been
a bit less than 20% from 2011 onwards (The Standish Group, 2015). Although there’s no consensus on the
exact percentage of failing projects, what´s clear is that too many projects do not meet expectations.
The rates become even more troubling when a distinction is made in project sizes. The Standish Group
(2015) states that “smaller projects have a much higher likelihood of success than larger ones.” With a
bigger project comes a higher complexity. Although this is not true for all cases, it can be said that with a
bigger project come more interfaces, both internal and external, which might increase complexity. Note
that complexity is not only technical, but also external and organizational (Bosch-Rekveldt, 2011).
To make things worse, more projects are becoming complex and the complexity of projects keeps
increasing according to Harvett (2013) and Baccarini (1996). This increases the need for a change in the
project management approach which suits the project, ultimately leading to higher success rates.
The necessity of changes in the project management approach, to try and tackle the high rate of failing
projects, is evident. One of these promising modern approaches is Agile project management. Although
Agile is a term used ever since software started to develop, it has been accelerating since a relatively short
period of time as the philosophy started out in the 2000’s with the Agile manifesto (Martin, Fowler, &
Beck, 2001). It has been practiced increasingly in recent years in many sectors, most evident in production
and ICT. “71% of organizations report using Agile approaches for their projects sometimes or more
frequently.” Agile has been proven to be effective across all project sizes, resulting in more successful
projects and fewer project failures (The Standish Group, 2015). When comparing Agile and less-Agile
projects, an increase from 45% to 69% is seen in successfully completing strategic initiatives (PMI, 2014).
According to a research on Agile project delivery, Agile projects in software delivery are 28% more
successful than traditional projects (Price Waterhouse Coopers, 2017). This success is mainly apparent
due to organizations being able to withstand change in turbulent markets (Zhang & Sharifi, 2000),
increased engagement and trust within the team and improved visibility of progress and problems (Villki,
2009).
Although implementation of Agile improves project management on certain outcomes for certain
organizations, Agile project management also has some downsides. Negative outcomes are seen in
maintaining a sustainable development pace, ensuring that deliverables are of sufficient quality and
increased costs (Morris, 2015). It should be noted that Agile is not a holy grail and might not be a promising
approach for every type of project. A well-thought decision should always be made on choosing the type
of project approach.
18
The Agile project management manifesto (Martin, Fowler, & Beck, 2001) is mainly focused on
Page
collaboration between people and adaptation to change. Project management is mainly about people
(Bakker & de Kleijn, 2014) and complexity is increasing perpetually (Harvett 2013; Baccarini, 1996). These
characteristics of project management seem to align with the focus of the Agile project management
approach. Consequently, Agile seems to be a promising approach to help overcome complexity (Lynch,
2015) and thus leading to higher success rates.
However, Agile project management is not being used to the fullest. It is seen that Agile is sometimes
introduced based on the hype and not based on improving the project management approach. Xebia
(2013) mentions that after initiation of an Agile project management approach, the step towards fully
Agile hardly happens. Although it is argued whether full Agile is needed, the survey of Xebia (2014) states
that Agile is used mostly ‘in name only’. This means that organizations want to use Agile elements just so
that they can say that they are Agile, not because this would be a better approach. Therefore, it is worth
to find out how the Agile philosophy should be implemented so that it actually leads to successfully
completing a project.
Also, not all elements of Agile are said to be applicable for every organization, in every sector, for every
type of project (Heemstra, Ketel, & van Daalen, 2015). As Agile is founded in ICT projects, it is fully
developed for this sector. Although Agile might help battle complexity and thus making complex projects
more successful, research should be done for other sectors than ICT before Agile is implemented
(Kettunen, 2009). It is to be found out if, and which, elements of Agile project management help
successfully completing projects differently for different sectors.
The mentioned effectiveness of Agile project management in the ICT sector makes Agile a potential
approach to battle the increasing complexity and meeting of the project’s requirements in other sectors
as well. The promising character of the relatively new project management approach gives a motivation
to find out how an Agile implementation can have a positive effect on the success of projects.
1.1 Research goal and questions

The goal of this research will be to design a framework of essential elements of Agile project management
which helps to successfully complete complex projects in the high-tech sector. This leads to the following
research question:
MQ: HOW CAN AN AGILE WAY OF WORKING HELP TO SUCCESSFULLY COMPLETE HIGH -TECH PROJECTS?
To come to an answer to this question, the following sub questions need to be answered:
SQ1: HOW CAN PROJECT SUCCESS BE MEASURED IN AN AGILE ENVIRONMENT?
SQ2: WHICH AGILE ELEMENTS COVER THE AGILE FRAMEWORK?
SQ3: HOW CAN THE AGILE MATURITY LEVEL OF A PROJECT TEAM BE MEASURED?
SQ4: WHAT ARE THE BEST PRACTICES OF AGILE PROJECT MANAGEMENT?
SQ5: HOW DOES THE AGILE MATURITY LEVEL OF A PROJECT TEAM INFLUENCE THE IMPORTANCE OF THE AGILE BEST
PRACTICES?
SQ6: HOW CAN AN AGILE PROJECT MANAGEMENT APPROACH BE EMBEDDED IN AN ORGANIZATION?
19
Page
1.2 Research approach
The main question will be answered through theoretical and practical research. An overview of the
research approach is illustrated in Figure 3. A literature study will examine the first three sub questions.
First, success in an Agile environment will be defined. The Agile project management practices which are
currently being used are then explored through literature. Next, a method of measuring the Agile maturity
level of projects is investigated in literature. Also, how to combine Agile and traditional project
management within an organization and how to scale Agile will be explored in literature. This then covers
the theoretical research. After the theoretical framework is completed, a research on Agile project
management in practice will be executed. This will be done by means of case studies. The goal of this
practical research is to find the relations between the above-mentioned elements, so to answer sub
questions 4 until 6. For each case, the Agile maturity level will be established based on the measurement
model found in the theory. Next, the Agile practices used in that specific project are extracted from the
interview and the impact of that practice is established. The interview will also extract a certain level of
success of that project. This will be established by finding out what the result of using a certain Agile
practice is. The interview will also cover the use of Agile within a department or organization.
Theory Practice
SQ3 SQ1
Measuring Agile Agile maturity
maturity level level
Case study
Defining and set-up SQ5
measuring Project success
P3M project success SQ6
P3M
SQ4
SQ2 Use of Agile

Agile elements practices
Figure 3 - Research approach

So, the main question will be answered by finding answers to the six sub questions. In which the first three
will be answered based on literature, four, five and six based on practice. The cases will be compared to
each other by means of a cross-case analysis. This analysis will be discussed based on the topics of
maturity, context, Agile way of working and organizational Agile.
SQ1 SQ2 SQ3 SQ4 SQ5 SQ6

Literature study
Literature study
Literature study
Case study
Case study
Case study
MQ
20
Page
Figure 4 - Research methods

1.3 Research outline
This exploratory thesis has started with an introduction to explore the background of this research, it has
mentioned the problem, motivation, knowledge gap and the goal of the research. This has led to the
research questions of this thesis.
Next, a literature study will be performed to obtain the required theoretical knowledge for the research.
It will first discuss what Agile project management is to set the scene. Then, the chapter presents a
definition of success in an Agile environment after which Agile elements will be identified. At last, the
measuring method of the Agile maturity level of projects is discussed.
After the theoretical research, a case study design will be presented which covers the case selection and
interview protocol. The results of the research and interviews are then given. The findings of this research
and the interviews will be presented afterwards.
Theory Practice Wrap-up
Chapter 5 Chapter 7
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Discussion
Results case study
Introduction Literature study Findings Case study design
exploratory Chapter 6 Chapter 8
research Analysis Closure
SQ1|SQ2|SQ3 SQ4|SQ5|SQ6 MQ
Figure 5 - Research outline
21
Page
2. Literature study
This chapter starts with an overview of the Agile approach to elaborate on the context set in the
introduction. It discusses what it entails and gives the main points of departure and principles. Next,
literature will be explored to answer the first three sub questions. Chapter 2.2 defines project success in
an Agile environment. Chapter 2.3 explores the Agile elements in literature. Chapter 2.4 will find out how
the level of Agile maturity can be measured. Chapter 2.5 states a conclusion of the literature study.
Chapter 5 Chapter 7
Results case study
2.1 The Agile approach

Agile will be explained to further set the context. Firstly, the background will be mentioned to show how
and why it started and what the main points of departure are. As Agile is a broad term, a scope for ‘Agile’
will be given. Next, an Agile way of working will be compared to the traditional approach after which Agile
will be examined within software development. This subsection will end with making a start of exploring
the impact of Agile on program and portfolio level of an organization.
2.1.1 Background
The Agile philosophy was founded due to lacking success of the traditional project management approach
in the ICT sector. It was found to be too expensive, too often too late and of too low quality. In software
development, the traditional waterfall method could not make use of the benefit of software that it could
be changed very quickly. Because of this dissatisfaction, the Agile manifesto was created (Martin, Fowler,
& Beck, 2001). It makes use of an iterative approach with the focus on continuous delivery and fast value
creation for the customer.
The Agile manifesto was set up around four values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
This does not mean that the Agile mindset neglects process, tools, documentation, contract negotiation
and a plan but it values individuals, working software, customer collaboration and responding to change
more. These four values are elaborated in twelve principles (Appendix A).
2.1.2 Agile approach defined and scoped

‘Agile’ is considered as an umbrella term for many Agile methods. The term ‘Agile’ should be seen as a
philosophy rather than an actual project management approach. Examples of the Agile approach or
22
methods are Scrum, Lean software development, Extreme Programming (XP), Kanban, Iterative and
incremental development (IID), Adaptive software development (ASD) and Dynamic systems
Page
development method (DSDM). The research will focus on the Agile method which is used most often in
practice because this will benefit most projects. Focusing on one approach prevents the research from
basing findings on different approaches which might make the findings fuzzy. Nowadays, SCRUM and Lean
are the most-used Agile approach. However, Scrum is an actual (software) development project
management approach while Lean helps to optimize that process. Although Jalali & Wohlin (2010) and
(Barton, 2009) say that Lean is merely a different name used for Agile since no meaningful distinction is
made, several other articles do mention a difference between Agile and Lean, mostly appearing in the
objective of tactical and strategical thinking (Highsmith J. , 2002), (Dall'Agnol, Janes, Janes, Succi, &
Zaninotto, 2003), (Smits, 2007). Hence it is concluded that Agile and Lean are very different things. It is
said that Agile and Lean can be used together. This means that Lean practices are not a form of Agile.
Therefore, Lean elements will not be considered in the analysis of this research. Given the difference in
points of departure between scrum and other Agile approaches, a focus will lay on the Scrum method due
to a limitation of time for the research. This means that XP, Lean, Kanban, IID, ASD, DSDM will be out of
scope in this research although certain elements of Scrum will overlap with the other forms of Agile
methods.
2.1.3 Agile vs. traditional project management

Traditional project management can be seen as the structured approach in which a waterfall ‘over the
fence’ approach is being used, illustrated in Figure 6. The next phase starts only after the preceding phase
has been completed. This plan-driven approach has a basis of predictability. In this method, a project team
works in phases towards a pre-defined goal in which value is delivered mostly at the end of the project.
Monitor &
Scope Plan Launch Close project
control
Figure 6 - Phases traditional project management
The Agile execution, as illustrated in Figure 7, is split up in different sprints and in each sprint the cycle is
run over again. This creates short iterations which enables quick adaptation to change.
no
Monitor &
Scope Plan cycle Launch cycle Close cycle Next cycle Close project
control cycle
yes
Figure 7 - Phases Agile/Scrum
The execution of the Agile method, specifically scrum, starts with project planning. In contrast to
traditional project management, it can be done within a day and covers the product vision statement and
a product roadmap. Consequently, release planning is to be performed. In this meeting, only one next
release is planned. Within the Scrum method, the execution is split up in sprints. Sprints are timeframes
ranging from 2 to 5 weeks in which the full project cycle will be followed. The requirements of the product
are defined by user stories in which the needs of the clients are stated from their perspective. After each
sprint, value needs to be delivered to the client. The remaining work after the sprint is placed in the project
backlog. Thereafter, a new sprint is initiated in which the project cycle will be fully run through again. This
makes the approach a dynamic one since the approach is tailored to the needs of the client and the status
23
of the project after each sprint.

Page
Research on the implementation of Agile project management by KWD (Heemstra, Ketel, & van Daalen,
2015) mentions differences between the Agile approach and the traditional approach. The full table of
differences is found in Appendix B, Table 17.
The PhD research of Jalali Sohi (2018) explored the use of Agile project management in infrastructure
projects. it focused on the scrum method as this is seen as the most used Agile tool in practice. A literature
review conducted by Jalali Sohi resulted in a comparison between the traditional waterfall approach and
Agile and Scrum as seen in Appendix B, Table 18. Another comparison is made by comparing the
approaches on their philosophy, organization & management, development process, people & team and
technology (Verbruggen, 2017) as seen in Appendix B, Table 19.
Summarizing the difference between Agile project management and traditional project management
shows that Agile is characterized by adaptability to change while traditional project management is
characterized by creating certainty through a plan-driven approach working towards a pre-defined goal.
Agile or waterfall?
While there’s no checklist or framework to choose which approach suits best, there are some variables
which should be considered to go for a traditional or Agile approach. The motivation that Agile is a hype
and that everyone else does it should not be the reason to go for an Agile project approach. Although
some (Conforto & Amaral, 2008) believe Agile should be chosen when traditional project management
fails, Cicmil, Williams, Thomas, & Hodgson (2006) believe that it is of importance to classify projects and
align this classification to an appropriate management style. It is important that the chosen approach fits
with the organizational and involved stakeholders’ competence and experience. However, it is not
possible to give a watertight guidance for choosing a method. This means that it is not a black or white
decision.
Many papers suggest that projects might require a hybrid approach between the waterfall and scrum
(Cobb, 2011); (Hass, 2007); (Geraldi, 2008). It is important to understand both approaches to make a clear
decision. Certain guidelines should be considered to help find a configuration between the traditional and
Agile approach. These guidelines can be: the degree of certainty of the end-product, likelihood of change
and whether a phased or an incremental approach is suitable.
Projects in an Agile environment

The Agile philosophy can be used within a project and within permanent teams. The difference is that
projects have a clear end while permanent teams work continuously to create value. The latter can be
called a value stream. Even within permanent teams, projects can be initiated which will lead into a hybrid
form. The two situations cause a difference in looking at the timing and budget constraints. However, in
this research, Agile will be examined as a way of working and a philosophy rather than making a distinction
between project and continuous flows of value. This research therefore assumes results are the same for
projects and value streams.
2.1.4 Program and portfolio management in an Agile approach

Agile can be examined on different managerial levels: within projects, programs and portfolios. Examining
Agile on these three levels will require different perspectives. Agile on a project level focusses more on
the communication and collaboration elements within teams of Agile project management, while Agile
24
on a program and portfolio level looks more into the alignment within the organization and between
Page
teams. Alignment of IT, hardware and business are essential in high-tech companies. On portfolio level,
this is necessary to increase value delivery when projects are working Agile (Thomas & Baker, 2008). This
means that a focus should lie on the continuous flow of value in IT and hardware in an Agile environment
(Biknevicius, 2016).
To structure the alignment of Agile and traditional projects in a program or portfolio, a scaled Agile
method can be used. Inter-teams, this is referred to as ‘scrum of scrums’ (Paasivaara & Lassenius, 2010).
Several methods for Agile program and portfolio management exist. Some of these are: Disciplined Agile
Delivery (Ambler & Lines, 2019), Scaled agile framework (SAFe, 2019) Large-scale scrum (LeSS Framework,
2019), Nexus (Schwaber, 2019), Scrum at Scale (Sutherland, 2019), Spotify (Kniberg & Ivarsson, 2012) and
Enterprise Scrum (Beedle, 2019). Differences and similarities found between scaled Agile methods in a
review from Alqudah & Razali (2016) are presented in Table 20 of Appendix C.
SAFe is the most used method to scale Agile projects within large enterprises. It combines Agile and Lean
and can be used on program and portfolio level. On portfolio level, SAFe refers to value streams to provide
a continuous flow of value. The program level of SAFe refers to Agile Release Trains (ART), consisting of
multiple Agile teams, which is seen as a continuous delivery pipeline.
However, it is seen in practice that most organizations which have Agile teams do not manage programs
and portfolios fully Agile (Hombergen, 2019). This brings up the question why this is not managed fully
Agile. A study from Berger & Eklund (2015) in large scale mechatronics-driven companies mentions the
long-present increasing speed in IT while lead-times in manufacturing and hardware development came
down only recently due to Agile developments. Surveys across 46 respondents from mechatronic-driven
companies found several expected benefits from scaling Agile outside the IT department and several
expected challenges from scaling Agile. Most important challenges are inflexible test environments,
mindset within the company and the understanding of Agile along the value chain. The most important
expected benefits are faster time-to-market and shortening lead times
25
Page
2.2 Successfully completing a project in an Agile environment (SQ1)
The success criteria need to be established in order to assess the Agile elements, which are to be discussed
in chapter 2.3, against success. These criteria will be criteria which can measure to which degree a project
has been completed successfully. It is important to understand the difference between success criteria
and success factors. Success factors are elements of a project which should be used in order to obtain
success. Traditional examples of these are amongst others, clearly defined goals and competent project
team members (Pinto & Slevin, 1988). On the other hand, Success criteria are the values of a project which
should be met in order to obtain success. Traditional examples of these are time, cost and performance
(Avots, 1969). They can be translated into quantitative elements by setting Key Performance Indicators
(KPI’s).
A distinction between success of the final product and success of the process needs to be made. Studies
of de Wit (1988) and Munns & Bjeirmi (1996) name this the concept of project/product success and
project management success. Project management is a major influence on project success and therefore
the project management approach plays an important role in leading to project success (Radujkovic &
Sjekavica, 2017). In an Agile environment, process success plays an important role since value is created
frequently and not only at the end of a project.
The process of the project and its management should therefore also play a role in measuring success. In
an Agile environment, this could also entail improvements on the Agile way of working process. A project
which didn’t deliver well but caused an improvement/optimization of the Agile way of working within a
team or organization could still be considered a success on the process part (Söderlund, 2019).
The values and points of departure differ in an Agile environment compared to the traditional
environment as mentioned in Chapter 2.1.3. It is therefore to be examined if success is defined differently
in Agile projects compared to traditional projects as well. APM says that Agile leaders should focus on
being able to adapt successfully rather than following the pre-set plan. The iron triangle is therefore not
the only success criteria, value and satisfaction started to play a more central role in Agile. When trying
to get closer to value and appreciation the following 6 success criteria can be specified (Westerveld, 2003):
project results (time, costs and quality/scope), appreciation client, appreciation project personnel,
appreciation users, appreciation contracting partners, appreciation stakeholders. Although this study is
not situated in an Agile environment, it does grasp criteria which have become central in an Agile
environment.
Another important study on this, developed from the study of Westerveld (2003) is from Solis Vuurmans
(2015). This research examines the critical success factors within Agile project management, not the
success criteria. However, in order to study the factors, success criteria are set out in an Agile environment
in his literature study. The emphasis is on the happiness of the actors involved during the process. The
following three success criteria were found: happiness of the client, happiness of the company, happiness
of the people involved. This shows the importance of creating value for society over reaching a goal which
has been set up front (Bognes, 2009).
(Highsmith J. , 2009) illustrates the adaptation of the traditional triple constraints. He introduced the Agile
triangle as a replacement for the traditional iron triangle. Both triangles are represented in Figure 8. The
26
new triangle consists of value, quality and constraints.

Page
fixedness
Scope Value
Iron Agile
Scope
triangle triangle
Iron
triangle
Cost Schedule Quality
Cost Schedule
Figure 8 - Transformation of success triangle (Highsmith, 2009)

Value is seen as extrinsic quality for the customer and creating a releasable product. Value is the most
fixed element of the Agile triangle and has the highest priority. Value should be created incrementally and
continuously so that value is created from the start instead of only at the final delivery as shown in Figure
9. Value is then being created while working on the product. Quality is seen as intrinsic and requires the
product to be reliable and adaptable. Quality is required to deliver continuous value to the customer. The
project constraints are still important conditions which are to be met. In other words, value for the
customer and quality of the product must be assured within these conditions. They contain the same
constraints as the traditional iron triangle: scope, schedule and costs.
However, value is represented differently in an Agile

environment opposed to the traditional way of thinking
as illustrated in Figure 9. Time is not fixed anymore.
Euro's
Instead, a continuous flow of value is created with no

(certain) end-time. Success should therefore be
considered after a certain time period instead of the end
of a project. Costs are proportionate to time as most
costs come from wages of the worker, these costs should
after some point in time be lower than the created value. Time
Value_Agile Value_traditional
Scope is less fixed to comply with being able to adapt in Costs
order to assure value and quality.
Figure 9 - Value & cost comparison
Combining the success elements found in literature gives
that success can be separated into a process part and a project part. For the process part of success, the
following criteria have been found. Project team satisfaction brings along productivity and should not be
neglected. It is mainly seen in the motivation of the team members. Also, the improvements of the Agile
way of working within a team or organization is considered as a process success criterion.
For the project part of success, the following criteria arise. Satisfaction of the customer is the priority,
after which the satisfaction of the project team and its organization follows. Creating value continuously
is an important aspect of Agile and thus of project success which translates into customer satisfaction.
Quality is intrinsic and can be seen as creating an adaptable and reliable product. Project constraints have
27
become less important in Agile and are not to be fixed upfront but are still a requirement. Project
constraints can be translated into satisfaction of the organization.
Page
From exploring the literature on success can be concluded that project success criteria in an Agile
environment are not much different compared to a traditional environment. However, more weight is
given to quality of the product and value for the customer than to cost, scope and schedule. Therefore,
the success of projects in this research will be defined on the criteria as seen in Table 1.
Table 1 - Synthesis success criteria
Project team satisfaction

PROCESS
Motivation
Agile implementation !
Improvements on Agile way of working
Project constraints (Organizational satisfaction)
Cost
Scope
Schedule
PROJECT
Quality
Adaptable product
Reliable product
Value (Customer satisfaction)
Continuous flow of value to customer
Releasable product
The success criteria will be points of departure for measuring the success of the cases.
28
Page
2.3 Agile project management elements (SQ2)
Literature is explored to attempt to cover Agile practices. As mentioned in chapter 2.1.2 the focus will be
on Scrum practices. This exploration will be performed on Agile guides, literature in practice and literature
reviews to get an overview. The Agile guides will cover what is supposed to be practised, the literature in
practice covers the elements that in fact are being used and the literature review covers the studied Agile
elements. The case study of this research, set up in chapter 4, will test whether the elements found in the
literature actually contribute to completing projects successfully.
The literature study started with reviewing two Agile guides. These two guides mention practices to apply.
A guide to Agile practices is set up by the Agile alliance and institute Agile in 2013 (A guide to Agile
practices, 2019). This guide consists of a list of 60 Agile practices and can be seen in Table 21 in Appendix
D.
A Scrum guide has been set up to define roles, events, artifacts and the rules that bind them
together (Schwaber & Sutherland, 2013). The events and artifacts can be identified as Scrum practices
and are therefore considered in the coming synthesis. 8 practices have been found and can be seen in
Table 22 in Appendix D.
Next, to find what literature mentions about which Agile practices are actually used, papers which look at
the practice have been explored. Petrillo & Pimenta (2010) studied good practices of Agile methods
applied in the game development sector by conducting a Postmortem Analysis (PMA) based on 20
projects. This study gives an insight in the effectiveness of the practices as Petrillo & Pimenta (2010) define
them as good practices. 13 Agile good practices came out of the research, all practices adhering to Scrum,
XP and Agile modeling (AM). The good practices in Table 24 in Appendix D are in order of the frequency
in which it has been used in 20 game developments.
The PhD research of Jalali (2018) explored the use of Agile project management in infrastructure
projects. Jalali (2018) examined Scrum elements in three cases and compared theory with practice. Based
on literature, he found 16 Scrum practices categorized by scrum concepts and project phase as seen in
Table 26 in Appendix D. A research at an engineering and consultancy firm into three projects showed
that these practices are not used often or to the fullest.
Lastly, literature is examined to see what theory mentions about Agile. A literature study performed by
Sletholt, Hannay, Pfahl, Benestad, & Langtangen (2011) resulted in 35 Agile practices. These practices are
based on Scrum and Extreme Programming (XP), two reference models of Agile. “Scrum and XP are
complementary in the sense that Scrum focuses on practices for management and organization, while XP
focus more on technical development practices.”. The practices can be seen in Table 23 in Appendix D.
Based on the assumption mentioned in chapter 2.1.2, elements of XP are not considered. So only the
elements which are applicable to scrum are inserted in this table.
Jalali & Wohlin (2010) established 26 Agile practices in global software engineering, these are
ranked by the frequencies in the studied papers as seen in Table 25 in Appendix D.
Agile practices found through literature have been surveyed on their importance for teams under
326 respondents with extensive experience in Agile software development (Williams, 2012). Only the
practices scoring 3 out of 5 or higher on the importance were taken into account. This resulted in a list of
45 important practices of Agile software development. These practices can be seen in Table 27 in
29
Appendix D.
Another literature review concluded several Agile practices and their criteria based on the Agile
Page
principles and objectives (Florencio, Sambinelli, & Borges, 2017). This resulted in 23 Agile practices. These
practices and their relation with the principles of Agile are shown in Table 28 in Appendix D.
19 Agile practices were found in a study of 8 comparisons (Soares & Brodbeck, 2017). These
practices are categorized by the corresponding principles of the Agile manifesto (Martin, Fowler, & Beck,
2001). Table 29 in Appendix D shows an overview of these practices found.
A synthesis of the preceding literature is made. First, all Agile elements found in the above-mentioned
literature were put together for easy reference. These elements and literature were put in one table
stating the elements in the rows and the literature in the columns. The literature is categorized based on
guides, literature in practice and literature reviews. The guides show practices which are supposed to be
used according to Agile, elements in practice show the elements that are actually being used and the
literature reviews show elements which were found in the search to a complete overview of Agile.
A cell was checked with an ‘x’ if the element is mentioned in the corresponding literature. Elements which
had much overlap were combined. For example, ‘Kanban board’ and ‘Scrum board’ do differ a bit but
depend on the chosen method and therefore these practices are combined into ‘scrum or Kanban board’.
Elements which were mentioned by only one article and were not considered outstandingly different
compared to other practices were eliminated from the list. If an element could be considered as a sub-
element, it was argued which level of the practice fits the synthesis. For example, ‘virtual scrum wall’ is a
sub-practice of ‘scrum board’. A virtual scrum wall is a form of a scrum board and in this case, the first
practice is eliminated and ‘scrum board’ remained. Elements which are only of use for specific Agile
methods which are considered out of scope were eliminated.
Elements which are very closely related to the principles of Agile are usually mentioned in the literature
reviews and guides as they are based on the Agile manifesto, in practice these principles are not
mentioned. A distinction is made between elements which are related to actual Agile practices and
elements which are related to the Agile principles. This separates the practices which can actually be
performed and the principles which can be adhered to by using these practices.
It was found that the elements relating to principles covered all principles of the Agile manifesto except
for principle 6: Face-to-face communication. However, this principle is covered in practice 21 from Table
2. So in fact, the elements found in literature which are related to principles represent the Agile manifesto.
Therefore, these will not be further covered as Agile practices.
The elements now left are all Agile practices, seen in Table 2. The table shows the Agile practices found in
literature and is categorized by the values and principles of the Agile manifesto. The elements found in
literature which are related to Agile principles can be seen in Table 30 of Appendix D.
The synthesis has made it clear what Agile means in terms of practices and principles. The synthesis of
Agile practices (Table 2) will be compared to the Agile maturity measurement model found in chapter 2.4
to structure the interview part on the Agile practices. An additional benefit from this comparison is that
it enables to check whether the measurement model covers Agile based on scientific literature.
30
Page
Table 2 - Synthesis Agile practices
Literature in
Guides Conceptual Literature studies
practice
Petrillo and Pimenta, 2010

A guide to Agile practices,
Soares & Brodbeck, 2017

Schwaber & Sutherland,
Florencio, Sambinelli, &

Jalali & Wohlin, 2010
Sletholt et. al., 2011
Williams, 2012
Borges, 2017
Jalali, 2018
2019
2013
Value Principle Practice
Individuals Business and
and developers
1 Scrum of scrums x x
interaction work together
(4)
2 Motivated Defined process Scrum/way of working x
3 individuals (5)Daily (standup/scrum) meetings x x x x x x x
4 Face-to-face Co-located team x x x
5 communication Informal face-to-face communication x
6 (6) Own room x x x x
7 Self-organizing Division of roles x x x
teams (11) Whole multidisciplinary team with one
8 x x x
goal
9 Planning poker x x x x x
10 Reflection (12) Sprint review x x x x x x
Sprint retrospective to learn from previous
11 x x x x x x x
sprint
12 Working Working Exploratory testing x x
13 software software (7) Unit testing x x x x x x
14 Acceptance tests x x x x
15 Automated testing x x x
16 Collective ownership of code x x x x
Technical
17 Refactoring x x x x x x
excellence
enhances
18 agility (9) Pair programming x x x x x
19 Simplicity (10) Use simple tools x x x
Team documentation focuses on decisions
20 x x
rather than planning
21 Informal design: no big design up front x
22 Customer Satisfy Formulation of informal user stories x x x x x x
24 collaboration customer (1) Continuous communication with customer x x x x x
Responding Welcome
to change changing
25 Sprint planning and selection of work x x x x x
requirements
(2)
26 Frequent Having a prioritized backlog x x x x x x
27 delivery (3) Refinement/grooming of backlog x x
Time-boxed sprints (producing potentially
28 x x x
shippable output)
29 Sustainable Release planning x x x
30 development Measuring velocity x x x x
31 (8) Use estimates x x x
32 Burndown chart x x x x x x
31
33 Definition of Done x x x
34 Kanban or Scrum board x x x x x
Page
2.4 Measurement of Agile maturity
It is vital to examine whether the degree of Agility of teams and organizations is influencing the best
practices of Agile, and their application. Therefore, an assessment of the agility of project teams and
organizations is needed. “Different surveys may judge Agility differently, which supports the viewpoint
that Agile is not well defined. Therefore, practitioners must decide what Agile means to them and select
the assessment survey that matches their definition” (Jalali, Wohlin, & Angelis, 2014). When one
assessment is used for all cases, a comparison can be made between these cases.
The Agile and traditional project management framework found in the master thesis on the project
manager’s role in APM (Verbruggen, 2017) gives a framework of the agility of projects or organizations.
It consists of five main subjects extracted from literature: philosophy, organization and management,
development process, people and team and technology. These subjects are categorized on a scale of four
levels ranging from traditional to fully Agile. The philosophy subject is categorized on a two-level scale.
After critically reviewing Verbruggen’s model, it can be concluded that the agility is hard to assess.
Additional steps need to be made before the model can be used. For now, it is merely a framework and
not an assessment. The framework should either be operationalized into a questionnaire to get results or
the five subjects should be scored during the interview. The latter would intensify the interview workload
and thus less effort can be made in extracting other findings.
Reviews on different agility measurement models have been written (Shaarabh, Rishi, & Sharma, 2014)
and (Sanchez & Rakesh, 2001). These models did not seem promising for this research. The models require
data which cannot be extracted in this research due to time and data limits or they do not focus on project
management agility.
Another review on different agility assessments compared assessments by means of a case study (Jalali,
Wohlin, & Angelis, 2014). Qualitative interviews of these cases showed that practitioners agreed that
Comparativeagility (About comparative agility, 2019) captured their own perception of the agility better
compared to other assessment tools. The biggest advantage according to the respondents were the
amount of questions which resulted in a more fine-grained conclusion and less dependence on single
questions. Statistical tests performed in the review also concluded that Comparativeagility portrays agility
in teams and organizations better than in the other surveys reviewed (Jalali, Wohlin, & Angelis, 2014).
Comparativeagility is developed by the co-founder of the scrum alliance (Denning, 2012). The agility of an
organization or team is measured by means of survey questions consisting of eight dimensions: teamwork,
requirements, planning, technical practices, quality, culture, knowledge creating and outcomes. It can
compare the outcome to a database of around 2000 organizations with 2.000.000 data points (Hesselberg,
2019). Next to that, the agility can be compared cross-case based on the answers to the same questions.
When comparing Verbruggen’s framework and the comparativeagility survey, it can be concluded that
the latter is easier to use for this research and will give less subjective results. The team members of
certain projects can assess their agility instead of the interviewer. This increases the amount of experience
and knowledge on that project which is used to assess the agility. Therefore, the Comparativeagility
32
survey will be used to assess the Agile maturity level of cases. The survey will be filled in by the
respondents before the interviews. The statements being assessed can be read in Appendix G. An effort
Page
can be made to try to let other project team members fill in the survey as well. The results will primarily
be used to structure the interview questions. The results of the survey also enable the comparison of the
cases on their agility to the other cases and to the database of comparativeagility. Lastly, the results of
the survey will be used for establishing a better view on where the projects stand on their Agile maturity.
A test of this survey has been performed to check whether the results are comparable to what the project
leader’s expectations are. It is concluded that the results of the survey are comparable to the expectations
and therefore the survey can be used for measuring the Agile maturity. The results of this test survey can
be read in Appendix E.
2.4.1 Literature vs. Comparativeagility

The Comparativeagility survey is compared to the Agile practices from chapter 2.3 and the success criteria
from chapter 2.2, in Figure 10. In this way, the survey is compared to literature.
Practices from literature Sub Dimensions Comparativeagility
Scrum of scrums Team composition
Defined process Scrum/way of working Team management
Daily (standup/scrum) meetings Focus
Co-located team Communication
Informal face-to-face communication Team member location
Communication focus
Own room
Level of detail
Division of roles
Emergence
Planning poker
Technical design
Sprint review
Planning levels
Sprint retrospective to learn from
Critical variables
previous sprint
Progress tracking
Exploratory testing
Sources of dates and estimates
Unit testing
When do we plan
Acceptance tests
Test-driven development
Automated testing
Pair programming
Collective ownership of code
Refactoring
Refactoring
Continuous integration
Pair programming Coding standards
Use simple tools Collective code ownership
Team documentation focuses on Automated testing
decisions rather than planning Customer acceptance testing
Formulation of informal user stories Timing SUCCESS CRITERIA FROM LITERATURE
Continuous communication with Management style Project team satisfaction
customer Responses to stress Motivation
Sprint planning and selection of work Customer involvement Agile implementation !
Informal design: no big design up front Title and salary alignment Improvements on Agile way of working
Having a prioritized backlog Infrastructure Project constraints (Organizational satisfaction)
Refinement/grooming of backlog People Cost
Time-boxed sprints (producing Reflection Scope
potentially shippable output) Timeboxes Schedule
Release planning Team learning Quality
Measuring velocity Improved quality delivered by team Adaptable product
Use estimates Improved customer satisfactions Reliable product
Burndown chart Improved team morale Value (Customer satisfaction)
Definition of Done Improved business economic value Continuous flow of value to customer
Kanban or Scrum board Delivering more quickly and more often Releasable product
Figure 10 - Literature vs. Comparativeagility
An overlap between literature and the survey is evident for most of the practices. This overlap is shown
in blue. It is seen that the last six sub dimensions of Comparativeagility, shown in orange, share the success
criteria presented in chapter 2.2. This means three things. Firstly, the survey results can be used to see
33
which practices are to be asked in more detail in the interviews. Secondly, the improvement of success of
the project is mapped in the survey.
Page
Thirdly, it can be said that the survey of Comparativeagility is for the most part supported by different
scientific articles on that subject. However, there are also practices found in literature which are not
covered in the survey. This requires a critical look at the practices not presented in the survey. These
practices are illustrated in Table 3.
Table 3 - Agile practices from literature, not covered in survey
PRACTICES PRINCIPLE VALUE

Scrum of scrums Business and developers work together (4) Individuals and interaction
Defined process/way of working scrum Motivated individuals (5)
Co-located teams Face-to-face communication (6)
Own room
Planning poker Self-organizing teams (11)
Exploratory testing Working software (7) Working software
Use simple tools Simplicity (10)
Team documentation focuses on decisions rather
than planning
Continuous communication with customer Satisfy customer (1) Customer collaboration
Refinement/grooming of backlog Frequent delivery (3) Responding to change
Use estimates Sustainable development (8)
Most practices of table 3 are a sub level of already mentioned practices. For this reason they are listed as
not covered in the survey as they are too detailed. E.g. ‘co-located teams’ and ‘own room’ are a sub level
of ‘informal face-to-face communication’, ‘use simple tools’ is covered in the practice ‘informal design; no
big design up front’, ‘use estimates’ is part of ‘measuring velocity’ and ‘refinement/grooming of backlog’
is a sub level of ‘prioritization of backlog’. These practices are too detailed to give a general conclusion
and therefore only the higher level practices are taken into account.
Additionally, three practices from Table 3 are thought to be essential for covering a full definition of Agile.
The first practice being ‘Scrum of scrum’ which is an essential practice as it is a part of answering sub
question 6. However, it is not considered as part of the definition of Agile because using multiple Agile
teams is not necessary. However, it is essential for this research and thus it is taken to the interviews.
The second practice being ‘Continuous communication with customer’ as it is closely related to the first
principle of the Agile manifesto. However, it is slightly wrong formulated. It is changed into ‘frequent
communication with customer’ and this practice is taken into the interview.
The third practice is ‘Defined process/way of working scrum’. This practice is mentioned within the
exploratory interviews as can be read in chapter 3.2. It is therefore chosen to add this practice to the list
of practices to be discussed in the interview.
This results in Table 4 which shows the Agile practices which shows a full description of Agile in terms of
practices.
Several practices do cover the survey and literature, illustrated in Table 4. The corresponding question
from the Comparativeagility survey is shown for each practice. It is known, before the interview takes
place, to which degree these practices have been used in the case. This gives the opportunity to ask the
impact of (not) using these practices in more detail in the interview. After analyzing the results, it can be
said what influence the degree of use of certain practices has on the success of the project.
34
Page
Table 4 - Practices which cover the term ‘Agile’
PRACTICES QUESTION SURVEY PRINCIPLE VALUE

Daily (standup/scrum) meetings 13 Motivated individuals (5) Individuals and interaction
Defined process/way of working scrum
Informal face-to-face communication 10, 11, 12 Face-to-face communication (6)
Division of roles 6, 8 Self-organizing teams (11)
Whole multidisciplinary team with one goal 1, 2, 7, 14
Sprint review 56 Reflection (12)
Sprint retrospective to learn from previous 57 & 58
sprint
Scrum of scrums Business and developers work
together (4)
Unit testing 35 Working software (7) Working software
Acceptance tests 44, 45
Automated testing 41, 46
Collective ownership of code 42, 43
Refactoring 38 Technical excellence enhances
Pair programming 36, 37 agility (9)
Formulation of informal user stories 16, 17, 18 Satisfy customer (1) Customer collaboration
Frequent communication with customer
Informal design; no big design up front 20, 34 Simplicity (10) Responding to change
Sprint planning and selection of work 24 Welcome changing
requirements (2)
Having a prioritized backlog 25 Frequent delivery (3)
Time-boxed sprints 28
Release planning 23, 27 Sustainable development (8)
Measuring velocity 29
Burndown chart 30
Definition of done 32, 33, 50
Kanban or Scrum board 31
2.5 Conclusion literature study

It is concluded that a distinction is made between process and project success. Process success entails
project team satisfaction and improvements on the Agile implementation within the team or organization.
Project success entails the three project constraints (cost, scope and schedule), quality and value. The
success criteria found are also covered in the last sub dimension of the Comparativeagility survey.
A comparison between the Agile practices found in literature and Agile practices from the
comparativeagility survey has been made in Figure 10. The practices which are both in the survey and
literature are dealt with in the case study. Additionally, the practices ‘frequent communication with
customer’ and ‘defined process/way of working scrum’ are added to further cover what Agile entails. This
results in a list of practices found in literature which are also covered in the survey or are found to be
essential to test Agile on project success as seen in Table 4. It is seen that this list covers all four values
and twelve principles of the Agile manifesto (Martin, Fowler, & Beck, 2001).
35
Page
3. Preliminary results
Chapter 5 Chapter 7
Results case study
The preliminary results are extracted from exploratory interviews. These interviews were held before
constructing the case study. The exploratory research gave answers to the first three research questions
on what is success in an Agile environment, what practices Agile entail and how the Agile maturity level
can be measured.
First, the findings from the exploratory interviews held at two high-tech companies will be presented.
Afterwards, these results will be discussed. The exploratory interviews had an impact on the Agile
practices list since some practices were not covered by literature. Next, the Comparativeagility survey is
tested and the preliminary result of this survey is presented. The preliminary findings are used to form
the case study set-up and structure the interview questions as is mentioned in chapter 4.
3.1 Findings exploratory interviews

13 exploratory interviews were held to gain a better understanding of what it means to have an Agile way
of working and to see what benefits and disadvantages come along. The interviews helped in verifying the
results of the literature study. The findings of the exploratory interviews helped defining and structuring
the case study. Table 5 shows an overview of the interviewees of the exploratory research.
Table 5 - Information respondents exploratory interview
ORGANIZATION FUNCTION DATE INTERVIEW

High Tech Company Agile expert 12-03-2019
Lean expert 26-03-2019
Agile expert 11-03-2019
Business analyst 12-03-2019
Requirements engineer 04-03-2019
Group lead 13-03-2019
Agile specialist 12-03-2019
Director operations portfolio management 01-04-2019
Project leader 18-03-2019
Program manager 26-03-2019
Benefits manager 20-03-2019
Change manager 02-04-2019
Serving products, Engineering manager 05-04-2019
services and solutions
from military defense to
civil security
36
Page
Findings from benefits managers at a high-tech company:
Planning:
Developers favor planning on short-term only. Long term planning is of necessity for higher level
management so that they can align different projects or teams.
Also, it is hard to make a long-term planning for low mature Agile teams because there is no reference
point. The velocity estimation is hard to make. An estimation is easier to make for more mature Agile
teams
Certainty:
There is a need for certainty on higher level management because the traditional mindset is still present.
The mindset of higher-level management is still as it was traditionally. They want to know what teams will
deliver and when they will do this. Therefore, this should still be estimated within agile. However, the
Agile mindset requires to let go of creating certainty and make room for adaptations. The focus should
shift from wanting to know upfront what team/projects will deliver to maximizing the velocity of the
teams so that most value is created.
Trust:
Trust often lacks from higher management that value will be created because they have to let go of
creating certainty. This is mainly present in low mature Agile organizations because teams have not yet
been able to prove that they deliver value. Within more mature Agile organizations, teams have shown
that they create value and thus the trust has grown.
At PostNL, this problem was solved by hiring an external scrum team which had proven in other projects
that they deliver value. This was accepted by higher management. This improved the overall belief in Agile
from higher management.
Findings from requirements engineers at a high-tech company:

There are four motivations from the department (OSE) to have chosen an Agile approach:
1. Surveys have shown that Agile improves results compared to the waterfall method
2. Traditional project management is outdated. It shows that it does not work for the full 100
percent and it does not always have a positive connotation
3. There is a hype around Agile which has created awareness
4. Other departments of the organization are using Agile so there needs to be a shared
understanding
It was believed that Agile would be the holy grail and that it would solve all problems that were present.
This already has been busted. Even more, the transition itself created more complications. So until the
department operates fully Agile, complications remain. In the first place due to the puzzle of aligning
traditional and Agile projects and teams. Secondly, project managers are still present in the organization
and they require the same way of working. So they still ask for deliverables which suit traditional project
management but not Agile such as a business case, reporting etc. Thirdly, for traditional project
management, a project management method has been written and a full competence center is set up for
training traditional project management skills. For Agile this is not yet the case, the Agile way of working
37
is therefore different for each team and project. Fourthly, roles and practices are being confused because
Page
every project and team has a different definition for it.

Quote from a program manager at a high-tech company:
“There are no shortcuts in the transition towards Agile. You should embrace the
errors and learn from it.”
Findings from LEAN experts at a high-tech company:

There is a shared interest in the transition away from traditional project management. However,
employees think too much in silos. The principles in broad lines behind Lean, DevOps and Agile are about
the same but because different terms are used, people are hesitant on choosing a certain approach. The
cause behind this is the implementation of these new approaches initiated bottom up. This caused certain
teams to go in-depth on one approach while neglecting the other. Alignment between teams has
decreased because of this.
Findings from change managers at a high-tech company:

Coaching
Coaching is missed. Employees are backing Agile but the exact way to use it is unsure. Training by external
Agile experts and setting up a framework/PMM can help with this.
Support from higher management

The support from higher management is not sufficient. There’s no clue on where this company stands in
their Agile maturity and more importantly, there is no vision and goal on where to go to.
“it’s okay to learn by doing but it’s a shame how long this transition takes and the
amount of errors that are being made.”
Findings from an Agile expert at a high-tech company

Differences in the maturity level between projects and departments will bring along complications and
should thus be coordinated in a structured way.
Findings from a manager Engineering at a high-tech company

Shared belief in Agile
When first starting with Agile, many team members were stuck in the traditional project management
mindset. They didn’t like the change towards an Agile method. This was mainly due to the increase in
transparency of work. Others could see the errors and weaker sides of other team members. After several
years you could see that this actually improved success because errors were spotted and improved.
Therefore, a shared belief in the Agile mindset is necessary to become successful but this can take some
time.
Defining one Agile approach across the full organization

38
A shared definition of the tools and philosophy behind Agile is beneficial. However, the teams should get
to make the decision on the configurations such as the duration of a sprint, duration and time of daily
Page
stand ups, which tools they use. This should be fit to their own needs and capabilities.
Coaching
An Agile coach is a must have for introducing Agile to teams. This coach should be external so that team
members actually listen. He should not be presented as a guru which transforms a mindset within a
company because this can scare off team members and they might become skeptical.
39
Page
3.2 New insights in Agile practices
From the exploratory interviews it was found that several Agile elements were missing. A shared belief in
Agile was stated as an important element. When this belief is not shared, a transition towards an Agile
organization will be hard to realize. This element is therefore added to the Agile elements list of this
research.
A second element is added to the list after being mentioned in the exploratory interviews frequently.
Coaching and training seems to be a significant influence in the transition towards an Agile approach. This
is in line with the element of having a defined approach. After this definition stands, training and coaching
can help to educate the employees to use the method.
Another element which is mentioned in the exploratory interviews but is not fully covered in literature is
having an Agile method defined for the whole company. This method is often written for traditional
project management. However, this is not often written for Agile as it is left to the 12 principles. This
causes different teams to implement Agile differently. This might be a good way as every team might
require a different Agile approach. However, some definition is appreciated by respondents so that every
team and department can speak the same Agile language. Therefore the practice ‘defined process/way of
working scrum’ is changed into ‘One defined process/way of working scrum across organization’.
Due to limitations of time in the research, not all practices found can be discussed during the interview.
Therefore, a selection will be made to ensure enough time can be used to discuss a practice in the
interview. A ranking of the practices which cover wat Agile entails, is made based on the view of two Agile
experts. The practices are ranked based on their view on the degree of influence on completing a project
successfully ranging from not influential (1) to highly influential (5). Table 6 shows the complete list of
practices found in literature and exploratory interviews with their accompanying average score given by
Agile experts, the corresponding questions of the Comparativeagility survey, the corresponding principle
of the Agile manifesto and the corresponding value of the Agile manifesto.
Table 6 – Complete list of Agile practices found in exploratory research
PRACTICE EXPERT SCORE QUESTION SURVEY PRINCIPLE VALUE

Daily (standup/scrum) meetings 4,5 13 Motivated individuals (5) Individuals
One defined process/way of working 4,5 and
scrum across organization interaction
Shared belief in Agile 5
Coaching 4,5
Informal face-to-face communication 5 10, 11, 12 Face-to-face
communication (6)
Division of roles 4 6, 8 Self-organizing teams (11)
Whole multidisciplinary team with one 4 1, 2, 7, 14
goal
Sprint review 4,5 56 Reflection (12)
Sprint retrospective to learn from 4 57 & 58
previous sprint
Scrum of scrums 3,5 Business and developers
work together (4)
Unit testing 2,5 35 Working software (7) Working
Acceptance tests 4 44, 45 software
Automated testing 2,5 41, 46
40
Collective ownership of code 3,5 42, 43

Refactoring 3 38 Technical excellence
Pair programming 3 36, 37 enhances agility (9)
Page
Formulation of informal user stories 3 16, 17, 18 Satisfy customer (1)

Frequent communication with 5 Customer
customer collaboration
Informal design; no big design up front 4 20, 34 Simplicity (10) Responding
Sprint planning and selection of work 4,5 24 Welcome changing to change
requirements (2)
Having a prioritized backlog 5 25 Frequent delivery (3)
Time-boxed sprints 4,5 28
Release planning 4 23, 27 Sustainable development
Measuring velocity 4 29 (8)
Burndown chart 4 30
Definition of done 4 32, 33, 50
Kanban or Scrum board 4,5 31
3.3 Towards the case study

The eleven practices from Table 6 scoring 4,5 or higher out of 5 are taken into the final selection of
practices. The practices scoring 4 out of 5 are being discussed whether they are taken into the final
selection or not. The ‘division of roles’ is added since self-organizing teams are considered to be an
essential part of Agile and thus seems to be important enough to discuss in the interviews. ‘Acceptance
tests’ are also selected because Agile is found in software development and thus tests are always
important. Acceptance tests combines testing with the importance of the customer. An ‘informal design;
no big design upfront’ reflects the simplicity principle and is a significant difference compared to a
traditional approach and thus it is worth discussing in the interviews.
‘Sprint retrospectives’ shares the underlying perspective of ‘sprint reviews’ which is learning from
reflecting on the process. These practices are therefore not selected. ‘Kanban or scrum board’ is
considered as a sub-practice of the ‘daily (standup/scrum) meetings’ and is therefore discussed together
with the latter. ‘Division of roles’ is a task in order to fulfill a ‘whole multidisciplinary team’ and is therefore
combined. ‘Release planning’ is about planning. This is also covered in ‘sprint planning’ and is thus not
selected. ‘measuring velocity’, ‘burndown chart’ and ‘definition of done’ can be categorized into progress
tracking principles. The tracking of progress is illustrated in a ‘Kanban or scrum board’. These three
practices will therefore not be selected. The rest of the practices are considered of less importance by the
experts and are therefore not selected. At last, ‘scrum of scrum’ is a noticeable practice. It is not necessary
for an Agile project to be completed successfully, which is reflected in the score given by the Agile experts.
However, it is essential for aligning multiple projects and will therefore be covered in part 3 of the
interview on aligning projects in programs and portfolios. It will however, not be selected for the interview
part on Agile practices.
The final selection of Agile practices being asked in the interviews is illustrated in Table 7.
Table 7 - Final selection of practices
PRACTICE SCORE QUESTION SURVEY PRINCIPLE VALUE

1 Shared belief in Agile within the team 5 Motivated individuals (5) Individuals and interaction
2 Informal face-to-face communication 5 10, 11, 12 Face-to-face Individuals and interaction
communication (6)
3 Frequent communication with 5 Satisfy customer (1) Customer collaboration
customer
4 Having a prioritized backlog 5 25 Frequent delivery (3) Responding to change
5 Daily (standup/scrum) meetings and 4.5 13, 31 Motivated individuals (5) Individuals and interaction
Kanban/Scrum board & Self-organizing teams
41
(11)
6 One defined process/way of working 4.5 Continuous attention to Responding to change
scrum across organization technical excellence and
Page
good design(9)
7 Coaching of Agile 4.5 Motivated individuals (5) Individuals and interaction
8 Sprint review 4.5 57 Reflection (12) Individuals and interaction
9 Sprint planning and selection of work 4.5 24 Welcome changing Responding to change
requirements (2)
10 Time-boxed sprints 4.5 28 Frequent delivery (3) Responding to change
11 Whole multidisciplinary team with 4 1, 2, ,6, 7, 8, 14 Self-organizing teams (11) Individuals and interaction
one goal and division of roles
12 Acceptance tests 4 45, 46 Working software (7) Working software
13 Informal design; no big design upfront 4 20, 35 Simplicity (10) Responding to change
The final list of practices, which are to be discussed in the interview, cover all four values of the Agile
manifesto. Regarding the principles, all are covered except for principle 4: ‘Business people and developers
must work together daily throughout the project’. However, principle 4 is covered partly in the practice of
multi-disciplinary teams and fully in the practice ‘scrum of scrums’ which will be discussed in part 3 of the
interview on the alignment of projects on program and portfolio level.
The exploratory research is used as a stepping stone towards the case study. It formed a base to the
understanding of what Agile entails, how success can be measured in an Agile environment and how Agile
maturity can be measured. The finding of these three components following from the literature study will
be used to form the case study. The case study method is discussed in chapter 4.
42
Page
4. Case study
Chapter 5 Chapter 7
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Results case study Discussion
A case study is performed to find the answers to sub research questions 4-6, to find what the best
practices of Agile are, what the influence of Agile maturity is on these best practices and to see how Agile
can be embedded in an organization. A case study is selected as research method for these research
questions because it offers the right level of detail for the exploratory nature of this research. The
empirical data gathering is done according to Yin’s (2018) book about preparing and doing case study
research. The case study research approach is illustrated in Figure 11. The phases are performed and
explained in the accompanying chapters. The case study is based on the findings of chapter 3.
CH 4.3
CH 5
Prepare
CH 4.1 CH 4.2
Collect
Plan Design
Share Analyze
CH 7 CH 6
Figure 11 - Case study approach (Yin, 2018)
4.1 Motivation of case studies as a research method

(Yin, 2018) mentions several requirements of a study which should be met to choose a case study as a
research method. These requirements are all met. The most important requirements are:
• A ‘how’ or ‘why’ in the research question
• A contemporary set of events;
• Over which a researcher has little or no control
In planning the case study, the result must be held in the back of the mind. In short: “Case studies are
generalizable to theoretical propositions and not to populations or universes” (Yin, 2018). This means that
the conclusion of the research cannot say that every organization in the high-tech sector should perform
the best practices of Agile project management found in this research. The conclusion will merely explore
43
the best practices in the cases covered which might help gaining scientific knowledge on the matter and
Page
gaining insight in the best practices of Agile project management in the high-tech sector.
4.2 Case study design
The case study will help answering sub questions 4, 5 and 6. The design of the case study gave attention
to the following dimensions: single vs. multiple cases, qualitative vs. quantitative data, holistic or
embedded cases, single-method vs. mixed-method designs. The case study of choice is an embedded,
qualitative, multiple case study which will be analyzed using a single-method due to the exploratory
nature of this research.
For selecting the cases, the following selection criteria have been set:
1. Both high-tech cases as non-high tech.
2. The project has practised an often-used Agile project management approach (i.e. scrum).
3. The project has been completed in the recent past or is under completion.
4. A minimum of two respondents are available for interviews per organization.
The case within the high-tech industry company will be the main case. The reason for this is that the
graduation internship is situated there and therefore data gathering is easiest at that company. The case
is operating in the high-tech sector and exploratory research found that the organization is in an early
phase of Agile maturity. Interviews will be held within the IT and Development & Engineering departments
within the high-tech company. Other cases at different organizations can help say something about how
Agile project management elements can help complex projects in the high-tech sector towards success.
In other words, research on other projects will be done in order to help low Agile mature projects such as
the ones in the internship company towards success by using Agile project management best practices.
The replication design should entail a minimum of two other projects which share the characteristics of
the first company: having a low-level Agile maturity and operating within the high-tech sector. These first
three mentioned cases establish literal replication. Three other projects should have a high Agile maturity
so that the difference can be explored. Project team members of such projects can have the experience
to understand how Agile should be implemented and thus show which Agile elements work best. These
projects can be within organizations from a different sector than high-tech. So a minimum of 6 cases is
needed. Note that this means that a minimum of twelve respondents is needed since a minimum of two
project team members with different job titles per project (case) are aimed to be interviewed. The first
case will have 5 respondents so that there is a balance in 5 projects from the first organization and 5
projects from outside of the internship company.
This leads up to the replication design as illustrated in Table 8.
Table 8 - Replication design
High-tech Non-high tech

Case 2 (Respondent 6-7) Case 4 (Respondent 10-11)
High level Agile maturity
Case 5 (Respondent 12-13)

Low level Agile maturity Case 3 (Respondent 8-9)
The case study design has been tested against the four criteria of testing quality mentioned by Yin (2018).
These criteria are construct validity, internal validity, external validity and reliability. Different strategies
have been used to safeguard these criteria. These strategies are e.g. having two respondents per case,
44
defining important terms in the introduction mail and start of the interview, having the respondents verify
the findings and by reporting the set-up of the case study and the interview report.
Page
4.3 Preparing the interviews
The respondents are asked to fill in a context survey by means of a Google Form, presented in Appendix
F. This first survey is used to verify that the project meets the selection criteria as mentioned in chapter
4.2. Also, this first survey helps to create a case description. If the case meets the selection criteria, a date
is set for the actual interview. A mail introducing the interview is sent to further familiarize the respondent
with the topic and it is mentioned that they are asked to fill in the Comparativeagility survey before the
actual interview. An overview of data sources used and its goals are mentioned in Table 9.
After having received the results of the Comparativeagility survey, a selection of interview questions will
be made from the full interview. Those Agile practices which the interviewee expected to have influenced
the success of the projects will be covered during the interview. A focus will therefore lie on the practices
which have an extreme score in the Comparativeagility survey. The full interview protocol including the
introduction mail, interview format and the interview report setup can be read in Appendix E.
Table 9 - Overview data sources
TYPE OF DATA SOURCE GOAL

Contextual survey • Check if case meets selection requirements
• Gain insight in the respondents and type of projects
Comparativeagility survey • Gather Agile maturity scores

• See on what subjects to focus in the interview
Interview • Gain insight in the effect of Agile practices used
A pilot interview was held to gain experience with the interview format, information of whom is displayed
in Table 10. This pilot interview is performed at the internship company due to the convenience and easy
access. One team member from one project will be interviewed to see whether this interview covers the
project well enough. The pilot interviewee will be interviewed on a project he worked on before he
started at the first organization so that the pilot interview will not interfere with the analysis of other
interviews held at internship company. The interview format was then adapted based on the pilot report
to create an optimized protocol.
Table 10 - Pilot respondent information
Respondent Organization Project Function Experience Agile Date interview

code
0.1 Dutch retail bank offering financial Development of Agile coach 5+ years 05-06-2019
products to both companies and reporting tool
individuals
The answers from the pilot showed that the interview could give insight in the Agile practices and could
add findings to the research. All questions could be answered within the time stated without having to
rush or skip questions. The interview was well structured as it followed a natural sequence. The results of
the pilot interview have been processed as a trial. However, the findings will not be used in the results
because it was used as a reference to see whether the interview process would work well.
45
Page
4.4 Analyzing the surveys and interviews
All analyses will be performed in a qualitative way. This is chosen because of the size of the case and
respondents database. Analyses are performed within cases and cross-cases and are following the
approach of Huberman & Miles (1983) and the Gioia methodology (Gioia, Corley, & Hamilton, 2012). The
latter showed: “how inductive researcher can apply systematic, conceptual and analytical discipline that
leads to credible interpretations of data and also helps to convince readers that the conclusions are
plausible and defensible”.
The first analyses will be performed within the cases. The results of the interviews within the case will be
described by mentioning noticeable answers per case per respondent (chapter 5). It will mention a case
description and examine the answers of the different parts of the interview: context, Agile practices, Agile
success and Agile on program and portfolio level. 1st order categories of themes and concepts will emerge
from this (Gioia, Corley, & Hamilton, 2012). This first analysis will also see whether the answers of different
respondents within the case are consistent. The results of these analyses are mentioned in chapter 5.
After having presented the results of each case, a cross-case analysis will be performed to find 2nd order
categories, which looks into a deeper structure (Gioia, Corley, & Hamilton, 2012). First, the results of the
Comparativeagility survey are analyzed. Spiderweb graphs are created to see the scores on the
dimensions of the Comparativeagility survey per project. From this graph, it can be easily seen which
projects have alike maturities and which differ. It will also help to identify on which Agile dimension the
project is mature or not. The results will be compared across cases to see their relative Agile maturity. It
will be examined how the cases score on different Agile maturity dimensions such as culture, technical
practices, requirements etc. Noticeable differences and similarities will be discussed. These analyses will
be described per category of interview questions (context, Agile way of working, Agile on organizational
level).
Next, the contexts of the cases are compared. It will define whether the cases have the same motivation
to choose an Agile method and see whether the Agile process has the same success or not.
Then, the effects of Agile practices are discussed. It was seen whether cases share the same experiences
with these practices. It was mentioned when problems occur across several cases and discuss how they
reacted to that problem. Patterns and themes will be noted (Huberman & Miles, 1983).
The Agile practices and values mentioned as most important will be counted and ranked (Huberman &
Miles, 1983).
After that, a comparison will be made on how the cases use and experience Agile in programs and
portfolios.
A variable-by-variable matrix will be created to see whether certain conditions show the same
consequences across cases (Huberman & Miles, 1983). It was seen in the exploratory interviews that
certain conditions might have an effect on the best implementation of Agile. More concrete, it will be
seen whether the Agile maturity, motivation of choosing Agile and the way Agile is initiated (bottom-
up/top-down) influences the motivation and mindset of the team members and the success of the Agile
process in the same way across cases. It will then be discussed how these different cases approach the
Agile process and its implementation differently.
An overview of the analysis is created to make the approach clear and can be seen in Figure 12.
46
Page
Individual cases Cross-case analysis 1/2
Cross-case Agile Agile

Respondent information Case descriptions Success
overview maturity
CH5 CH5 CH6 CH6.1 CH6.2
Cross-case analysis 2/2
Context Agile way of working Organizational

CH6.3 CH6.4 CH6.5
Discussion Closure
Discussing the Discussing the

Conclusions Recommendations
findings Limitations
CH7.1 CH7.3 CH8.1 CH8.2
Figure 12 - Analysis overview
47
Page
5. Results case study
Chapter 5 Chapter 7
Results case study
After having interviewed all respondents, the results are stated in this chapter. Each case is described and
noticeable characteristics and answers are mentioned. The first five cases are within one organization.
The last five cases are five different organizations. A full list of respondents with their corresponding
information can be seen in Table 11. Information of the full answers to the interviews of all respondents
can be seen in Appendix H.
Table 11 – Information respondents case study
Respondent Organization Project Function Experience Agile Date interview

code
1.1 High Tech Company Delivery of technical Project Cluster Manager 1-3 years 10-07-2019
component
1.2 Software integration Group leader 5+ years 02-07-2019
1.3 Agile transformation Program 5+ years 12-06-2019
manager/Project leader
1.4 Sustaining of Project leader 0-1 year 07-06-2019
technical component
1.5 IT value stream Value stream manager 3-5 years 16-07-2019
2.1 Serving products, services and Surveillance solution Manager engineering 5+ years 21-06-2019
2.2 solutions from military defense to for the Great Barrier Scrum master 5+ years 22-08-2019
civil security Reef
3.1 Industrial and manufacturing Production Integral project 5+ years 16-08-2019
company intensification manager
3.2 Lead engineer 3-5 years 24-07-2019
4.1 Supplier of financial services, Migration of Product owner 3-5 years 12-06-2019
4.2 mainly insurances software system Specialist 3-5 years 01-07-2019
5.1 Supplier of health insurances Website migration Tribe leader 1-3 years 09-07-2019
5.2 Mission leader/software 1-3 years 26-07-2019
developer
6.1 High tech automation industry Delivering software Agile coach 5+ years 26-06-2019
6.2 company and hardware for a Project leader/Release 5+ years 26-06-2019
transport system train engineer
5.1 Case 1.1: Delivery of a technical component

Context
This case had the goal to continuously deliver a complex technical component for Success: 3.71
a high-tech system. It is not considered as a project but a continuous value stream Maturity: 3.73
as delivery is expected continuously. One team of this value stream was working
Agile for over two years. An Agile method was chosen and forced by the group leader. Because some
recruited team members had some experience with Agile, they went along with it. Another reason was
that Agile is a hype and trend and therefore they thought Agile would work for them too. The team started
48
working Agile without communicating to other teams that they were working Agile.
Page
Agile way of working
It took time before the team showed an effective way of working. This
Top 3 practices: mainly took time because they did not communicate that they were
• Retrospectives
• Scrum board starting to work Agile. Therefore the alignment with other teams was not
• Sprint review effective at the start as it was very unstructured. Since the day they said
they were working agile, everything went much easier. They could discuss
priorities and backlogs instead of budget and resourcing. The maturity level grew over the years because
of training and experience. Their success has improved due to the fact that they are transparent in what
they are doing and problems come to the surface quickly. Also, they are doing the right tasks now to reach
success.
According to the respondent, the use of Agile increased success because of two reasons. First, the team
really knew each other. It was said that because teams are stable, they go through more of the
teambuilding phases. After two years the team is really collaborating well. Secondly, the engineers had
calmness because they are not moved from one project to the other. This creates clarity and stress levels
will go down. Agile is said to be effective because of the ritual of improving continuously (retro’s) and also
predicting becomes more accurate by learning the team’s velocity.
The respondent mentioned that teams do not have to go full Agile to have the benefits because not all
practices fits all type of projects. The good thing is that there are various ways of practicing Agile. The
interviewee said that not every type of work is applicable for Agile. In this organization, the project leader
can propose the right method, the project sponsor then decides which in this case was scrum. This is done
because the project leader can only make decisions within the project and knows less about the external
connection. Agile might be the right choice for the project, but Agile should also fit in the alignment to
other teams within the organization. This was said to be harder to assess for a project leader compared
to the project sponsor.
You should really think of whether Agile or waterfall fits the project. – Respondent
1.1
Organizational
Agile was initiated top-down within the department. It was stated that when Agile is initiated top-down,
there might be less acceptation from the teams because they fear the unknown. It does not necessarily
have to be resistance towards Agile, but more against the change. By initiating change top-down without
introduction and without having thought through how the roll-out will go, it was said to not work well and
teams would most likely want to go back to the method they were working with.
It is therefore advised by the respondent to have higher management write a method to follow for
initiating and practising Agile. It was said that instructions are to be written specifically for the
organization, as it is a typical organization with their own culture. Instructions are said to be essential to
ensure that there is alignment and shared definitions. It is advised that everyone should have a guideline
of how to implement Agile so that everyone does it in the same way. This is supposed to remove the fear
and unknowns from the workers and will lead to higher acceptance from the teams. It was stated that at
49
this moment, too many teams in the organization are said to be implementing Agile without having
Page
thought through how the transition needs to go.

A tailor-made method or guidelines are essential for our company because general
guidelines do not always work since our company is so unique. – Respondent 1.1
Agile is mentioned as the only way to do portfolio management. Even though this might be an
overstatement, Agile should result in stable teams instead of moving the people around. This will reduce
frustration of employees and brings along certainty. So within Agile, it is said that portfolio management
is not practised on the level of the engineer by moving him around, but by prioritizing projects and
programs. This stresses their focus on strategic decisions instead of resourcing. Having fixed teams brings
along more predictability of the costs. Not having to discuss budget is said to save a significant amount of
time, which can instead be used for actual work on the project’s goal.
In Agile portfolio management, work is brought to the teams instead of bringing

people to the work. – Respondent 1.1
50
Page
5.2 Case 1.2: Software integration
Context
This case describes a project which had the goal to integrate software patches to Success: 3.29
improve the products which were already in use by the end-user. This ‘project’ is Maturity: 3.55
repeated each quarter so it can be seen as a value stream. A Kanban method was
used. This method was chosen by the respondent because it was believed to improve the process and
also because team members had some experience with Agile.

The initiation of an Agile method did not cause resistance but did lead to
Top 3 practices: some questions by the team members. This was said to be solved by
• Daily standup meeting showing the teams what problems were occurring before and how Agile
• Sprint planning
• Scrum board could tackle these problems. Introducing this new method created
structure in the workstream, made it easier to steer and monitor
problems and enabled better communication with external stakeholders through the transparency Agile
offers. A change in communication was seen through more informal communication and closer contact
with the customers. It helped in managing expectations of external stakeholders as they were updated
frequently.
Training and coaching was perceived as essential to have a certain basic knowledge across the team,
especially important when you want to scale within the organization. Multi-disciplinary teams are seen as
a pro because it makes it possible to have one team responsible for a project, so that everyone knows the
details of the project.
It is noticeable that the phasing of this project could be seen as repeatable projects which make up a value
stream. This was arranged like that because the teams which delivered to them are working traditional.
Sprint reviews were not arranged in the three week sprints but are done though feedback the team
receives on testing of the usage. They hold retrospectives in three week sprints. However, they receive
the same type of tasks each quarter as they receive patches. They have to integrate these patches and
send it to the users. So the type of task is the same each quarter, while flexibility is needed because the
content of the patches is always different.
The respondent mentioned that there’s a minimum maturity of Agile needed to reach its benefits. It is
said that you cannot cherry pick some practices which you find nice, that diminishes the framework and
theory behind it. For the SAFe rollout within the organization, they wrote a cookbook. They wrote down
the learnings of some pilots which are specific for their organization. This is still work in progress and is
not currently being used in practice.
Agile was said to improve success because of the transparency it offered. It resulted in sharing
expectations with the customer better and it made it easier to show progress. Also, it could be seen more
quickly when the team was not fulfilling client’s needs and adapt to it right away. This effect of Agile was
enforced by the daily standup meeting and the scrum board.
Although you do need to tailor the method for your project, you need to respect the
51
framework and principles and keep those intact. – Respondent 1.2

Page
Organizational
Agile was initiated bottom-up in this case. This was seen as an effective way because the ones who need
to work Agile are the ones who choose the method, they should therefore be motivated to make it work.
Pure top-down is seen as not effective when the ones who need to work Agile are not willing to change
their way of working. This can cause resistance. A mix of support from management and the floor is said
to be required to have Agile fully embedded in the organization. Even when teams are working traditional,
it was seen that adapting to teams who are working Agile is needed to create alignment.
52
Page
5.3 Case 1.3: Agile transformation
Context
The goal of this project was to lead the Agile transformation within an organization. Success: 3.29
It had three goals: driving the transformation, ensuring they were able to educate Maturity: 3.21
their employees in the new way of working (via the Agile Academy) and enabling
on-the-job coaching to make the change stick. The team consisted of Agile experts which made the choice
to work in iterations a quick one. The second reason for working in iterations was that flexibility was
necessary because organizational change brings uncertainty. Thirdly, they needed a way of handling new
insights/feedback quickly and change the transformation strategy upon them. Agile was implemented in
this case from middle management.

Even though the team consisted of Agile experts, the process had a
Top 3 practices: learning curve. It started off well, then it became challenging and the
• Knowing why you
choose Agile process is now becoming better again. It was said to be helpful that
• Leadership for everyone knew the Agile concepts but this also caused a lot of discussion
change on a detailed level.
• Maturity of
transitional leaders
According to the respondent self-organization can’t be forced, that needs to arise. The way of working
that they chose enabled self-organization, but it was said that a leader is still needed to send the team in
the right direction. Naturally, a leader should arise from the team, and self-organization should then
follow.
It was seen that Agile had an influence on success because of three reasons: Agile causes focus and
calmness for the engineer, a sense of belonging is created because of fixed teams, and lastly a rhythm is
created by timeboxing, enabling the teams to learn how much work they can deliver in a fixed amount of
time. Doing this for multiple iterations was said to increase the predictability of the teams. The need for
focus, sense of belong, structure and certainty could lead from the nature of the developers working in a
high-tech project.
The Agile method is said not to be a holy grail but it makes bottlenecks in the processes transparent. It
therefore might look as if things are going less well than before. However, it was said that this can also
seem that more problems occur because problems are seen more quickly due to the short iterations and
transparency. For the organization it can be confronting to see the inefficiencies, but in the long run this
transparency is said to help improve the way of working.
Three success factors are mentioned: having a burning platform stresses the issues that need to be
addressed, having leadership actively supporting the change and thirdly the maturity of people
performing the transition needs to have a certain level.
The respondent stated that a project leader’s role is to guide the team and set the direction. This was
said to be done by setting a goal and helping the team to aim for that goal. How the team reaches the
goal, should be left up to them.
Organizational
53
In a transition, aligning Agile and non-Agile teams was seen to be a challenge. Sometimes an Agile team
Page
needed something from a traditional team while the rhythm is significantly different (or even non-
existing). Adding someone from the traditional team in the planning session of the Agile teams is stated
as a good first step in creating an understanding between both worlds.
When starting to work Agile, it is recommended by the respondent to start with following the book, to
prevent cherry-picking. Based on the outcome of following the book, it is advised to adapt the method
when necessary. There are five criteria mentioned to check how teams are doing to become basic Agile:
1. the team needs to be stable.
2. there needs to be a rhythm on team level, on team-of-teams level and portfolio level.
3. roles need to be in place that facilitate the teams (people and process), safeguards the technical
architecture (technical focus) and sets a direction for the team (business and product).
4. portfolio management needs to give direction on what is needed from the team-of-teams every
quarter.
5. rituals: making a promise (sprint planning), showing what has been delivered during the iteration
(review/demo) and identifying actions for the next iteration on how the team can improve (retrospective)
By cherry picking practices and adding them to your current way of working, it
becomes a Frankenstein of the worst of both worlds. – Respondent 1.3
54
Page
5.4 Case 1.4: Sustaining of technical component
Context
The goal of the project is to sustain and develop a technical component of a Success: 3.00
product. It is structured as a continuous value stream, not as a project. Agile was Maturity: 3.03
chosen because eventually most projects would have to start working Agile within
the organization anyway. So the motivation was to prepare for the future. This case has been working
Agile for only three months, the shortest period of time of all cases in this research.

Top 3 practices: Three months after initiation, the process goes worse than before
• None seen yet initiating Agile. This however, was expected by the respondent as he said
that in a transition success usually goes down first in order to go up.
We are now in the valley of despair. This is not because of the Agile approach but due
to being in a transition. – Respondent 1.4
Agile is seen to be improving efficiency in the future by means of communication towards a whole team
instead of one manager which should shorten communication lines. Therefore the project leader will have
more time for acquiring new work and speaking to stakeholders. This case has therefore chosen to keep
a project leader on the project.
There was doubt whether Agile would improve the process. Especially because of the whole new
vocabulary which makes it harder to understand what people are talking about. Now team members who
don’t know how to lead a team become a team leader in the role of the product owner.
Teams were created before the project initiation event. Depending on the tasks teams picked there, they
started to specialize on these tasks. In hindsight it was said to be better to create teams upfront and
structure it as one team per subject, so for each role an employee which was specialized on that subject.
They are struggling with how to communicate to the client. They are doubting whether it is good if a
person of the client joins meetings such as demo’s because this is mostly used to communicate internally.
The message should be different when you communicate internally compared to externally so having both
roles in one meeting makes it hard to address both parties.
Organizational
For portfolio management, value estimation is expected to work the other way around. Traditionally, a
budget is received for a program and allocated to projects. In Agile projects, it is known what the
expenditures will be because there should be stable teams and thus the costs are predictable for the
resources required.
For now, the only problem which occurs in the alignment between Agile and non-Agile projects is that
their planning is only for three months and other projects plan for 5 years. The projects which are
depending on them are said to plan less easy because the Agile team cannot plan for the long-term yet.
55
Page
There is no shared method written for the department or organization yet. Though, the respondent thinks
this would help in initiating Agile. It is mentioned that this can be done by means of a successful pilot and
documenting lessons learnt. The respondent mentions that a method should, however, not be very
detailed because every department and every project requires a different approach. At least the roles and
meetings are said to be defined so that everyone has the same idea for these things. A framework is said
to be required to give a broad direction into Agile.
Projects should still be able to choose from a framework or give a little twist to it but
at least knowing what to choose from would help. – Respondent 1.4
56
Page
5.5 Case 1.5: IT value stream
Context
This case is seen as an IT value stream centered on big data and analytics. Its goal Success: 4.29
is to deliver value continuously. An Agile method was chosen by one team initiative Maturity: 3.72
as a pilot to improve five pillars: increase speed of delivery, more flexibility,
increase quality, decrease risk and happier customers.

Top 3 practices: Improvements on the Agile process can still be made as the full mindset
• Daily scrum switch has not happened yet. The Agile mindset within the teams is quite
meeting okay but stakeholders and higher management lacks this mindset according
• Team ownership
• Transparency
to the interviewee. In order to reach a snowball effect, their mindset should
change too. It is said that it takes time to make this change. This was seen
to prevent the value stream from maturing in terms of Agile.
It started off with one Agile initiative and this was a successful pilot. This made other teams want to join
the Agile initiative. Success cases are said to be a major influence in having people support Agile as it
creates trust in the method.
When initiating Agile, it was seen that many people were stuck in the old way of working, especially the
ones who worked here for a long time. This was tried to be solved by coaching of experienced scrum
masters and coaches. A well-working scrum master is considered to be essential for maturing as a team
and department.
Teams did not start with being self-organized. They were used to being told what to do. Management
therefore needs to make a change in mindset too. A management track has started in IT to make this
change. It was stated that the leaders need to learn to give freedom and trust to the team.
Having a multidisciplinary team was mentioned to be adding value because experience and knowledge is
spread within the team. Not only technical knowledge but also organizational and Agile knowledge.
Having a multi-disciplinary team is therefore considered as essential.
Improvements are measured on each of the five pillars mentioned above. The respondent said that Agile
enabled this improvement because of end-to-end ownership of the team. So having the team responsible
for the full work for the full lifecycle and seeing problems and success right away and being able to
communicate this with the customer right away caused the improvements. The team stays responsible
for the product. This gives the incentive to not make errors and design it in such a way that problems do
not occur. It was said that Agile also helped by being able to measure and transparently communicate
success, so being transparent.
Organizational
They now follow a framework which is inspired by SAFe. They believe SAFe is too big for them.
Standardizing is said to help in implementing Agile, but it is needed to know what works for a full
department. It is therefore said that management needs to gain an Agile mindset because they are the
ones who can decide whether standardizing is needed and how it can work.
It was mentioned that higher management needs to back Agile first before planning on large scale (epic
57
level) can work. This case reached a ceiling of Agile maturing because management did not back Agile.
Page
This can only be solved by showing higher management that Agile works.
The interviewee advised program and portfolio managers to go to the team to see progress instead of the
other way around. This only works when management has an Agile mindset. They now still want to see a
report in detail every couple of weeks.
There are justified sorrows of higher management, problems do come along with
scaling. However, when everyone has the Agile mindset, we can solve these problems
very quickly. – respondent 1.5
58
Page
5.6 Case 2: Surveillance solution for nature reservation
Context
This case is a project which works on a surveillance solution for a large maritime Success: 3.50
nature reserve in Australia. The project is using an Agile scrum method because
Maturity: 4.07
the respondent had made the choice in 2014 to go Agile for the full department.
This was done to improve quality, efficiency and predictability and to solve problems with scaling,
knowledge sharing and single points of failure. Scrum specifically was chosen because it was a structured
framework which could be followed strictly to prevent uncertainty.

Top 3 practices: Teams were structured cross-functional at first. This showed not to be
• Daily standup working well. Then they changed it to organizing teams by sub-system.
meeting multi-disciplinary teams enabled knowledge sharing. An Agile method was
• Transparency not backed by the whole company at the start. All 5 development teams
• Stable team
started with Agile, but after several years, two teams changed: one to
Kanban (because of the nature of their work, solving ad-hoc issues for a large part of their work) and one
to abandon Scrum altogether, returning to be a group of individualists with their own backlog (this team
works on a separate product for a separate market and are not dependent on each other). The other
teams adopted a Scrum method.
On individual level, however, there was hesitance initially. This was said to be mainly because many have
been working there for tens of years and are fixed in a certain way of thinking and working. A respondent
said to be too soft towards people who did not back the choice to go Agile. He accepted that they didn’t
agree. He said they had to place these people somewhere else quicker, so basically get rid of those who
do not back Agile soon enough. It was said that they slowed down the process of the transformation,
didn’t stop or block it but slowed it down.
Everyone had to do a scrum training and exam on scrum.org in order for the basic knowledge to be present
and the same for everyone. This enabled people to talk the same language. A coach was present for the
first 9 months to help the teams out. These trainings and having an Agile coach is considered to be
essential for a transition.
After about a year, big improvements were observed. The social impact was bigger than expected by the
respondent. A sense of belonging was observed which caused more fun in the work because of the team
feeling fixed teams produced.
Daily scrum meetings and a scrum board were said to help because of the transparency it offers. It causes
a responsibility to deliver, otherwise the rest of the team will see you didn't do the job. It enabled room
for discussion which helps the process toward success. Also, a team feeling is created when this meeting
is held daily. For high tech companies, it is said that engineers need structure. The ‘autism’ level is
mentioned to be higher in technical companies. Therefore it is advised to bring a balance between
structure and change. Meeting everyday with the same team helps to bring this balance. Try to minimize
uncertainty in the way of working. Sprint reviews enable transparency from the point of view of the client.
This add huge value as it speeded up the improvement process.
59
Page
Daily scrum meetings really need to be held daily. – Respondent 2.1
Dedicated and experienced scrum masters and product owners are said to be essential so it was advised
to hire them from outside or train them extensively. The product owner has the leadership role in these
teams. He needs to give direction, but also freedom, to the team on how to do the tasks. This should be
done based on the needs of the client. The product owners who know the needs of the client well, are
seen to be the best product owners. It was said that the product owner needs to be a leader, not one of
the team, while the scrum master is facilitating and can be ‘one of the guys’.
Organizational
In broad terms, a shared Agile method is written down organization wide. How to fill it in is left free to
the departments and teams.
The respondent had instructed the department to go Agile. So Agile was initiated top-down, one team at
the time. Implementing in series is advised to do as a big bang transformation is said to lead to too much
uncertainty.
High tech companies specifically are said to generally be very conservative, considering their structure
and higher management. They are said to rather want good output then a well working process.
Therefore they like to plan everything upfront. It is said this can only be changed by showing that an Agile
way of working works.
60
Page
5.7 Case 3: Support and improvement of wafer production
Context
This case works on continuous support and improvement of wafer production. It Success: 3.36
is an outsourced project by the organization of case 1. The team started out with Maturity: 2.85
merely introducing a daily scrum meeting and calling it Agile two years ago. Since
a year, a goal of improving wafer production productivity has been added to the task list. Together with
limited resources, it asked for a more Agile way of working. So the way of working could actually be called
Agile since one year ago.

Top 3 practices: The Agile way of working started off very minimalistic. It was perceived by
• Daily standup respondent 3.2 that it did not add much value to the team, but more to the
meeting managers. They wanted to stay in control and receive feedback each day
• Multi-disciplinary
teams
my means of a daily standup meeting. Therefore many team members
• Scrum board believed this introduction was dubious.
Even though the obstacle would have been bigger, starting off with more elements of
Agile/scrum instead of only a daily scrum meeting would have helped people
understand why we were going to start working Agile. – Respondent 3.2
Since a year (so 1 year after initiation), the Agile way of working has improved by adding more Agile
practices, this happened because more new people came in which had some Agile experience. Also, the
goal of the project changed from support (escalation solving) to support and development, this suited an
Agile way of working better because tasks were more predictable. They then became more Agile. This was
seen for example in the scrum meetings. They made room for technical aspects such as asking for help
when needed to continue instead of focusing on progress updates. Also, the team became multi-
disciplinary. Becoming more Agile was said to be adding much more value for the team as it proved to be
more efficient. More interaction and communication was said to be going on, problems were found
quicker, help was asked for immediately. So the gained transparency helped the team out a lot.
Just doing it shows how it works. If it works well, you gain support. – Respondent 3.2
Documentation is still written, quite a lot in fact. Replacing this with informal communication is said to
improve process but it will be needed for structural documentation. Informal documentation is stated
not to be enough for these high-tech producing processes. Documentation such as knowledge sharing can
be exchanged by having multi-disciplinary teams and better informal communication. Multi-disciplinary
teams also cause quicker and better communication.
They used to fully design the project by means of requirements etc. Only since a year, a more iterative
61
approach is introduced because of limited resources. The team was not used to this approach and thus
caused uncertainty. A way in which is said this would have worked better was by preparing the team that
Page
an iterative design was going to take place. This would have reduced uncertainty and helped preparing
the team.
You should introduce Agile gradually, practice per practice. however, the framework
should be followed fully, you cannot pick principles. – Respondent 3.1
Generally, instructions or a prescription is said to help people in implementing a new way of working
because it becomes more certain as they will have something to hold on to. This is also said to prevent
resistance against the new way of working. Stating best practices or lessons learnt of pilots should be in
such a manual. It is stated that following the framework fully makes implementation easier, only then will
the team see the added value of Agile. However, the other respondent mentioned that it is advised to not
minimize the freedom of choosing a method, otherwise it creates resistance instead of minimizing it.
Organization
The organization is very hierarchical and conservative. Leaders and higher management are still very much
stuck in a traditional mindset and want to stay in control. Autonomous teams are said to be unthinkable
in this organization. Adding to this, the external stakeholders see the project manager as a point of contact
which they have come to find a habit. It should therefore be argued whether implementing Agile
throughout the organization is required and reachable.
The project manager is still responsible for the team, so teams themselves are not empowered. This is
said to be too much of a culture switch for the organization. Changing the role or even removing the role
of the project manager is said to benefit the Agile process. However, this will not happen any time soon
in the organization because the culture is still too hierarchical. It is said this might only change when
replacement of management takes place. When this switch does take place, autonomy can only be
introduced/come into existence when the team members have technical and organizational experience.
Without it, a team cannot and dares not to make decisions.
Without the project manager, the standup meetings are much quicker. – Respondent
3.2
This means that autonomy is needed for an Agile team to work well. The respondent argued whether a
project manager should be present in the team meetings as part of the team, if he should even be
present at all.
62
Page
5.8 Case 4: Migration of software system
Context
This case was a completed project which had the goal to migrate a client portfolio Success: 4.14
to a different SAP landscape. This project can therefore be described as a software Maturity: 3.91
project. It was not in the high-tech sector. Although the project was performed
using an Agile method, scope and schedule were fixed. The project chose an Agile method because teams
around them were working Agile too, they said there was no other choice.
Top 3 practices: Agile way of working

• Sprint planning Overall, the Agile process was working quite well. It was mentioned that
• Daily standup Agile helped completing the project successfully because it created
meeting
• Timeboxing
commitment within the team due to a shared goal, it enabled flexibility, it
made it easy to make short-term decisions and it offered a mandate on team
level to make decisions.
The Agile process was said to mainly work well because they had worked with the same team on a likewise
project before. Therefore the way of working as a team was already aligned so everyone knew what to
do. There was less uncertainty of how to work compared to the first time they worked Agile.
There was an Agile method written for the organization. It was mentioned that the basis of such a method
should be definitions of the roles, meetings and practices to make sure that everyone speaks the same
language and to facilitate teams to work Agile. It was written in broad lines and advice was given on how
to implement it but there was no ‘one’ method to choose as it differs per project. A too much standardized
approach was said to lead to resistance and does not improve efficiency and effectivity.
Ownership of the team was mentioned as an important reason why Agile increased success. It enabled
the team to make decisions and this made quick decisions possible. The team designed the project instead
of a business analyst or architect. This made the team feel as if it was their project. This caused the team
to be fully committed to the result. Also, continuous improvement was seen because lessons were learnt
after every sprint by means of the review and retrospective.
If you were to think that a daily 15-minute standup meeting isn’t helpful, you’re
probably doing it wrong. - Respondent 4.1
Organizational
It was believed that the main factor which influenced the acceptance of Agile within the organization was
having a successful pilot. Trust was then gained from higher management which caused them to integrate
more in the organization. Because higher management backed Agile, teams were accepting Agile more
too.
The two respondents said that Agile can only work if everyone knows what everyone talks about so
communicating on how the process works gives better results too. This was done through a full day at the
start of the project to align definitions and processes of Agile within the team and stakeholders.
63
Page
5.9 Case 5: Website migration
Context
This case is a project to migrate a website from one system to another. In 2014 Q2, Success: 3.57
the first teams of the software department started working Agile as pilots. This Maturity: 3.90
team was formed in August 2016. This was the third website they did as the same
team. Agile was initiated to improve the process: decrease time to market and increase predictability. A
respondent mentioned that defining a minimal viable product enabled to deliver value in each sprint.
Together with close customer relation, it was said to lead to better, faster and more frequent value
delivery. They started to think in priority instead of capacity.

Agile has been working quite well for some years. When the second
Top 3 practices:
• Multi-disciplinary
respondent joined, he did not have any Agile experience. But because
team the team had a fixed way of working already, it was easy for him to get
• Timeboxing up to speed.
• Frequent
communication with
customer The team being multidisciplinary was said to have a big impact on
success. IT and business work together in the team. A mutual
understanding was established because of this. This led to quicker delivery because requirements and
priorities could be aligned right away. Also problems were detected quicker and could be solved quicker.
The team having the autonomy to make decisions was said to add to the benefit because decision making
could happen really fast while safeguarding the needs of both business and IT.
Even though our team members from business were not used to Agile, and our IT
guys had a different Agile way of working, having them together in our team was
very beneficial for quickly seeing our differences in opinion and fixing them right
away. – Respondent 5.2
Training people was said to speed up the transition to an Agile mindset. But not everyone is trainable.
Some stick to the old mindset, some can change towards an Agile mindset really quickly. This gap was said
to be solved by hiring new people with Agile experience to a certain extent. It was said that having a coach
also helped because it gave a certain direction, support and grip so that people without Agile experience
knew what to do. It took away some uncertainty. The other respondent added to this that he believes
that it is most important to have the product owner and scrum master to be experienced in Agile and
really have that mindset. They are the ones to guide the team into the right direction, content and process
wise. They can also spread their Agile knowledge and experience to the rest of the team. Although a
respondent says it is more important to have experience as a team than to have individual Agile
experience.
3 week sprints enable more flexibility within the sprint because you can switch tasks
around. 2 week sprints keeps the rhythm up and keeps pressure on finishing tasks to
64
prevent postponing them. – Respondent 5.2

Page
Agile was believed to increase success due to having multidisciplinary teams, valuing communication over
documentation and by incremental delivery. Thinking in terms of a minimal viable product enabled quick
delivery of value. It is believed that using one Agile practice will not be effective because it is the
combination which works. There is no instruction book on how to implement an Agile way of working in
the best way, but working conform the Agile principles and having certain practices fixed is said to help a
lot. It was advised to have fixed rhythms, fixed multidisciplinary and not too big teams. Coloring within
these lines is allowed.
Although you do not need to apply all agile practices in order to see the benefits. As
long as you apply the full framework, concept and mindset behind it, you will see
benefits. – Respondent 5.2
Organizational
They hold quarterly business reviews to align 20 Agile teams and plan for the next quarter. So they only
define the ‘what’. The ‘how’ is left to the team to decide to prevent resistance and because the team
itself knows best how to do it.
On program and portfolio level, it was advised to make sure that you have your resources fixed for at least
the next quarter. If you need to make choices, than that is on priority, not on capacity. The program
managers look at KPI’s so they rate epics on e.g. customer satisfaction, amount of customers, etc. Then
they can rank the epics. This could help in prioritizing epics. In planning, the tribe leader and the Product
owners look whether the high level planning can be reached in that quarter.
65
Page
5.10 Case 6: Delivering software and hardware for parcel transport systems
Context
This case is developing a product which is used for sorting and transporting Success: 3.64
products. It is mainly focused on software but the software is written to make the Maturity: 3.58
hardware work. An Agile method was chosen to improve the success since results
were disastrous before. Other reasons for choosing Agile was that it fitted their project more because the
software component had become increasingly important, the outside world is changing faster and faster
so flexibility was necessary and the last reason was to bring in some fun in the work.

Top 3 practices: It is seen that results have improved in 1,5 years of working Agile. E.g.
• Team ownership scheduling improved from 3-4 months behind to two days late. However,
• Stable teams the process can still improve. It is said that higher management should first
• Transparency
back Agile in order to be able to further mature.
Agile was said to mainly have an effect on success because of the transparency it offered, problems could
not be hidden anymore and are therefore fixed quicker. Also, people are working with each other more
directly which was said to enable quicker solving of problems too. Another reason mentioned why Agile
has improved success is seen in stakeholder engagement. The number of escalations are decreasing
because stakeholders bring in their view continuously, so if the project is not going into the direction
which the stakeholders want, they can steer into the right direction right away. Success by means of
quality of the product mainly showed when some peace and quiet returned in the organization, which
could only happen after some time of transition.
There was a problem with team members resisting the Agile way of working. This was stated to be solved
by showing them what the benefits are when working truly agile through talking, training, coaching,
presentations and hoping that those who do back Agile explain why it works. Especially when higher
management gives such a training, they saw better understanding that higher management backs Agile
so they should probably back Agile too as the whole company might shift towards Agile.
Agile gives freedom and responsibility to the workers, also to the ones who cannot deal with this
responsibility. This can work out in a negative way. They therefore hired experienced PO’s and SM’s to
take up these roles for teams in which there was not a person who was able to take up such a role.
Scrum is like having your mother-in-law over, she will point out everything that is
wrong but you need to make the improvements yourself. – Respondent 6.1
The daily scrum meeting made sure that the full team knows what is going on, discussions can arise and
a team feeling is created. They also hold weekly meetings with all scrum masters and a separate meeting
with all product owners. Experience of the best SM or PO is then spread and alignment between teams is
created. In planning, they have a rule that stories cannot be longer than half a sprint to make sure value
is added in each sprint.
66
It was seen that Agile increased success because people collaborate more and feel heard because of
Page
empowerment of teams. Also, the team got more fun out of working. On top of that, stakeholders have
more insight in the project and can steer the process better, given that the stakeholder has an Agile
mindset too. All in all, transparency is the key word.
Organizational
They try to follow SAFe as strictly as possible. This framework is there for a reason, it is said to work when
followed strictly. However the actual method is filled in as needed. It is said though that SAFe/Agile in
name only will never work. It is said that teams need to use all artefacts in order to reach the mindset to
use Agile in a good way. So 100% Agile is advised. To get those who do not back Agile get used to the idea,
it is mentioned that you can set the events without naming them as Agile events.
They advised to convince higher management as soon as possible as they now reached a ceiling in which
teams can work Agile but the company does not embrace Agile yet.
If you were to change the framework you would say that you know how to do it
better than the Agile manifesto, I think not many teams can do that in the world. –
respondent 6.1
67
Page
6. Cross-case analysis
Chapter 5 Chapter 7
Results case study
This chapter examines the case results and will compare these across the cases. Chapter 6.1 examines the
Agile maturity of the cases to categorize them. Chapter 6.2 will do the same for the case success. Chapter
6.3 will discuss the findings of the practices discussed during the interviews and ends with seeking best
practices. The final subchapter of the analysis will compare results of the respondents on scaling Agile and
embedding it in an organization. A cross-case overview can be seen in Table 12, this data is gathered from
a survey and the interviews.
Table 12 - Case information
Case Organization Sector Agile method Start Agile Initiation Phasing Sprint
code duration
1.1 High Tech Company High-tech Hybrid scrum 2016 Q4 Top-down Value stream 2 weeks
1.2 High-tech Kanban, scrum 2017 Bottom-up Value stream 3 weeks
1.3 High-tech Scrum, SAFe 2018 Middle Project 1 week
management
1.4 High-tech SAFe 2019 Bottom-up Value stream 2 weeks
1.5 High-tech Scrum, DevOps 2017 Q1 Bottom-up Value stream 2 weeks
2 Serving products, High-tech Scrum 2014 Top-down Project 2 weeks
services and solutions
from military defense to
civil security
3 Industrial and High-tech Hybrid scrum 2018 Q4 Middle Value stream 2 weeks
manufacturing company management
4 Supplier of financial Non-high tech Scrum, DevOps 2016 Top-down Project 2 weeks
services
5 Supplier of health Non-high tech Scrum, DevOps 2014 Q2 Top-down Project 3 weeks
insurances
6 High tech automation High-tech Scrum, SAFe 2017 Q2 Bottom-up Value stream 2 weeks
industry company
6.1 Agile Maturity

The Agile maturity of the cases have been measured by help of the Comparativeagility survey. The average
scores are seen in Figure 13. The survey questions are structured by means of dimensions. Which
questions are asked per dimension can be read in Appendix G. The scores for the cases per dimension can
be seen in Figure 14. The world index consists of all two million datapoints of two thousand companies in
Comparativeagility’s database. This index helps to see where the cases stand and to give a better idea of
what the scores mean. The scores of the cases of this research with two respondents (2-6) are averaged.
68
Page
5.00
4.07 3.91 3.90
4.00 3.73 3.55 3.72 3.58 3.71
3.21
Maturity score
3.03 2.85
3.00
2.00
1.00
0.00
Cases
1.1 1.2 1.3 1.4 1.5 2 3 4 5 6 World index
Figure 13 - Average maturity scores
6.1.1 Categorization maturity

The average maturity scores give an indication of the actual maturity but no exact representations of the
actual maturity due to different interpretation of respondents during the survey. Therefore, the maturity
is categorized by considering the data of the survey as well as the interpretations of the answers given in
the interviews. It is perceived that the results of the survey are generally comparable with the overall view
of the interviews, though there are some exceptions. The cases will be categorized in low, medium and
high mature for easier qualitative analysis based on not only the survey data but also the perceptions of
the interview. Figure 14 shows the scores of the cases per dimension, as well as the world index. These
Agile maturity dimensions are established by, and directly related to, questions from the
Comparativeagility survey, as seen in Appendix G.
Teamwork Requirements Planning Technical Practices
Quality Culture Knowledge-Creating Outcomes
5.00
4.00
MATURITY SCORE
3.00
2.00
1.00
0.00
1.1 1.2 1.3 1.4 1.5 2 3 4 5 6 World
CASES index
Figure 14 - Maturity scores per dimension
Four cases are categorized as low mature. Case 1.2 scores higher on culture and quality but lower on all
the other dimensions. Their average of 3.55 is considerably lower than the world index. The case is
therefore categorized as low mature. Case 1.3 scores very low on culture and quality while other
dimensions score around the world index. The interview suggested that this case is not mature. Therefore
this case is categorized as low mature. Case 1.4 shows almost the same scores for each dimension, which
69
is suspicious. This could be caused by the respondent not filling in the survey in the right way. However,
the interview suggested that this case was not at all mature and the survey resulted in a low score of 3.03.
Page
Therefore, this case is categorized as low mature. Case 3 shows quite low scores, especially for ‘knowledge
creating’. This means that no reflection or lessons learned are documented throughout a sprint. This
prevents improving the Agile process as a team. The other dimensions score somewhat average.
Considering the extreme low score for knowledge creating, the case is categorized as low mature.
Three cases are categorized as medium mature. Case 1.1 shows a well-balanced score division per
dimension, comparable to the world index in terms of average and score division per dimension. Technical
practices are scored lower, which seems to be the case for most teams, as seen in the world index. The
case is therefore categorized as medium mature. The case 1.5 scores are very spread, some dimensions
score very high while others score fairly low. This could be because the respondent wanted to give a good
indication in differences between the practices. When keeping the interview in mind, an average score of
3.90 is too high. This case’s maturity is therefore categorized as medium. Case 6 scores a bit lower than
the world index. Only technical practices score much lower than the index. The interview suggested the
team to be on its way but not fully there yet. The case is therefore categorized as medium mature.
Three cases are categorized as highly mature. Case 2 is considered highly mature because all dimensions
score higher than the world index and some score even a point higher. This is confirmed in the interview.
This case is therefore categorized as highly mature. Case 4 shows very high scores on its Agile maturity.
Only technical practices score lower than the world index. This case is therefore categorized as highly
mature. Case 5 scores higher than the world index on four of the dimensions. This view is also seen during
the interviews. The case is therefore categorized as highly mature.
The categorization and the maturity scores can be seen in Figure 15.
Medium Low Low Low Medium High Low High High Medium
5.00
4.07 3.91 3.90
4.00 3.73 3.55 3.72 3.58 3.71
3.21
Maturity score
3.03 2.85
3.00
2.00
1.00
0.00
Cases
1.1 1.2 1.3 1.4 1.5 2 3 4 5 6 World index
Figure 15 – Average maturity scores and categorization
6.1.2 Maturity dimensions

Comparing scores per dimension gives insight in the weight of influence on the maturity score, this is
illustrated in Figure 16 showing scores per dimension over all the cases.
70
Page
Figure 16 – Box plot of maturity scores per dimension
It is seen that planning, knowledge-creating and teamwork are scored relatively high while technical
practices are scored by far the lowest. Planning is scored high as this practice is extensively used in
traditional project management as well, and thus teams are experienced with this dimension. Knowledge-
creating and teamwork score high because it consists of reflection, communication, location and progress
tracking. These practices are considered the first things that get attention when starting to work Agile.
These practices are also present in most low mature cases. Technical practices might be scoring low
because it largely consists of testing practices. Testing does not occur and is said to not be important in
non-software related cases.
Most dimensions have scores of around 3 or 4 and a relatively low standard deviation of 0.4 to 0.5.
However, the ‘knowledge creating’ dimensions score a range from 1.67 to 4.84 with a high standard
deviation of 0.96. This tells that not everyone has the willingness to reflect and mindset to improve. The
‘culture’ dimension also almost shows the full range from 1.60 to 5.00 with a high standard deviation of
0.90. This tells that the ‘culture dimension’ and ‘knowledge creating’ dimensions have the biggest
influence in differences in maturity across the cases.
It is noticeable that cases which were initiated top down generally have a higher score on the culture
dimension than those who started bottom-up. This might be the situation because support of
management is present. It is also seen that culture scores much higher for cases which have initiated Agile
longer ago. This can indicate that it takes time to fully implement an Agile culture, this statement will be
further discussed in the next subchapter and in chapter 6.1.3.
6.1.3 Maturing takes time
Don’t think success makes huge steps right away when you implement Agile. You might
need to make a mistake two times before you realize how it should work. Transitions take
time, and finding the way of working which suits your team and project does too. –
71
Respondent 2.2
Page
The cases all initiated Agile at a different point in time. The moment in time in which the team started
working Agile was asked during the interview. Case 1.4 was only working Agile for three months at the
moment of the interview while case 2 was working Agile since 2014. A plot of the maturity scores versus
the months since initiation is seen in Figure 17. It is seen from the trend line that the maturity score
increases as cases are working Agile for a longer period of time. The corresponding R2 of 0.91 indicates
that the model explains 91% the variability of the response data around its mean. This suggests that
maturing takes time.
4.50
4.00
3.50
y = 0.0224x + 2.8178
Maturity score
3.00 R² = 0.9067
2.50
2.00
1.50
1.00
0.50
0.00
0 10 20 30 40 50 60 70
Months since initiation
Figure 17 - Maturity score vs. months since initiation

72
Page
6.2 Case success
The success of the cases has also been measured by help of the Comparativeagility survey. The success of
the cases is needed to examine the influence of their Agile way of working on project’s success. The
average scores of the success dimensions are illustrated per case in Figure 18. The scores of cases with
two respondents are averaged. The averages of the success scores merely give an impression of how well
the project performs. The exact scores are of less importance. The success of the cases will be categorized
to make easier qualitative analyses.
5.00
4.29 4.14
4.00 3.71 3.57 3.64
3.50 3.36
3.29 3.29
Success score
3.00
3.00
2.00
1.00
0.00
Cases
1.1 1.2 1.3 1.4 1.5 2 3 4 5 6
Figure 18 - Average success scores
In the survey, it was asked whether the dimensions showed improvement. Respondents could answer
from 1 to 5. 1 being false, 3 being nor true nor false and 5 being true. Therefore, scores higher than 3
indicate improvement since the introduction of Agile and scores lower than 3 indicate success has
decreased. From the survey results can be concluded that no case showed a decrease in success since the
introduction of Agile.
6.2.1 Categorization success

The successes of the cases are broken down in different dimensions by means of the survey questions.
Seven questions were asked to find out whether the seven dimensions of success showed improvement.
Figure 19 shows the scores of the cases per success dimension.
Quality Productivity Functional customer satisfaction
Usability customer satisfaction Team morale Economic value
Quick and often delivery
5.00
4.00
SUCESS SCORE
3.00
2.00
1.00
0.00
1.1 1.2 1.3 1.4 1.5 2 3 4 5 6
73
CASES
Figure 19 - Success scores per dimension

Page
It is seen that most dimensions score a 3 or 4 for all cases. Some cases have one or two outliers. Case 1.1
and 1.2 are similar and show average success scores. Case 1.3 scores really low on ‘Quality’. Based on the
survey question, this says that the case does not deliver higher quality products than before, although
other dimensions score average. Case 1.4 scores lower on ‘frequency and speed of delivery’ than other
cases. This case has initiated Agile only three months ago. Therefore the differences in success might not
be visible yet. Case 1.5 scores higher than other cases on ‘customer functionality satisfaction’ and
‘frequency and speed of delivery’. Case 2 scores higher on ‘Quality’ and ‘Productivity’ while ‘frequency
and speed of delivery’ is scored slightly lower than other cases. Case 3 scores average on all dimensions.
Case 4 scores higher on many dimensions and no dimension is scored lower than averages of cases. Case
5 sores average on all cases but ‘frequency and speed of delivery’. Case 6 scores about average on all
dimensions.
Comparing the results of the survey to what has been said in the interviews gives a slightly different
perspective. The survey showed no decrease in success for all cases. However, the interview of case 1.4
indicated that things are going worse than before. Therefore, case 1.4 will be categorized as having low
success. Case 2 indicated a moderate success score, indicating a slight improvement, according to the
survey. However, the perceived success during the interview was actually very high. The respondents
mentioned that problems such as knowledge sharing, teamwork and structuring of teams were tackled
since the Agile transition. Therefore, case 2 is categorized as a high success case. All other success scores
retrieved from the survey show a same success categorization as observed in the interviews. Table 13
shows the categorization of case success with their accompanying success score.
Table 13 - Categorization cases by success
Low success Medium success High success

Case 1.4 (3.00) Case 1.1 (3.71) Case 1.5 (4.29)
Case 1.2 (3.29) Case 2 (3.50)
Case 1.3 (3.29) Case 4 (4.14)
Case 3 (3.36)
Case 5 (3.57)
Case 6 (3.64)
74
Page
6.2.2 Success dimensions
Comparing average success scores per dimension gives insight in the effect of Agile on different
dimensions of success. This is illustrated in Figure 20 showing a box plot of success scores per dimension
ranked by average success scores.
Figure 20 - box plot success scores per dimension (ranked by averages)
It Is seen that Agile improved all success dimensions on average of the cases of this research as all average
scores are higher than 3.0. It is also seen that Agile improves success on average most in terms of team
morale. The dimensions economic value and usability customer satisfaction has on average improved
least, which is remarkable considering the focus of the Agile framework on customers and the figures
mentioned in the introduction of this thesis.
However, the box plots of usability customer satisfaction ranges from 3.00 to 4.00 meaning that it
improves success in any case. The box plot of economic value tells that all cases showed an increase but
the error bars indicate that a decrease in success on economic value is possible.
The dimension quick and often delivery shows the highest variability ranging from extreme improvement
of success to a decrease in success. Which says that it is unsure whether Agile causes an increase in success
on this part. This is remarkable since quick and often delivery is one of the main principles of the Agile
manifesto.
All other success dimensions show box plots indicating improvement in any case. So it can be concluded
that on all dimensions except quick and often delivery and economic value success is increased when
introducing Agile.
75
Page
6.2.3 Maturity vs. success
Examining whether maturing actually leads to more success answers the questions whether being more
Agile mature helps in completing projects successfully. The box plot seen in Figure 21 shows this relation.
The maturity categorization is followed according to Figure 15. It is seen from the cases of this research
that low mature cases score lower on success. Medium and high mature cases show about the same
results for success. This is complementary to what respondent 2.2 mentioned on the fact that a certain
threshold should be reached in terms of Agile maturity to improve success. It might not be necessary for
all types of projects to reach a high maturity level, as high improvements on success are also occurring in
medium mature cases. It is also seen that low mature cases show lowest improvement in success.
n=3 n=3
n=4
Figure 21 - Maturity categorization vs. success scores
The relation between maturity scores and success scores without categorization is seen in Figure 22. An
increase in success is seen for higher mature cases in this figure as well. However, only 36% of the variation
is explained.
4.50
4.00 y = 0.5893x + 1.4841
3.50 R² = 0.3622
3.00
Sucess score
2.50
2.00
1.50
1.00
0.50
0.00
0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00
Maturity score
Figure 22 - Maturity vs. success

76
A highly mature team with bad software engineers still has bad output. But also,
good software engineers in a low mature team brings bad output. – Respondent 2.2
Page
Figure 22 shows two cases which have very high maturity while their success improves less than the trend.
It also shows two cases which show high improvements on success while their maturity are not among
the two highest scores. This could indicate that the trendline stagnates after a certain level of maturity.
This would mean that the effort of maturing results in a smaller improvement of success after a certain
level of maturity. This says that it is not necessary to reach a maximum level of maturity in order to reach
the highest improvements on success and that it might be more effort- and cost effective to be medium-
high mature.
77
Page
6.3 Agile way of working
This sub-chapter starts off by identifying the reasons why Agile improves success in chapter 6.3.1. Each
practice discussed in the interview will be explained in chapter 6.3.2 by mentioning how the cases make
use of the practice and what the effect of the practice is. This chapter ends with identifying the best
practices of Agile in chapter 6.3.2 by linking the practices to maturity and success.
6.3.1 Effect of Agile

It was asked, by means of an open question, how the respondents perceive that Agile caused an
improvement in success during the interviews. The frequency of these answers is illustrated in Figure 23.
This indicates the effects of Agile and how it causes an increase in success. It is found that Agile offers
transparency which is mentioned to increase success most. Another frequently mentioned reason how
Agile improves success is that better communication occurs. Teams having end-to-end ownership of the
project enables them to make decisions and make them feel as if it is their project. This is mentioned to
be a reason why Agile has improved success. Because teams are staying together for a longer period of
time, a team feeling can be created which causes a sense of belonging for team members. This brings
more fun in the work and is said to improve success rates. Quick problem identification is mentioned as a
reason why Agile increases success too. This is closely related to transparency as problems are identified
quicker because of transparency.
Transparency
Team ownership
Better communication
Quick problem identification
Calmness for engineers
Teamfeeling
Fun in work
Minimum viable product
Incremental delivery
Flexibility
Continuous improvement
Client interaction
Freedom
Rhythm
0 1 2 3 4 5
Figure 23 - Frequency reasons Agile improves success

78
Page
6.3.2 Agile practices
A list of practices which cover Agile has been defined in Table 7 in chapter 3.2. These practices are
examined during the interviews to seek for Agile best practices. An insight of how these practices were
practised and what their effect is was found during the interviews. Many practices are intertwined and
have an effect on each other. The reasons why Agile improves success, as mentioned in chapter 6.3.1, are
accomplished by practicing certain Agile practices. So, the way Agile is practised affects the way Agile can
help projects to become successfully completed. Table 14 shows a variable-by-variable matrix with
characteristics and the degree to which Agile practices are fulfilled per case. This gives insight in the effect
of certain characteristics on the practices. For example, it can easily be seen that all highly successful cases
have a shared method written for the department or organization. The data of this table is extracted from
the surveys and interviews.
Table 14 - Variable-by-variable matrix
CASE 1.1 1.2 1.3 1.4 1.5 2 3 4 5 6
Success Medium Medium Medium Low High High Medium High Medium Medium
Maturity Medium Low Low Low Medium High Low High High Medium
Initiation Top- Bottom- Middle Bottom- Bottom-up Top- Middle Top- Top-down Bottom-
down up manage up down manage down up
ment ment
Shared belief Yes Yes Yes No No No No Yes Yes Yes
Agile Medium Medium Yes No No No No Yes Medium No

experience
Informal Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
communication
Frequent Yes Yes Yes No Yes Yes Yes Yes Yes Yes
communication
customer
Shared method Work in Work in Not Not Yes Yes No Yes Yes No
progress progress aware aware
Sprint review No No Yes Yes Yes Yes Yes Yes No Yes
Retrospective No Yes Yes No Yes Yes No Yes Yes Yes
Sprint planning Quartely per Quartely Per sprint Per No Per Per sprint Per
sprint and sprint sprint and quarter sprint
quarter
Multi- No Yes Yes Yes Yes Yes Yes Yes Yes No

disciplinary
Management No No No No No Yes No Yes Yes No

support
Shared belief in Agile within the team

In short, resistance against Agile usually does not occur when the team has Agile experience. A shared
79
belief can be created firstly by letting the team decide whether to choose Agile or not. Secondly, having
the team realize the benefits of Agile by training or coaching and showing successful pilots. If this does
Page
not create a shared belief, the ultimate option is to let go of people who show resistance.
More detailed, there is a distinction in shared belief in Agile between teams which already had Agile
experience and those who were new with Agile. It was seen from Table 14 that from the 5 cases which
had medium to high experience with Agile, 4 cases had a shared belief in Agile. From the 5 teams which
did not have Agile experience, 4 cases did not have a shared belief in Agile. When teams already had
experience with Agile, the belief in Agile was higher, as said by respondent 1.3, 4.1 and 4.2. This tells that
more people back Agile when they already know how the process works. This adds to the finding that
maturing takes time, as experience with Agile and as a team is needed to have a shared belief in Agile.
Not having a shared belief in Agile within the team can lead to resistance against the initiation of Agile.
Resistance was said to slow down the process of a transformation. This resistance was tried to be
prevented by letting teams decide to start working Agile or remaining with their way of working. If they
did choose to work Agile or if someone decided it for the team, any resistance was tried to be solved by
making sure the team understands the basics of Agile and how Agile can be beneficial for them. Creating
the understanding was ensured in two ways. Firstly, training the team so that employees understand what
Agile is and why it could work. Secondly, having an Agile coach on the team so that he can convey the
strength of Agile and help the team understand why Agile can be beneficial for them. Another way to
have people back Agile before actually introducing Agile within their own team is by showing successful
pilots. This makes people support the method, increasing the shared belief in Agile. Therefore, many
respondents advised to just start introducing Agile within an organization. If pilots become successful,
people will trust the method and support is gained. This will cause a snowball effect of teams initiating
Agile.
Success cases are a major influence in having people back Agile. It creates trust in the
method. – Respondent 1.5
If these two practices did not ensure a shared belief in Agile and therefore did not get rid of the resistance,
it was seen that case 2, 5 and 6 intervened by hiring new people with Agile experience. These experienced
people can help organize the Agile meeting and pass on their experience within a team.
We were too soft towards people who did not back Agile. We accepted that they
didn’t agree. We had to place these people somewhere else. They slowed down the
transition. – Respondent 2.1
Furthermore, experience as a team was considered to be more important than having individuals with
Agile experience. This was illustrated best in case 1.3 and 5. Case 1.3 consisted of very Agile-experienced
individuals but needed time to have the team dynamics right. Respondent 1.3 was an Agile-inexperienced
when he joined an up-and-running Agile team which made it easy for him to follow along.

80
All cases except 1.4 had frequent communication with the customer, as seen in Table 14. This is logical as
it is a principle of the Agile manifesto. This made sure that the team did what needed to be done to satisfy
Page
the customer. Shorter communication lines with the customer resulted in quicker communication and
quicker decision making. Also, when problems arise, this was communicated right away. This created
transparency for both parties and prevented unexpected setbacks. It therefore was said that it helped in
managing expectations of the customer. It therefore contributes to transparency and quick problem
identification, two of the most frequently mentioned reasons of why Agile improves success.
Case 1.4 is struggling with frequent communication with the customer. They are not aware how to do this
and during which event. They have the feeling that a different message should be communicated when
the customer is present. This could be solved by organizing a sprint review in which the message is meant
for the customer.
Daily standup/scrum meetings and Kanban/scrum board

The daily standup were said to be most effective when performing according to the book by 9 out of 15
respondents. By the book means every day, 15 minutes to check progress and ask for help when needed.
This ensured that the full team knew the progress of the tasks. This enabled other team members to finish
tasks when someone was not present. When skipping these meetings, so not doing it according the book,
it was felt that the team was not well enough up to date to take over other people’s tasks.
The benefit of a daily standup meeting is mainly seen in the transparency it offers, as mentioned by 7
respondents. Transparency was also the most frequently mentioned reason why Agile improved success
in the interviews as mentioned in chapter 6.3.1. Added to that, it causes a responsibility to deliver because
progress is checked daily. Thirdly, it enabled room for discussion which helps the process towards success.
Lastly, it created a team feeling as everyone was up to date with each other on business- and personal
affairs.
Asking for help during these meetings is one of the ways transparency is offered. This also helps in quick
problem identification, which is one of the most frequently mentioned reasons why Agile improves
success.
One defined process/way of working scrum across organization

4 cases have an Agile method written down for their organization and 2 cases are working on it. It is
believed by 10 out of 15 respondents that a standardized method for an organization is beneficial because
it gives something to hold on to and it created a shared language so that everyone can understand and
align with each other. It is believed to be beneficial only when presenting such a process on high level.
There are cases which say a defined way of working will help structure a transition but they do not have
such a method written. This was mainly not written (yet) because there was not enough experience with
test pilots to understand what this method should exactly entail.
A too much standardized approach will lead to resistance and does not improve
efficiency and effectivity. However, a method should be written to make sure that
everyone speaks the same language, have a shared rhythm and to facilitate teams to
work Agile. – Respondent 4.1
81
Without such a written method or process, it is said to start off with following the book (scrum/SAFe) as
much as possible on high level such as considering the Agile mindset. This is said by 7 respondents, 2
Page
respondents disagreed and 6 respondents were unsure. When not following the book, cherry-picking
occurs which results in a Frankenstein way of working of Agile and waterfall. A Frankenstein way of
working is said to not work as good because there is a reason why a framework is written. The elements
of the framework are intertwined and thus having some elements does not result in as much benefit.
Cherry-picking diminishes the framework and theory behind it.
If you were to change the framework you would say that you know how to do it
better than the agile manifesto, I think not many teams can do that in the world. –
Respondent 6.1
5 respondents mentioned that starting off with following one method also reduces uncertainty for the
teams and helps them speak one language which can help prevent any resistance from occurring. It is said
by respondent 1.2 that there’s a minimum level/maturity of Agile needed to reach the benefits. This is
also suggested by analyses in chapter 6.2.3. Based on the outcome of following the book, the written
method can be adapted. It is important to note that this method should only describe high level
arrangements of the way or working. E.g. the method can state which practices are to be used while the
way such a practice is filled in should be left to the team to decide.
Although you do need to tailor the method for your project, you need to respect the
framework and principles and keep those intact. – Respondent 1.2
Especially for high tech companies, an instruction can be beneficial because technical workers favor
certainty and something to hold on to. Such an instruction can take away the fear of the unknow.
The ‘autism’ level is higher in technical companies. Therefore you need to bring a
balance between structure and change. Try to minimize uncertainty in the way of
working. – Respondent 2.2
A defined method can be written by means of describing observations of pilots. It is advised to let the
method be written by higher management as they have an overview of that works for the different
departments. Management therefore needs to gain an Agile mindset because they are the ones who can
decide what method can work. Writing down lessons learned are important for teams starting off with
Agile. At least the roles and meetings should be defined so that everyone has the same idea for these
things. 11 out of 15 respondent said that a method should however not be very detailed because every
department and every project requires a different approach and freedom should be left to the teams. A
framework is required to give a broad direction into Agile, projects should still be able to choose from that
framework or give a little twist to it. Leaving freedom of choosing a method to the team minimizes
resistance and makes sure the method fits the team and their tasks.
82
Coaching/training of Agile
Some cases organized training from the start and others found out later that it was necessary. It was
Page
generally said that training should be performed as soon as possible for all employees who will work Agile.
This is said to be necessary because it results in a basic understanding of how Agile works. This helps in
the Agile process as everyone understands what the principles and practices entail. Furthermore, it helps
people give insight in why Agile can work for them, so that acceptance of the new way of working is
formed. Those cases which had a lot of Agile experience said they didn’t organize anymore training
because a good level of Agile understanding was already reached.
People should understand and see for themselves that Agile works. This will have
them back Agile and other teams will want to work Agile too if they see that it works.
– Respondent 3.1
After having held these trainings, an Agile coach is said to even further enhance the knowledge of the
employees by spreading his experience and knowledge. He is also the one who can design the Agile
process in a way which works for the specific project. This Agile coach is said to give direction, support
and grip so that people without Agile experience know what to do and why they should do it.
These trainings and having an Agile coach is essential for a transition in order for the
basic knowledge to be present and the same for everyone – Respondent 2.1
Sprint review
The sprint reviews are held by 7 out of 10 cases. Those cases who hold sprint reviews say they create
transparency by openly communicating progress and problems to the client in each sprint. Also, feedback
is given by the client to the team in each sprint. In this way, the client and the project team can solve
problems quickly together instead of finding out the product does not meet the client’s requirements
when delivering a full product.
Traditionally you are a submarine which goes underwater for a couple of months,
Agile is a dolphin which comes to the surface more often. Problems are found much
quicker. – Respondent 2.1
Five respondents said that in addition to the sprint review, a sprint retrospective adds value as it improves
the Agile process. Two respondents organizes retrospective while not organizing sprint reviews. The
retrospectives are held with only the people inside the team. They reflect on the way of working of the
past sprint and establish direct tasks to improve the process. These tasks are then added to the backlog
for the next sprint. This is mentioned to be a huge improvement by 5 respondents compared to the way
reflections and improvements were organized in the way of working before Agile. Instead of reflecting
once a year and doing nothing with it, it is organized for every sprint and implemented in the next sprint.
Sprint planning and selection of work

83
It was seen that the sprint planning is organized very differently per case. Case 3 did not even held these
meetings. two did it quarterly and 6 held it every sprint. It is seen that most plan for the full team instead
Page
of per person. During the sprint, team members could pick tasks. However, many respondents admitted
that tasks are selected based on the type of workers they have on the team. Only two cases (2 and 4)
followed the book during the sprint planning e.g. estimating task effort by doing planning poker and
selecting tasks based on both priority and velocity.
Sprint duration
6 cases held sprints of 2 weeks. 2 cases had sprints of 3 weeks and 1 case had a sprint of only 1 week.
Another case changes the duration of the sprints depending of the phase of the project. Sprints of 2 weeks
are said to be long enough to add value and short enough to adapt quickly, keep focus and pressure. One
case set a rule during planning that stories cannot consist of more effort than can be done in half a sprint
to ensure value is added each sprint. Some teams extended the sprint duration because they believed
Agile caused too much overhead e.g. the sprint events take up time which cannot be spend on doing the
actual work. Too long sprints were said to enable people to think that they have more than enough time
to finish the tasks selected during planning. A frequency graph of the duration of sprints are illustrated by
categorized success in Figure 24. What can be seen is that all highly successful cases have sprints of 2
weeks. However, the one low success case has a sprint of 2 weeks too. This suggests a promising finding
that 2 week sprints lead to highest improvement of success. Further research is to validate this statement.
3 weeks
2 or 3 weeks
2 weeks
1 week
0 1 2 3 4 5 6 7
Low success Medium success High success
Figure 24 - Frequency sprint duration categorized by success
The most effective sprint duration is said to differ per type of project and what suits the team best. It was
advised to not change the duration of the sprints when the project is running by all except case 3.
Whole multidisciplinary team with one goal

8 out of 10 cases said to have multidisciplinary teams. It is said by 4 of the 12 respondents that work in
multidisciplinary teams that it is beneficial because experience and knowledge is spread within the team.
The daily stand ups in combination with multidisciplinary teams is said to enforce this.
The social factor of Agile had a bigger impact than expected. – Respondent 2.1
It is perceived by 3 respondents that a multidisciplinary team creates a team feeling and a sense of
belonging. This is enhanced by the daily scrum meetings. This can help bringing more fun in the work.
Having fixed teams enables workers to build a relation and creates calmness as they aren’t switched
around projects often. In this way, work is brought to teams instead of bringing people to the work.
84
My biggest lessons learnt is having the team design the project instead of a business
Page
analyst or architect. This makes the team feel that it is their project. They know
everything of the project instead of only the part on which they are working. –
Respondent 4.2
Having a multidisciplinary team is said by 7 respondents to result in a feeling that a team is working on
the project instead of people working on small tasks. This caused the full team being responsible for the
project. 4 respondents working in multi-disciplinary teams said that making the team autonomous
enhances the feeling that the project is their project. This brings along the responsibility of delivering and
is said to ultimately make the team self-organizing. This autonomy should arise from trust in the team by
management.
Just doing it shows how it works. If it works well, you gain support by management –
Respondent 3.2
Acceptance tests
Testing was not seen as a problem for any case. Some cases want to make the tests even more automated
as it saves time. However, testing was not perceived as beneficial only because of an Agile way of working.
Informal design; no big design upfront

It was seen that cases which have the same type of tasks each quarter, or had a deadline of the project
did design the project almost in full at the start of the project. Cases which had more uncertainty in the
need of the customer or how to translate this need into requirements, designed the project continuously.
The four cases which had uncertainty in the need of the customer are also the ones who mentioned the
need for flexibility as a motivation for choosing Agile.
85
Page
Results Agile practices
The cross-case analysis resulted in insight on the practices of Agile. It showed to what degree they are
applied in practice and what the effect of such practices are. These insights are illustrated in Table 15.
Table 15 - Results Agile practices
AGILE PRACTICE APPLIED IN PRACTICE EFFECT HOW TO INFLUENCE

Shared belief in Agile High for experienced Prevents resistance - Give teams freedom in designing
within the team teams, low for their way of working - - Convey
inexperienced teams why Agile can help them
- Hire experienced workers
Informal face-to-face By all cases -Quick communication Having stable teams
communication
Frequent By all cases but case 1.4 - Offers transparency Have the client be physically
communication with - Quick communication and attending events/meetings
customer decision making
Having a prioritized By all cases, mostly by - Train/coach the product owner
backlog common sense or - Hire an experienced and
vertical slicing by the dedicated product owner
product owner
Daily standup/scrum Mostly by the book - Offers transparency Create the feeling that asking
meetings and - Creates a responsibility to questions is good
Kanban/scrum board deliver
- Quick problem identification
- Enabled room for discussion
One defined Applied by 4 cases, 2 are - Gives something to hold on to; Pilot projects are required to write
process/way of working on it creates certainty such a method
working scrum across - Creates shared language; helps
organization aligning teams
Coaching/training of Every case except case 3 - Helps in creating a basic Hire coaches and set up training
Agile understanding; people know
why Agile can help them
- Coach gives directions and
support
Sprint review By 7 out of 10 cases - Creates transparency
- feedback is acquired often;
leading to quick problem solving
Sprint planning and By all cases but case 3
selection of work
Sprint duration 1, 2 or 3 weeks - Short sprints enables quick - Set duration depending on type
adaptation but makes it hard to of tasks
create value - Do not change duration during a
- Long sprints add value but can project
cause lack of focus
Whole By 8 out of 10 cases - Creates responsibility to - Make the team multi-disciplinary
multidisciplinary team deliver - Have stable teams
with one goal - Experience and knowledge is
spread
- Creates a team feeling and
sense of belonging
Acceptance tests By all cases - Leads to quick problem
identification
- Automated tests save time
Informal design; no Only by four cases which - Enabled flexibility in scope Only set up high level requirement
86
big design upfront had high uncertainty in at the start of the project
the need of the
Page
customer
6.3.3 Agile best practices
It was asked during the interviews, by means of an open question, which three Agile practices influence
success most. A frequency graph of these practices can be seen in Figure 25. It is found that the daily
standup meeting is mentioned most frequently as a best practice. Transparency is mentioned often as a
best practice and also as an effect of Agile which helps to reach success (as can be seen in Figure 23). As
mentioned before, the daily standup meeting helps teams being transparent. Therefore it can be said that
the two practices mentioned as most important are linked to being transparent.
Three linked practices are also often mentioned to be important: a multi-disciplinary, stable team with
ownership. These three practices are all based on the team. Other practices which are often mentioned
are the scrum board and a sprint planning which relate to estimation and monitoring.
It is noticeable that timeboxing is only mentioned once as an important practice which influences project
success. This practice is one of the main principles of Agile and is mentioned often in literature. Two effects
can explain this. First, time boxing may be so evidently inherent to Agile that respondents did not mention
this as important practice influencing success. Secondly, the practice being mentioned only once does not
say the practice is not important, it only says that all respondents except one found three practices more
important to influence success.
It is noticeable that frequent communication with the customer is only mentioned once as important
practice. This practice is in one of the main principles of the Agile manifesto. Two effects can explain this.
Firstly, technical employees tend to have an inward focus by nature, they mainly think of their own team
and tasks instead of the external stakeholders. Secondly, the practice being mentioned only once does
not say the practice is not important, it only says that all respondents except one found three practices
more important to influence success. During the interviews, respondent mentioned that customer
communication was beneficial as it offered transparency and helped in quick problem identification.
Therefore the benefits are seen in the best practice ‘transparency’ of Figure 25 and in the effect of Agile
‘quick problem identification’ in chapter 6.3.1.
Daily standup meeting

Scrum board
Team ownership
Transparency
Multi-disciplinary team
Stable team
Sprint planning
Maturity of transitional leaders
Sprint review
Leadership for change
Knowing why you choose Agile
Retrospective
Timeboxing
0 1 2 3 4 5 6
Frequency
Figure 25 - Frequency best practices

87
Page
To answer research question 4 and examine which of the Agile practices mentioned as most important
actually influence success most, a frequency graph of these practices is categorized by low, medium and
high success in Figure 26. The only case which is categorized as not being successful could not tell any
practice which is most important considering the fact that they just started working Agile for three
months. Therefore, low successful cases are not present in this figure. It Is seen that highly successful
cases mention only five different practices as most important. These are: daily standup meeting,
transparency, team ownership, sprint planning and stable team. It is noticeable that these five practices
are in the top 6 mentioned practices considered important. This means that the practices mentioned most
frequently as having an effect on success by all cases, actually are mostly mentioned by cases which have
high success. Therefore, these practices can be considered as best practices. Also, these practices are
linked to the top 6 mentioned reasons why Agile improves success, as seen in Figure 23.

Transparency
Team ownership
Scrum board
Sprint planning
Stable team
Timeboxing
Retrospective
Sprint review
0 1 2 3 4 5 6
low success Medium success High success
Figure 26 - Frequency best practices per success category
To answer research question 5, the influence of the case maturity on the best practices mentioned are
explored. A frequency of best practices mentioned per category of maturity can be seen in Figure 27. It
can be seen that the daily standup meeting is mentioned as best practice for all three categories of
maturity and is therefore said to be important for all maturities. Team ownership and transparency is only
mentioned in medium to high maturity cases. The scrum board is only mentioned in cases which have low
to medium maturity. Figure 27 shows that transparency and team ownership is mentioned by medium
to high mature teams. This indicated that these practices are more important when a team has grown
past the low mature category. It can also be seen that the scrum board is mentioned in the top 3 most
important practices by low to medium mature cases. This can suggest that the scrum board is important
when starting out with an Agile way of working and becomes less important, or other practices become
more important, when maturing.
88
Page
Transparency
Team ownership
Scrum board
Sprint planning
Stable team
Timeboxing
Retrospective
Sprint review
0 1 2 3 4 5 6
Low maturity Medium Maturity High maturity
Figure 27 - Frequency best practices per maturity category
89
Page
6.4 Organization and Agile
This sub-chapter starts off with identifying different effects of an Agile introduction when comparing a
top-down initiation to a bottom-up initiation of Agile in chapter 6.4.1. This is followed by describing the
effects of Agile on program and portfolio management in chapter 6.4.2. Next, the engagement of cases in
aligning with other teams are discussed in chapter 6.4.3. This chapter concludes with chapter 6.4.4 on
describing the necessary leadership roles within an organization.
6.4.1 Top-down or bottom-up

A frequently mentioned topic in the interviews is the one on the way Agile is initiated. In the cases, Agile
is initiated either by higher-management, team leaders or by the floor (lower-management). This will
further be mentioned as top-down, middle-management or bottom-up initiation. These ways of initiation
caused different effects.
Top-down initiation
In a top down initiation, management directs teams to start working Agile. This can be in the form of
higher management communicating to the full organization to start working Agile or middle-management
telling teams to start working Agile. This approach was seen to lead to resistance from the floor in many
cases, especially when employees have been working at the company for many years with the same way
of working.
Without a proper plan of rolling it out, this initiation leads to uncertainty for the employees. As mentioned
before, worker in technical companies do not favor uncertainty. Enforcing a new way of working without
them knowing how it will be organized will not be appreciated by all employees. It may not cause
resistance against Agile but more against change.
If you initiate Agile top down, you have less acceptation from the teams because
technical workers fear the unknown - Respondent 1.1
When Agile is initiated top-down, resistance of the employees is thus seen as a limiting factor. This
resistance is tried to be prevented or minimized in different ways. Most evidently in communicating why
Agile is needed to improve the process. This makes employees realize why a change is needed and
therefore support is created. A second way resistance is minimized is by training and coaching employees
on Agile. This makes them understand how Agile works, making them realize why the framework and way
of thinking can benefit their work. A third way resistance was seen to decrease is by having successful
pilots. This made them realize that Agile actually can benefit a way of working.
Showing that it works gives trust and ensures others to see that Agile works. –
Respondent 4.1
The positive side of this initiation is that when Agile is initiated organizational wide, the same type of
90
approach can be initiated across the organization. This ensures a shared definition (practice 6 of Table 7)
of Agile as it comes from one entity. Also, when Agile is initiated by higher management, it means that
Page
the organization supports Agile across the company. This can make it easier to align different teams and
departments and structuring the governance to fit an Agile way of working. Another positive side of this
type of initiation is that collaboration with other teams is not found to be problematic.
Bottom-up initiation
When Agile is initiated bottom-up, singular teams start working Agile on their own initiative. This can be
initiated by a team member or their team leader, categorized as lower-management. In this type of
initiation, resistance is minimized. Having full support of the team to become Agile can help maturing the
team fast.
Implementing bottom-up works best to mature as a team. You prevent resistance in

the ones who need to work Agile. This helps teams work well and thus pilots show
success. – Respondent 1.5
Although team maturity is increased more easily compared to the scenario of top-down initiation, it is
perceived that these teams reach a ceiling of maturity. Often, other teams are not joining an Agile
transition as they have not yet seen that it benefits the project. Collaboration and aligning with other
teams then becomes a problem. To break that ceiling, support of higher management is needed to further
mature. They can then inspire or oblige other teams to go Agile too.
Within one team, there’s a limit to maturing Agile. The mindset can only become fully
agile when the whole organization transforms to facilitate Agile teams. – Respondent
1.2
This phenomenon can explain why the cases which initiate Agile bottom up show lower maturity scores
than cases which initiated Agile top-down. Without support of higher management, teams cannot further
mature because the rest of the organization does not align with them in the same way of working. This
makes scaling hard to realize.
In short, it is perceived that support of both the employees and higher management is needed to become
highly mature. Without support of the employees, resistance arises from the people who need to work
Agile. Without support of higher management, alignment between other teams cannot be organized well.
6.4.2 Program and portfolio management

Four cases said that Agile affected their program and portfolio management. These effects were mainly
seen due to changes in team configuration as teams became stable. Stable teams are defined as having
fixed employees in one team for an infinite amount of time. This resulted in not having to switch people
around projects. Combined with the fact that these teams became multi-disciplinary, many types of
projects could be performed by such a fixed team. For program management, this meant that work could
be brought to fixed teams instead of bringing people to the work. This shifted the focus of program
management from resourcing on the level of the engineer to prioritizing projects.
91
Besides this, it was mentioned that Agile resulted in the costs being more predictable per unit of time.
Page
However, it was said that planning became harder since teams went Agile. The reason for this is that it is
unsure when a certain amount of work is delivered due to the flexible nature of such teams and the fact
that scope is flexible too. Therefore, the cost per unit of time were predictable, but the total costs for a
certain amount of work was said not to be accurate.
It was said that this predictability could be improved when effort estimation for the full project
and the velocity of the teams are precise. No case said that this was already precise. It was mentioned
that it takes time and experience for this effort estimation and velocity monitoring to be precise. A
requirement for this estimation of effort and velocity is that the teams are actually stable for the long run.
An effect was also seen in reporting from the teams to management. Seven cases mentioned reporting
was still done in the traditional way by setting up reports regularly and sending it to management. Three
cases mentioned they report differently. These three cases said they flipped reporting. Now, management
either walks by the teams to check progress on the scrum board and asking the team questions directly
or he can check progress digitally by means of software such as Jira. An upside of this new way of reporting
is said to be that management can check progress real time. Teams said not to write monthly reports, this
time is now used for documenting in Jira. This new way of reporting was said to only be able when
management has an Agile mindset.
6.4.3 Alignment with other teams

Two cases observed problems with aligning to other teams which were not working Agile. One respondent
said that problems occur in planning. Their team is unable to plan for longer than three months ahead
while other teams plan for 5 years ahead. This makes long-term planning for teams which are dependent
on their team more difficult. Another respondent saw problems in rhythm. In their team, they need to
deliver in two weeks which sets a lot of pressure on the work while in non-Agile teams this pressure is not
present even though their team might need something from them. He said this could be solved by adding
someone from the traditional team in the sprint planning of the Agile team.
The other eight cases did not see any problems in aligning with other teams or solved these problems. It
was said alignment problems can be prevented by openly telling you work Agile and by communicating
who needs what when. Another respondent mentioned these problems were solved by introducing
alignment meetings which are called Planning Increments in SAFe. Other cases mentioned that this
alignment is not needed as long as a product is delivered. It was said that delivering is the goal so the
dependent team does not care whether it is created in an Agile or traditional method. Therefore the need
for alignment differs per type of project.
6.4.4 Leadership roles

Project manager
There are two ways to deal with the project manager role. Firstly, the project manager’s role changes.
Secondly, the project manager disappears.
Some cases still have project managers, but the role has changed. It changed from leading the project to
making sure the team is aligned with other teams. His role is more facilitating and supportive, they call it
interactive leadership. The project manager is then of use to get rid of impediments so that the team can
do what it needs to do. Besides that, another role which is said to be left to the project manager is a
visionary role. In this role, he sets the direction for the team. He is said to define the ‘what’ rather than
92
the ‘how’. The choice (how) for the method is left to the team to decide. Giving freedom to the team is
said to be very important.
Page
It was often seen that when a case got rid of project managers, the leadership role is taken over by the
product owner. He is said to focus on guiding the teams into the right direction. This should be done based
on the needs of the client. This leadership role is said to be more about giving freedom to the team and
sending them off in the right direction than by telling them what to do.
In an ideal Agile world there is no project manager – Respondent 6.1
Product owner and scrum master

Dedicated and experienced scrum masters and product owners are said to be essential. It was said to be
essential because a good scrum master can facilitate the daily scrum meetings, reviews and retrospectives
to ensure good communication, ensure problems come up right away, and to ensure improvements of
the process. A good product owner is said to be needed to ensure the team has the right priorities to set
the team into the right direction in order to meet client’s needs.
It was mentioned by respondent 6.1 that the roles of a product owner and scrum master need to be
performed full time. This means that a product owner or scrum master cannot have another role too. So
developers in a team cannot have the role or product owner or scrum master.
The leadership role in terms of setting the right priorities and helping the team in the right directions was
said to be taken over by the product owner. Again, it is important to state that it is left free to the team
how to reach the goal. However, it was seen that not all product owners have this leadership
characteristics by nature. Some focus on content and some focus on leading the team. It was said that
product owners who have a leadership role in the teams focus on guiding teams into a direction. It is good
to have knowledge and experience on the content in order to be able to give the right direction. It was
therefore advised to either train them extensively or hire experience from outside.
The same accounts for scrum masters. It is advised to have experienced scrum masters on board. They
can design the Agile way of working which suits for the team. Also, his experience and knowledge will be
spread throughout the team since they work together on a daily basis.
Transformational leadership
Another role which is mentioned to be performed by the leading person is a transformational role. This
could be the project manager, product owner, scrum master or Agile coach. In this role, the leader is said
to lead the Agile transformation. He should make sure everyone understands why Agile is being chosen
as a way of working to both the teams and management. Besides that, he should stress that, and why,
Agile is working for them. This role therefore has an impact on the transition to Agile mindsets for team
members and higher management. Team will be understanding why they work like they do, and higher
management will be convinced that Agile is a way of working for teams that leads to successes. This role
is mostly seen and most important for low to medium mature teams. When the required Agile maturity
of the team has been reached, the transformational role can be used to embed Agile in the organization.
If that has been accomplished, a transformational leadership role is not necessary anymore.
93
Page
6.5 Towards the conclusion
This chapter has established answers to the last three sub research questions of this research, on the best
practices of Agile, the influence of the maturity on these best practices and how Agile can be embedded
in an organization. The conclusions are presented in chapter 8.1 Before the actual conclusions are made,
the findings of the research are linked to literature in chapter 7.1 and limitations of this research are
mentioned in chapter 7.2 which are to keep in mind when stating conclusions.
94
Page
7. Discussion
Chapter 5 Chapter 7
Results case study
This chapter will discuss the outcomes of this research. Chapter 7.1 will discuss the findings per theme
and a link will be made to literature. Chapter 7.2 discusses the limitations of the research.
7.1 Discussing the findings

Several themes emerged in the findings of this research. The themes are: team configuration,
transparency, roles, management support and the characteristics of technical employees. These themes
will be elaborated on and findings will be linked to existing research.
7.1.1 Team configuration

The analysis of the cases found that practices on teams are mentioned
Important practices: frequently as having influence on success. Team ownership is important
• Team ownership
• Stable team to make teams self-organizing and improve teamwork. Having team
• Multi-disciplinary team ownership makes team members feel as if the team is working on the
project instead of individuals working on parts of the project. This brings
responsibility and therefore the incentive to successfully complete the project. The team being stable is a
requirement to be able for the team to become empowered. Having stable teams also creates a team
feeling which is said to bring more fun in the work for employees. Also, it changes the way program
management works (as read in chapter 6.4.2). Multi-disciplinary teams enable the taking over of tasks
when needed so that work does not stop when a person falls out. It is also said to be beneficial because
experience and knowledge is spread within the team.
Although teamwork quality is said to influence success of teams, the effect is only marginally greater in
Agile than in traditional teams (Lindsjorn & Sjoberg, 2016). Teamwork quality is said to improve when the
team becomes empowered. Higher management showing trust to teams is said to lead to increased
autonomy and accountability of teams (Kirkman & Rosen, 2000). “In addition to giving teams more
freedom and discretion, team members must believe in their team's capabilities, find meaning in their
team's tasks, and fully realize the impact that their team's work has on customers if they are to become
truly high-performance - empowered teams” (Kirkman & Rosen, 2000).
Teams becoming empowered also show negative effects. McAvoy & Butler (2009) state that “empowered,
cohesive teams can exhibit problems such as groupthink or the Abilene Paradox”. The use of a devil’s
advocate is mentioned to solve these problems (McAvoy & butler, 2007).
95
Page
7.1.2 Transparency
This study found that transparency is the most frequently mentioned
Important practices: effect of Agile which contributes to improvement of success.
Transparency is both seen in the form of progress and problems.
• Scrum board
• (informal) Communication Progress and problems are transparent for the team due to the scrum
(with customer) board and daily standup meetings. Transparency is offered to the client
• Sprint review
by means of the frequent (informal) communication with the client and
the sprint review. This transparency is found to lead to earlier
adaptation of scope when needed and quicker problem identification and solving.
A study of 1000 respondents by Laanti, Salo, & Abrahamsson (2011) supports the fact that transparency
is providing improvement. Fry & Greene (2007) state that “transparency is key to success and that sharing
information with everyone is critical in the ability to adapt on a daily basis and to ensure success”.
However, Conboy, Coyle, Wang, & Pikkarainen (2010) saw that 17 out of 17 cases studied showed that
transparency brings fear by at least one developer because their progress and skills become transparent.
The study recommends several solutions of which pair programming is one. This eliminates transparency
of skill weaknesses while transparency of progress and problems remains.
7.1.3 Roles
The findings of this research on leadership and changing roles show
Important practices:
• Changing project manager role that the project management role changes from focusing on what the
• Leadership role team needs to do to making sure the team can do what the team
• Product owner role thinks is needed to be done. This shows a changing role from a
• Scrum master role
directive one to a facilitating role.
This is in line with Turner & Muller (2010). They mention that in an Agile environment, the project manager
is transformed into a project leader which focusses on guiding in the right direction, motivating, coaching
and facilitating instead of having the responsibility for the project, executing, controlling, planning etc.
The roles for a project manager as mentioned by Turner and Muller (2010) are taken over by the team in
an Agile environment.
Verbruggen (2017) mentions that the change from managing to leading is not only the case for an Agile
environment and is also true for traditional projects. She adds that project managers require the need to
be Agile and require having an Agile view on the role of the project manager. It is all about being an Agile
leader and having an Agile mindset. This adds to the fact that a shared belief in Agile and support from
management is required.
This research agrees with the mentioned need for a change in leadership by Verbruggen (2017).
Nonetheless, it adds that having the Agile mindset is necessary across all levels of hierarchy and not only
for a project manager. Nye (2013) mentions differences between two types of leaders: transactional and
transformational. The first has modest goals and realizes them by small steps. The latter has a visions
which is realized by big changes. Especially in the role of a transformational leader, those who have
experience and knowledge on Agile are expected to take up this leadership role. They are the ones who
can make sure that every hierarchical level can acquire an Agile mindset. The study of (Yukl, 2010) says:
96
“Introducing Agile methods like Scrum takes time, because it requires the whole organization to change.
Page
It requires transformational leadership”. This is supported by the more recent study of van Kelle, van der
Wijst, & Plaat (2015) which mentions transformational leadership as a factor that determines success of
Agile projects.
Even more, this research questions the need for a project manager when experienced and dedicated
product owners and scrum masters are present. In an Agile environment, teams can organize themselves
and thus they can decide what tasks need to be performed to reach a certain goal. The product owner is
seen to take up the role of prioritizing tasks and is thus steering the team in the right direction when
necessary. The scrum master is taking up the role of facilitating events, coaching and motivating.
7.1.4 Management support

This research found that management support is essential for teams to
Important practices: reach high maturity. Without support of higher management, alignment
• Successful pilots
between other teams cannot be organized well. It was found that
• (transformational)
Leadership showing successful pilots and having (transformational) leadership roles
help in gaining management support.
With management supporting Agile come several implications. Higher management can obtain an Agile
mindset, they will show trust in Agile teams which is required for the teams to become empowered and
they can write a shared Agile method for the department or organization.
The study of Sidky & Bohner (2007) shares this finding by mentioning that it is impossible for a team to
become highly Agile when the company culture does not support Agile. This is stressed by a study of
Cockburn & Highsmith (2001) which mentions that executive management support is essential when
transitioning an organizational process. Fry & Greene (2007) add to this that “executive commitment is
crucial in implementing Agile. Without executive support, transitions might fail.”
Corman & Bohner (2005) said that gaining management support is more challenging for an Agile transition
as “Agile methods represent a major cultural change for them.”. Showing how Agile realizes better results
is the key way to convince management.
7.1.5 Characteristics of technical employees

Focusing on high-tech companies, the characteristics of technical employees have been mentioned as
having an influence on the Agile way of working in practice. It is mentioned in chapter 6.3.2 that technical
employees favor structure and certainty and have an inward focus, disregarding the external
stakeholders.
Engineers tend to have a project-based mindset in which clarity and focus are important (de Bruijn, ten
Heuvelhof, & in 't Veld, 2010). Several characteristics of technical workers were mentioned by (Seviour,
2018). Engineers want order and structure at work and in their personal life, engineers dislike change and
engineers attach to structure. In line with this reasoning, Thamhain (1983) mentions several needs
expressed by technical engineers including minimizing changes and having clear goals, role definition and
control. When change is necessary, engineers favor clear communication of the changes. They mentioned
that most of their conflicts are over ambiguities regarding the way of working.
97
This research found that following the Agile principles fully and having a shared instruction across a
department or organization can help fulfilling these needs of technical engineers. Starting out with
Page
following the Agile framework fully can help in giving something to hold on to. Also having a shared
instruction on an Agile way of working across a department or an organization can help bring structure
and certainty in the way of working and making changes clear.
As engineers are experts on content, they tend to focus on their internal tasks (Rottmann, Sacks, & Reeve,
2015). This disregards the focus on external factors such as leading and communicating with stakeholders
(Reeve, Sacks, Rottmann, Daniels, & Wray, 2013). This might explain why the practice ‘frequent
communication with customer’ is not mentioned often as an important practice in the interviews while
being an important principle of the Agile manifesto.
98
Page
7.2 Discussing the limitations
“Case studies are generalizable to theoretical propositions and not to populations or universes” (Yin,
2018). This means that the conclusion of this research cannot say that every organization in the high-tech
sector should perform the best practices of Agile found in this research. The conclusion explores the best
practices in the cases covered which might help gaining scientific and practical knowledge on the matter
and gaining insight in the best practices of Agile. These conclusions show what practices and effects of
Agile are promising in increasing success. Future research must examine whether these exploratory
findings are true for large populations by means of a quantitative approach.
7.2.1 Interviews
15 interviews are held to retrieve results. A higher number of interviews would improve the
generalizability of the findings. The five interviews conducted at the internship organization give a good
overview of the current state of Agile within the company. The five different cases at that organization
were in good balance with the five cases of other companies. However, given time limitations of this
research only one interview was conducted for each case within the internship organization.
7.2.2 Analysis
It was found that the interviewed cases had different characteristics such as the sector, type of initiation,
the months since initiation, etc. Some analyses were held to see whether a certain characteristic had an
influence on certain aspects of success or maturity. Because only 10 cases were used in the research, each
characteristic was represented by only a few cases. The influence of these characteristics can hardly be
significant because of this. This is another reason why more cases would be beneficial.
Even if significant differences or influences were found, it was not factored to other influences. An
example is when it was analyzed whether the duration of sprints had an influence on maturity and success.
Even if differences were seen, it could well be that the highly mature cases had all initiated Agile longer
ago and that it is a coincidence that these cases all have a certain duration of sprints.
The duration since introducing Agile are not exact numbers. During the interview, it was asked when their
team started working Agile. Some respondents could answer very precise and others gave answers such
as “mid 2018”. The months until juli 2019 were counted. The example of mid 2018 would have resulted
in 12 months. Asking for a more precise date would result in more accurate results.
7.2.3 Maturity and success scores

Even though measures were taken to improve validity of the Comparativeagility survey, filling in such a
survey is subjective. Differences were seen between the survey results of two respondents from the same
project. Averaging this comes closer to the actual score. However, having this survey filled in by even more
members of the project would improve the validity of the score.
All limitations mentioned in this chapter are to be held into account when further research will be
practiced on this subject. Other recommendations for further research can be read in chapter 8.2.1.
99
Page
8. Closure
Chapter 5 Chapter 7
Results case study
This chapter will give answers to the research questions in chapter 8.1. Based on these conclusions,
recommendations will be given in chapter 8.2 to make Agile work on team level and to embed Agile in an
organization. Next, recommendations for future research will be given to further validate the
recommendations made in this thesis. This chapter will close off with a personal reflection of this research.
Chapter 8.4 closes off with a personal reflection on this research.
8.1 Conclusion
This conclusion gives an answer to the research questions. Firstly, the six sub research questions will be
answered. Secondly, the answer to the main research questions is formed by combining the answers to
the sub research questions.
Project success in an Agile environment

SQ1: How can project success be measured in an Agile environment?
A distinction between success of the final product and success of the process is made. In an Agile
environment, process success plays an important role since value is created frequently and not only at
the end of a project. Compared to traditional project success, value and satisfaction play a more central
role in Agile. Added to that, value is represented differently in Agile as it is added continuously.
Combining the success elements found in literature gives a synthesis of success in an Agile environment.
The process part of success is divided into team satisfaction and Agile implementation. From exploring
the literature on success can be concluded that project success criteria in an Agile environment are not
much different compared to a traditional environment. However, more weight is given to quality of the
product and value for the customer than to cost, scope and schedule. Therefore, the success of projects
in this research will be reported on the criteria as seen in the right column of Figure 28.
These success criteria are found to be covered in the last questions of the survey of Comparativeagility,
as shown by the orange arrows in Figure 28. These questions ask to which degree success has been
improved since the Agile introduction. Improvement of success of the cases in this research is therefore
100
Page
Critical variables
Progress tracking
Sources of dates and estimates
When do we plan
Test-driven development
Pair programming
Refactoring
Continuous integration
measured by means ofstandards
Coding the Comparativeagility survey. Survey data of cases therefore showed whether
Collective code ownership
Agile caused an improvement or decrease in success.
Automated testing
Customer acceptance testing
Timing SUCCESS CRITERIA FROM LITERATURE
Management style Project team satisfaction
Responses to stress Motivation
Customer involvement Agile implementation !
Title and salary alignment Improvements on Agile way of working
Infrastructure Project constraints (Organizational satisfaction)
People Cost
Reflection Scope
SUCCESS DIMENSIONS COMPARATIVEAGILITY
Timeboxes Schedule
Team learning Quality
Improved quality delivered by team Adaptable product
Improved customer satisfactions Reliable product
Improved team morale Value (Customer satisfaction)
Improved business economic value Continuous flow of value to customer
Delivering more quickly and more often Releasable product
Figure 28 - Comparison success literature and Comparativeagility
Elements covering Agile

SQ2: Which Agile elements cover the Agile framework?
Executing a literature review resulted in a list of most mentioned practices of Agile, specifically the scrum
method. This list was categorized by the corresponding values and principles of the Agile manifesto. This
table merely sums up the practices listed in theory. To create a list of practices which cover Agile, the
table was refined. Some practices from this list were a sub-level of already mentioned practices. These
were deleted from the list as they are too detailed. Exploratory interviews found that several Agile
practices were missing. ‘a shared belief in Agile’, ‘coaching and training’ and ‘defined process/way of
working scrum’ were found to be essential to cover Agile. This list was than validated by two Agile experts
from a high-tech company, this resulted in scrapping several practices.
The final list of practices which cover Agile is illustrated in Table 16. These practices cover all four values
of the Agile manifesto (Appendix A). The list also covers all principles mentioned in the Agile manifesto
except the fourth principle ‘Business people and developers must work together daily throughout the
project’. The fourth principle is partly covered by the practice ‘multi-disciplinary teams’ and fully by the
practice ‘scrum of scrums’.
Table 16 - List of practices fully covering Agile
PRACTICE PRINCIPLE VALUE

1 Shared belief in Agile within the team Motivated individuals (5) Individuals and interaction
2 Informal face-to-face communication Face-to-face Individuals and interaction
communication (6)
3 Frequent communication with Satisfy customer (1) Customer collaboration
customer
4 Having a prioritized backlog Frequent delivery (3) Responding to change
5 Daily (standup/scrum) meetings and Motivated individuals (5) Individuals and interaction
Kanban/Scrum board & Self-organizing teams
(11)
6 One defined process/way of working Continuous attention to Responding to change
scrum across organization technical excellence and
good design (9)
101
7 Coaching of Agile Motivated individuals (5) Individuals and interaction

8 Sprint review Reflection (12) Individuals and interaction
9 Sprint planning and selection of work Welcome changing Responding to change
Page
requirements (2)
10 Time-boxed sprints Frequent delivery (3) Responding to change
11 Whole multidisciplinary team with Self-organizing teams (11) Individuals and interaction
one goal and division of roles
12 Acceptance tests Working software (7) Working software
13 Informal design; no big design upfront Simplicity (10) Responding to change
Measuring the Agile maturity level

SQ3: How can the Agile maturity level of a project team be measured?
Several different literature and measurement models have been reviewed. A survey by Comparativeagility
is found to be of best use for this research to measure the Agile maturity of the cases. The reason for this
is that it gives objective results and the data is easy to use and analyze. statistical tests performed in
literature concluded that Comparativeagility portrays agility in teams and organizations better than in the
other surveys reviewed (Jalali, Wohlin, & Angelis, 2014).
The questions from the survey are compared to the list of practices which cover Agile. An overlap between
literature and the survey is evident for most of the practices. It can be said that the survey and its scientific
validation of Comparativeagility is for the most part supported by different scientific articles on that
subject. However, there are also practices found in literature which are not covered in the survey. The
practices ‘frequent communication with customer’ and ‘defined process/way of working scrum’ have
been covered in the interview to obtain a full overview of the Agile situation of the cases.
Agile best practices

SQ4: What are the best practices of Agile project management?
It was seen that cases which improved success most mention only five different practices as most
important. These practices are:
• Transparency
• Team ownership
• Sprint planning
• Stable team
It is noticeable that these five practices are in the top 6 mentioned practices by the respondents when
asked which three Agile practices influence success most. This means that the practices mentioned most
frequently as having an effect on success by all cases, actually are mostly mentioned by cases which have
high success. This research showed that these 5 practices are considered to be the important practices of
Agile.
The practice of using the Scrum board is mentioned in the top 5 by the respondents when asked which
three Agile practice influences success most. It is noticeable that this practice is only mentioned by
respondents from medium successful cases. This practice is therefore found to be important to improve
success but it is not recognized as the most important practice.
Of the above-mentioned important practices, three stand out. Daily standup meeting, transparency and
102
team ownership are most frequently mentioned as important practice to increase success by the cases
which were highly successful. This indicates that these practices have the biggest influence on increasing
success and are thus regarded as best practices.
Page
It is found that the daily standup meeting is mentioned most frequently as a best practice. Transparency
is mentioned often as a best practice and also as an effect of Agile which helps to reach success. The daily
standup meeting helps teams being transparent. Therefore it can be said that the two practices
mentioned as most important are linked to being transparent.
Having a stable multidisciplinary team results, besides having all required functions in one team, in a
feeling that a team is working on the project instead of people working on small tasks. This caused the full
team being responsible for the project. Making the team autonomous enhances the feeling that the
project is their project. This brings along the responsibility of delivering and is said to ultimately make the
team self-organizing. This autonomy should arise from trust in the team by management.
It is noticeable that frequent communication with the customer is only mentioned once by the
interviewees as an important practice which influences project success. This practice is one of the main
principles of Agile and is mentioned often in literature. The practice being mentioned only once does not
say the practices is not important, it only says that all respondents except one found three practices more
important to influence success. The assumption can be made that frequent communication with the
customer is not mentioned often as important because technical employees tend to have an inward focus
by nature, they mainly think of their own team and tasks instead of the external stakeholders. This means
that high-tech companies should keep this in mind and try to make technical employees better aware of
the importance of customer involvement.
Influence of the Agile maturity level

SQ5: How does the Agile maturity level of a project team influence the importance of the Agile best
practices?
‘Culture’ and ‘knowledge creating’ are dimensions of Agile maturity which influence the maturity level
most. It is also seen that culture scores much higher for cases which have initiated Agile longer ago. This
indicated that it takes time to fully implement an Agile culture. This is supported by the quantitative
analysis in Chapter 6.1.3 which shows that Agile maturity scores increase over time.
It might not be necessary for all types of projects to reach a high maturity level, as high improvements on
success are also occurring in medium mature cases. It is also seen that low mature cases do not show a
decrease in success.
Considering the influence of the Agile maturity level on the importance of best practices, it is seen that
the daily standup meeting is mentioned as best practice for all three categories of maturity and is
therefore said to be important for all maturities. Sprint planning is mentioned in low and high mature
cases. Team ownership, transparency and stable teams are only mentioned in medium to high maturity
cases. This suggests that these three practices play a more important role in higher mature teams. The
scrum board is only mentioned in cases which have low to medium maturity. This suggests that this
practice plays a more important role in lower mature teams. However, it is not mentioned by highly
successful cases. For this reason, this practice is not mentioned as best practices.
103
Page
Implementing Agile in an organization
SQ6: How can an Agile project management approach be embedded on organizational level?
Differences in the effect of an Agile initiation were found in cases which are initiated top-down and
bottom-up. It was found that support of both the teams and management is required in order to further
mature. It was found in the interviews that when support of the team lacks, a team will not reach a
threshold level of maturity to see the benefits of Agile. When support of management lacks, a team cannot
further mature as alignment with other teams are harder to realize. Creating management support can
be done by showing successful pilots. This will help higher management realize that Agile can work.
Alignment with other teams is mentioned to be important to embed Agile on an organizational level. It
was found that several ways exist to solve or prevent problems in alignment. The first way is to openly tell
you work Agile and by communicating who needs what when. Another way is to introducing planning
increments to align different teams.
5 respondents mentioned that starting off with following one method also reduces uncertainty for the
teams and helps them speak one language which can help prevent any resistance from occurring. At least
the roles and meetings should be defined so that everyone has the same idea for these things. A method
should however not be very detailed because every department and every project requires a different
approach. A framework is required to give a broad direction into Agile, projects should still be able to
choose from that framework or give a little twist to it. This is important because leaving freedom of
choosing a method to the team minimizes resistance and makes sure the method fits the team and their
tasks.
Finally, the analysis of the interviews showed that the transformational leadership trait within project
managers, product owners, scrum masters and Agile coaches help to embed Agile in an organization. This
is supported by literature in chapter 7.1. Having this type of leaders can help teams and management
understand that and why Agile works so that support is created. Team will be understanding why they
work like they do, and higher management will be convinced that Agile is a way of working for teams that
leads to successes.
How Agile can help successfully completing projects

MQ: How can Agile project management elements help to successfully complete Dutch complex
projects in the high-tech sector?
It is found that each practice which covers Agile has a different effect in different contexts. Therefore,
there is not one way how to practice Agile to help successfully complete project. However, chapter 6.3.2
presents findings on these practices which should be kept in mind when practicing Agile of which Table
15 present an overview. The Agile practices which are mentioned to have influenced success most are
seen in the answer to sub question 4. Following the guidelines presented in chapter 8.2.2 can help in
making Agile help successfully completing Dutch complex projects in the high-tech sector.
On average, the introduction of Agile causes an increase of success. Team morale shows the highest
average improvement. Usability customer satisfaction and economic value showed lowest average
104
improvement. However, the box plots in Figure 29 shows that usability customer satisfaction ranges from
3.00 to 4.00 meaning that it improves success in any case.
Page
The box plots of Figure 29 shows that economic value improved for all cases while the error bar ranges
from an increase to a decrease. The error bar of the dimension quick and often delivery shows a high
variability ranging from an extreme increase to a decrease of success. This tells it is unsure whether Agile
causes an increase in success on these dimensions. All other success dimensions show box plots indicating
improvement in any case. So it can be concluded that Agile can certainly help to successfully complete
complex projects on all dimensions except quick and often delivery and economic value.
Figure 29 - box plot success scores per dimension (ranked by averages)
9 out of 10 cases have shown improvements in success since their Agile introduction. The other case did
not see any decrease in success. This research therefore concludes that Agile is promising in helping to
successfully complete Dutch complex projects in the high-tech sector.
105
Page
8.2 Recommendations
This section makes recommendations for further research (chapter 8.2.1) as well as practical
recommendations (chapter 8.2.2).
8.2.1 Future research

This research has some limitations as mentioned in chapter 7.2. Future research brings the opportunity
to build on the findings of this exploratory research. In short, it is advised to tackle the subject of Agile
best practices quantitively with a high number of respondents. Secondly, it is advised to do more research
on the factors which influence these best practices. Recommendations for further research are discussed
in this sub-chapter.
Quantitative analysis
Execute a quantitative research method to improve reliability. The qualitative approach of this research
by means on interviews provided a good method to explore the themes which influence best practices of
Agile. However, generalizability can be improved by executing a quantitative analysis. Such a research can
make use of more respondents and more variables can be examined. Also, maturity of a team can be
measured more precisely when filled in by the full team instead of one or two team members. It is possible
that developers have different views on the maturity than product owners, scrum masters or Agile
coaches. In short, more respondents are needed to get to more significant findings and to be able to
generalize for a larger population. During such a quantitative research, it is advised to ask for a precise
month in which teams were starting to work Agile. This can verify the finding of this research that it takes
time to mature and can test the suggestion that a maximum maturity level is not required for the highest
improvement in success.
Use success figures from practice

Measure improvement on success more concrete and precise by comparing actual quantitatively
measured figures in the time before and after introducing Agile. A requirement for this is that projects
should have a functioning measurement system. This research could not make use of this because the
studies companies did not have these measurement systems in place.
Agile practices
Examine which practices are to be implemented first when starting out with Agile and what factors
influence this configuration. It was found that almost every team starts out with at least a daily standup.
However, it was found that using only a daily standup meeting from the Agile practices was not successful.
It was also mentioned by a case that starting off with too many practices leads to confusion and resistance.
This research found the best fitting maturity level for only 6 practices. It should therefore be attempted
to find a more extensive framework of practices when starting out with Agile. This framework can be
found by an extensive quantitative research in which projects with different maturities state the use and
effectiveness of Agile practices.
Group dynamics
106
Study the role of group dynamics in the teamwork quality of teams which start off with Agile. It is seen
that social and teamwork factors have an impact on the success of teams. Tuckman (1965) mentions that
when teams are formed, they go through certain stages which influence the productivity of the team. It
Page
should therefore be argued whether group dynamics have an influence on the effect of Agile, especially
for low mature teams since they typically have started out with Agile recently.
Agile teams have no direct team leader as the team leads itself. This implies that there is no one to
influence the team dynamics. It should be examined whether this is true and if so, how can these
influences be used for the best? Also, it is to be examined whether the low improvement on success is
due to a low Agile maturity level or because the team has recently been formed and are still in early stages
of group dynamics.
Creating management support

Describe how management support can be created. This research found that management support is
required for Agile to be embedded in an organization. It only found that by having transformational
leadership roles and by showing successful pilots, this support is created. It is argued that it is likely that
more factors influence the support of management, this is therefore to be described in a further study.
Defining an organizational method

Develop a standardized outline of a method which can be used throughout an organization as it is found
to help in aligning teams within an organization. This thesis found that this framework should include the
elements which are to be focused on such as the Agile events, practices, roles etc. To be clear, the method
should not state how these elements should be practiced but rather show guidelines or alternatives to
choose from. The team should have the freedom to decide for themselves how to practice the elements.
It is advised to start with an exploratory research on this topic and from that research continue to further
detail such a method.
107
Page
8.2.2 Recommendations for practice
The findings of this research have been translated into recommendations to make use of Agile in order to
improve success in practice. The recommendations are categorized into three different stages: initiating
Agile, maturing Agile and Scaling Agile. A summary of practical recommendations can be seen in Figure
30.
Initiating Agile
Maturing Agile
Embedding Agile
•Just do it •Have everyone •Have a shared process on
understand the basics Agile within a
•100% framework department or an
•Have dedicated and organization
•One team at the time experienced scrum
masters and product •(transformational)
•Convey why Agile works owners on board Leadership roles
•Create team ownership •Share successes and

lessons learnt
•Take the time
•Argue whether to strive

for maximum maturity
Figure 30 - Overview recommendations
The recommendations are derived from the cross-case analysis. The first column of Figure 30 is applicable
to teams which have just started out with Agile or low mature Agile teams. The second column is for teams
who want to further mature to a higher level. The third column are recommendations to make scaling
possible throughout a department or organization as it helps creating management support and
alignment between teams. The bullets in the overview of practical recommendations are discussed next.
When initiating Agile

The following implications play a role when teams want to start working in an Agile way. First
of all, a decision has to be made whether Agile fits the type of project. Observed
improvements caused by an Agile way of working cannot be generalized for all projects. The
one in charge of choosing the governance should therefore think whether the project and the
team fits an Agile way of working.
Just do it
No change will occur without doing anything. It is therefore advised, if believed that Agile fits the team
and project, to just start introducing Agile. When a transition has started, the pitfalls will be seen and the
way of working can be adapted. Trial and error is seen to be the only way to improve the process.
Follow the framework fully

It is advised to introduce Agile gradually, practice per practice. However, the framework is to be followed
fully, cherry-picking should be prevented. Cherry-picking diminishes the framework and theory behind
108
Agile. So the Agile mindset should be fully implemented. How far to go with the method and practices is
for the project to decide and should be adapted to the type of project and team. It is advised to see how
Page
the practice works for the team, and then decide whether to continue or stop that practice.
One team at a time
When multiple teams are to be transitioned to an Agile way of working, it is advised to start one team at
a time. As a transition brings along uncertainty for the employees, it is recommended to minimize any
extra uncertainty when possible. When implementing Agile in many teams at once, uncertainty can be
created. This is especially not favored in technical companies as technical workers disfavor uncertainty.
Also prepare employees for a change when this is possible. As technical workers do not favor change, it is
advised to let them know as soon as possible when changes occur.
Convey why Agile works

Every person who is working Agile should know why the Agile way of working is improving the process, as
mentioned in chapter 6.3.2. This will prevent any resistance against the way of working and the transition.
Conveying why Agile works for the team can be done by informative sessions on Agile. The effect is
strengthened when this type of session is performed by higher management as the need becomes more
clear. A dedicated and experienced scrum master is found to be essential to convey this message. When
multiple teams are being introduced to Agile, it is advised to hire an experienced scrum coach which can
design the right Agile way of working from the start and convey why this should fit the teams.
When maturing Agile

The following implications play a role when Agile has been introduced but the process has not
yet been embedded completely in the teams.
Have everyone understand the basics

It was found in the cross-case analysis that resistance against Agile usually does not occur when the team
has Agile experience. Therefore, everyone should understand the values and principles of the Agile
manifesto. This lays a base for gaining the Agile mindset. When this is understood, events and practices
should be clear so that team members know what to do and why this is done. Especially gaining insight in
the relation between the events and practices is essential in gaining an Agile mindset.
Training and exams can help in gaining this knowledge. Scrum masters and Agile coaches should help team
members in having everyone understand the basics too.
When Agile teams are dependent on other Agile teams or vice versa, it will help when they all have had
the same Agile training. This will make sure that everyone speaks the same Agile language so that no
misunderstandings take place.
Basic Agile training is preferred to also be given to non-Agile teams when they are dependent on Agile
teams or vice-versa. This will help in alignment of these teams as the non-Agile teams will understand why
a rhythm is so important in Agile teams.
Have dedicated and experienced scrum masters and product owners on board
In an Agile way of working, teams should manage themselves. The leadership roles are therefore to be
109
changed. Project managers are not necessary for having teams do their job as they can organize
themselves. However, when the decision is made to keep project managers, their role should shift
towards a facilitating and supportive role towards a team and a transformational role to enable Agile
Page
maturing within the department (see chapter 6.4.4).

A leadership role is also seen in the role of the product owner. The product owner should make sure that
tasks are prioritized based on the need of the client. He therefore sets the team in the right direction and
steers when needed. It is important to note that the product owner does not decide how the team makes
sure the tasks are performed, only what tasks have priority.
The scrum master can be said to have a leadership role in terms of the Agile process. He is the one who
facilitates the events and practices. Together with a possible Agile coach, he should make sure the team
matures Agile wise up to the required level.
It is advised to have these roles being performed full-time. One person should not have multiple roles.
The abovementioned roles are essential to be experienced as they are the ones who should convey the
knowledge to the rest of the teams. It is therefore advised to hire experienced product owners and scrum
masters or train them extensively.
Create team ownership

Stable multi-disciplinary teams are a requirement for having an Agile way of working. This brings the
opportunity for them to operate as a team and create a team feeling. it makes them feel they are working
as a team on the project instead of working individually on parts of a project. Having the team feel that
the project is theirs brings responsibility and the incentive for them to successfully complete the project.
This feeling is to be amplified by having the team be present at the start of the project and letting the
team decide on the design.
Making the team autonomous enhances the feeling that the project is their project. This brings along the
responsibility of delivering and is said to ultimately make the team self-organizing. This autonomy can
arise by management showing trust in the teams. It is advised to work on creating management support
for Agile in order for them to show trust in Agile teams.
It is advised to set a role of a devil’s advocate to prevent problems such as groupthink and the Abilene
paradox.
Take the time

A required Agile maturity level cannot be reached right away. A transition takes time. Failures will most
probably take place. However, it is seen that those teams who have initiated Agile longer ago have a
higher Agile maturity level. Therefore, teams should take the time to mature.
Argue whether to strive for maximum maturity

Teams should argue which maturity level is required to obtain most improvements on success. Don’t over
invest resources if it does not weigh up to the benefits. The required maturity level will differ per project.
it is seen that medium and high mature cases have about the same improvements in success. Low mature
cases also see less improvement in success. This suggests that maturing from low to medium has a big
improvement on success while maturing from medium to high does not show major improvements on
110
success. This would say that investing resources in maturing from medium to high would not weigh up to
the benefits. It is advised to critically look at this trade-off for each project.
Page
Embedding Agile in an organization
This research has found that management support on Agile is needed in order to give the
opportunity to further mature as teams and thus on organizational level. Management
support enables teams to align with both Agile as non-Agile teams within their organization.
Practices to stimulate management support will be discussed in this sub-chapter.
Have a shared process on Agile within a department or an organization

It is advised to write a definition of Agile which is shared across the organization. This should minimally
entail the requirements of a team and project in order to choose Agile, the tasks of Agile roles and the
definitions of Agile events and practices. This results in the full organization having the same
understanding about Agile and can enable alignment between teams and projects. It is advised to give
freedom to the teams to which extent they will make use of the Agile events and practices. Writing down
this definition can be done and adapted by means of pilot Agile projects.
Having a shared instruction of Agile written within a department or organization also pays attention to
the characteristics of engineers and developers working in the high-tech sector. As these type of workers
disfavor uncertainty and are looking for structure.
Leadership roles
The ones who have the most experience and knowledge on Agile are the ones who should take up a
transformational leadership role to mature the teams and organizations. They should convey the strength
of Agile and communicate how Agile can help the teams and organization. This can either be a project
manager, scrum master or Agile coach. Two effects take place when having transformational leadership
roles taken up by people with experience and knowledge on Agile. The first one being that teams
understand why they work Agile so that resistance of the team is minimized. The second effect is that
higher management can be convinced that Agile can improve success for certain projects so that
management support is created and further maturing can take place.
Share successes and lessons learnt

Adding to the recommendation of ‘just do it’, it is advised to have pilot projects starting off with
implementing Agile. Lessons learnt of the Agile process in these pilots can be shared with other projects
starting off with Agile. When sharing successes of these Agile pilots, other teams will want to see if Agile
fits them too. More importantly, sharing successful Agile pilots makes higher management trust the Agile
team and its way of working. Trust of higher management is needed to create empowered teams, as
mentioned in the recommendation ‘Create team ownership’. Also, it helps in making management
support Agile. This support will enable alignment of Agile teams with other (non-)Agile teams.
111
Page
8.3 Relevance of research
8.3.1 Relevance for theory
This study added value for theory on three subjects: Defining success in an Agile environment, listing
practices which fully cover Agile and showing how to measure Agile maturity.
First of all, Table 1 of chapter 2.2 is found to cover success in an Agile environment. This way of looking at
success focusses on two different perspectives: both the project and process success. Especially since an
Agile way of working focusses more on process and interaction, this should also be represented in
measuring success. It was found that this success can simply be measured by means of the last five
questions of the Comparativeagility survey. Comparing the result of the data required by the survey to
the view of success perceived during the interviews, it can be said that comparable views are established.
However, as mentioned in chapter 7.2 and 8.2, it is advised to have this survey filled in by more
respondents to acquire even more reliable results.
Secondly, this study created a list of practices which cover Agile. Most overviews of Agile consist of
principles which are to be followed but lack focus on the actual practices. Table 7 of chapter 3.2 is found
after extensive literature research and lists the practices which cover Agile.
Thirdly, studying different types of measurement models for Agile maturity have been reviewed. It was
found that Comparativeagility suited best for this type of research. However, this survey has been critically
assessed by comparing the survey to the literature study and exploratory interviews. It was seen that
several practices were missing to assess the maturity of cases. These were added to the list of practices.
8.3.2 Relevance for practice

The introduction of this thesis mentions that practitioners are unclear about how Agile can help
successfully completing projects. Implications for practice is found for three different stages. First, when
initiating or thinking of initiating Agile. Secondly, for maturing Agile. Thirdly for embedding Agile in an
organization. The recommendations of this study provide those who work, or want to work Agile certain
guidelines on what to keep in mind depending on which stage they are in.
First of all, the measuring of Agile maturity as mentioned in chapter 2.4 can be used by practitioners to
see where their team stands. According to this result, they can set a dot on the horizon and create a
roadmap to get where they want to be. This survey can also be used on a larger scale within the
organization to compare different teams.
Secondly, practitioners can make use of the findings on the effect of Agile practices as mentioned in
chapter 6.3.2, an overview is illustrated in Table 15. Practitioners are to critically look at their configuration
of the best practices found in chapter 6.3.3. Chapter 6.4 provides insight when wanting to scale Agile
within an organization.
Recommendations on how to reach the effect of Agile successfully completing projects and to configure
practices to help reach this effect are discussed in chapter 8.2. Depending on their stage of Agile
implementation, practitioners can see which advice is given. A final note on the practical relevance of this
study is that practitioners should always decide for themselves what is best for their project. As numerous
112
factors influence the effect of certain Agile practices, there is not one instruction to implement Agile best.
For each element, a fit-for-purpose approach should be handled.
Page
8.4 Personal reflection
The graduation process has learned me several things. Firstly, it is not a hard task to write but it is hard to
convey your message in a concise way. Also, I have learned that focus is essential in performing a
graduation research. The interest in the topic made me want to examine more than possible in the time
available.
My knowledge on Agile was very basic at the start of this research. The past months have shown me that
it is easy to learn to understand the basics of Agile but it is might take years of experience to obtain an
Agile mindset. Once again, it showed that social, personal and team factors have a bigger impact than
expected upfront. Therefore, people make projects succeed, not just a set of practices.
I am confident that this research is a good exploration of the topic on Agile in teams and organizations.
Graduation students starting a graduation research after me can make use of this research as a basis to
examine one of the mentioned further research topics leading from my research.
I am glad to see that project management is innovating in search for methods to improve effectivity and
efficiency. This thesis resulting in the finding that Agile did not show a decrease in project success for any
case makes me confident that improvements are still imaginable.
113
Page
References
A guide to Agile practices. (2019, March 03). Retrieved from Agile Alliance and Institut Agile:
https://web.archive.org/web/20160315034555/http://guide.agilealliance.org/
About comparative agility. (2019, March 28). Retrieved from Comparative agility:
https://www.comparativeagility.com/about/
Alqudah, M., & Razali, R. (2016). A review of scaling Agile methods in large software development.
International journal on advanced science engineering information technology vol.6 no. 6, 828-
837.
Ambler, S., & Lines, M. (2019). A practitioner's guide to Agile Software Delivery in the Enterprice.
Retrieved from Disciplined Agile Delivery: http://www.ambysoft.com/books/dad.html
Avots, I. (1969). Why does project management fail? California Management Review, 77-82.
Baccarini, D. (1996). The concept of projcet complexity - a review. International Journal of Project
Management Vol. 14, No 4, 201-204.
Bakker, H. (2008). Management of Projects: a people process. Inaugrural address. Delft, The
Netherlands: Delft University of Technology.
Bakker, H., & de Kleijn, J. (2014). Management of Engineering Projects - People are Key. NAP Network.
Barton, B. (2009). All-out organizational scrum as an innovation value chain. The 42nd Hawaii
international conference on system sciences. Waikoloa.
Beedle, M. (2019). Enterprise scrum. Retrieved from http://www.enterprisescrum.com/
Biknevicius, E. (2016, 07 17). Declaration of interdependence. Retrieved from Agile Project Leadership
Network: http://pmdoi.org/
Bognes, B. (2009). Implementing beyond budgeting: unlocking the performance potential. Hoboken, NJ:
John Wiley & Sons.
Bosch-Rekveldt, M. G. (2011). Managing project complexity: A study into adapting early project phases
to improve project performance in large engineering projects. Delft University of Technology:
Delft Centre for Project management.
Cicmil, S., Williams, T., Thomas, J., & Hodgson, D. (2006). Rethinking project management: researching
the actuality of projects. International journal of project management, Vol 24(8), p. 675-686.
Cobb, C. (2011). Making sense of Agile project management: Balancing control and agility. Wiley.
Cockburn, A., & Highsmith, J. (2001). Agile software development: the people factor. Computer, 131-
133.
Collins, A., & Baccarini, D. (2004). Project success - a survey.

114
Conboy, K., Coyle, S., Wang, X., & Pikkarainen, M. (2010). People over process: Key people challanges in
Agile development. IEEE Software.
Page
Conforto, E., & Amaral, D. (2008). Evaluating an Agile methof for planning and controlling innovative
projects. Project management journal.
Corman, M., & Bohner, S. (2005). The impact of Agile methods on software project management. 12th
IEEE international conference and workshops on the engineering of computer-based systems.
Greenbelt, USA: IEEE.
Dall'Agnol, M., Janes, M., Janes, A., Succi, G., & Zaninotto, E. (2003). Lean management - a metaphor for
extreme programming? Proceedings of the 4th international conference (pp. 26-32). Genova,
Italy: XP2003.
de Wit, A. (1988). Measurement of project succes. International Journal of Project Management, 164-
170.
Denning, S. (2012, March 01). The power of Scrum. Forbes.
Florencio, M., Sambinelli, F., & Borges, M. (2017). ASA: Agile software development self-assessment
method. Agile methods, 8th Brazilian workshop, WBMA (pp. 21-30). Belem, Brazil: Springer
International Publishing.
Fry, C., & Greene, S. (2007). Large scale Agile transformation in an on-demand world. IEEE computer
science.
Geraldi, J. (2008). The balance between order and chaos in multi-project firms: A conceptual model.
International Journal of Project Management, Vol 26(4), p. 248-256.
Gioia, D. A., Corley, K. G., & Hamilton, A. L. (2012). Seeking qualitative rigor in inductive research: notes
on the Gioia methodology. Organizational Research Method, 16-31.
Harvett, C. (2013). A study of uncertainty and risk management practice relative to percieved project
complexity. Insitute of sustainable development and architecture: Bond University.
Hass, K. (2007). The blending of traditional and Agile project management. PM World Today, Vol. 9(5).
Hazar, C. (2019, 03 12). Exploring Agile. (Y. Hendriks, Interviewer)
Heemstra, F., Ketel, L., & van Daalen, E. (2015). Agile: geschikt ongeschikt. Voor en door
projectmanagers. KWD Reeks.
Hesselberg, J. (2019, March 13). Introduction comparative agility. (Y. Hendriks, Interviewer)
Highsmith, J. (2002). Agile software development ecosystems. Boston, MA, USA: Addison-Wesley
Longman publishing.
Highsmith, J. (2009). Agile project management: creating innovative products. second edition: Addison-
Wesley professional.
Hombergen, R. (2019). Seven methods for successful programme management. PM Congress. Delft.
115
Huberman, M., & Miles, M. (1983). Qualitative data analysis: a methods sourcebook.
Page
Jalali Sohi, A. (2018). Flexibility in project management: Towards improving project performance.
Jalali, S., & Wohlin, C. (2010). Agile practices in global software engineering - a systematic map.
Proceedings of the 5th international conference on global software engineering (pp. 45-54). IEEE
computer society.
Jalali, S., Wohlin, C., & Angelis, L. (2014). Investigating the applicability of Agility assessment surveys: A
case study. Journal of Systems and Software, 172-190.
Kettunen, P. (2009). Adopting key lessons from agile manufacturing to agile software product
development - a comparative study. Technovation, 408-422.
Kidder, L., & Judd, C. (1986). Research methods in social relations. New York: Holt, Rinehart & Winston.
Kirkman, B., & Rosen, B. (2000). Powering up teams. Organizational dynamics, 48-65.
Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify.
Laanti, M., Salo, O., & Abrahamsson, P. (2011). Agile methods rapidly replacing traditional methods at
Nokia: a survey of opinions on Agile transformation. Information and software technology, 276-
290.
LeSS Framework. (2019). Retrieved from LeSS works: https://less.works/less/framework/index.html
Lindsjorn, Y., & Sjoberg, D. (2016). Teamwork quality and project success in software development: a
survey of Agile development teams. Journal of systems and software, 274-286.
Lynch, J. (2015, 10 4). Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. (S. Hastie, & S.
Wojewoda, Interviewers)
Martin, R. C., Fowler, M., & Beck, K. (2001). The Agile Manifesto.
McAvoy, J., & butler, T. (2007). The impact of the Abilene paradox on double-loop learning in an Agile
team. Information and Software technology, 552-563.
McAvoy, J., & Butler, t. (2009). the role of project management in ineffective decision making within
Agile software development projects. European journal of informations systems, 372-383.
McKenna, G., Wilczunski, H., & Vanderschee, D. (2006). Capital execution in the oil and gas industry.
McLean, Virginia, USA: Booz Allen Hamilton.
Morris, D. (2015). The paradox of Agile transformation: why trying too hard to be agile stops
organisations from becoming truly agile. University of Auckland.
Munns, A., & Bjeirmi, B. (1996). The role of project management in achieving project success.
International Journal of Project Management, 81-87.
Paasivaara, M., & Lassenius, C. (2010). Using scrum practices in GSD projects. In S. e. al., Agility across
time and space (pp. 259-278). Berlin: Springer-Verlag.
Petrillo, F., & Pimenta, M. (2010). Is agility out there? agile practices in game development. SIGDOC '10
116
proceedings of the 28th ACM international conference on design of communication (pp. 9-15).
São Carlos, São Paulo, Brazil: ACM New York.
Page
Pinto, J., & Slevin, D. (1988). Project success: definitions and measurement techniques. Project
Management Journal 2, 67-72.
PMI. (2014). Pulse of the profession 2014: The High cost of low performance.
PMI. (2017). Pulse of the Profession 2017: Project Success Rates Climb, Fewer Dollars Wasted.
PMI. (2018). Pulse of the Profession 2018: Success in disruptive times.
Price Waterhouse Coopers. (2017). Agile project delivery. Mitigate project risks and deliver value to your
business.
Radujkovic, M., & Sjekavica, M. (2017). Development of a project management performance

enhancement model by analysing risks, changes and constraints.
SAFe. (2019). about. Retrieved from Scaledagileframework: https://www.scaledagileframework.com/
Sanchez, L., & Rakesh, N. (2001). A review of agile manufacturing systems. International Journal of
Production Research, 3561-3600.
Schwaber, K. (2019). Nexus guide. Retrieved from scrum.org: https://www.scrum.org/resources/nexus-

guide
Schwaber, K., & Sutherland, J. (2013, July). The definitive guide to scrum: the rules of the game.
Retrieved from The scrum guide: https://www.scrumguides.org/docs/scrumguide/v1/Scrum-
Guide-US.pdf
Seviour, R. (2018). Selling for Engineers.
Shaarabh, M., Rishi, G., & Sharma, S. (2014). A Review on Measurement of Agility. Industrial Engineering
& Management.
Sidky, A., & Bohner, S. (2007). A disciplined approach to adopting Agile practices: the Agile adoption
framework. . Innovations in systems and software engineering, 203-216.
Sletholt, M., Hannay, J., Pfahl, D., Benestad, H., & Langtangen, H. (2011). A literature review of agile
practices and their effects in scientific software development. SECSE '11 proceedings of the 4th
international workshop on software engineering for computational science and engineering (pp.
1-9). Waikiki, Honolulu, HI, USA: ACM New York.
Smits, H. (2007). The impact of scaling on planning activities in an agile software development center.
Proceedings of the 40th Hawaii international conference on systen sciences.
Soares, L., & Brodbeck, A. (2017). For some places more than others - agility and organizational culture.
Agile methods, 8th Brazilian workshop, WBMA (pp. 121-133). Belem, Brazil: Springer
international publishing.
Söderlund, J. (2019). Future of Project Management. Project Management Congress 2019. Delft.
117
Solis Vuurmans, S. (2015). Project success within agile project management environment. Delft
University of Technology.
Page
Sutherland, J. (2019). Scrum at scale. Retrieved from Scruminc.com:
https://www.scruminc.com/scrum_at_scale_part_i/
Thamhain, H. (1983). Managing engineers effectively. IEEE transactions on engineering management,

EM-30.
The Standish Group. (2015). CHAOS Report 2015.
The Standish Group. (2018). CHAOS Report 2018.
Thomas, J., & Baker, S. (2008). Establishing an Agile portfolio to align IT investments with business
needs. Agile conference (pp. 252-258). Toronto, Canada: IEEE Computer society.
Tuckman, B. (1965). Developmental sequence in small groups. Psychological bulleting, 384-399.
Turner, J., & Muller, R. (2010). Project-oriented leadership. United Kingdom: Gower Publishing Ltd.
van Kelle, E., van der Wijst, P., & Plaat, A. (2015). An empricial study into social success factors for Agile
software development. IEEE/ACM 37th IEEE International Conference on Software Engineering.
Florency, Italy: IEEE.
Verbruggen, A. (2017). A project manager's journey towards agile project management. Delft University
of Technology.
Villki, K. (2009). Impact of agile transformation. Flexi, 5-6.
Westerveld, E. (2003). The Project Excellence Model: linking success criteria and critical success factors.
International journal of project management, 411-418.
Williams, L. (2012). What Agile teams think of Agile principles. Communications of the ACM 55(4).
Xebia. (2013). Dutch Agile survey report.
Xebia. (2014). Dutch Agile Survey Report.
Yin, R. (2018). Case study research and applications: design and methods. Los Angeles: SAGE
Publications.
Yukl, G. (2010). Why flexible and adaptive leadership is essential. Consulting pshychology journal
practice and research, 81-93.
Zhang, Z., & Sharifi, H. (2000). A methodology for achieving agility in manufacturing organizations.
International journal of operations & production management, 496-513.
118
Page
Appendices
Appendix A
Twelve principles of Agile project management.
Following the four values of Agile project management (Martin, Fowler, & Beck, 2001):
• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
The following twelve principles were established (Martin, Fowler, & Beck, 2001):
1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
119
Page
Appendix B
Agile vs. traditional project management
Table 17 - Agile vs. Traditional approach (Heemstra, Ketel, & van Daalen, 2015) page 33-35
TRADITIONAL APPROACH AGILE APPROACH

Based on The assumption that system are fully Good quality and adaptable software can be
specified and predictable and that they developed through small teams by making
can be built with help of a very precise iterations and changes in de development
planning process. Continuously improvement and
testing of the design.
Control Process aimed People aimed
Management style Command-and-control Leadership and collaboration
Knowledge management Explicit Tacit
Development approach Life cycle model (waterfall, spiral of Evolutionary development model (quick result
variations of this) by starting to deliver directly)
Desired organization structure Bureaucratic and formal Organic
Role allocation Individual Self-organizing teams
Communication Formal Informal
Role principal Important Critical
Project cycle Directed by activities and tasks Directed by characteristics of the product
Size Bigger teams and bigger projects Smaller teams and smaller projects
Environment Stable; not much change Turbulent; much change
Role of stakeholder within the project Influence the scope and requirements. Influences the project requirements. Play a role
Play a role in the requirement phase and during the full project life cycle
delivery of results
Change management Changes are managed according to pre-set Changes are managed according to flexible
procedures procedures.
Stakeholder management process Well organized and pre-set No pre-set plan
Management/leadership style Accent on control Accent on facilitating and support
Project team dynamics Members work in individual basis in a Teamwork is central on every level. People are
team; collaboration is not the prime focus. an important part of the organization and are
People are interchangeable defining
Work culture Planning is central; deadlines are holy Less stress and more work fun (less striving and
more flow)
Table 18 - Traditional vs. Agile approach (Jalali Sohi, 2018) p. 43.
TRADITIONAL APPROACH AGILE AND SCRUM APPROACH

Project environment Rational and linear project environment The recognition of the changing and dynamic
project environment
Project complexity Not taking complexity into account Taking complexity into account
Focus Focus on planning and control Focus on value delivery
Project’s goal flexibility Achieving predetermined goals is the main Changes regarding insights of the client and the
focus project team are incorporated
Management style Command and control approach Prepare-and-commit approach
Control Process centered People centered
Team composition Different specialists work sequential based `multidisciplinary team works together on the
on prescribed processes on the new development of a new product from start to
product development finish
Organizational type Applied in hierarchical organizations The steering has a more horizontal character
Attitude toward change Changes and adaptability are limited Enhances the ability of teams and organizations
to react to change
Communication Forma lines of communication Informal communication
Product delivery Life cycle model Iterative delivery
Task assignment Task assignment by project manager Self-assigned tasks to individuals
Steering of team Central role of project manager Self-organizing project teams
Planning Detail up-front planning Iterative planning
Attitude toward client Important critical
120
Page
Table 19 - Agile vs. traditional approach (verbruggen, 2017)
COMPARATOR ASPECTS AGILE PROJECT MANAGEMENT TRADITIONAL PROJECT MANAGEMENT SOURCES

S
PHILOSOPHY
Mindset Individuals Processes & tools Nerur et al., 2005; Vinekar et al.,
Working software Comprehensive documentation 2006; Agile Manifesto
Customer collaboration Contract negotiation
Responding to change Following the plan
ORGANISATION AND MANAGEMENT
Organization Structure Flat team-based structure Hierarchical structure Owen et al., 2006; Van
Form Flexible & participative Bureaucratic with high formalization Waardenburg & Van Vliet, 2013;
encouraging cooperative social (mechanic) Nerur et al., 2005; Vinekar et al.,
Culture action (organic)
Comfort and empowerment via Comfort and empowerment via 2006;
many degrees of freedom framework of policies and procedures
(thriving on chaos) (thriving on order)
Management Managemen Leadership-and- collaboration Command-and-control Owen et al., 2006; Nerur et al.,
t style
Decision Decentralized & pluralist decision Centralized & managerial decision 2005; Vinekar et al., 2006; Hass,
making making making 2007
DEVELOPMENT PROCESS
Development Development Iterative, adaptive, extreme Linear, incremental Fernandez & Fernandez, 2008,
methods style
Development Evolutionary delivery model; Life cycle model; Wysocki,et2011;
Vinekar al., 2006; Hass, 2007;
model Leau et al., 2012; Van
e.g. Scrum, XP, DSDM, Crystal, e.g. Waterfall model, spiral model, V- Waardenburg & Van Vliet, 2013
FDD model
Development Project cycle Guided by project features Guided by tasks or activities Owen et al., 2006; Williams et al.,
approach Iron triangle Resources and time are fixed Scope (solution) is fixed 2010; Hass, 2007; Nerur et al.,
Development Development Adaptable; readily changeable Pre-planned; fixed 2005; Cockburn,
Owen 2006
et al., 2006; Van
direction & direction Waardenburg & Van Vliet, 2013;
nature of Vinekar et al., 2006; Leau et al.,
planning 2012; Williams et al., 2010;
Vinekar et al., 2006;
Planning Planning is done prior and for Rigorous planning for the entire project
approach every iteration
Value delivery Value Frequent value delivery; after At the end of each phase/ at the end of Vinekar et al., 2006; Owen et al.,
frequency delivery every iteration (timebox) value is the project the value accepted by the 2006; Williams et al., 2010;
delivered to the customer customer Boehm and Turner (2003)
Dealing with Change Change is inevitable, dealt with Threat for meeting the plan, not dealt Van Waardenburg & Van Vliet,
change after every iteration with until the next release 2013; Owen et al., 2006; Hass,
PEOPLE AND TEAM 2007;
Teamwork Team Small teams, collaborative work Large teams, individual work Williams et al., 2010; Hass, 2007;
composition
Team Co-located teams Not always co-located teams Vinekar et al., 2006; Nerur et al.,
location
Role Self-organising teams & Individual & favours specialisation 2005; Leau et al., 2012; Boehm
assignment
Skills encourages role
Interpersonal & multidisciplinary Specialized skills and Turner (2003); Owen et al.,
Reward interchangeability
skills award systems
Team Individual award systems 2006;
systems
Customer Customer High customer involvement; Low customer involvement; as-needed Vinekar et al., 2006; Nerur et al.,
involvement involvement dedicated customers focused on customer interactions focused on 2005; Leau et al., 2012; Boehm
prioritized increments contract provisions and Turner (2003); Owen et al.,
Customer Co-located customer Not always co-located customer 2006;
Attitude to location
Learning Double loop learning Single loop learning Williams et al., 2010; Owen et al.,
121
learning type 2006; Hass, 2007
TECHNOLOGY
Page
Requirements Definition of Requirements can undergo Requirements undergo a foreseeable Boehm and Turner (2003); Leau et
requirement unforeseeable change, and evolution and are formalized (e.g. al., 2012; Owen et al., 2006; Van
s consist of prioritized informal projects, capabilities, interfaces, quality) Waardenburg & Van Vliet, 2013;
stories Williams et al., 2010
Clarification Requirements discussed and Requirements at the beginning of the
of clarified ‘‘just-in-time’’ project (Contract driven; requirements
requirement serve as contract)
Testing s Executable test cases define Documented test plans and procedures Boehm and Turner (2003); Vinekar
requirements testing et al., 2006; Williams et al., 2010;
Write test prior to code (test- Write code prior to test Hass, 2007; Leau et al., 2012
driven development)
Timing of Testing early in the development Testing late in the development process
testing process
Frequency of Testing on every iteration (incl. Testing after coding phase completed
testing customer acceptance testing) (incl. customer acceptance testing)
Release High release frequency (‘’go live’’ Low release frequency (‘’ go live’’ Van Waardenburg & Van Vliet,
frequency release per one to four weeks) release per six or more months) 2013;
Project metrics Documentati Minimal, up-to-date metrics Emphasis on data collection Boehm and Turner (2003); Vinekar
and on
Knowledge & Tacit knowledge & informal Explicit knowledge & formal et al., 2006; Williams et al., 2010;
documentation communicati communication communication Hass, 2007; Van Waardenburg &
on Van Vliet, 2013; Owen et al., 2006;
Coding Design Simple design; refactoring Extensive design; refactoring assumed Boehm and Turner (2003); Leau et
Nerur et al., 2005
assumed in-expensive expensive al., 2012; Williams et al., 2010
Code Collective code ownership Not always collective code ownership
ownership
122
Page
Appendix C
Comparing scaled Agile methods
Table 20 - Comparing scaled Agile methods (Alqudah & Razali, 2016)
CRITERIA DAD SAFE LESS LESS2 SPOTIFY NEXUS

Team size 200 people or more. It also Large Up to 70 Any large Any large Three to
supports small and medium Enterprise people or 10 projects, projects, nine
teams. includes SCRUM More Normally SCRUM
more teams, 7 than 250 to 300 teams
than 1 stakeholders thousand people at
release in each people on Spotify (30
trains (50 to team one teams)
124 people in product
each release
trains)
Training and Workshops to Training is Seven Seven Lack of Scaled
certificate on explain the idea of needed and companies companies training Professional
DAD, Book of DAD there should in six in SCRUM
is available be certified, countries six countries Training is
coaches are available are needed
for coaching available
for coaching
Methods and Kanban Practices SCRUM, SCRUM SCRUM Allow SCRUM
practices adopted (mainly visualizing Lean, was fully was fully Kanban, with
Work and limiting Kanban, adopted adopted SCRUM, additional
work in progress), SCRUMban, including including DevOps and practices in
SCRUM (almost all DevOps and additional additional Lean Startup solving the
SCRUM practices), some practices for practices for dependency
Agile Modeling practices of large large related
which is the source XP projects projects issues in
for DAD’s modeling multiple
and documentation teams
practices, the
Unified Process, XP,
TDD and Agile
Data.
Technical practices High (Need to adopt Medium but Medium and Medium Medium but Medium and
required many technical should low for and teams should low for
practices which understand SCRUM low for be able to SCRUM
require high the use of adopters SCRUM communicate adopters
technical skills) portfolio adopters well
management
tools
Organization type Multiple Enterprises Large Enterprises Enterprises Portfolio
Organization and and portfolio Traditional specifically level for
Enterprise level organization similar to medium
practicality Spotify project
123
Page
Appendix D
Agile elements
Table 21 - Agile elements (A guide to Agile practices, 2019)
AGILE PRACTICES
1 Acceptance 19 Given - When - Then 37 Quick Design Session 55 Ubiquitous Language
Testing
2 ATDD 20 Heartbeat Retrospective 38 Refactoring 56 Unit Testing
3 Automated Build 21 Incremental Development 39 Relative Estimation 57 Usability Testing
4 Backlog 22 Information Radiators 40 Role-Feature-Reason 58 User Stories
Grooming
5 Backlog 23 Integration 41 Rules Of Simplicity 59 Velocity
6 BDD 24 Invest 42 Scrum Of Scrums 60 Version Control
7 Burndown Chart 25 Iteration 43 Sign Up For Tasks
8 Collective 26 Iterative Development 44 Simple Design
Ownership
9 Continuous 27 Kanban Board 45 Story Splitting
Deployment
10 Continuous 28 Lead Time 46 Story Mapping
Integration
11 CRC Cards 29 Milestone Retrospective 47 Sustainable Pace
12 Daily Meeting 30 Mock Objects 48 Task Board
13 Definition Of 31 Niko-Niko Calendar 49 TDD
Done
14 Definition Of 32 Pair Programming 50 Team
Ready
15 Estimation 33 Personas 51 Team Room
16 Exploratory 34 Points (Estimates In) 52 Three C's
Testing
17 Facilitation 35 Planning Poker 53 Three Questions
18 Frequent 36 Project Chartering 54 Timebox
Releases
Table 22 - Agile elements (Schwaber & Sutherland, 2013)
AGILE PRACTICES
1 Sprint planning
2 Daily scrum
3 Sprint review
4 Sprint retrospective
5 Product backlog
6 Monitoring sprint progress
7 Increment
8 definition of done
Table 23 - Agile elements (Sletholt et. al., 2011)
SCRUM EXTREME PROGRAMMING

1 Priorities (Product Backlog) maintained by a 13 User stories are written (*) 25 Use collective ownership (*)
dedicated role (Product Owner)
2 Development process and practices 14 Give the team a dedicated 26 Simplicity in design (*)
facilitated by a dedicated role (Scrum open work space (*)
Master)
124
3 Sprint planning meeting to create Sprint 15 Set a sustainable pace (*) 27 Choose a system metaphor
Backlog
4 Planning poker to estimate tasks during 16 The Project Velocity is 28 Use CRC cards for design sessions
Page
Sprint planning measured (*)

5 Time-boxed sprints producing potentially 17 Move people around (*) 29 Create spike solutions to reduce risk
shippable output (*)
6 Mutual commitment to Sprint Backlog 18 The customer is always 30 No functionality is added early
between product owner and Team available (*)
7 Short daily meeting to resolve current issues 19 Code written to agreed 31 Refactor whenever and wherever
standards (*) possible
8 Team members volunteer for tasks (self- 20 Code the unit test first 32 All code must have unit tests
organizing team)
9 Burndown chart to monitor sprint progress 21 All production code is pair 33 All code must pass all unit tests before
programmed it can be released
10 Sprint review meeting to present completed 22 Only one pair integrates code 34 When a bug is found tests are created
work at a time
11 Sprint retrospective to learn from previous 23 Integrate often 35 Acceptance tests are run often and
sprint the score is published
12 Release planning to release product 24 Set up a dedicated integration
increments computer
* Elements of XP which are also beneficial for the Scrum method
Table 24 - Agile elements (Petrillo and Pimenta, 2010)
AGILE PRACTICES ADHERE TO AGILE METHOD…

1 Qualified team Scrum, AM, XP
2 Belief in the success of the project Scrum, XP
3 Creativity stimulus Scrum, AM
4 Focus on the product Scrum, XP
5 Version control XP
6 Using simple tools XP, AM
7 Programming good practices XP
8 Agile modeling XP, AM
9 Defined process Scrum Scrum, XP
10 Quality control XP
11 Feedback quickly Scrum, XP
12 Good practices of management Scrum, XP
13 Continuous integration XP
Table 25 - Agile elements (Jalali & Wohlin, 2010)
AGILE PRACTICES
1 Continuous integration 11 Short iterations 21 System metaphor
2 Standup meetings 12 Proxy customer 22 Instant messages
3 Pair programming 13 Sprint demo 23 User stories
4 Retrospectives 14 Code standards 24 Code reviews
5 Scrum of scrums 15 Refactoring 25 Acceptance tests
6 Test Driven Development (TDD) 16 Burndown charts 26 Feature driven development
7 Sprint review 17 Virtual scrum wall
8 Backlog 18 Unit testing
9 Automated testing 19 Planning game
10 Planning meeting 20 Close collaboration
Table 26 - Agile elements (Jalali, 2018)
PHASE SCRUM CONCEPT SCRUM PRACTICE

Backlog refinement Formulation of stories 1
Initiation
Analysis of duration of stories 2

Prioritizing and DoD 3
Sprint planning Selection of work for sprint 4
Planning poker 5
125
Sprint Division of tasks 6

Daily stand up 7
Design
Removing impediments 8
Page
Complete scrum board 9

Testing/review 10
Closing of sprint 11
Incomplete stories in PB 12
Extensions Backlog refinement 13
Scrum of scrums 14
Sprint review Presenting results to client 15
Delivery
Sprint retrospective Evaluation of process 16
Table 27 - Agile elements (Williams, 2012)
AGILE PRINCIPLES
1 Continuous integration 19 stand up/scrum meeting 37 kanban
2 short iterations 20 timeboxing 38 acceptance tests written by product manager
3 done' criteria 21 test-driven development unit testing 39 pair programming
4 automated tests run with each 22 just-in-time requirements elaboration 40 burndown charts
build
5 automated unit testing 23 small team (12 people or less) 41 code inspections
6 iteration reviews/demos 24 Emergent design 42 design inspections
7 potentially shippable' features at 25 configuration management 43 planning poker
the end of each iteration
8 whole' multidisciplinary team with 26 daily customer/product manager 44 stablization iterations
one goal involvement
9 synchronous communication 27 release planning kanban
10 embracing changing requirements 28 test-driven development acceptance acceptance tests written by product manager
testing
11 features in iteration are customer- 29 team documentation focuses on pair programming
visible/customer-valued decisions rather than planning
12 prioritized product backlog 30 informal design: no big design up front burndown charts
13 retropective 31 co-located team code inspections
14 collective ownership of code 32 team velocity design inspections
15 sustainable pace 33 requirements written as informal planning poker
stories
16 refactoring 34 10-minute build stablization iterations
17 complete' feature testing done 35 task planning kanban
during iteration
18 negotiated scope 36 coding standard acceptance tests written by product manager
Table 28 - Agile elements (Florencio, Sambinelli and Borges, 2017)
AGILE PRACTICES
1 Updating requirements 11 Colocation of client and 21 Continuous stakeholder
product owner communication
2 Minimal requirements and design are 12 Tools and processes that 22 Frequent reflection and learning
written support feedback
3 Development cycles are short 13 Code is shared (can be 23 Striving for customer satisfaction
changed by everyone)
4 Features can be put in production anytime 14 Refactoring of code
5 Automated acceptance test 15 Constant velocity/pace
6 Automated integration tests 16 Continuous delivery
7 Automated performance tests 17 Continuous feedback
8 Automated unity tests 18 Simplicity
9 Team analyzes velocity 19 Empowered teams of
motivated individuals
126
10 Velocity is determined by burn down chart 20 Accommodate change
Table 29 - Agile elements (Soares & Brodbeck, 2017)

Page
AGILE PRACTICES AGILE MANIFESTO PRINCIPLE

1 Delivery planning Welcome changing requirements…
2 Requirements in form of stories
3 Iterations/small, frequent deliveries Deliver working software frequently…
4 Active customer involvement Business people and developers must work
5 Multidisciplinary teams together…
6 Motivation Build projects around motivated individuals
7 Co-location The most efficient (…) face-to-face
conversation
8 Test-driven development Working software is the primary measure …
9 Continuous integration
10 Sustainable pace Agile processes promote sustainable
development …
11 Code refactoring Continuous attention to technical
excellence …
12 Pair programming
13 Simplicity Simplicity
14 Incremental project
15 Minimum modeling/documentation
16 Collective understanding The best (…) designs emerge from self-
17 Stand-up meeting organizing teams
18 Visual progress indicators
19 Retrospectives/learning At regular intervals, the team reflects…
Table 30 - Agile principles found in literature
literature In
Guides Conceptual Literature studies
practice
Petrillo and Pimenta, 2010
A guide to Agile practices,
Soares & brodbeck, 2017

Schwaber & Sutherland,
Florencio, Sambinelli, &

Jalali & Wohlin, 2010
Sletholt et. al., 2011
Williams, 2012
Borges, 2017
Jalali, 2018
2019
2013
PRINCIPLE MANIFESTO
8. Sustainable
33 Sustainable pace x x x x x
development
34 Frequent releases x x x x 1. Continuous delivery
35 Continuous integration x x x x x x 3. Frequent delivery
36 Iterative development x x 3. Frequent delivery
37 Incremental development x x x 3. Frequent delivery
38 Short iterations x x x x 3. Frequent delivery
39 Simple design x x x x 10. Simplicity
40 Rules of simplicity x x x 10. Simplicity
41 Test driven development x x x x 7. Working software
42 Belief in the success of the project x 5. Motivated individuals
43 Focus on the product x 7. Working software
44 Motivated individuals x x 5. Motivated individuals
45 Feedback quickly x x 3. Frequent delivery
Self-organizing (Team member
46 x x x 11. Self-organizing teams
volunteer tasks)
Feature driven development valued 2. Welcome changing
47 x x x
by customer requirement
127
2. Welcome changing
48 Embracing changing requirements x x
requirement
Page
Appendix E
Testing comparativeagility survey

The result of a testcase for measuring the Agile maturity is presented in Figure 31. The project lead of the
Failure Mode knowledge based (FMkb) project filled in the survey. He mentioned afterwards, without
seeing the results, that he finds his project to be in a low Agile maturity level. The results indeed show
that the case scores lower than the mean of the Comparativeagility database on each dimension.
Agility FMkb (45229)

Teamwork
5
Outcomes 4 Requirements
3
2
1
Knowledge-Creating 0 Planning
Culture Technical Practices
Quality
FMkb Comparativeagility database mean
Figure 31 - Agility test project

128
Page
Appendix F
Interview protocol
Mail of introducing the interview

Dear [Name],
I would firstly like to thank you for participating in the interview and helping me with my research, it is really
appreciated.
My research is performed by means of an internship at [high-tech company] on the operations and strategic
excellence department in the Business Agility team. During this internship I am supported by Herman Mooi, Project
and Program management expert at [high-tech company].
On [date] I will visit you at [location]. Before the interview, I would like to introduce you further to the research by
means of this mail. Attached you can find the management summary of my research approach. Before the interview
I would like to ask you to fill in a survey to further identify the case study. Please fill this in ultimately a week in
advance. All data will be anonymized and will not be shared with others. The data will be deleted after the research.
The interview will take one to one and a half hour. I hope you are okay with recording the interview for my own
reference during the analysis. It will be deleted after the research is complete.
An interview report will be sent within [#] days after the interview. You then can agree with the usage of the quotes
and validate the findings. It is appreciated to return a confirmation within a week after receiving the interview report.
The interview will be of high value for my research and therefore I really appreciate the time you use for it. In return,
your project is analyzed on several Agile elements, the Agile maturity and its performance. In addition, you will
receive the findings of this research. Together we can come closer towards the best way to implement Agile!
I thank you again and will see you on [date].
Contextual survey before interview

The contextual survey is asked to be filled in by making use of the following link:
https://forms.gle/3MArK5YY9hYiNcMG8
Part 0: Questions before interview Goal:
Interviewee
1. What is your formal role/position title within your Identify the expertise of the interviewee
organization [short title]
2. What tasks & responsibilities do you have in that role?
3. How many years have you worked within your current
organization? [years]
4. How many years of experience do you have within your
role? [years]
5. How many years of experience do you have with Agile?
[years]
6. Which Agile methods have you worked with? [check:
Scrum/CP/Lean development/DevOps/FDD/DSDM/hybrid]
7. If any, which certificates of Agile did you achieve? [list]
Project
8. What is the official name/title of the project?
9. What was the goal of the project? Identify whether the case meets the requirements and create a
129
10. What is the status of the project (finalized or not) case description
11. Was the project part of a bigger program? [yes/no]
Explain.
Page
12. What Agile method did your project use? [scrum/Lean/xp…] e.g. Scrum/XP/Lean/Kanban/Iterative and incremental
development (IDD)/Dynamic systems development method
(DSDM)
13. How long were your sprints? [weeks]
Interview format
Table 31 - Interview details
Interview details
Interviewer
Name Yaron Hendriks

[Case # .
Interview code
Respondent #]
Date
Name Department
Interviewee
Years exp.
Project
Current role
Years exp. Agile Role in project
Table 32 - Interview questions and goals
Goals
Goals of the interview
− Establish the effect of the Agile practices (not) used within the project.
− Evaluate the degree of the project being completed successfully in addition to comparativeagility survey
− Find out how to combine Agile and traditional projects within program and portfolio management.
Goals of interview analysis:
− Determine the relation between Agile practices and project success.
− Determine the relation between the Agile maturity level and Agile best practices.
Introduction interview ~5 minutes:

− Thank interviewee for participating.
− Introduce myself.
− Summary of research.
− Names and organizations will be anonymized
− Do you give permission to record interview? All data will be deleted after the research.
− The interview will take approximately 1-1,5 hours. Ask how much time person has!
− Explain how the interview will go.
− Stress that questions should be answered according to experiences from the project mentioned (current/last project they worked
− on) you have any questions before we start?
Do
Part 0: Context 5-10 minutes Goal Leading from

Project (big picture)
1. Why was Agile chosen to use as a method? Hype? improving efficiency? Alignment with rest 2.1.3 Agile or
of company? waterfall
2. Did the Agile process work well during the project? e.g. no Agile method defined within organization, Exploratory
If not, why not? If yes, why? bottom-up/top-down issue etc.? interviews
3. Was the Agile method a good choice for the project? Find out why Agile is not fully implemented yet? 2.1.3 Agile or
If not, what other (Agile) method would have been waterfall
better?
4. How do you think Agile has improved the success of the Let them name 3 top practices Main research
project most? question
130
Part 1: Agile Practices ~45 minutes

Shared belief in Agile within the team Exploratory
5. Were all team members backing the choice of using an Agile method upfront? [yes/no] interviews
Page
Did this change during the course of the project? How/why?

6. Did you feel team members were stuck in the ‘old’ traditional mindset? [yes/no] (strict planning etc.)
if yes, what effect did this have on the process?
How can this be solved?
Coaching
7. Did the team have experience with Agile project management?
How did this influence the process?
8. Did any Agile coaching or training take place?
How did this help, or why not?
Daily (standup/scrum) meetings (13) [score] & Kanban/scrum board (31) [score] 2.4.1
9. How did you configure these meetings? comparison
Was this beneficial? Why? literature and
10. What was the added value of the scrum board? survey
Informal face-to-face communication (10,11,12) [score]
11. How did you facilitate more informal communication opposed to documentation? Was this helpful?
Multidisciplinary teams (1, 2, 7, 14) [score] & Division of roles (6,8) [score]
12. What is the major feature of the multidisciplinary team that added most value?
How did that show?
What can be improved?
13. How did you make sure teams were self-organizing? Or why not? (managing themselves)
Did the team really have own responsibility to deliver tasks? How did that show?
Sprint review (57) [score] & Sprint retrospective to learn from previous sprint (57,58)
14. What is the added value of sprint reviews?
(How do team members actually learn from these reviews?)
Testing (Acceptance tests) (45,46) [score]
15. Were these tests effective in identifying errors and preventing future errors? Why (not)?
Informal design; no big design up front (20,35) [score]
16. To what extend was the project designed upfront? (how detailed) (planning, goals, etc.)
17. How did the level of detail of the design lead to higher success?
18. Did any problems occur (later on) because of the level of detail in the design? Which ones?
Time-boxed sprints (28) [score]
19. Why was this duration adequate (or not)?
20. Could value be added in each sprint?
Sprint planning and selection of work (24) [score]
21. How did you plan for one sprint?
(who joined the planning and how did you select tasks?)
22. How did you make sure this planning was good? How did you prevent doing too little or plan too much?
Having a prioritized backlog (25) [score]
23. How did you prioritize tasks? (what were the criteria and how is it estimated?
Frequent communication with customer Table 3 –
24. How close was the customer/end-user involved during the project? Agile
In what way did this influence the success of the project? practices
from
literature,
not covered
in survey
One defined process/way of working scrum across organization Exploratory
25. How was Agile initiated within the organization? Bottom-up/top-down? [either/or] interviews &
How did that influence the success of Agile implementation? table 3
26. Is there an Agile framework/way of working/method written for your team or within the company? [yes/no]
How do you feel that this ‘standardized’ method helps the process? And how does it hinder the process?
Part 2: Project success ~10 minutes

27. In what ways did you see an increase of success due to choosing Agile instead of a different (more traditional)
method
and in what ways did success decrease?
28. Which three Agile practices do you consider influence project success most?
131
And which three Agile practices do you consider least effective?
Part 3: Program and portfolio ~10 minutes

Page
29. Does the organization make use of Scaled Agile methods? [SAFe/LeSS/Spotify/PRINCE2 Agile/Nexus]
30. To what extend does your company embrace those frameworks? (strictly or out-of-the-box own interpretation) 2.1.4 program
Why strictly or own interpretation? and portfolio
31. How does your organization make sure that Agile and traditional/non-Agile project are aligned and
collaborate?
32. What impact does Agile have on program and portfolio management?
33. How is the value of a project estimated upfront and how did you report expected value delivery to higher
management?
34. How did you report earned value/progress during the project to higher level management? Is it different than
traditional?
Closure ~5 minutes
− Interview report will be created and sent to interviewee for verification and validation.
− Request to send approval/verification within 1 week.
− Potential further interview? With other project team members? Other organizations?
− Material to send me?
− Questions or remarks?
Interview report
During the interview, notes will be made for adapting the interview questions during the interview and to get an
overview of the answers of the respondent in broad lines. The interview will also be recorded so that I can listen
back to it for my own reference. An interview report will be written immediately after the interview. This report will
entail a transcript and summary of the full interview. It will also mention preliminary findings. The statements made
by the interviewee will be linked to the research questions of the case study and to the goal of the interview. This
report will be used for my own reference during the analysis and will not be published. The transcripts of the
interviews can be found in a separate file attached to this research.
132
Page
Appendix G
Comparativeagility survey questions
Each statement is answered by selecting (true), (more true than false), (neither false nor true), (more false
than true), (false). The questions in bold are directly linked to the practices which cover Agile as discussed
in chapter 2.5.
Teamwork
1. Everyone required to go from requirements to finished system is on the team
2. Team members are willing to work outside their specialties to achieve team goals.
3. Whole teams, including the ScrumMaster and Product Owner, have no more than 11 people on them.
4. People are not on more than two teams
5. Team members are kept together as long as possible.
6. Team members choose which tasks to work on.
7. Management sets goals but doesn't tell team members how to achieve them.
8. Team members don't have to work on tasks that they deem to not add value.
9. Management rarely changes the team's priorities during an iteration.
10. Team members communicate in an effective manner without undue interference.
11. Team members from one team communicate with team members from other teams in an effective manner without undue
interference.
12. Formal written documents are used to supplement rather than replace faster, more informal communication.
13. Standup meetings are effective at synchronizing work.
14. The team is not concerned about knowledge gaps when someone goes on vacation (or is otherwise unavailable).
Requirements
15. Teams are able to start projects with incomplete requirements.
16. Non-functional requirements are determined early enough to appropriately influence design and testing.
17. Requirements are represented at different levels of detail based on how soon the team expects to implement them.
18. The product owner is available to discuss upcoming features and work-in-progress.
19. The whole team embraces change and emergent opportunities in an efficient, low-ceremony way.
20. Projects do not begin with an extensive technical design phase.
21. The team performs iterative technical design throughout a project.
Planning
22. Team members, including the product owner, are engaged in the planning process in a way that they can meaningfully and
appropriately affect scope and deadlines.
23. Technical team members and product owners collaborate in determining what features will be included in the release plan.
24. At the start of each iteration, the team performs sufficient just-in-time planning to be confident of what it can complete in the
iteration.
25. The product owner maintains a prioritized product backlog.
26. One or more of scope, schedule, or resources is allowed to change during a project.
27. Iterations focus on creating features with value to customers and infrequently focus on infrastructure specific work.
28. All work is done in iterations of no more than 30 days.
29. Teams know their velocity.
30. There is a highly visible representation of the team's progress within a release.
31. Each day, there is a highly visible representation of the team's progress within an iteration.
32. Each feature has a well-defined completion criteria that can be used to determine if the feature is done or not done.
33. We do not consider a partially completed feature done.
34. Estimates are created collaboratively by the people who will do the work.
35. Upfront planning is sufficient without being excessive.
Technical practices
36. Most code is written using test-driven development (TDD).
37. Code is written using pair-programming.
38. Team members pair program at appropriate times.
39. Refactoring is performed whenever needed.
133
40. Technical debt (i.e., accumulated undone or poorly done work) is made visible to both technical team members and stakeholders.
41. The entire system is built automatically at least once per day.
42. Automated unit and acceptance tests are run as part of each automated build.
Page
43. Within our team, anyone can change anyone else's code.
44. The team can change any code in the system, even code written by other teams.
Quality
45. Product owners actively participate in the creation of the acceptance criteria for each feature.
46. All bugs are fixed during the iteration in which they are found.
47. At the end of each iteration there is little or no manual testing required.
48. The team performs a variety of types of testing including functional, performance, integration, and scalability each iteration.
49. Team members who perform testing are involved and productive right from the start of each iteration.
50. At the end of each iteration, the team has high-quality working software that it is comfortable being tested by people outside of the
team.
51. The team has pre-defined and agreed-upon criteria for considering a feature done.
Culture
52. When faced with a situation where scope cannot be met with the allotted resources in the allotted time, the team's initial reaction is
to prioritize and explore tradeoffs.
53. The team maintains a steady rate of productivity without being overworked.
54. The team considers the economics of its choices when we make decisions.
55. Bonuses, annual reviews, and compensation promote team behavior.
56. Titles are not significant in how team members interact with one another.
Knowledge creating
57. Iteration reviews are attended by product owners, stakeholders, and team members who provide actionable feedback.
58. The team holds retrospective meetings at the end of each iteration in which the team evaluates how they are doing and discuss how
to get better.
59. The team acts on retrospective feedback in a timely manner.
Outcomes
60. The team is producing higher quality products than before.
61. The team is more productive than before.
62. Our customer(s) are more satisfied with the functionality of our products than before.
63. Our customer(s) are more satisfied with the usability of our products than before.
64. The team has higher morale than before.
65. Our business is recognizing greater economic value than before.
66. We are delivering functionality to users more quickly and/or more often than before.
*Answers to the questions in bold are used in the interview
134
Page
Appendix H
Overview interview
The overviews of the interviews can be read in the case descriptions in chapter 5. Full transcripts can be found in a
separate file attached to this thesis. For reference and proof, the voice recordings are saved until the graduation
date.
135
Page

Managing Projects Agile

Uploaded by

Copyright:

Available Formats

Managing Projects Agile

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Managing Projects Agile

Uploaded by

Copyright:

Available Formats

Yaron Hendriks

Photo by İrfan Simsar on Unsplash

Managing projects Agile

Date: October 9, 2019

Writer: Yaron Hendriks

University: Delft University of Technology

Faculty: Civil Engineering and Geosciences

Master study: Construction Management and Engineering (CME)

Prof. Dr. H.L.M. Bakker – Chair of the graduation committee

Dr. ir. M.G.C. Bosch-Rekveldt – First supervisor

Dr. G. de Vries – Second supervisor

Dr. ir. H.G. Mooi – External supervisor

Project and Program management expert at ASML

The past 7 months have been a great experience.

Delft, September 6th 2019

Embedding Agile in an organization

•Create team ownership •Share successes and

•Argue whether to strive

Figure 1 - Overview recommendations

Na het verkennen van verschillende Agile volwassenheid meetmodellen, is gebleken dat de

verschillende stadia van de Agile manier van werken.

Effect van Agile

Agile borgen in organisatie

Figure 2 - Overzicht aanbevelingen

5.1 Case 1.1: Delivery of a technical component.............................................................................. 48

5.2 Case 1.2: Software integration.................................................................................................... 51

7.1.5 Characteristics of technical employees .............................................................................. 97

7.2 Discussing the limitations ........................................................................................................... 99

1.1 Research goal and questions

SQ2 Use of Agile

Figure 3 - Research approach

SQ1 SQ2 SQ3 SQ4 SQ5 SQ6

Figure 4 - Research methods

Theory Practice Wrap-up

Figure 5 - Research outline

Theory Practice Wrap-up

2.1 The Agile approach

The Agile manifesto was set up around four values:

2.1.2 Agile approach defined and scoped

2.1.3 Agile vs. traditional project management

Figure 6 - Phases traditional project management

Figure 7 - Phases Agile/Scrum

of the project after each sprint.

Projects in an Agile environment

2.1.4 Program and portfolio management in an Agile approach

new triangle consists of value, quality and constraints.

Figure 8 - Transformation of success triangle (Highsmith, 2009)

However, value is represented differently in an Agile

Instead, a continuous flow of value is created with no

Project team satisfaction

Petrillo and Pimenta, 2010

Soares & Brodbeck, 2017

Florencio, Sambinelli, &

2.4.1 Literature vs. Comparativeagility

Table 3 - Agile practices from literature, not covered in survey

PRACTICES PRINCIPLE VALUE

PRACTICES QUESTION SURVEY PRINCIPLE VALUE

2.5 Conclusion literature study

3.1 Findings exploratory interviews