Content uploaded by Richard Oprins
Author content
All content in this area was uploaded by Richard Oprins on Apr 07, 2019
Content may be subject to copyright.
Leiden University
ICT in Business
AGILE: TRANSCENDING THE BORDERS OF IT
The emerging influence of feedback and creativity
Name: Richard Oprins
Student-no: S1416731
Date: 25 September 2018
1st supervisor: Dr C. J. (Christoph) Stettina
2nd supervisor: Dr S. F. (Steve) Foster
MASTER'S THESIS
Leiden Institute of Advanced Computer Science (LIACS)
Leiden University
Niels Bohrweg 1
2333 CA Leiden
The Netherlands
1
2
Acknowledgements
I would first like to thank my thesis advisor, Dr C. J. (Christoph) Stettina of the Centre for
Innovation at Leiden University. Dr Stettina was always available whenever I had a
question on the research or during the writing of this thesis. He consistently allowed this
paper to be my own work, but steered me in the right the direction whenever he
thought I needed it.
I would also like to thank the experts who were involved in the validation survey for this
research project. Without their passionate participation and input, the validation survey
could not have been successfully conducted.
I would also like to acknowledge the assistance of Dr S. F. (Steve) Foster of the Leiden
Institute of Advanced Computer Sciences at Leiden University as the second reader of
this thesis, and I am indebted to him for his very valuable comments.
Finally, I must express my very profound gratitude to my partner for providing me with
continuous support, for listening to me for endless hours, for helping me to order my
thoughts, and for encouraging me throughout my years of study and during the process
of researching and writing this thesis. I could not have done this without you.
Richard Oprins
3
4
Abstract
In the search for more effectiveness and in an attempt to speed up delivery,
organizations and teams outside of the information technology (IT) domain are shifting.
This has resulted in a bigger utilization of the Agile way of working outside of the IT
domain.
The study that was conducted applied qualitative research methods and aimed to gain
more insight into the application of the Agile way of working by teams and
organizations. The data gathering was done by means of semi-structured interviews
with eighteen participants. The analysis was performed by using an open-, axial- and
selective coding of the data. The participants were spread across the globe and were
selected because of their experience in applying Agile outside of the IT domain.
The research question that was posed was: “How does Agile affect domains outside of IT
and their processes?”, and was subdivided into three other, crucial questions. The teams
and organizations that were studied used the Scrum software tool during their
adaptation and implementation of the Agile way of working. They were inspired to use
Scrum after they had seen it work in other organizations and after they had read about
its success in published literature. They were motivated by the transparency and
accelerated delivery that they saw when Agile was applied within teams.
The Agile way of working is based on practices and rituals performed by teams. The
results of this study demonstrated that Scrum was the most used and the most useful
tool. The teams, when utilizing Scrum, always adopted iteration and frequency, but they
did alter several rituals. The applications of Scrum resulted in the alteration of daily
meetings, which were changed in terms of their frequency, duration, and how and
where the meetings took place. Retrospective rituals were dropped by several teams, a
development that was surprising since the Agile way of working is the foundation for an
organization that is seeking to learn. Teams that do not reflect on their progress and on
their work do not improve.
The study looked into current developments and found that Agile ways of working are
usually adopted by domains close to IT first. Eventually, Agile produces change on the
organizational level. Not all teams will adopt Agile as we know it in IT, but will, instead,
use methods that focus on basic practices that are known in the different domains. This
can be seen by the rise in popularity of other methods such as: Design Thinking, Lean
Startup, Growth Hacking, and Beyond Budgeting.
5
6
Table of Contents
1. Introduction .............................................................................................................. 12
1.1. Personal motivation .............................................................................................. 12
1.2. Research aims and objectives ............................................................................... 13
1.3. Scope ..................................................................................................................... 14
1.4. Structure of the thesis ........................................................................................... 14
2. Theoretical framework .............................................................................................. 16
2.1. What is Agile? ........................................................................................................ 16
2.1.1. The basics of Agile ............................................................................................. 18
2.1.1.1. eXtreme Programming (XP) .......................................................................... 20
2.1.1.2. Scrum ............................................................................................................ 21
2.1.1.3. Kanban .......................................................................................................... 22
2.1.1.4. Agile software development ......................................................................... 23
2.1.2. Agile or agile ...................................................................................................... 25
2.1.3. Distinction between method and frameworks ................................................. 25
2.2. Agile in other domains and organizational departments ..................................... 26
2.2.1. Manufacturing ................................................................................................... 26
2.2.2. Marketing .......................................................................................................... 27
2.2.3. Sales .................................................................................................................. 27
2.2.4. Education .......................................................................................................... 28
2.2.5. Healthcare ......................................................................................................... 29
2.2.6. Finance .............................................................................................................. 30
2.2.7. Human Resources ............................................................................................. 30
2.3. Theoretical views on Agile management practices: Change management and
knowledge management ...................................................................................... 31
2.3.1. Organizational view ........................................................................................... 32
2.4. Knowledge management ...................................................................................... 35
2.5. Organizational routines ......................................................................................... 39
3. Methodology ............................................................................................................. 42
3.1. Research strategy and research design ................................................................ 42
3.1.1. The research paradigm ..................................................................................... 43
3.1.2. Research methodology ..................................................................................... 44
3.1.3. Research technique ........................................................................................... 44
3.2. Research process ................................................................................................... 45
3.2.1. Initial phase ....................................................................................................... 45
3.2.2. Interviews .......................................................................................................... 45
7
3.2.3. Grounded theory approach .............................................................................. 46
3.3. Case selection strategy ......................................................................................... 46
3.4. Data collection ...................................................................................................... 47
3.4.1. Coding ............................................................................................................... 47
4. Results ....................................................................................................................... 48
4.1. Participants ........................................................................................................... 48
4.2. Organizational domains found .............................................................................. 50
4.3. Agile frameworks applied ..................................................................................... 50
4.3.1. Reported application of Agile practices and rituals .......................................... 52
4.3.2. Reported alteration of Agile practices and rituals ............................................ 53
4.3.3. Reported application of practices and rituals “by the book” ........................... 54
4.4. Reported motivation to implement Agile practices and rituals ............................ 55
4.5. Critical success factors: starting small, senior level commitment, management
vision, customer focus .......................................................................................... 57
5. Discussion .................................................................................................................. 58
5.1. What is Agile beyond IT domains and practices? ................................................. 58
5.1.1. Agile practices in different domains ................................................................. 59
5.1.2. Which Agile practices are used and why? ......................................................... 60
5.1.3. What changes does the Agile way of working introduce? ................................ 61
5.1.4. What did participants say stayed the same? .................................................... 62
5.1.5. Which domains have adopted an Agile way of working? ................................. 64
5.2. Agile management: What is the bigger picture? .................................................. 65
5.2.1. Continuous learning retrospective: to improve Agile practices in new contexts
……………………………………………………………………………………………………………………..66
5.3. Agile and the evolution of management methods: What is next? ....................... 67
5.3.1. Which methods are on the horizon? ................................................................ 68
5.3.2. Domains with the need for creativity or feedback show a higher pace of change
and can take advantage of Agile methods ........................................................... 69
5.3.3. What was the purpose of using Agile? .............................................................. 71
5.4. Limitations and future work .................................................................................. 71
6. Conclusions and recommendations .......................................................................... 74
6.1. Conclusions ........................................................................................................... 74
6.2. Validity considerations .......................................................................................... 75
6.3. Recommendations for future research ................................................................. 76
7. References ................................................................................................................. 78
7.1. Literature references ............................................................................................ 78
7.2. Internet references ............................................................................................... 81
8
8. Appendix A – The Agile Manifesto ............................................................................ 84
9. Appendix B – Interviews............................................................................................ 86
9.1. Interview questions pilot ...................................................................................... 86
9.2. Introduction .......................................................................................................... 86
9.3. Experience agile outside of IT ............................................................................... 86
9.4. Change process / Introduction process agile in domains other than IT ............... 87
9.5. Process now .......................................................................................................... 87
9.5.1. Looking further .................................................................................................. 87
9.6. Interview questions ............................................................................................... 87
9.6.1. Introduction ...................................................................................................... 87
9.6.2. Experience agile outside of IT ........................................................................... 88
9.6.3. Change process / Introduction process agile in domains other than IT ........... 88
9.6.4. Process now ...................................................................................................... 89
9.6.5. Looking further .................................................................................................. 89
9.7. Altered Interview questions used with participant 9 ........................................... 89
9.7.1. Introduction / ethical considerations................................................................ 89
9.7.2. Experience agile outside of IT ........................................................................... 89
9.7.3. Change process / Introduction process agile in domains other than IT ........... 90
9.7.4. Process now ...................................................................................................... 90
9.7.5. Looking further .................................................................................................. 90
10. Appendix C - Code book ........................................................................................ 92
11. Appendix D - The interviews ................................................................................. 96
11.1. Interviews (Pilot-Phase) .................................................................................... 96
11.2. Interviews .......................................................................................................... 96
9
List of figures
Figure 1 - Origin of the Agile movement ........................................................................... 18
Figure 2 - An example of a waterfall project. .................................................................... 20
Figure 3 - eXtreme Programming explained ..................................................................... 21
Figure 4 - Scrum process ................................................................................................... 22
Figure 5 - Schematic presentation of the Buurtzorg way of working ............................... 29
Figure 6 - Triade Model ..................................................................................................... 32
Figure 7 - Organizational cultures ..................................................................................... 34
Figure 8 - Box of Bricks of research ................................................................................... 42
Figure 9 - The research pyramid ....................................................................................... 43
Figure 10 - Qualitative study coding process .................................................................... 45
Figure 11 - Graphical overview of rituals used.................................................................. 52
Figure 12 - Frameworks used, as stated by the respondents ........................................... 59
Figure 13 - Mastering new rituals ..................................................................................... 66
Figure 14 - Popularity of Agile frameworks as a search term from 2004 - 2018 .............. 68
Figure 15 - Trends in Agile methods from 2004 - 2018..................................................... 69
Figure 16 - Future of Employment .................................................................................... 70
Figure 17 - Domains where Agile was being implemented .............................................. 71
10
List of tables
Table 1 - Scope of this research ........................................................................................ 14
Table 2 - Organization metaphors used in change management ..................................... 33
Table 3 - Key issues in migrating to Agile .......................................................................... 35
Table 4 - Six characteristics for managing new product development process ............... 36
Table 5 - Variables in a complex environment .................................................................. 37
Table 6 - Participants: overview ........................................................................................ 49
Table 7 - Participants: geographical spread ...................................................................... 50
Table 8 - Industry and domains where Agile ways of working were found ...................... 50
Table 9 - Frameworks used within the domains discussed .............................................. 51
Table 10 - List of rituals used, as mentioned by the interviewees.................................... 53
Table 11 - Practices and rituals altered when applying Agile as stated by the respondents
........................................................................................................................................... 54
Table 12 - The unchanged rituals as described by the respondents when applying Agile 55
Table 13 - Motivation or reason why organizations started using an Agile way of working
........................................................................................................................................... 56
Table 14 - Inspiration for a change into an Agile way of working ..................................... 56
Table 15 - Return on investment comments made by the respondents .......................... 56
Table 16 - Advantages and challenges experienced by the respondents ......................... 57
Table 17 - High- and C-level management involvement as mentioned by the respondents
........................................................................................................................................... 57
Table 18 - Used practices and rituals ................................................................................ 57
Table 19 - Motivation to use the Agile framework ........................................................... 62
Table 20 - Industries where the Agile framework has been introduced .......................... 64
Table 21 - Domains that have adopted an Agile way of working ..................................... 64
11
List of abbreviations
ASD
Adaptive Software Development
DoD
Department of Defense
Dr
Doctor
DSDM
Dynamic Systems Development Method
FDD
Feature-Driven Development
HR
Human Resources
IT
Information Technology
JIT
Just in Time
OMG
Object Management Group
ROI
Return on Investment
TPS
Toyota Production System
US
United States
WIP
Work in Progress
XP
eXtreme Programming
12
1. Introduction
Organizations are confronted by stronger competition and a growing demand to deliver
products or services faster. This has motivated organizations to change, and was picked
up and discussed by a group of software developers who, in turn, created the
foundation for a people-centric, cooperative, collaborative, and dynamic framework
called Agile. Software development had created the working conditions to bring “agility”
(Agile) to the competitive playing field.
Agile methodologies are no longer limited to the domain of start-ups and small
development shops anymore, but are being adopted by large organizations on a global
scale (VersionOne, 2016) as a new way of working. Agile as a popular framework in
relation to Information Technology (IT) has been very successful in the software
development domain. There has been a big shift of non-IT organizations becoming
drawn to adopting Agile because they are interested in becoming more effective and in
speeding up delivery. Stettina & Hörz (2015) corroborate the effectiveness of Agile:
“Agile methods stimulate collaboration on project level through recurring routines;
however, they make frequent collaboration also more necessary on portfolio level”
(Stettina & Hörz, 2015).
The success of Agile in IT is making other organizations or organizational units more
interested in this new way of working because they realize that customers are
demanding a shorter time to market and are wanting to see more innovation in product
development. This is contributing to the drive for organizations to look for other ways of
working during the process of developing products and is leading to a growing interest
on the part of non-IT organizations in adopting the Agile. Organizations initially seeking
to adopt the Agile way of working are beginning this process by studying and using
approaches that have been used by IT companies and organizations.
1.1. Personal motivation
During the last few years, I have been a student who is interested in exploring the
boundary between the world of IT and business—the interaction between the two is
very interesting. The cooperation between the world of business and the world of IT is
very often challenging and, at times, can be confusing. The research that is reported
here explores and reflects those subtleties and difficulties.
The move towards the Agile way of working has grown in the last few decades. Around
me, I see an increase of organizations that are looking to adapt to the Agile way of
13
working. I am especially interested in exploring how IT-related frameworks can merge
into the activities of business. This is an important new phenomenon and is a topic that
should be explored, which is what my research involves.
1.2. Research aims and objectives
Despite the large-scale research that has been carried out on Agile and the way it has
been applied within the IT domain, there is either no or very limited research that has
been done on the application and its influence on how work is done outside of the IT
domain.
Nerur, Mahapatra, and Magalaraj found that the dynamic business environment is a
driving force for organizations to continuously adapt and change the way they are
structured and for them to design their strategies and policies to manage their
organizational surroundings. Changes impact various aspects of the organization,
including its structure, culture, and management practices (Nerur, Mahapatra, &
Mangalaraj, 2005).
The aim of this study is to contribute to the understanding of the influence that Agile
plays within non-IT organizations and how organizations have been inspired by Agile’s
influence in the IT world. Comprehending this mutual influence provides insight into
some of the important issues when one examines Agile’s working collaboration within
non-IT organizations.
To support an enhanced understanding, the research aims to create a model to
understand how Agile works within organizations. The overall research objective is to
recognize issues and what best practices could be used when Agile is applied to
activities, such as sales and marketing within non-IT organizations; in addition, Agile has
significant contributions to make within the field of change management and to an
understanding of how other departments could implement Agile.
To answer the above, the following research question has been formulated for this
thesis:
“How does Agile affect domains outside of IT and their processes?”
To answer this question, the following three guiding questions have been defined:
➢ What methods are used when Agile is applied as a way of working within a
non-IT organization?
14
➢ Which practices do organizations use when applying Agile within a non-IT
organization?
➢ What are the challenges, advantages, and key success factors of applying an
Agile way of working in a non-IT organization?
1.3. Scope
This study looks at the way organizations have adopted an Agile way of working within
their teams outside of the IT domain. The purpose of the research purpose is to explore
the way of working within those teams. The subject is broad and can be explored from
different angles. Therefore, it is important to apply a research process that is real-based,
thorough, and practical (Leeuw, 2001).
Looking at how the Agile way of working enhanced teamwork and to answer the
questions that guided this research, the study looked at how Agile was implemented on
the team level. The interviewees were asked about their knowledge about how teams
operate and about what methods were used to introduce change during the
implementation of Agile. The research did not examine how the Agile way of working
had been applied at the organizational level, nor did this research assess whether an
Agile implementation had been successful or not. The main objective was to probe
different methods used and how they were applied (tab. 1).
Subject
Scope
Individual
Not in scope
Team level
In scope
Project level
In scope
Organizational level
Not in scope
IT
Not in scope
Non-IT
In scope
Table 1 - Scope of this research
1.4. Structure of the thesis
This thesis has been structured as follows: Chapter 1 introduces the research subject,
and details the motivation, the aim, the objectives, and the scope of this study. Chapter
2 focuses on the theoretical framework and summarizes what the literature on the
subject says: what Agile is; how Agile is applied in other domains; and theoretical
findings on Agile management practices and change management. It also describes the
role of knowledge management and of routines used in organizations. Chapter 3
presents the methodology applied and explains the research strategy, the research
design, the research process, and data collection and selection. Chapter 4 presents the
results of this study and the participants, departments applying Agile, the Agile
15
frameworks, and the motivational and critical success factors as reported by the
participants. Chapter 5 discusses how Agile is viewed and how it operates outside the
realm of IT; Agile management; and the evolution of management methods. Chapter 6
completes the research by presenting conclusions and recommendations for future
research.
16
2. Theoretical framework
This chapter focuses on providing a review of the literature explaining the history of
Agile and what Agile is (2.1). This research summarized in this study focuses only on non-
IT organizations where the Agile way of working is broadly applied; this has been done in
order to learn the basics of Agile (2.2). An important part of implementing the Agile way
of working is change management and organizational learning (2.3).
2.1. What is Agile?
In the late 1980s, US industry was struggling to compete with its rivals—the Asian
Tigers
1
—which contributed to the growing concern about the downturn of the US
manufacturing industry and the loss of American competitiveness. This led to the
appointment of an inter-agency task force by US Congress, which instructed the
Department of Defense (DoD) to look at US manufacturing with the objective to make it
more competitive (Kidd, Agile manufacturing: a strategy for the 21st century, 2004). The
recommendations are summarized in the report: “21st Century Manufacturing
Enterprise Strategy (1991)” published by the Lacocca Institute at Lehigh University in
Bethlehem, Pennsylvania.
This was the first time the term “Agility” had been used to describe a working
method/procedure to counter competing forces in manufacturing. Kidd provided three
definitions on how Agility could be operationalized:
The concept of Agile Manufacturing is built around the synthesis of a number of
enterprises that each have some core skills or competencies which they bring to
a joint venturing operation, which is based on using each partner’s facilities and
resources. For this reason, these joint venture enterprises are called virtual
corporations, because they do not own significant capital resources of their
own. This helps to make them Agile, as they can be formed and changed very
rapidly (Kidd, 1994).
He went on to provide the following, additional information on Agile:
An Agile corporation is a fast moving, adaptable and robust business enterprise
capable of rapid reconfiguration in response to market opportunities. Such a
corporation is founded on appropriate processes and structures and the
1
Asian Tigers is an acronym for: South Korea, Taiwan, Singapore, and Hong Kong. They all had experienced
strong industrialization since the 1960s and rapidly grew, becoming a threat to the United States.
17
integration of technology, organization and people into a coordinated system in
order to achieve a quantum leap forward in competitive performance by
delivering capabilities that surpass those obtained from current enterprise
practices (Kidd, 1995).
The Agile that arises can be used for competitive advantage, by being able to
respond rapidly to changes occurring in the market environment and through
the ability to use and exploit a fundamental resource - knowledge. People need
to be brought together, in dynamic teams formed around clearly defined market
opportunities, so that it becomes possible to lever one another’s knowledge.
Through this process is sought the transformation of knowledge into new
products and services (Kidd, 1994).
The inter-agency body concluded in their research that the era of mass production was
ending and that US industry must focus on Agile manufacturing to regain its leadership
in world manufacturing.
This vision concentrated on achieving customer focus and Rapid product creation
(Nagel, 1992) and gave an overview on the way US industry should develop.
The origins of how Agile works lies in quality management (fig. 1). Edward Deming,
during a congress in Japan, presented the Deming Wheel (Deming, 1950). This was an
alteration of the Shewhart cycle, “Producing, Selling and Inspecting” to which Deming
added a fourth step, “Redesign after marketing research”. This was adopted by the
Japanese and became known as the Design-Production-Check-Research cycle (Moen &
Norman, 2006).
18
Figure 1 - Origin of the Agile movement
In 1979, the Toyota Production System (TPS) gained interest by the progress Toyota had
made since the 1950s. Quality had been significantly improved. The gap between Toyota
and other car manufacturers and the role that TPS played in gaining the advantage was
presented in the book, The Machine that Changed the World (1991), by James P.
Womack, Daniel Roos, and Daniel T. Jones. The TPS was named Lean for the first time.
The authors studied this way of working and presented the five lean principles in their
book Lean Thinking (1996).
The quality presented by Toyota was also studied and described by Hirotaka Takeuchi
and Ikujiro Nonaka in their article in the Harvard Business Review of February 1986
(Takeuchi & Nonaka, 1986), where they mentioned the iterative development flow
“Scrum”, named after a rugby move, “scrummage”, which means restarting a game after
a minor infringement. A group of eight rugby players work together to get possession of
the ball in the game. This was later used by Jeff Sutherland and Keith Schwaber as an
acronym in their Agile framework “Scrum”.
2.1.1. The basics of Agile
In 2001, seventeen people came together and created the Agile “Manifesto for Agile
Software Development” (Beck, et al., 2001). The full manifesto can be found in chapter
19
8. This manifesto is based on twelve principles, the main focus of which is continuous
delivery of valued software. To achieve this, a feedback loop is used to create the
possibility for the customer to change the requirements during the software lifecycle,
thus giving the customer a competitive advantage. This loop applies the following 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
During the last few decades, Agile has spread from software development into other
domains within organizations. The motivation for this, becoming more flexible and thus
outperforming rivals, is the same as when the Agile movement started in the 1990s. In a
review of Agility across many disciplines. Conboy elaborates and evaluates the Agile
framework in a software development context and found “Agile supply chains”, “Agile
decision support systems”, and “Agile workforces”. These terms were applied
collectively throughout an enterprise. He suggests that Agility must be viewed in a
“business-wide context”, which means that it is “not a series of techniques but a
fundamental management philosophy” (Conboy & Fitzgerald, 2004).
To implement this Agile way of working, those engaged in software development base
their activities on the frequent delivery of working software. The focus is on keeping the
shortest possible time scale while delivering working software.
To be successful as a team, it is important that those involved in the team work closely
together on a daily basis. In addition, it is critical that a certain level of confidence is
maintained—that everyone is working to get the job done. Regular reflection and
feedback ensure that the team becomes more effective.
The adjectives that are used in an Agile way of working to describe the focus on a short,
repetitive work cycle and delivering a functional product are “iterative” and
“incremental”. When using the waterfall project method (fig. 2), every step has to be
finished before continuing to the next step, which gives project teams only one chance
to get each aspect of a project right. In an Agile paradigm, every aspect of
development—requirements, design, and so on— is revisited throughout the lifecycle.
There is always the possibility of changing the direction of the delivered product.
20
Figure 2 - An example of a waterfall project.
The field of software delivery has developed different methodologies to embrace an
Agile way of working. Some examples of this are: EXtreme Programming (XP); Scrum;
the Dynamic Systems Development Method (DSDM); Feature-Driven Development
(FDD); Kanban; Adaptive Software Development (ASD); Lean; and Crystal, from which
Lean, Scrum, XP, and Kanban are most used methodologies at this time (VersionOne,
2016). It is not appropriate to describe all the methodologies in detail; given the scope
of this study, this paper will only describe the most used methods in IT: eXtreme
Programming (2.1.1.1), Scrum (2.1.1.2), and Kanban (2.1.1.3).
There is no best choice between the different methods. With XP, there are more rules to
follow than with Kanban. There is not just one best option; sometimes, even
combinations of options are used (Kniberg & Skarin, 2010).
2.1.1.1. eXtreme Programming (XP)
EXtreme Programming was developed by Kent Beck, Ken Auer, Ward Cunningham,
Martin Fowler, and Ron Jeffries, all of whom were also developers and signers of the
Agile Manifesto. EXtreme Programming improved software development in five
essential ways—communication, simplicity, feedback, respect, and courage. By
constantly communicating with customers and fellow programmers, the team could
keep the design clean and simple. From day one, the testers started giving feedback to
the team. The product was delivered to the customers as soon as possible. The team
implemented changes as suggested by the client (Wells, 2017).
Requirements
Design
Implement
Test
Maintain
21
EXtreme Programming consists of a set of rules divided into five parts: planning,
managing, designing, coding, and testing. It was developed to be used in problem
domains where both requirements and the functionality often change. This is the reason
why risk is addressed early in the process (fig. 3). XP is set up to mitigate risk in order to
increase success.
Figure 3 - eXtreme Programming explained
Source: http://www.agile-process.org/
2.1.1.2. Scrum
Since the publication of the Agile Manifesto, massive research has been carried out in
relation to Agile software development. Dingsøyr et al. concluded the following: “After
an initial spurt of studies on eXtreme Programming, the academic community seems to
have turned its attention to Scrum” (Dingsøyr, Nerur, Balijepally, & Moe, 2012).
Jeff Sutherland and Ken Schwaber (Schwaber & Sutherland, Scrum Guide, 2016) describe
Scrum as a framework that can be used to address complex adaptive problems and to
manage complex product development (fig. 4). It is based on empirical process control
theory and it is based on three pillars: transparency, inspection, and adaption, which are
achieved as follows: Transparency is attained when all the participants are using the
same terminology defined in the same manner. Inspection is verified when a common
definition of “done” is agreed and verified; in addition, stakeholder involvement is high
and delivery is frequent, thus ensuring that progress can be corroborated and
undesirable outcomes can be identified during an early phase. Adaptation is assured
22
through frequent inspections during the process to ensure that progress is being made
and, if the resulting product appears to be unacceptable, adjustments must be made as
soon as possible to minimize any divergence from the desired end-product.
Figure 4 - Scrum process
Scrum teams are self-organizing and are involved in three roles: product owner, Scrum
master, and the development team. The product owner is responsible for maximizing
the value of the product and the work of the development team. The Scrum master is
responsible for ensuring that the Scrum principles are understood and followed by the
team and that the development team consists of the Professionals who, on an
incremental basis, deliver a potential viable product which meets the agreed definition
of “done”.
Scrum depends on the team improving in accordance with five values: commitment,
courage, focus, openness, and respect. The adherence to these five values will maintain
its reputation and that it is successful. Scrum events are time-boxed meaning that a
fixed period of time is allocated in each activity; this means that the event is finished
when the result is met or when time is up. Thus, this means that development proceeds
in sprints, which are time boxed between one and four weeks. This keeps the focus on
the delivered product and keeps complexity and risk low.
2.1.1.3. Kanban
Kanban focuses on the capacity within the team and adjusts the work in progress (WIP)
according to this capacity. This creates more flexible planning options for the team,
faster output, clearer focus, and transparency throughout the development cycle.
23
The work of the teams is placed on a Kanban board and is used to visualize the work and
to optimize the flow of the work among the team members. The basic Kanban board
consists of a three-step workflow: “to do”, “in progress”, and “done”. The board may
vary based on team size, structure, or objective.
The team focuses on the work in progress and, when ready, picks the most important
piece of work to carry out from the “to do” list. The product owner prioritizes this list,
ensuring that the team always goes for maximum customer-valued work. Unlike Scrum,
Kanban has no fixed iterations. The work is done when it’s done. The lead time (time
needed to complete work) depends on the skills within the teams. This can be controlled
by ensuring that there are unique and irreplaceable skills within the team.
2.1.1.4. Agile software development
The success of Agile software development can be encapsulated by the three factors
that guarantee the success of a project—reduced time, reduced costs, and increased
quality. In addition to these success factors, two more factors/categories have been
introduced by Subhas Chandra Misra, Vinod Kumar, and Uma Kumar. These categories
are: organizational factors and people factors (Misra, Kumar, & Kumar, 2009). In their
research, they found nine factors which have a significant relationship to success:
• Customer satisfaction
• Customer collaboration
• Customer commitment
• Decision time
• Corporate culture
• Personal characteristics
• Societal culture
• Training and learning
Customer collaboration and customer commitment are found to be very important, and
are the two factors that drive the development teams, since they want close customer
collaboration in order to keep the customer closely associated, engaged, and committed
to the project. The development team is trying to satisfy the customer by developing
software efficiently.
24
One advantage of Agile is speed and another success factor is “decision time”. The fact
that Agile software development is fast and iterative enables important decisions to be
made quickly, thus contributing to its success.
An important success factor is the corporate culture. Creating a secure environment that
fosters supportive management, that has all stakeholders involved, that removes politics
from the scene, and that promotes good customer-vendor relationship within the
organization ensures that the team is adaptable to change.
Social culture and personal characteristics are important factors for success. When
creating a team, managers should include people who are communicative, dynamic,
progressive in attitude, and who share a similar social culture.
In terms of training and learning, it was concluded that the best contribution to success
was to encourage continuous learning within the team by their training each other. The
team members should be helped by mentoring and by creating an open space for
discussions.
These success factors are also described by Tsun Chow and Dac-Buu Cao (Chow & Cao,
2008) in their survey study on critical success factors in Agile projects. In their study they
found the following contributed to success:
• A correct delivery strategy
• The proper practice of Agile software engineering techniques
• A high-calibre team
Three additional factors that have been identified as being critical to enhancing success
are:
• A good Agile project management process
• An Agile-friendly team environment
• Strong customer involvement
Although Agile software development is popular with practitioners, there is no specific
reason as to why. Torgeir Dingsur et al. (Dingsøyr, Nerur, Balijepally, & Moe, 2012)
concluded in the examination of publications and citations that the transformation
delivered by the Agile Manifesto was remarkable. All the different methods, tools,
techniques, and best practices have been accepted by practitioners around the world,
who have developed a diversity of methods. The Agile Manifesto has been applied to XP,
25
Scrum, Lean Software Development, FDD, and crystal methodologies, and so on. Every
method claims to follow the core principles of the Agile Manifesto (Dingsøyr, Nerur,
Balijepally, & Moe, 2012).
2.1.2. Agile or agile
In this thesis, Agile has usually been capitalized. The Agile community speaks of “Agile”
and “agile”. Agile with a small letter (usually “agility”) refers to the usual English
adjective of working in a fluid, quick and responsive manner. However, this thesis
principally deals with Agile methods based on Scrum frameworks, and thus the capital
letter been predominantly the usage of choice.
This report focuses on Agile as being the changes that must be made in order to make
an organization more flexible.
2.1.3. Distinction between method and frameworks
During the interviews, the respondents alternated between mentioning frameworks and
methods to explain their way of using Agile in the organization. Some explicitly
mentioned a framework or method to describe a specific behaviour. To be consistent in
this report, I will use the definitions as described by van Haren publishing (Verbrugge,
2018). A framework is described as follows:
A framework is an entity between a ‘model’ and a ‘method’. A framework is, or
contains, a (not completely detailed) structure or system for the realization of a
defined result/goal. Many frameworks comprise one or more models, based on
the modelling techniques mentioned above and often based on (best) practices.
Compared with methods, frameworks give the users much more freedom
regarding the (partial or entire) use of the framework and the use of the models
or techniques therein (Verbrugge, 2018).
A method is described as:
A method is a systematic approach to achieve a specific result or goal and offers
a description in a cohesive and (scientific) consistent way of the approach that
leads to the desired result/goal. Minimally a method consists of a way of
Source 1- https://www.thefreedictionary.com
ag·ile
adjective
1. Characterized by quickness, lightness, and ease of movement; nimble.
2. Mentally quick or alert: an agile mind.
26
thinking and a way of working. Possible additional components of a method are:
management model(s), presentation model(s), support model(s) (prescriptions,
instructions, tips, examples, etc.), based on the modelling techniques mentioned
above. The meanings of the terms ‘practice’ and ‘model’ are much broader than
the term ‘method’ (Verbrugge, 2018).
2.2. Agile in other domains and organizational departments
The literature research revealed that an Agile way of working is described and studied in
domains outside of IT and is summarized in the following sections: manufacturing
(2.2.1), marketing (2.2.2), sales (2.2.3), education (2.2.4), healthcare (2.2.5), finance
(2.2.6) and Human Resources (HR) (2.2.7).
2.2.1. Manufacturing
Manivelmuralidaran (Manivelmuralidaran, 2015) found that Agile manufacturing is
different from traditional manufacturing. Agile manufacturing concentrates on customer
enrichment and competitiveness through cooperation. Because software developers in
general are higher educated and trained, Agile manufacturing could integrate people,
information, and technology in the same team.
Organizational needs are described by Manivelmuralidaran as:
A wide range of knowledge which addressed all dimensions of the system
including organization, people, technology, management accounting practices,
etc. Most importantly the inter-related nature of all these areas needs to be
recognized and an interdisciplinary manufacturing system design method must
be adopted as standard practice (Manivelmuralidaran, 2015).
This can be explained as the next step in developing the multidisciplinary approaches
that professionals are currently using.
Manivelmuralidaran mentions four transitions that must be present during any efforts
to achieve Agile manufacturing. These transitions are:
• An examination and definition of the underlying conceptual framework on
which Agile manufacturing enterprises will be built
• An exploration and comprehension of the nature of the mass production
paradigm and the nature of the cultural and methodological difficulties
involved in the transition to Agile manufacturing
27
• A definition of a methodology for designing a 21st century manufacturing
enterprise
• An understanding that Agile manufacturing is based on a systems
perspective of technology, organization, and people, and tied to clear
business visions and goals
In their article, “Agile manufacturing: Relation to JIT, operational performance and firm
performance,” R. Samuel Saleb, Kenneth W., Green Jr. and Dwayne Whitten (Samuel
Saleb, Green, Whitten, & Green, 2011) concluded that:
In the manufacturing sector, Just in Time (JIT)-purchasing combined with JIT-
production enhances a firm’s manufacturing agility. Improved manufacturing
agility leads to the improved operating performance of the firm, which in turn
leads to the improved marketing and financial performance of the firm (Samuel
Saleb, Green, Whitten, & Green, 2011).
2.2.2. Marketing
Marketing is another area where Agile ways of working have had an impact.
This has been confirmed by such people as Claire Drumond (Drumond, 2016) from
Atlassian Software, who wrote in a blog on her company website: “Marketers are
constantly seeking ways to be faster and nimbler, especially as social media, content,
and digital marketing technology have changed the way they’ve traditionally gone to
market. The days of executing static campaigns planned months in advance are gone
(Drumond, 2016).
Marketing has adopted Agile ways of working because of faster feedback from the
customer and the fact that the end product is improved in a very short space of time.
Marketing is a domain where an alternative manifesto, based on Agile principles, has
been formulated. This manifesto is based on previous published marketing manifestos
(Ewel, et al., 2018).
2.2.3. Sales
Introducing Agile into the sales domain has had some surprising results. This has been
presented by Rini van Solingen, Jeff Sutherland, and Denny de Waard (van Solingen,
Sutherland, & de Waard, 2011) at the 2011 Agile conference in Salt Lake City. They
introduced the Agile way of working into the sales domain and found some surprising
28
results. They concluded in their research three findings applicable when Agile is
introduced into the sales domain:
• Sales are much more predictable than expected. Cause and effect become
visible when using Scrum.
• Scrum as the sales best practice allows the sales teams transparency into
the full sales process and helps them realize the impact of sales on other
company divisions.
• Scrum showed how maintaining relationships and referrals are vital in sales.
Agile is useful when seeking to create a clear picture of the needs of the customer. The
feedback received when Agile ways of working have been applied is that Agile gives
information on how to improve client focus and give sales people gain an insight into
their behaviour in the relation with the client so they can become more effective
(Steenberg, 2016).
2.2.4. Education
Agile is also slowly claiming a position in education. Grigori Melnik and Frank Maurer
describe in their paper the experiences they have had with introducing Agile in the
classroom (Melnik & Maurer, 2003). Introducing the Agile way of working at schools has
two advantages: It prepares students to be flexible when they start working on
assignments in the software industry. This means that schools must be open to change
and prepare everyone for this new emerging demand from the industry (Melnik &
Maurer, 2003). Second, it gives teachers important feedback on the progress students
are making.
However, roles in the classroom differ from the roles on Agile teams. In class, the
teachers act as product owners and Scrum masters who provide the backlog. The work
of each team is reviewed at the end of each sprint by the teacher, who also provides the
feedback as well (Cubric, 2013).
The above has also been demonstrated in the research of Christoph Johann Stettina,
Zhao Zhou, Thomas Bäck, and Bernhard Katzy (Stettina, Zhou, Bäck, & Katzy, 2013). They
found that the Agile way of working in education leads to a more mature, practical, and
academic standards because of an iterative coaching routine. By shortening and at the
same time intensifying the coaching, students become more involved. They also found
that coaching in teams provided a higher information exchange and student satisfaction
29
in contrast to the bit of extra effort that was needed. (Stettina, Zhou, Bäck, & Katzy,
2013).
2.2.5. Healthcare
There is little literature published on the application of the Agile way of working in
healthcare. The one article that this research made use of, which was on the Scrum
Alliance website, pointed out the efficacy of implementing Agile, and described how a
family practice in the southeastern United States was transformed by adopting an Agile
method of continual learning and adaptation (King & King, 2018). King gives an example
of how Scrum was applied to a family practice and how it maintained and improved the
skills of doctors, nurses, and medical assistants. The transformation was documented by
measuring clinical skills at the start of the application of Agile and then demonstrated
what progress had been made through an iterative development of those skills. The
improvements were demonstrated to doctors, who gave feedback on the presentation
telling them about how their skills could be developed.
A very powerful example which can be given about the efficacy of applying Agile to
healthcare can be found in the Netherlands. A home care organization called
“Buurtzorg” is a Dutch healthcare organization which was founded in 2007 and has now
grown to more than 8,000 nurses delivering care to approximately 70,000 clients
nationwide. The nurses have been organized into small teams (maximum 12 nurses per
team) and are supported by handheld technology that simplifies the complexity of the
daily routines (KPMG Healthcare, 2014). The process used has similarities with the Agile
way of working (fig. 5).
Figure 5 - Schematic presentation of the Buurtzorg way of working
(Source: http://buurtzorg-services-japan.com/wp-content/themes/buurtzorg/images/service/img_service03.jpg)
The team starts with an assessment of the clients’ needs; these are matched with the
nurse’s needs, accepted by the team, and assigned to one or two nurses. When the
30
team grows up to 12 nurses, they split up in two new teams. Two nurses are responsible
for 6 to 8 clients. Coaches are available to support the teams and to solve problems.
Every other week, the team discusses and reviews cases and problems. Some team
members have specific expertise, such as “dementia care”. The teams are self-
supportive and responsible (Gray, Sarnak, & Burg, 2015).
2.2.6. Finance
The results were minimal in the search for literature on the application of Agile in the
financial domain. There is an enormous amount of documentation available on applying
the Agile way of working within financial institutes, but most material is based on the IT
used by financial organizations.
This section of the thesis explores which Agile methods are used by finance
departments. One blog article has been found, which was posted in September 2011 by
Christine Hegarty (Hegarty, 2011) from Scrum Inc. She describes how Agile was applied
during the synchronization of an organization’s financial obligations, and potentially
involved such things as bank statements (arriving monthly) and taxes, which are
submitted quarterly and yearly. There was no follow-up on the experiences that had
been described (Hegarty, 2011), despite a request being made by an unknown
interested individual who asked for more information on 24 May 2013. The only follow-
up that has been provided is by Jeff Sutherland, who stated that applying the points
Hegarty made in her blog revamped the financial system. The velocity increased and
finance now probably takes 25% of the effort it used to. No references were provided as
to which department or domain was the object of this study.
2.2.7. Human Resources
The search for literature about the application of an Agile way of working in the domain
of Human Resources yielded minimal results. One article on “How HR teams can benefit
from Scrum” was posted in 2013 by SCRUMstudy on their website. It describes a way
that Agile, specifically Scrum, can be applied in the HR department (SCRUMstudy,
2013
2
). The post has no references to examples or to other literature. The described way
of working is mainly Scrum-based, as described in the Scrum guide.
Another article that was identified described why HR must embrace the Agile way of
working. Because HR works in yearly or quarterly cycles, this way of working is becoming
2
https://www.scrumstudy.com/
31
an obstruction for organizations who are adopting the Agile way of working (Gothelf,
2017). The author also states that there is very little literature on Agile within the HR
domain. At the end of the article, there is advice as to how to introduce Agile into the
HR community. The suggested starting point is holding bi-weekly retrospective
meetings. This short iteration helps to improve processes and motivates staff to initiate
change by giving and receiving ideas and feedback in a quick manner.
2.3. Theoretical views on Agile management practices: Change
management and knowledge management
To transform an organization to a new way of working, change is needed. These changes
are sometimes small, but the results can be enormous. For an organization transforming
itself from a “waterfall” business model into an Agile way of working, the change is
considered huge. To guide everyone who is involved in changing from old to new ways
of working, change management strategies are needed.
Sridhar Nerur, Radhakanta Mahapatra, and George Mangalaraj (Nerur, Mahapatra, &
Mangalaraj, 2005) conclude that a shift towards an Agile organization is a change from
autocratic management to leadership and collaboration. Organizations which make the
transformation become responsive and flexible. Focusing less on
paperwork/documentation and more on Lean approaches, transforms knowledge in
Agile organizations into tacit knowledge. This can be done by focusing on knowledge
management, which is becoming vitally important for Agile organizations. This change
creates a major shift and requires adaptation to changed work procedures, tools and
techniques, communication channels, problem-solving strategies, and the roles people
play in support of the new, flexible way of working (Nerur, Mahapatra, & Mangalaraj,
2005).
This research did not test the model itself, but examined how the process of change had
been implemented. The Triade Model of Theo Poiesz (Poiesz, 2014) was applied and
formed the basis for the way teams or organizational change had occurred. Since the
change to an Agile way of working principally involves changes in behaviour, this model
was a good choice because it focuses on the application of the following three pillars of
behaviour:
32
Motivation:
An examination of the extent to which an individual is prepared to
reach the set objective or shared interests to achieve a particular
behaviour.
Capacity:
An analysis of the availability of the quality, skills, or instruments
that are required to achieve specific behaviours.
Opportunity:
An enquiry as to twitch existing conditions promote or hinder
specific behaviours. These factors stipulate whether and to what
extent the behaviours can be changed.
The Triade Model suggests a multiplicative relationship between the three factors (fig.
6). Theo Poiesz concluded that the three components must be altered at the same time
to achieve the desired affects and to ensure that the individual experiences change as a
flow. This directly impacts individual behaviour, which has to be altered when an Agile
way of working is deployed.
Figure 6 - Triade Model
2.3.1. Organizational view
This research examined the methods used in non-IT domains that have made or that are
still in the process of making the transformation towards an Agile way of working. It
became clear that change should be implemented throughout an entire organization.
For example, product development is currently carried out in most organizations with
the help of project management. Project management carried out in a traditional
manner involves control over budgets, schedules, and scope. When projects are
implemented in an Agile manner, the focus is on achieving business value, with
questions about budgets and schedules becoming secondary issues (Fernandez &
Fernandez, Winter 2008/2009).
Behaviour
Opportunity
Capacity
Motivation
33
By adapting Agile methods of working and shifting the way development is managed,
change takes place on the organizational, team, and individual level.
To focus on change management methods, this research made use of the models and
approaches to organizational change as defined by Esther Cameron and Mike Green
(Cameron & Green, 2015). In this model, organizations are classified according to four
metaphors taken from Morgan’s organizational metaphors. These metaphors are listed
(tab. 2), which helps to identify the kind of organization that is involved and thus the
specific change methods that must be applied in order to organizational shifts to be
made:
Machine
The designed end state can be worked towards. Resistance must be
managed. Change needs to be planned and controlled.
Political system
Changes must be supported by a powerful person. Change needs a
powerful coalition behind it. Defining who are winners and losers is
important.
Organisms
Change is adaptive. Individuals and groups need to be psychologically
aware of the “felt need” for change. The end state can be defined and
worked towards.
Flux and
transformations
Change cannot be managed; it emerges. Managers are part of the
system, not outside the system. Conflict is useful. Managers enable
good connections to be made between people.
Table 2 - Reprinted from: (Cameron & Green, 2015) Organization metaphors used in change management
Changing the culture and mindsets of people is not easy and takes time. To alter an
organization’s culture, a change strategy should be chosen. Cameron and Green
developed a cultural framework (fig. 7) (Cameron & Green, 2015) which can assist an
organization to decide which strategy is best to follow when moving from one culture
into another.
34
Flexibility & Discretion
Internal Focus & Integration
Clan
Adhocracy
External Focus & Differentiation
Hierarchy
Market
Stability & Control
Figure 7 - Reprinted from (Cameron & Green, 2015) Organizational cultures
By knowing the current, prevailing culture and the culture the organization desires to
achieve, needed interventions can be identified to make the shift from one culture to
another.
In addition to changing an organization’s culture, there will be other outstanding issues
that will have to be solved. Sridhar Nerur, Radhakanta Mahapatra, and George
Mangalaraj (Nerur & Balijepally, 2007) found in their research a set of key issues (tab. 3)
that would arise when the shift to an Agile way of working was taking place. Despite the
fact that they looked at issues involving software development, their findings are
applicable since they have to do with what happens in the organizational domain. The
challenge to implement Agile is bigger and more problematic in bureaucracies and
informal organizations than it is in organizations that are open to innovation.
35
Management and organizational
• Organizational culture
• Management style
• Organizational form
• Management of software development knowledge
• Reward systems
People
• Working effectively in a team
• High level of competence
• Customer relationships—commitment, knowledge, proximity, trust, respect
Process
• Change from process-centric to a feature-driven, people-centric approach
• Short, iterative, test-driven development that emphasizes adaptability
• Managing large, scalable projects
• Selecting an appropriate Agile method
Technology (Tools and Techniques)
• Appropriateness of existing technology and tools
• New skill sets—refactoring, configuration management, units
Table 3 - Reprinted from (Nerur, Mahapatra, & Mangalaraj, 2005) - Key issues in migrating to Agile
2.4. Knowledge management
Using the perspective of knowledge management, this section looks at how Agile
methods of working have performed over the last few decades and examines the
current ways organizations are working with Agile.
In the article “The new new product development game”, Takeuchi and Nonaka
(Takeuchi & Nonaka, 1986) explicate the principles inherent to a holistic approach in
product development. By using this approach, organizations demonstrate that they are
prepared to meet competitive requirements. The authors observed the development
process which was unfolding in several organizations in the United States and Japan, and
found that several factors were present when the development process was successful.
These success factors have been refined to six characteristics (tab. 4) that are key to
managing new product development processes.
36
#
Name
Short description
1
Built-in instability
Management creates tension (instability) in the team by setting a broad
goal or general strategic direction.
2
Self-organizing project
teams
A broad diversity of members specifically chosen to be part of the team
must and can organize themselves; they will set targets to meet the
goals or the directions set by management.
3
Overlapping
development phases
Using overlapping development phases, the teams merge when the
semi-finished product is transferred from them onto another team. This
creates a shared responsibility.
4
"Multilearning"
Learning across multiple levels (individual, group, and corporate) but
also across multiple functions takes place. Team members have to learn
about adjacent techniques, technologies, and functionality.
5
Subtle control
Management, by promoting self-control and fostering a servant
environment where people are carefully picked, can create the
following conditions: an open work environment, evaluation and
reward-based group performance, the management of differences in
rhythm of the development process, an environment that tolerates
mistakes and that encourages suppliers to become self-organizing; in
this way, management is involved enough to present the team from
going into chaos.
6
Transfer of learning
Create moments where knowledge can be shared and restructure teams
after completion (without weakening them) helps to share the
knowledge gained within the organization.
Table 4 - Six characteristics for managing new product development process (Takeuchi & Nonaka, 1986)
The authors provide a new approach with examples and methods that serve as a handle,
which then can be used as a game changer.
Ken Schwaber, in his article, “The Scrum development process”, (Schwaber, 1995),
referenced several articles, including the article of Takeuchi, “The new new
development process” (Takeuchi & Nonaka, 1986), thus confirming the importance of
the ideas put forward by Takauchi and Nonaka. In his article, Schwaber introduced a
development process called Scrum, which claimed to be the solution for increasing
flexibility and being responsive to requirements, even if they are (re)defined during the
development process.
Scrum is defined as a form of black box process management that uses the known
project roles defined by the Object Management Group
3
. The main purpose of Scrum
methodology is management, enhancement, and maintenance for an existing product or
system. Scrum tries to solve several problems posed by a growing complex environment
3
Object Management Group® (OMG®) is an international, open membership, not-for-profit technology
standards consortium, founded in 1989 (source: http://www.omg.org/about/index.htm)
37
by describing an emerging set of environmental variables (tab. 5) that provide
complexity.
Availability of skilled professionals
Domain expertise
Time/ funding
Stability of implementation technology
New features
Other variables
Stability and power of tools
Methodology
Effectiveness of methods
Competition
Table 5 - Variables in a complex environment
Although several attempts were made, no real answer has been presented on how to
manage these variables in such a way that results become more readily predictable, that
risk is lowered, and that the development process is better defined. Several methods
were developed to deal with these issues, but all have their downside. The “waterfall
method”, which is a more structured, less flexible, and less iterative process is not good
at responding to unexpected changes. The spiral methodology is based on iterations
“spiraling” through the phases (determine objectives; evaluate; identify and resolve risk;
develop product; and plan next phase) of development. Each phase is built on a small
waterfall process. Although the spiral process provides some flexibility, it is still based on
linear development processes. The iterative methodology adds risk controls in order to
deliver a more predictable outcome, but due to the stiffness and inflexibility of the
development process, unpredictable behaviours occur throughout the development
process.
In spite of the complex and complicated process, Scrum delivers the needed flexibility
and preferred control within the development process. This development process is in
itself unpredictable, but control mechanisms have been embedded to control this
unpredictability. This is done by defining the deliverables iterative and by evolving them
during the project, thus responding to the changing environment. Thus, the Scrum
approach uses three phases: pregame, game, and postgame. During the game, the
development is done in sprints built on the variables of time, requirements, quality,
cost, and competitiveness. The interaction among these variables determines the end of
the phase.
During the pregame phase, there are two products to be delivered. First, the new
release is set within the context of the currently known backlog and, second, the
development is placed in the system’s architecture. During the postgame phase, the
release is prepared, final documentation is finished, and all is tested and released. Every
sprint has a review moment where the whole team looks back and examines
38
functionality, the system, and the changes made to the backlog. Based on this review,
new items can be put on the backlog, which changes the content and direction of the
deliverables.
The development process is controlled by using loose controls such as: the backlog,
release enhancements, packets, changes, problems, risks, solutions, and issues. These
controls are used in different phases of development. The team is a small group
consisting of developers, documenters, and quality-control staff. The team defines the
backlog and manages all the problems during the sprint. Team members are selected for
their knowledge and expertise on the packages and not on their domain competence.
Product management is described as management controlling the deliverables. If these
measurements and controls are not used correctly, the results become unpredictable,
which makes Scrum ineffective. Scrum is defined as an empirical method, meaning that
there is a critical need to introduce measurement and controls because the
development process is very loosely defined.
The advantage of applying Scrum is that it provides flexibility in terms of planning
product releases and, in parallel, in terms of managing the variables as the project
advances towards completion. Tacit knowledge is shared within the small teams during
sprints, and developers are free to create surprising solutions as they learn.
The current application of Scrum is based on the thoughts of Ken Schwaber and the
Agile Manifesto. When the Scrum methodology is viewed against its origins, it is clear
that it originated from the work of Takeuchi Nonaka, a fact that leads to some
interesting conclusions.
Both authors focus on an iterative and overlapping approach to creating flexibility. Both
are working with self-organizing teams, which are set up in a way that encourages tacit
knowledge, which they derive from available explicit knowledge (measurements and
documentation from previous sprints). Where Nonaka focuses on maximizing available
knowledge as a means of providing the success factors during the development process,
Schwaber focuses more on controlling the process, on team design, and, to a lesser
extent, on the rituals to be used. What is interesting is that the Agile Manifesto with its
twelve principles does not focus on these items. An examination of the Scrum Guide
(Schwaber & Sutherland, 2016), which is mentioned by almost all the participants in our
study, shows that this guide focuses on the roles, events, artifacts, and even the rules
that bind them together.
39
Agile organizations are constantly delivering and checking on how they can improve
their performance, which means that Agile becomes a way for them to become
organizations that learn. This becomes clear when one realizes that retrospection is an
important factor in becoming proficient in Agile. Current applications of Agile start by
altering the way Scrum and other methods are implemented. An important step that
must be taken during the alteration of the work processes is for the organization/people
working Agile to understand what skills are required, and then for them to master them
before altering them in accordance to defined needs.
This process is described by a five-stage model created by Dreyfus and Dreyfus (Dreyfus
& Dreyfus, 1980), and describes the stages involved in developing from being a novice to
becoming an expert. When organizations achieve mastery, they are capable of
approaching a problem in a holistic way because they are able to monitor their
surroundings and are capable of analyzing the complexities of the changing environment
in which they operate. Although our research did not look at the success rates of the
cases presented by the participants, they did report the existence of failing
implementations of Agile. If learning is applied too quickly, this could lead to
demoralization, which could then lead to a lower learning curve. This means that an
organization not fully implementing Agile cannot become fully competent and therefore
they are not completely proficient. These organizations are known for partially engaging
in Agile-related tasks (“doing Agile”) instead of growing towards a mastery level and
becoming Agile.
2.5. Organizational routines
Organizational routines are important for creating a foundation on which the team(s)
are built. In addition, when teams are adapting to an Agile way of working,
organizational routines become an important asset.
Organizational routines are repeated patterns that do not often change over time. These
routines are adjusted, for example, when an organization, department, or team decides
to adopt the Agile way of working. Then, some or all of the organizational routines will
be altered. In Agile organizations or teams, the organizational routines depend on the
method being applied. Each method involves a set of rituals intrinsic to that method.
Strode (Strode, 2006) found that, although each method was different and applied its
own ways of planning, managing, evaluating, and controlling the iterations, all the
methods shared some properties in common. Strode (Strode, 2006) described the
40
properties of the rituals as “incremental and iterative development, projects undergoing
constant change, active user involvement, feedback and learning, frequent meetings,
daily is optimal, etc.”.
Feldman (Feldman, 2006) stated that the routines did not alter much, but that the
people involved in routines altered those routines to execute work in a way that best
suited them. This response is also applicable to Agile teams. People who are involved in
an Agile way of working start with adopting an Agile method, which will then be
transformed over time to better fit their way of working. Feldman found that a
characteristic of organizational routines is the potential for the dynamics to shift if the
routines and the thoughts and reactions of people who are using the routines shift
(Feldman, 2006). Since this study examines the way organizations adapted the Agile way
of working, it will also analyze the changes organizations made to the routines being
used.
41
42
3. Methodology
This chapter describes the methodology of this research and the design and data used in
this study. Section 3.1 of Chapter 3 describes the research strategy and design. Section
3.2 focusses on the research process. Section 3.3 presents the case selection strategy. In
the last section (3.4,) the data collection method is described.
3.1. Research strategy and research design
The purpose of this study is to contribute to the understanding of the influence of Agile
in non-IT domains and how organizations have been inspired by how Agile has been
used in the IT world. The application of an Agile way of working has just started making
progress in terms of its moving out of the IT domain. As a result, there is no or little
scientific research available on this subject.
To gain a better understanding on this subject, this research looked at the choices
available and how they played a role. To demonstrate the connection between
real-world observations and scientific research, Jonker and Pennink’s “Box of bricks of
research” (Jonker & Pennink, 2010) was used (fig. 8) as a guide to how scientific research
should be carried out. This helped in establishing the appropriate research behaviours
and approaches.
Figure 8 - Box of Bricks of research (Jonker & Pennink, 2010)
This visual helps to define the research design, and has been used to guide and utilize a
scientific approach, one which makes a clear distinction between observed reality and
empirical reality.
To assist in designing research, Jonker and Pennink present the research pyramid (fig. 9).
This is a tool used to assist in the choices that have to be made during the conduct of
research. On each level, different questions must be answered. By moving from the top
43
down, the research design will change from the abstractions at the top to very concrete
items at the bottom of the pyramid.
Figure 9 - Adapted from (Jonker & Pennink, 2010) - The research pyramid
3.1.1. The research paradigm
The subject of this research involves a new environment where not much knowledge is
available. There are several possibilities as to how the research should be conducted.
The basic approach is based on the way the researcher looks at the subject. These are
positivism and interpretivism. This study adopted and apply the interpretivist
philosophy.
Since the approach of choice is interpretivism, the research that was carried out
examined the differences between humans as social actors. This approach makes it
possible to look at the research subjects in a way that enables an understanding to take
place of how the Agile way of working has been implemented and what motives
underlie the observed behaviours. The aim of the approach is to view the world of the
subjects studied and to understand how they apply the Agile way of working.
The subject of this study has not been extensively presented in scientific publications.
Most of the information can be found on websites or other sources that can be
subjective and biased by commercial concerns. This means that observation was a key
tool that was used to acquire credible data and facts. Alongside observation, an
interpretivist approach was applied during the research. I wanted to observe the way
teams have applied the Agile way of working outside of IT. This gave me the ability to
focus on causality and on principles such as generalizing, which means that one reduces
a phenomenon to its simplest elements. This can be done in three principle ways
(Saunders, Lewis, & Thornhill, 2009); in this study, I have chosen to interview experts.
Research paradigm
Research
methodology
Research methods
Research techniques
44
One basic approach could involve following a positivist philosophy, whereas in this
study, an “observation of social reality” was applied during the process of answering the
research question. To stipulate which approach the organizations used and the attitudes
they adopted when they applied the Agile way of working could be studied using the
positivist philosophy. The problem I expected to encounter was that this would provide
answers, but would not provide scientific proof. There is not enough knowledge
available on the subject to begin with a theory in mind.
3.1.2. Research methodology
I chose to use an interpretivist research approach, a research method that can be used
for testing or building a theory (Saunders, Lewis, & Thornhill, 2009). Because there is
little information found on the subject, the study applied an inductive method to
investigate the question. As described by Easterby-Smith (Easterby- Smith, Thorpe,
Jackson, & Lowe, 2008), the application of such a method involves the following:
Research using an inductive approach is likely to be particularly concerned with
the context in which such events were taking place. Therefore, the study of a
small sample of subjects might be more appropriate than a large number as with
the deductive approach. Researchers in this tradition are more likely to work
with qualitative data and to use a variety of methods to collect these data in
order to establish different views of phenomena.
The research reported on here was based on a grounded-theory design and enabled
organizational phenomena within teams that were using Agile as way of working to be
studied. It has been demonstrated that the grounded theory design can be used to study
business and management (Goulding, 2002). This approach helps a researcher to
explore a specific phenomenon, in this case, the application of an Agile method of
working. The results were used to answer the overall research objective, to recognize
the important issues involved, and to find the best practices that could be used when
Agile is applied within non-IT organizations.
3.1.3. Research technique
Each task was based on data that had been collected during the research. There were
several sources that were used to collect the evidential basis needed for analysis.
Data collection can be performed in several ways. Yin (Yin, 2009) states that the
collection of exploratory evidence can be done by using six sources of evidence, all of
45
which have their own pro and cons. To gain insights into the research question, Yin (Yin,
2009) mentions four sources that can be used, which are interviews, direct observation,
participant observation, and physical artifacts. All have their strengths and weaknesses.
This study has picked interviews as the principle data-collection technique. Interviews,
which provide insights and personal views, are a source of reliable evidence in relation
to answering the guiding question that is being investigated. In addition, interviews
provided information of direct relevance to the topic being studied and, given the
limited timeframe, were the best method to be used.
3.2. Research process
The coding technique that was used was based on the qualitative research method
described by Strauss and Cordin, who provide guidance on the steps that should be
followed to come to a new theory on the basis of qualitative data (fig. 10).
Figure 10 - Qualitative study coding process
3.2.1. Initial phase
In the initial phase, the research question was formed and was followed by extensive
research into the available literature. The main goal was to acquire knowledge of the
Agile way of working. This was done by analyzing the available literature on the history
of Agility. During the literature-review phase, the principle focus was on the history of
the application of Agile methods of working.
3.2.2. Interviews
Interviews were conducted after the initial phase. The interviews were held in a semi-
structured way, and this approach was applied in order to learn more about the subject
by using the iterative process. All participants were selected because of their experience
in implementing an Agile way of working outside of IT. The background of the
participants varied from marketing to education.
Interviews
Transcripts of
the interviews
Open coding
Code the
transcripts
Axial coding
Categorizing
the open codes
Exploring the
axial codes'
properties and
dimensions
Selective coding
Choose the
core concept
from the axial
codes
Relate other
axial codes to
the core
concept
46
The interviews were held using a pre-structured set of questions, which were divided
into four sections. The first set of questions were formulated in a manner that would
create rapport and encourage the person being interviewed to provide some basic
information. The second section of questions focused on how the organization or
department concerned began changing to an Agile way of working. The third phase
zoomed in on the method the organization/department used to become Agile and
explored which specific routines or rituals had been applied. The fourth and final part of
the interview gave the participants room to reflect on their experiences in the
application of Agile methods of working in the department or organization.
3.2.3. Grounded theory approach
This study has been based on explorative research that sought to find and present
answers to the guiding questions, and so interviews were conducted to collect the
relevant data. Thirty-seven people from 22 different organizations were approached. All
individuals were chosen on the basis of whether they had experience in applying Agile
methods of working outside of the IT world. In total ,19 people were interviewed. One
participant was excluded from the results because the interviewee had only theoretical,
but no practical knowledge in applying Agile ways of working outside of IT.
All interviewees had the practical experience involving Agile applications outside of IT
that was required. Several had experience involving more than one organization. Every
interview was recorded as a separate case study and was transcribed for analysis. These
cases were then cross analyzed.
3.3. Case selection strategy
The participants were all found via searches on LinkedIn and Google, and were
approached by email and requested to answer the following: Were they available for an
interview? Did they have experience in applying Agile outside the IT domain and if not,
could they provide the name of someone who had had such experience? Several
participants provided the names of a number of contacts who also had had experience
in applying Agile outside the IT domain.
The participants had had various kinds of experience in different industries and domains
with applying Agile methods. All interviews focused on their experience in applying Agile
within their organization (with at least one or two clients) or on teams. Each interview is
presented as an individual case.
47
3.4. Data collection
Multiple case studies were chosen in order to collect data, a technique that allowed for
the research questions to be investigated in depth and in a real-life context. Interviews
were also conducted with experts in the field of applying Agile ways of working outside
of IT.
The interviews were conducted in two parts. The first interviews consisted of a pre-
study to check if the questionnaire and the presentation of the questions were useful.
The first three interviews were held in February, March, and April of 2017.
The second part used an altered questionnaire and was used to collect the data. These
interviews were held during the months of April through November of 2017.
3.4.1. Coding
The collected data needed to be coded before it could be used and interpreted. The
coding was done by using the process as described by Strauss and Cordin (fig.10), and
started with open coding, where the transcripts are coded by word, line, or paragraph.
The next step was grouping codes into categories, resulting in axial codes. This process
enabled me to group the data, analyze it, and accurately interpret it.
48
4. Results
This chapter presents the research results, which were based on interviews and the
analysis of the collected data. The results are presented both in textual and visual form.
Section 4.1 of Chapter 4 introduces the participants. Section 4.2 presents the domains
where the Agile way of working was being implemented or applied. Section 4.3 presents
the reported frameworks that were being applied. The rituals and motivations that were
applied are shown in section 4.4. Finally, in section 4.5, the critical success factors.
4.1. Participants
The participants were selected on the basis of their experiences with Agile as reported
on their LinkedIn accounts or when they were questioned directly. The expertise that I
was looking for was whether the people in question had either applied Agile methods of
working to other domains or whether they had transformed their organizations by
applying Agile to non-IT domains. A total of 37 people from 22 different organizations
were invited for an interview.
Nineteen people responded and participated in the interviews. The interviews were held
face-to-face, by phone, or by Skype (tab. 6). At the start of each interview, the
participants were asked for permission to record the interview and they agreed that all
responses would be made anonymous. To build trust and create a safe environment for
the participants to share his or her experiences without being hesitant or holding
(DiCicco-Bloom & Crabtree, 2006) the first questions focused on a personal description
of their experience.
The first three interviews were conducted as a pilot, a trial run, and were used to check
if the interview setup was complete. Based on the results, several interview questions
were changed or added so that better insights could be gained into the research
question (Turner, 2010). The first interview questions can be found in the Appendix (9.1)
and the final interview questions can be found in section 9.2. Respondent nine replied to
the request to participate by stating that he could allocate a maximum of 30 minutes for
the interview. Based on experience with previous interviews, I realized this would not be
sufficient to ask all the interview questions. This interviewee did not respond favourably
to a request for written submissions, and thus the decision was made to alter the
questions for respondent nine. The shortened list of questions is added in 9.3.
The participants were identified through a search, via Google, to see if they had made
any statements about Agile methods on their websites and on such sites as LinkedIn,
49
and were asked to participate after it had been ascertained that they had applied Agile
(or Agile methods; e.g. Scrum, Kanban, eXtreme Programming (XP)). In addition, I found
participants through “word of mouth” referrals (asking some of my professors if they
knew of useful interviewees in their personal networks). Finally, I made use of the
personal networks of the interviewees, asking them if they could provide the names of
other people who met the interview criteria. The participants were all approached via
email, and were asked if they would be willing to participate in a 60-minute interview.
The interviews took place at a time that suited the participants in order to match their
agenda or to take into account the different times zones where the respondents lived.
The participants had had a great deal of experience in applying Agile methods in
different companies or domains and were spread worldwide. Although most of the
respondents were Dutch, some were not and lived outside of the Netherlands (tab. 7).
Nine respondents were working as consultants who were responsible for Agile
Pt.
Role interviewee
Experience
(years)
Industry application of Agile
methods
Domain application
Method
1
Consultant
?
Local government and
related organizations
Portfolio management,
Finance and control
Scrum
2
Agile coach
?
Financial industry
Marketing
Scrum
3
Agile coach
?
Financial industry
Marketing
Scrum
4
Consultant,
Agile coach
10 years
Manufacturing, product
development,
transportation, Finance
Product development, R&D
manufacturing, Product
development,
Procurement
Scrum
5
Consultant
5 years
Finance
Marketing
Scrum,
SAFe
6
HR manager,
Program manager
6 years
Energy
E-commerce, Online Sales
7
Consultant,
Writer
> 10 years
Administration
Sociocracy
Scrum
8
PhD Student
1 year
Product development,
Research
Research project
Scrum
9
Public speaker
> 10 years
Various
Marketing, Sales, Start-ups
10
Manager:
methods, quality,
and technology
7 years
Food retail
HR
Scrum
11
Consultant,
Writer
> 10 years
Various
Machine manufacturing,
Sales and marketing
Scrum
12
Manager
Senior product
owner
7 years
Financial industry
Insurance
Sales
Internet
13
Consultant
7 years
Financial industry
Marketing
Scrum
14
Consultant
9 years
Energy; manufacturing
Geology
Scrum
15
Employee
Communication
Department
1 year
Social services,
Education
Team communication
Scrum
16
Agile coach
5 years
Education
Schools
Scrum
17
Marketing
manager
3 years
Travel industry
Marketing
Spotify
18
Consultant
Professional user
(Scrum Master)
Writer
10 years
Telecom
Software hosting
Customer Service
HR
Scrum
19
Consultant
No interview
Table 6 - Participants: overview
50
implementation. Most had had more than 5 years of experience in applying the Agile
way of working, and they had had experience both in and outside of the IT domain. Two
interviews, part of the pilot phase, took place within the same organization and within
the same domain. One participant agreed to give an interview, but stated at the start
that his/her experience on applying Agile methods outside IT was based on hearsay
only, not on personal experience. As soon as that statement was made, the interview
was concluded.
Continent
Country
Participants
Europe
Netherlands
14
Germany
2
Switzerland
1
North-America
USA
1
South-America
Columbia
1
4.2. Organizational domains found
The participants were approached because they had stated that they had had
specialized knowledge with working with Agile specifically outside the IT domain (tab. 8).
Industry
Domain
Role in the organization
Number of participants
Customer Services
Marketing
Agile coach, Scrum master
1
Education
Management consultant
Agile coach
1
Education
Schools
Researcher
1
Education
Schools
Agile coach
1
Education
Communication
Manager
1
Energy
Geologists
Agile coach
1
Energy
Marketing
Unit manager
1
Financial Industry
Marketing
Agile coach
2
Insurance
Marketing
Agile coach
2
Manufacturing
Marketing
Agile coach
1
Public sector
Communication
Agile coach
1
Public Sector
Marketing
Agile coach
1
Public Speaker
Management consultant
Not applicable
1
Retail
HR
Scrum master
1
Transportation
Management consultant
Agile coach
1
Travel Industry
Marketing
Unit manager
1
Table 8 - Industry and domains where Agile ways of working were found
The participation of people from the marketing domain was significant, with 12
participants being active within that domain.
4.3. Agile frameworks applied
Organizations that have adopted an Agile way of working can choose different methods
or frameworks to use when doing so. Organizations generally look for the best method,
one that suits their needs, when seeking to implement Agile. Several respondents
Table 7 - Participants: geographical spread
51
mentioned that it was important to think about the method chosen when transforming
the company to an Agile way of working.
Outside of the IT domain, different methods and frameworks have been used. The
interviewees gave several examples of methods and frameworks they were using or
have used in the past (tab. 9).
Domain
Used method
# Mentioned
Marketing
Scrum
9
Spotify
3
EXtreme Programming
2
Scaled Agile Framework
1
Google sprint method
1
Design Thinking
1
Appreciated inquiry
1
Kanban
1
Sales
Scrum
2
Human Resources
Scrum
1
Research & Development
Scrum
1
Procurement
Lean
1
Customer Services
Scrum
1
Table 9 - Frameworks used within the domains discussed
The most used framework was Scrum, followed by the Spotify model. The marketing
domain was the most diverse, where eight different methods were mentioned during
the interviews. The number of methods mentioned was higher than the number of
participants. This is due to the fact that several participants had had experience at more
than one organization. They also referred to other implementations and methods that
were used.
During the interviews, one area of response that was particularly interesting involved
the answers to the methods used and what role those methods played in terms of
encouraging the participants to promote an Agile way of working; the methods chosen
also motivated them to use the rituals that they did during Agile implementation. The
results gave an overview of the rituals (fig. 11, below) used within the organizations.
52
Figure 11 - Graphical overview of rituals used
4.3.1. Reported application of Agile practices and rituals
The interviewees stated they were using methods which consisted of multiple rituals to
be performed. In addition, the interviewees described the different rituals they used
within the teams when they were applying Agile (tab. 10). If the interviewee mentioned
applying “Agile by the book”, the rituals used were marked in red. Individual rituals
mentioned are marked in black.
53
Table 10 - List of rituals used, as mentioned by the interviewees
Black used to indicate a specific mention of a ritual. Red is used when the respondent said, “We do Scrum by
the book”
Scrum rituals were the most used, since almost all the interviewees stated they use
rituals which were identified as belonging to Scrum.
Three interviewees stated that implementation should start with all the available rituals
and could be altered later. Eight interviewees mentioned that they first implemented all
the rituals and, over time, when the team(s) had mastered those rituals, the team could
alter them.
4.3.2. Reported alteration of Agile practices and rituals
The practices and rituals used within the different domains were altered by the teams
(tab. 11). The alterations made to the rituals were not equally spread, since every
alteration was made for a specific reason. The differences in the alterations made
involved the frequency, location, duration, time, utilization, etc.
The interviewees mentioned the daily Scrum ritual as the ritual that was altered the
most, and some stated that the rituals used were altered to fit their way of working. The
most altered ritual was the one having to do with stand-up frequency, which was
changed from daily to weekly. Some interviewees stated that they did not have a fixed
Sprint frequency
Daily Scrum (Stand-up)
Retrospective
Sprint planning
Sprint review
Backlog
Implement all rituals and adjust to the team
Userstory
Definition of done
Co-located
Scrum Master
Cross-functional teams
Start with Scrum (not mendatory)
Sprint meeting
Optimization
Empowering the team
Knowledge sharing
Roadmap
Working with fun
Product Owner
Weight the shortest job first
Big Event at start Sprint (SAFe)
Value owners
Respondent 1
0
0 0 0 0 0 0 0 0
Respondent 2 0 0 0 0
Respondent 3 0 0 0 0 0 0 0 0 0 0
Respondent 4
1
1
1
1
0
0
0
0
Respondent 5
0
0
0
0
0
0
Respondent 6
0
0
0
0
0
0
0
0
0
Respondent 7
0
0
0
0
Respondent 8
1
1
1
1
1
0
Respondent 9
Respondent 10
0
1
0
1
0
0
0
0
0
0
Respondent 11
0
1
0
1
1
0
0
0
0
0
Respondent 12
0
1
1
0
0
0
0
Respondent 13
0
0
0
0
0
0
0
Respondent 14
1
0
0
1
0
0
0
Respondent 15
0
0
0
0
0
0
0
0
Respondent 16
0
0
0
0
0
0
0
0
Respondent 17
0
0
0
0
0
Respondent 18
1
1
1
1
1
0
Totals 15 15 15 14 11 8 8 5 4 4 4 3 3 2 2 2 2 2 1 1 1 1 1
54
time for the daily Scrum or that the Scrum was carried out by phone (interviewees 10,
13, 14, and 16).
Table 11 - Practices and rituals altered when applying Agile as stated by the respondents
During the interviews, a further explanation on altering rituals was given. Eight
interviewees mentioned that they had started with the Scrum framework rituals without
making any changes. After a period of time, the team adjusted these rituals to meet
their specific needs. This was further explained by three interviewees (interviewees 5, 6,
and 13) as following the Shu-Ha-Ri principle
4
.
4.3.3. Reported application of practices and rituals “by the book”
The respondents mentioned the use of rituals, both as they were given and in an altered
form, when they were applying an Agile way of working. The most used method was
Scrum. Several of the interviewees responded with the answer: “We implemented Agile
by the book”. When the rituals mentioned were examined and after a review of the
answers given during the interviews, it was clear that the interviewees meant that they
used the Scrum guide and implemented the practices and rituals as described by Jeff
Sutherland and Keith Schwaber (Schwaber & Sutherland, Scrum Guide, 2016). The rituals
4
Japanese martial art concept, which describes the stages of learning, progressing to mastery.
Daily Scrum (Stand-up)
Implement all rituals and adjust to the team later
Retrospective
Sprint frequency
Sprint planning
Start with Scrum (not mendatory)
Co-located
Shu-Ra-Ree
Sprint review
Teamforming
Backlog
Knowledge sharing
Scrum Master
impediment
Mixed methods
Respondent 1
1
Respondent 2
Respondent 3
1
Respondent 4
1
1
1
1
1
1
1
Respondent 5
1
1
1
1
1
Respondent 6
1
1
1
1
Respondent 7
1
1
1
Respondent 8
1
1
Respondent 9
Respondent 10
1
Respondent 11
1
1
Respondent 12
1
1
1
Respondent 13
1
1
1
1
Respondent 14
1
Respondent 15
1
1
1
Respondent 16
1
1
1
1
1
1
Respondent 17
1
Respondent 18
1
1
1
Totals 12 8 7 5 5 3 2 2 2 2 1 1 1 1 1
55
that stayed the same were mostly Scrum rituals (tab. 12). The red-marked rituals were
rituals not mentioned specifically by the respondent, but indicate that implementation
took place “by the book”.
Table 12 - The unchanged rituals as described by the respondents when applying Agile
Black used to indicate a specific mention of a ritual. Red is used when the respondent said, “We do Scrum by
the book”.
The sprint frequency was not altered by ten interviewees; this was followed by the
sprint review and sprint planning, which were not changed by nine interviewees. The
retrospective was kept the same by eight interviewees and the creation of a backlog was
done without any change by seven interviewees.
4.4. Reported motivation to implement Agile practices and rituals
The process to pursuit an Agile way of working originates principally from internal or
external drivers to change, which create the need to alter the organizational structure,
its commercial approach, the organizational culture, or the relevant processes within an
organization or team (as mentioned by Cameron and Green; Cameron & Green, 2015).
The interviewees mentioned one or more motivators for applying an Agile way of
working within their teams (tab. 13). External threads and fluctuating customer needs
were often mentioned as the reasons to change. Other reasons mentioned were the
Sprint frequency
Sprint planning
Sprint review
Retrospective
Backlog
Userstory
Definition of done
Cross-functional teams
Daily Scrum (Stand-up)
Scrum Master
Co-located
Empowering the team
Optimization
Roadmap
Sprint meeting
Working with fun
Knowledge sharing
Start with Scrum (not mendatory)
Implement all rituals and adjust to the team
Product Owner
Weight the shortest job first
Big Event at start Sprint (SAFe)
Value owners
Respondent 1
Respondent 2
Respondent 3
Respondent 4
Respondent 5
Respondent 6
Respondent 7
Respondent 8
Respondent 9
Respondent 10
Respondent 11
Respondent 12
Respondent 13
Respondent 14
Respondent 15
Respondent 16
Respondent 17
Respondent 18
Totals 10 9 9 8 7 5 4 3 3 3 2 2 2 2 2 1 1 0 1 1 1 1 1
56
need to address the absence of transparency and the desire to alter the way the
organization handled project management. All of these motivated a company to shift to
an Agile way of working.
Motivation or reason why applying Agile
#
Organizational drive to change based on threads and changing customer needs
7
No clear picture what the organizational unit is working on, what the costs are, and what the value
is that is delivered. No transparency
4
Project management approach used did not work (waterfall)
4
Employee satisfaction
3
There is no focus or the focus is too abstract; decision-making takes too long or does not happen.
1
Cost reduction
1
Pressures from or inspired by IT
1
Lack of a vision
1
Table 13 - Motivation or reason why organizations started using an Agile way of working
After examining the motivations for an organization to shift to Agile ways of working,
the study looked at the reasons an Agile approach was chosen. During the interviews,
the respondents stated who and what inspired them to change (tab. 14).
Inspiration
#
From other organizations
21
Specifically naming a financial institute
7
Suggested by the IT department (internally)
10
Via media (books, magazines, professional literature, etc.)
7
By attending conferences
6
From other movements (lean, test automation)
2
Table 14 - Inspiration for a change into an Agile way of working
During the interviews, the respondents frequently mentioned “return on investment
(ROI)” as an important motivating factor. This can be seen as an external factor: In other
words, change is based on what the competition is doing. If the competition has a
higher return on investment, they have achieved a higher level of overall effectiveness
in terms of generating a profit with the available assets.
Almost all the interviewees who mentioned ROI as an important motivator explained
why they had come to this conclusion. Since the responses they gave were diverse, they
are mentioned separately (tab. 15).
Return on investment mentioned by interviewees
#
Focus gives choice so customer value can be achieved early in the project
12
More fun by doing what is needed and not what is asked. This led to ownership and gave better results.
10
The backlog gave the client an overview as to what was important and delivered value and indicated what did
not deliver value
5
Workforce was scaled down (the interviewees were aware this was not the main goal of Agile)
4
Throughput is measurable
3
Transparency on what was needed to finish the work; this created commitment in the organization
3
More was delivered then had originally been planned
2
Less waste in terms of the budget
2
Table 15 - Return on investment comments made by the respondents
57
4.5. Critical success factors: starting small, senior level commitment,
management vision, customer focus
The interviewees were asked what success factors had contributed to the successful
application of Agile methods to the working of their teams. The respondents provided
answers as to the advantages and challenges which they had experienced or the
techniques they had used as they were implementing those changes (tab. 16).
Advantages
Mentioned
Challenges
Mentioned
Portfolio management created
transparency
13
The impact on the resources
25
Intrinsic motivation
9
The company itself has a big influence
on what a team can achieve
17
Everyone must be trained
8
Changing role for management
13
Empower people
5
Creating more time
7
Using available skills to deliver results
3
Difficult to define “empowerment”
6
Start small; use organic methods of growth
3
Staying Agile
5
Train management in Agile leadership
2
To become Agile, one must act Agile
4
Using all Agile rituals from the start
2
Changing is expensive
2
Start with easy results (quick wins)
2
Use humour
2
Table 16 - Advantages and challenges experienced by the respondents
The respondents, when asked to point to what the critical success factors were, also
mentioned the involvement of management as being important to successful change.
Eleven out of eighteen respondents mentioned that high or C-level management
involvement was a critical success factor when beginning to use an Agile way of working
(tab. 17).
Involvement
Number of respondents
Commitment
10
Secured at higher- or C-level management
7
Start with the top
4
Table 17 - High- and C-level management involvement as mentioned by the respondents
When looking at the practices and rituals that the participants used to apply Agile within
their organization, they mentioned several practices as being very useful (tab. 18).
Ritual
Mentioned
Retrospective
6
Daily Stand-Up
2
Demo
1
Planning
1
Short iterations
1
Story mapping
1
Transparency across teams
1
Weight Method
1
Table 18 - Used practices and rituals
Several respondents stated that “hiring consultants” was a factor that contributed to the
success of changing the way a team worked and the dynamics within a team.
58
5. Discussion
This chapter presents the results in relation to the guiding questions and discusses how
these results contributed to this field of study.
5.1. What is Agile beyond IT domains and practices?
In this study, the application of an Agile way of working through the use of Scrum has
presented itself as a leading, much-used practice by teams from different domains. The
Scrum method has been adapted by them after these teams had seen the success in
other domains or after they had read about Scrum in the media.
In the last few years, Agile has been moving out of the IT domain, but this study has
demonstrated that, when Agile is applied outside of the IT domain, it is not exactly
duplicate what has been done in the IT world. Some characteristics of IT implementation
remain, especially when one examines the way organizations and teams are adapting
this new way of working, but it is not a replication of what occurred in IT organizations.
Most implementations of Agile ways of working are based on Scrum and are altered
when applied. This was validated by the respondents during the interviews:
Scrum or [the] Agile way of working is used because it gives an objective and
goals which must be delivered to tackle a problem (respondent 15, employee
communication department).
The marketing project (cooperation between IT and business) was a success that
made the business asking to use Scrum (respondent 17, Marketing manager).
The daily stand-up changed in terms of frequency, the retrospective, sprint duration,
and sprint planning. Although the study did not look at the success or time needed to
apply Agile methods, it seems that adjustments were made quite quickly after
implementation. It is not clear if the changes were made after mastering the rituals.
Besides the use of Scrum rituals, several organizations looked at other methods to
become more Agile.
It can be demonstrated, then, that Agile changed from a strategic defence against
foreign developments threatening American competitiveness (Kidd, Agile
Manufacturing: Forging New Frontiers, 1994) into a successful way of working being
used to deliver customer value in terms of IT software development.
59
Agile in IT has expanded through the introduction of several different methods and
frameworks. The cases in this study listed Scrum (fig. 12) as the most used method when
Agile is applied outside the IT domain. Since some interviewees are active as
consultants, the results show a higher number of methods used than the total number
of participants.
Figure 12 - Frameworks used, as stated by the respondents
Some of the methods mentioned were positioned as “pure” Agile methods (Scrum, XP,
and Kanban). Spotify was mentioned as an Agile method, but it is normally used to scale
the application of the Agile way of working. The participants did mention SAFe and LeSS
when talking about scaling within the organization, but not as an Agile method. The
“Google Sprint Framework” was mentioned as an Agile method, but in the literature,
this is positioned as a five-phase framework for developing solutions by encouraging
user-centered thinking (Google, 2018). This framework is based on Design Thinking.
Kanban is mentioned as an Agile method, but its origins are in lean manufacturing.
5.1.1. Agile practices in different domains
Currently, it can be seen that Agile is being adapted by domains outside of IT. This study
found that the main domains in which it was being implemented were marketing, sales,
and customer support. To determine whether any new ways of working adopted by
organizations could be considered “Agile”, the study examined what Agile characteristics
were present in those non-IT organizations which were applying the new methods.
There are clear signs of Agile methods of working. Nerur and Balijepally (Nerur &
Balijepally, 2007) describe the Agile way of working as being holistic and as involving
60
self-organizing teams, two factors that encourage the interchangeability of roles. Team
members have overlapping specializations, generalized skills, and share knowledge so
they can self-organize in response to emerging requirements. These teams focus on
providing high customer satisfaction by applying three principles:
• The quick delivery of quality software
• Active participation of concerned stakeholders
• Creating and leveraging change
This study also found these specific factors in domains outside of IT. There are some
differences in the maturity of their expression and, therefore, the adaptation of Agile
methods of working was not the same as what had occurred in the IT domain. But the
domains of marketing, sales, and communications are performing as Agile organizations.
The products the teams deliver are delivered in short iterations and involve all the
stakeholders. The main goal on which everyone is focusing is to create or leverage
change.
5.1.2. Which Agile practices are used and why?
The Agile practices that respondents mentioned that they used were iterations (sprints),
daily stand-ups, retrospectives, sprint planning, and sprint reviews. These were adopted
because the respondents stated that they were using adaptations of Scrum.
Because a large theoretical development of the adoption of Agile ways of working is
absent (Conboy & Fitzgerald, 2004), there are many diverse and contrary definitions
present in terms of Agile, thus making it hard to define what constitutes a good Agile
way of working both inside and outside of the IT domain. To determine whether an Agile
implementation was effective, this research looked at practices used within teams
outside the IT domain. Most practices were based on the Scrum framework, and the
participants stated that they utilized this method extensively in their organizations.
Although they were aware of other methods, they all mentioned that they used Scrum
when asked for examples of how the Agile way of working was used by their teams.
In the IT domain, the Scrum method is widely used, and more than half of the
organizations that have applied an Agile way of working over the last few years have
chosen to use Scrum or a method that originates from Scrum (VersionOne, 2016),
(VersionOne, 2018).
61
The application, success, and source of inspiration in IT is reflected in the world outside
of the IT domain. Scrum is used more widely outside of the IT domain because non-IT
organizations have become of Scrum and the important role it has played in the IT
world. The transformation brought about by Scrum and other Agile methods of working
can be seen as a re-engineering of tasks in an organization, and reflects a huge effort
that is mandating change. Michael Hammer (Hammer, 1990), in his article
“Reengineering work: Don’t automate, obliterate”, states that fundamental
transformations are called for, and this requires management leadership with real vision
to guarantee commitment and consistency. This is important to successfully complete a
transformation that will increase alignment and create a perfect fit in terms of an
organization’s strategy, structure, culture, and processes (Tushman & O'Reilly III, 1996).
This obliges organizations to choose the right methods or frameworks to use. This is also
mentioned by several interviewees, who provided information about the other methods
and frameworks they had used.
5.1.3. What changes does the Agile way of working introduce?
The interviewees all stated that they applied a method which had its origins in IT.
Several of them described that they had changed a ritual during or after
implementation. Most of the respondents mentioned the use of an iterative process
within the teams, which means that, in cycles of two or three weeks, the teams
delivered a product. They all mentioned delivering value for the customer during these
short iterations. Although many applied the principles contained in the Scrum manifesto
as a guide to introducing Agile ways of working, the research found that there were
differences in how this was done. Nine out of the eighteen interviewees altered the
team’s updating mechanism. Agile-related daily meetings were changed in terms of
frequency (every other day) or by timeboxing meetings down to 5 minutes (interviewee
16). These alterations were based on situational circumstances (for example, at schools,
where time is limited). By keeping the stand-up to a minimum, the team had more time
to focus on delivering results. In addition, all of the team members could be present at
differing times (as a result of not having a daily meeting or because they used a daily
conference call to check up on the progress being made).
Other than in IT, the request to change towards an Agile way of working was more top-
down driven than bottom-up. Thirteen interviewees stated that management urged the
teams to start using Agile. They were inspired by the results demonstrated by other
organizations or by companies in the IT domain (tab. 19).
62
Motivation
#
From other organizations
21
Specifically, company X
7
Suggested by IT (internally)
10
Via media (books, magazines, professional literature, etc.)
7
Conferences
6
From other movements, like lean or test automation
2
Table 19 - Motivation to use the Agile framework
5.1.4. What did participants say stayed the same?
To determine the “agility” of the implementation, the interviewees were asked which
rituals or practices they used, stopped using, or altered during the process of
implementation of Agile ways of working. The responses showed that Agile ways of
working were based principally on the Scrum method, a fact that was not only
mentioned by the respondents, but that was demonstrated by the results from the
rituals that had been used (as seen in section 4.3). Several respondents mentioned they
had applied Scrum “by the book”. Three respondents mentioned that their company’s
policy was to use an in-house developed method based on the Scrum framework:
We use in-house developed ‘Agile portfolio management’, which gives a broader
view across projects instead of looking at just one project (respondent 1,
consultant).
Agile is seen as equal to Scrum (respondent 5, consultant).
But the above point is also validated in table 9 in section 4.3, where almost all the
respondents mentioned the use of Scrum in domains such as marketing, sales,
communications, etc. There is even an Agile Manifesto that has been specifically written
for use in the marketing domain:
I see most companies use Scrum. Especially the starters in becoming Agile use
Scrum following the rules from the Scrum guide. Those who are more
experienced consider agility as an attitude and not as a postulate to become
Agile as Jeff Sutherland and Ken Schwaber describe Agile (respondent 8, PhD
student).
This could be due to the clear explanation given by the Scrum guide (Schwaber &
Sutherland, 2016), which is still under revision and is regularly updated with the latest
insights.
63
Overall, the sprint frequency stayed the same. Most applications use a two-week
frequency for the sprints for the teams to deliver products. In addition, sprint planning
and sprint review are rituals that do not change in most implementations. The Scrum
guide provides a good description and a good definition of these rituals.
The retrospective ritual was also specifically mentioned by the interviewees. This ritual is
especially important in terms of the interviewees’ responses. Fifteen mentioned
(directly or indirectly) that they used the retrospective, but only six indicated that this
ritual was important. Twelve interviewees mentioned that the retrospective ritual had
been altered. Five mentioned the retrospective was no longer used:
The team could not speak out to reflect on the previous sprint. They found it
hard to express themselves. This stopped. (respondent 6, Agile consultant).
There is a difference between the people themselves and the role that play during the
application of Agile. The interviewees that stated that the retrospective was the most
important ritual were primarily consultants and had coached the team in Agile ways of
working. The interviewees that stated that the retrospective was not used any more
were mainly people that had developed from within the organization and then started
implementing an Agile way of working. Becoming Agile, implementing Agile ways of
working, changes the way knowledge is shared. The focus in Agile teams should be on
“individuals and interactions over processes and tools” (Beck, et al., 2001). This creates a
basis for knowledge-sharing through interacting. This is further pointed out by the Agile
Manifesto, which states that “a team must reflect at regular intervals to learn how to be
more effective and in response adjust and tune its behavior” (Beck, et al., 2001).
As seen in section 4.5, some of the challenges were the “the impact on the resources”
and the “changing role for management”. This could also be an important reason why
retrospectives were not continued within the team. The intention of the retrospective is
to give the team a moment to “inspect” themselves and to check how they can improve
their way of working, a practice that should be added to the next sprint planning.
If the team does not feel free to look at their behaviour and to learn how to change,
they will resist doing so.
…the team did not feel comfortable any more with the methods after the
retrospectives. Sometimes, it was also based on external influences; for
64
example, management telling [them that] they don't want a ritual to be used
anymore (respondent 8, researcher).
This is not only bad for the team’s behaviour, but also negatively impacts the process of
change. Six essential characteristics are key to success when beginning to change the
organization to become more Agile (Cameron & Green, 2015). When the impact
influences these characteristics the change most probably will not be successful. For
example, when management does not create a situation where the team can express
themselves to improve, they fail in changing the team and prevent them from acquiring
a learning mindset.
5.1.5. Which domains have adopted an Agile way of working?
This study found several industries and domains outside of IT where Agile has become a
way of working (tab. 20).
Industry
#
Finance industry
6
Energy
2
Schools
2
Table 20 - Industries where the Agile framework has been introduced
Within these industries, there are several domains found that applied an Agile way of
working (tab. 21). This shows that, in marketing, the Agile way of working was adopted
the most often. Management support and communication were both mentioned twice
as being why this occurred.
Domains
#
Marketing
9
Management consultancy
3
Communication
2
Schools
2
Geologists
1
Humans Resources
1
Table 21 - Domains that have adopted an Agile way of working
The reason why these domains were adopting Agile as a way of working was not related
to one factor. Several interviewees mentioned that the drive came from external
factors, such as other organizations or articles. Some interviewees mentioned that the
key motivator was the connection between transparency and success:
You must have a big perseverance to achieve the change; be transparent, using
humor and reveal yourself by saying you don't know if you don't. This drives the
need to collaborate (respondent 1, Agile consultant).
65
It was my aim to help the team experience that Agile is a way of working that
uncovers all. It places all the cards on the table, gives no solutions, but creates
openness so decisions can be made (respondent 2, Agile coach).
This could also be a reason for a company to become Agile. If an organization is not in
control, then Agile can help by making the work that the teams carried out “visible” to
everyone else in the organization. Organizations then have the possibility to make
choices and to bring focus into the teams.
Another reason to adopt the Agile way of working is that organizations are becoming
digitalized, more digitally present, and thus are intensifying their cooperation with IT
entities—all of which drives customers to demand faster product delivery. This can be
seen in the State of Agile Report (VersionOne, 2016), where 62% of the respondents said
that they are using Agile ways of working to accelerate product delivery. The results also
mentioned organizations who use an Agile way of working to improve the alignment
between business and IT. This has not changed significantly over last two years. Since
this finding of VersionOne is beyond the scope of this research, this was not pursued
further.
5.2. Agile management: What is the bigger picture?
The decision of organizations to become Agile and to motivate teams to adopt the Agile
way of working has been caused by the increasing demand from customers for faster
delivery and added value. These are qualities that are promoted by some authors of
Agile frameworks. For example, Jeff Sutherland, Anton Viktorov, Jack Blount, and Nikolai
Puntikov (Sutherland, Viktorov, Blount, & Puntikov, 2007) have seen an increase of 200%
in productivity in large teams, but organizations seem unclear as to how they can use
Scrum to enhance productivity. Carrying out a systematic literature review, Cardozo,
Barza, França, and da Silva (Cardozo, Araújo Neto, Barza, França, & da Silva, 2010)
looked for evidence of increases in productivity by those organizations that were using
Scrum and they found it. Most of the papers they examined also found that, next to
Scrum, other software development methodologies or process models were being used.
The exact numerical value (percentages) of increases in productivity were not
mentioned in the review.
The use of Agile methods is not simply about becoming more effective; it also involves
bringing about value to the customer at an earlier moment in time so that the return on
investment can be achieved at an earlier stage. This study did not seek to answer what
66
the effects were on returns in investment and how these could be measured. However,
the interviewees stated that adopting an Agile way of working had led to an earlier and
demonstrable return on investment. This could lead to the impression that work can be
skipped when working in an Agile way, but the work, all of the work, still needs to be
completed. By adopting an Agile way of working at an earlier stage, a return on
investment could be achieved, but this will only happen if the sequence of tasks is
changed. The tasks still have to be completed in their entirety.
You don't have to become more productive; the big benefit is by having the
focus on the deliverable [and so] you are able to get the return on investment
earlier. But if you look at the work that has to be done to complete the
deliverable, all still has to be done. You can't do this with fewer people
(respondent 11, consultant and writer).
The earlier return on investment is an important reason to adapt the Agile way of
working. Most interviewees (thirteen out of eighteen) mention this as an important
reason to change. This is in line with the customer value results that an Agile team wants
to deliver.
5.2.1. Continuous learning retrospective: to improve Agile practices in new
contexts
An important result of adapting the Agile way of working is the fact that an
organization’s knowledge base is increased. The team or organization that starts
working in an Agile manner becomes a learning organization (Nerur, Mahapatra, &
Mangalaraj, Challenges of migrating to Agile Methodologies, 2005).
Thus, the teams must learn and master the new rituals of an Agile way of working. This
is mentioned by several interviewees, who referred to the Shu-Ha-Ri principle (fig. 13).
Figure 13 - Mastering new rituals
67
The expression “follow the rules” means that it is crucial that the guidelines presented
by the different Agile methods should be followed. “Break the rule” is something that
occurs when a team starts altering the rituals because they want to discover new ways
of doing things. “Be the rule” occurs at the moment a team has to create a new set of
rituals that fits its organization or team, thus helping them to become Agile.
Learning is achieved during the retrospective ritual, and involves looking back on what
the team has achieved, what went well, and what could be improved. This is also
mentioned by Sjoerd Romme (Romme S. , 2002), who describes the shift from explicit
knowledge to implicit knowledge, a phenomenon that takes place through
internalization and applying routines and network relations. Learning, therefore, also
originates between people. When people share their expertise, implicit knowledge is
made explicit. This necessitates that people work together and that people trust each
other.
Performing a retrospective must be seen as a knowledge-creation process, which
Nonaka and Takeuchi describe as a process of creation, continuous innovation, and
gaining the competitive advantage. Continuous innovation means using the knowledge-
creation circle, as described by (Nonaka & Takeuchi, 1995) to learn and to improve the
team. By looking back on the results, the team learns from their mistakes. By sharing
what they know, the team externalizes its knowledge and creates new knowledge. This
also adds to the discussion of which method to choose. As Kniberg and Skarin (Kniberg &
Skarin, 2010) assert, the method is not the goal—continuous learning is. The crucial
element lies in a short feedback loop, which is key to learning. Teams should question
everything, experiment, fail, learn, and then experiment again. They should not worry
about getting it right at the start they should just begin and evolve during the process
(Kniberg & Skarin, 2010).
5.3. Agile and the evolution of management methods: What is next?
This section of the study seeks to view into the future in terms of what Agile methods of
working could become next and how management methods will evolve. The discussion
is divided into two parts: an examination of methods and frameworks and, secondly, an
analysis of evolving organizational structures.
68
5.3.1. Which methods are on the horizon?
During the last years, the frequency of Agile use has been increasing, especially in the
software industry. This phenomenon has also found its way into the world outside of IT.
The rising popularity of Agile methods is depicted in the graph below, which reflects
search trends in Google involving terms having to do with Agile methods of working.
“Agile” as a search phrase has been gaining popularity and has been the subject of a
rising number of Google searches and, since 2007, the same can be said for the search
term “Scrum”.
Figure 14 - Popularity of Agile frameworks as a search term from 2004 - 2018 (source: Google Trends)
The graph above (fig. 14) shows that the awareness of Agile methods of working is
increasing, mirroring a phenomenon that started in 2011, when the awareness of other
methods also began to rise. The initial decline in interest in relation to Kanban starts,
perhaps surprisingly, to reverse in 2011, and can, perhaps, be explained by the fact that
Kanban was adopted by the Agile community.
The graphs do not show this, but a study of the literature shows that Agile was
becoming more popular even before the Agile Manifesto was published. Radigan
(Radigan, 2017) found that the core principles of the Agile way of working are timeless
and applicable to almost any industry, although, initially, IT and software development
teams were the first to begin implementing Agile methods and practices. Radigan
concludes that IT and software companies, because they had few overhead costs, could
begin applying the basic new principles once they had understood them. Applying Agile
was easier than implementing something like Kanban which, on a factory floor, would
involve major changes to physical processes and the addition of substantial materials. In
69
a software development team, the only physical things that are needed are a board and
cards, both of which can be virtual (Radigan, 2017).
Changes in how organizations operate could also explain the trends that were
discovered. Since organizations have started to use an Agile way of working, they have
discovered that not all frameworks used by IT are ready for application to every
organization. When looking to make organizations Agile, people are looking for
frameworks and methods that respond to the specific conditions present in their
organization. Frameworks such as Scrum, XP, and Kanban have been specifically
designed for the domain of software development and are not so universal that they can
be used in any organization or domain. At this moment, it is clear that organizations are
not only fine-tuning a method or framework, but also that they are searching for
methods and frameworks that are a better fit for them (fig. 15). The increasing
popularity of Scrum is paralleled by trends involving Agile. In the last years the rising
popularity of Design Thinking, Lean Startups, and growth hacking have become clear.
Figure 15 - Trends in Agile methods from 2004 - 2018 (source: Google Trends)
5.3.2. Domains with the need for creativity or feedback show a higher pace of
change and can take advantage of Agile methods
Thus, it can be seen over the last few years that different domains and industries are
moving towards an Agile way of working. The rising popularity of Agile can be explained
by changes to the world as we know it. As stated by Marshall McLuhan, the world is
becoming a “global village” (McLuhan, 1960), which means that the entire world is
connected and that news and developments are shared over continents, countries, and
cultures; change reverberates at the speed of light, and this phenomenon impacts
organizations and how they work. Organizations must increase the pace to keep up with
competition, and a way to do this is to automate the production line or to automate jobs
70
that are repetitive by nature. Frey and Osborn (Frey & Osborne, 2013) found that there
is a connection between a lack of creativity and the likelihood that a job will be
automated. They discovered that the more creativity that day-to-day activities require,
the less probability there was that the job would be automated. In addition, jobs that
require feedback cannot be easily automated. Feedback is given in a multiple of ways,
and can involve the emotional expressions on the part of participants solving a difficult
and challenging task (Frey & Osborne, 2013). In their study, they presented the
probability of jobs being automated (fig. 16).
This study compared the findings of Frey and Osborn to the results in this research and
found some grounds for comparison. The domains outside of IT where Agile was being
applied (section 4.2) were roughly comparable to what Frey and Osborn had discovered.
In other words, similar to Frey and Osborn’s study, it was discovered that Agile was
being applied in several domains such as marketing, management, schools,
communication, and HR (fig. 17).
Figure 16 - Reprinted from Future of Employment - Frey & Osborne (2013)
71
Figure 17 - Domains where Agile was being implemented (mentioned by the interviewees)
Frey and Osborn found that jobs in computer engineering, science, education, legal,
community services, management, business and financial services, and arts and the
media were not easily automated (Frey & Osborne, 2013). The only domain that was not
suitable for Agile ways of working and thus did not adopt them was the service domain,
which can be explained by the fact that the service domain is more individualistic, more
based on individual labour, whereas Agile is a method of making teams more effective.
5.3.3. What was the purpose of using Agile?
The organizations studied all had a specific purpose for adopting the Agile way of
working. Although external threats and customer needs are mentioned most often as
motivations, it is surprising that “absence of focus” and the replacement of “not
functioning by the waterfall method” are also mentioned as reasons to change.
Although an Agile way of working creates transparency, it can also create focus by
enhancing customer involvement. What is surprising is that, although organizational
needs were often the reasons for adopting Agile methods, the chosen solutions had an
impact on the team level. Some interviewees stated that it was difficult to make
decisions, and that the transparency offered by Agile made decision-making easier.
5.4. Limitations and future work
This study looked at the how successful the application of an Agile way of working has
been. The main focus was on the impact of Agile within teams outside of the IT domain.
It did not look at the success of a specific application within organizations nor did it look
at the results in terms of providing specific performance indicators.
Because the number of organizations outside the IT domain is vast, the connection of
Agile ways of working and specific performance indicators is a difficult subject to study
because it requires large-scale quantitative research. Because this study was based on a
0246810 12
HR
Geologist
Communication
Schools
Management consultancy
Marketing
Domains using an Agile way of working
72
qualitative research design, its scope was too limited to engage in an investigation of
such a huge topic. The research undertaken in this study was focused on discovering
what specific organizational strategies and what performance factors ensured the
successful implementation of Agile.
Such research can also be undertaken on the basis of case studies. This approach was
not chosen because the goal of the investigation was to come to a broad, overall view of
the subject of Agile implementation and where Agile is being applied. This could be
overcome in future research since the different domains not applying Agile are known
and research can thus be oriented to one or more domains or methods to gain an
in-depth knowledge on the subject.
73
74
6. Conclusions and recommendations
This research performed a qualitative international study on the application of the Agile
way of working outside of the IT domain. This was done by approaching 31 individuals
for an interview, 18 of whom participated. The interviews were semi-structured and
were held face to face or via Skype. The interviews lasted between 45 minutes and 3
hours. This resulted in an extensive collection of data.
6.1. Conclusions
Not only did the study analyze the success (or otherwise) of applying Agile ways of
working outside of the IT domain, it indicated that the most successful implementations
took place in domains such as management, financial departments, schools, legal teams
and community services. When the data was analyzed and compared to see what kinds
of jobs could be automated, it showed that when employees were creative, when
feedback was important, and when people were more highly educated, the likelihood of
Agile methods being successfully introduced was higher. Introducing Agile in those
contexts had a positive impact on the organization.
What was also demonstrated by the research is that teams tended to Scrum as the de
facto standard when they were beginning to introduce Agile methods of working.
However, the results also showed that changes occurred during the application of new
methods, and the organizations began searching for other, relevant frameworks that
could be used (such as Beyond Budgeting, Design Thinking, etc.).
Differences were also found in the way teams adopted the Agile way of working. Most
teams had adopted the Agile rituals as described by the framework guides and the
manifestos, but altered them to fit the team. But not all of the rituals survived Agile
implementation, and some of them were changed and even abandoned. Most teams
adopted the daily standup, but changed the frequency of this ritual. The retrospectives
were adopted by almost all teams at first, but dropped by almost half of the teams
during or after the implementation. This indicates most teams are using Agile, but that
they did not got to the stage where they were completely Agile and become a learning
organization.
The results show that Scrum is still the most popular method, but other methods are
also used; Kanban, Lean Startup, and Design Thinking are also gaining popularity.
Although IT-based methods are used in every organization or domain, organizations are
looking for ways to deliver customer value in a faster way, depending on the discipline
75
of the team or organization. Some organizations have stopped the use of IT based
stratagems and are discovering how to use other methods. The teams that are looking
for other methods that better fit their way of working all depend on external support
when implementing those methods.
In this light, it is important to recognize and support an organization’s eagerness to
learn, and to realize that organizations need to be helped to enhance their feedback and
creativity, thus enabling them to choose other frameworks when needed. In addition, it
is important that the feedback received is applied to enhancing performance and the
learning curve. It may be said that the choice of framework to be used should not be the
main focus: the use of feedback and creativity in order to enhance their improvement
should be the primary goal.
6.2. Validity considerations
Due the fact this research was qualitative by nature and that it was explanatory, it was
important to guarantee the validity of the research. To achieve this, several sets of
measures were added, which safeguarded the soundness of the findings. The
constructive validity was secured in the research design. Research that is carried out
according to a qualitative design bases its data collection on interviews. There is always
the risk that the group of participants is not large enough for conclusions to be drawn.
The group of respondents interviewed during this study was large enough for the results
to be credible. Every interview was carefully transcribed and was sent to the participant
for review, thus verifying the accuracy of the responses. Remarks or changes suggested
by the respondents have been incorporated into the final version, which formed the
basis for the analysis.
To secure internal validity, every interview started with a few open-ended, personal and
simple questions that created a pleasant atmosphere for the respondent. The data was
coded in accordance with open-, axial- and selective coding as described by Strauss and
Corbin (Straus & Corbin, 1998). Structuring the data also enhanced its internal validity.
The external validity was ensured by selecting respondents from different industries and
domains. Open coding created the possibility of converting the data and enabled it to be
generalized so the results could be used in other environments.
76
By recording and transcribing the interviews and sharing the results of the interviews
with the respondents, the reliability was secured. This reduced the likelihood that the
data could be misinterpreted.
6.3. Recommendations for future research
This study was focused on seeking more insight into Agile ways of working outside of the
IT domain. The qualitative research reported here enhanced, in a small way, knowledge
about the topic, but there are still some subjects that could be researched in the future.
Firstly, this research has provided a lot of data about frameworks that are currently
being used. It would be good, in this regard, to do a follow-up study by observing a team
or an organization to discover the success of the Agile way of working as it is used in a
real-life context, thus exploring how the results of this study could be practically applied.
Secondly, an interesting subject inviting further study would be to look how teams
operate, that is, if they master a method before they start altering it to fit their needs.
Such a study could pinpoint why the changes are taking place at a specific moment in
time during the application of an Agile way of working.
Thirdly, a future study would involve looking for the application of the methods
mentioned by several respondents but not (yet) widely used, such as: Beyond
Budgeting, Design Thinking, etc.
All of the above would enhance our knowledge of Agile ways of working outside of the
IT domain, and would give organizations and researchers the tools they needed to
ensure the success of future implementations of Agile methods and frameworks.
77
78
7. References
7.1. Literature references
Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Fowler, M., . . .
Thomas, D. (2001). Agile Manifesto. Retrieved from Manifesto for Agile Software
Development: http://agilemanifesto.org/
Cameron, E., & Green, M. (2015). Making sense of Change Management (4th ed.).
London: Kogan Page limited.
Cardozo, E. S., Araújo Neto, J. B., Barza, A., França, A. C., & da Silva, F. Q. (2010). EASE'10
Proceedings of the 14th international conference on Evaluation and Assessment
in Software Engineering. SCRUM and Productivity in Software Projects: A
Systematic Literature Review (pp. 131 - 134). Keele University - United Kingdom:
BCS Learning & Development Ltd. Swindon, UK ©2010.
Chow, T., & Cao, D.-B. (2008). A survey study of critical success factors in agile software
projects. Journal of Systems and Software 81, 961 - 971.
Conboy, K., & Fitzgerald, B. (2004). Toward a Conceptual Framework of Agile Methods: A
Study of Agility in Different Disciplines. Proceedings of the ACM Workshop on
Interdisciplinary Software Engineering Research, WISER 2004, (pp. 37-44).
California. doi:DOI: 10.1145/1029997.1030005
Cubric, M. (2013). An agile method for teaching agile in business schools. University of
Hertfordshire, Hertfordshire Business School. Hertfordshire, UK: The
International Journal of Management Education.
Deming, E. M. (1950). Elementary Principles of the Statistical Control of Quality.
DiCicco-Bloom, B., & Crabtree, B. F. (2006). Making sense of qualitative research - The
qualitative research interview. Medical Education(40), 314-321.
doi:doi:10.1111/j.1365-2929.2006.02418.x
Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. (2012). A decade of agile
methodologies: Towards explaining agile software development. The Journal of
Systems and Software 85, 1213-1221.
Dreyfus, S. E., & Dreyfus, H. L. (1980). A five-stage model of the mental activities involved
in directed skill acquisition. Berkeley: University of California.
Easterby- Smith, M., Thorpe, R., Jackson, P., & Lowe, A. (2008). Management Research
(3rd edition). London: Sage.
Feldman, M. S. (2006). Organizational Routines as a Source of Continuous Change.
Organization science, 611 - 629.
Fernandez, D. J., & Fernandez, J. D. (Winter 2008/2009). Agile project management -
Agilism versus traditional approaches. The Journal of Computer Information
Systems, 10-17.
79
Frey, C. B., & Osborne, M. (2013). The Future of Employment. Oxford: Published by the
Oxford Martin Programme on Technology and Employment.
Goulding, C. (2002). Grounded Theory. London: SAGE Publications.
Hammer, M. (1990, july/august). Reengineering Work: Don't automate, Obliterate.
Harvard Business Review(volume 68).
Jonker, J., & Pennink, B. (2010). The essence of research methodology. Berlin -
Heidelberg: Springer-Verlag. doi:10.1007/798-3-540-71659-4
Kidd, P. T. (1994). Agile Manufacturing: Forging New Frontiers. Addison-Wesley.
Kidd, P. T. (1995). Agile Corporations: Business Enterprises in the 21st Century - An
Executive Guide. Cheshire Henbury.
Kidd, P. T. (2004). Agile manufacturing: a strategy for the 21st century. Macclesfield,
United Kingdom.
King, E., & King, V. (2018, february 2). Success Story: Agility and Health Care. Retrieved
from Scrum Alliance:
https://www.scrumalliance.org/community/articles/2014/january/success-
story-agility-in-healthcare
Kniberg, H., & Skarin, M. (2010). Kanban and Scrum, Making the most of both. United
States: C4Media Inc.
Leeuw, P. D. (2001). Bedrijfkundige MEthodologie - Management van onderzoek. Assen:
Koninklijke Van Gorcum B.V.
Manivelmuralidaran, V. (2015). Agile Manufacturing - An Overview. International Journal
of Science and Engineering Applications(Volume 4 Issue 3), 156 - 159.
Melnik, G., & Maurer, F. (2003, june 13). Introducing Agile Methods in Learning
Environments: Lessons learned. Calgary.
Misra, S., Kumar, V., & Kumar, U. (2009). Identifying some important success factors in
adopting agile software development practices. The Journal of Systems and
Software 82, 1869 - 1890.
Moen, R., & Norman, C. (2006, January). Evolution of the PDCA Cycle.
Nagel, R. N. (1992). 21st Century Manufacturing Enterprise Strategy Report. Lehigh
University, Iacocca Institute.
Nerur, S., & Balijepally, V. (2007, March). Theoretical Reflections on Agile development.
Communications of the ACM(Vol. 50, No. 3), 79-83.
Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to Agile
Methodologies. Communications of the ACM(48), 72-78.
Nonaka, I., & Takeuchi, H. (1995). The knowledge-Creating Company. New York: Oxford
University Press.
80
Poiesz, T. (2014). Redesigning Psychology: In Search of the DNA of Behavior. In T. Poiesz,
Redesigning Psychology: In Search of the DNA of Behavior (p. 60). The Hague:
The Hague, NL: Eleven International Publishing.
Radigan, D. (2017, 4 22). Kanban. Retrieved from www.attlassian.com:
https://www.atlassian.com/agile/kanban
Romme, S. (2002). Kennismanagement, strategie en IT. Maandblad voor Accountancy en
Bedrijfseconomie (MAB), 113-116.
Samuel Saleb, R., Green, K. W., Whitten, D., & Green, K. W. (2011). Agile manufacturing:
Relation to JIT, operational performance and firm performance. Journal of
Operations Management 29, 343-355.
Saunders, M., Lewis, P., & Thornhill, A. (2009). Research methods for business students
5th edition. Essex: Pearson Education.
Schwaber, K. (1995). SCRUM Development Process - Advanced Development Methods.
Sutherland J., Casanave C., Miller J., Patel P., Hollowell G. (eds) Business Object
Design and Implementation, 1995, 23. doi:https://doi.org/10.1007/978-1-4471-
0947-1_11
Schwaber, K., & Sutherland, J. (2016). Scrum Guide. Retrieved from Scrum Guides:
http://www.scrumguides.org
Steenberg, R. (2016, February 05). The impact of measures when optimising sales
processes using Scrum. Johannesburg, South Africa: Texila American University.
Stettina, C. J., & Hörz, J. (2015). Agile portfolio management: An empirical perspective
on the practice in use. International Journal of Project Management, 140–152.
doi:https://doi.org/10.1016/j.ijproman.2014.03.008
Stettina, C. J., Zhou, Z., Bäck, T., & Katzy, B. (2013). Academic Education of Software
Engineering Practices: Towards Planning and Improving Capstone Courses Based
upon Intensive Coaching and Team Routines. San Francisco, CA, USA: IEEE.
Straus, A., & Corbin, J. (1998). Basics of Qualitative Research: Techniques and Procedures
for Developing Grounded Theory. Thousand Oaks, California: Sage Publications.
Strode, D. (2006). Agile methods: a comparative analysis. Faculty of Business and
Information Technology Whitireia Community Polytechnic Porirua, New Zealand,
9.
Sutherland, J., Viktorov, A., Blount, J., & Puntikov, N. (2007). Distributed Scrum: Agile
Project Management with Outsourced Development Teams. 40th Annual Hawaii
International Conference on System Sciences (HICSS'07) , (p. 17). Waikoloa, HI,
USA.
Takeuchi, H., & Nonaka, I. (1986, January-February). The new new product
development. Harvard Business Review, 137-146.
Turner, D. W. (2010, May). Qualitative Interview Design: A Practical Guide for Novice
Investigators. The Qualitative Report(Volume 15), 754-760. Retrieved from
http://www.nova.edu/ssss/QR/QR15-3/qid.pdf
81
Tushman, M. L., & O'Reilly III, C. A. (1996, Summer). Ambidextrous organizations:
Managing evolutionary and revolutionary change. California Managemenr
Review(Volume 38, Number 4), 8 - 30.
van Solingen, R., Sutherland, J., & de Waard, D. (2011). Scrum in Sales - How to improve
account management and sales processes. Sixth International Conference on
Global Software Engineering Workshop (p. 6). Helsinki, Finland: IEEE.
Verbrugge, B. (2018, May 11). Best Practice, Model, Framework, Method, Guidance,
Standard: towards a consistent use of terminology – revised. Retrieved from Van
Haren Publishing: https://www.vanharen.net/blog/van-haren-publishing/best-
practice-model-framework-method-guidance-standard-towards-consistent-use-
terminology/
VersionOne. (2016). The 10th annual State of Agile Report. VersionOne.
VersionOne. (2018). 12th State of Agile report. Retrieved from State of agile report:
http://stateofagile.versionone.com/
Wells, D. (2017, 4 26). Extreme Programming: a gentle introduction. Retrieved from
Extreme Programming: http://www.extremeprogramming.org/
Yin, R. K. (2009). Case Study Research. Applied Social Research Methods Series(Volume
5), p. 28.
7.2. Internet references
Drumond, C. (2016, june 1). Agile marketing: fad or future of marketing? Retrieved from
Attlasian Blog: https://www.atlassian.com/blog/marketing-teams/agile-
marketing-fad-future-marketing
Ewel, J., Cass, J., Days, F., Arnold, T., Miller, R. J., Kaykas-Wollf, J., . . . Androski, N. (2018,
August 22). Marketing Manifesto. Retrieved from
http://agilemarketingmanifesto.org/: http://agilemarketingmanifesto.org/
Google. (2018, Januari 15). Design-Sprint-Kit. Retrieved from Design-Sprint-Kit:
https://designsprintkit.withgoogle.com
Gothelf, J. (2017, June 19). How HR Can Become Agile (and Why It Needs To). Retrieved
from Harvard Business School: https://hbr.org/2017/06/how-hr-can-become-
agile-and-why-it-needs-to
Gray, B. H., Sarnak, D. O., & Burg, J. S. (2015). Home Care by Self-Governing Nursing
Teams: The Netherlands’ Buurtzorg Model. The Commonwealth fund. Urban
Institute https://www.issuelab.org/resource/home-care-by-self-governing-
nursing-teams-the-netherlands-buurtzorg-model.html
Hegarty, C. (2011, September 6). Breaking Departmental Silos: Scrum in Finance.
Retrieved from ScrumInc: https://www.scruminc.com/breaking-departmental-
silos-scrum-in/
82
King, E., King V. Md. (2014, 1 14). Success Story: Agility and Health Care - A Family
Practice Transformation Based on Continual Learning and Adaptation:
https://www.scrumalliance.org/community/articles/2014/january/success-
story-agility-in-healthcare
McLuhan, M. (1960, May 18). Marshall McLuhan’s theory of the global village. (A. Millar,
& J. O'Leary, Interviewers) CBC. Retrieved September 3, 2018, from
https://www.cbc.ca/archives/entry/marshall-mcluhan-the-global-village
PMG Healthcare. (2014, December 17). Staying power: Success stories in global
healthcare. Switzerland. Retrieved February 2, 2018, from
https://home.kpmg.com/xx/en/home/insights/2014/12/engaged-people-
deliver-value.html#01
SCRUMstudy. (2013, December 27). How HR teams can benefit from Scrum. Retrieved
from Scrumstudy: https://www.scrumstudy.com/blog/how-hr-teams-can-
benefit-from-scrum/
83
84
8. Appendix A – The Agile Manifesto
(This is an exact copy of the Agile Manifesto as available at https:\\agilemanifesto.org)
We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:
❖ Individuals and interactions over processes and tools
❖ Working software over comprehensive documentation
❖ Customer collaboration over contract negotiation
❖ Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left
more. Principles behind the Agile Manifesto. We follow these 12 principles:
• Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the
project.
• Build projects around motivated individuals. Give them the environment and
support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing
teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
The manifesto is signed by:
Kent Beck
James Grenning
Robert C. Martin
Mike Beedle
Jim Highsmith
Steve Mellor
Arie van Bennekum
Andrew Hunt
Ken Schwaber
Alistair Cockburn
Ron Jeffries
Jeff Sutherland
Ward Cunningham
Jon Kern
Dave Thomas
Martin Fowler
Brian Marick
85
86
9. Appendix B – Interviews
This chapter gives the questions used during the interviews. Both pilot and final
interview questionnaires are presented.
All interviews started with the following three questions/statements:
INTRODUCTION / ETHICAL CONSIDERATIONS
1. Participation is voluntary.
2. The responses will be made anonymous.
3. Asking for agreement to record.
9.1. Interview questions pilot
9.2. Introduction
1. Could you please tell me about yourself? Your educational background, and
current position/role.
2. Could you please describe your organization and the organizational unit you
work for?
3. Do you have any experience with Agile methods/Scrum and how long?
9.3. Experience agile outside of IT
1. (For consultants) Do you have experience with implementing agile
methods/Scrum outside of IT? Can you give us concrete example(s)?
2. (For host organizations) Do you have experience with implementing agile
methods/Scrum outside of IT in your organization? Can you give us concrete
example(s)?
3. How did that begin? How and why did you start applying agile methods/Scrum
outside of IT?
4. (For consultants) How did you get requests from organizational departments to
implement agile/Scrum?
5. How do you usually get requests to help at implementing agile/Scrum?
a. Who initiated the change?
b. How got that person inspired?
6. (For host organizations) How did the change (to implement agile/Scrum in the
non-IT department) start?
87
a. Who initiated the change?
b. How got that person inspired?
7. What was the vision?
9.4. Change process / Introduction process agile in domains other than
IT
1. How did you initiate or lead the change?
a. Did you used a specific change process to manage the change?
b. Could you give me 5 to 10 concrete steps on the change?
2. How did the concrete change differ to the original plan?
3. During the change, did you direct the change(project) or direct the people?
a. If applicable, why did you choose to direct this part?
4. Did you achieve the original goal(s)?
5. Did you experience any challenges during the change process?
6. Looking back could you define success factors for the change?
9.5. Process now
1. How is agile implemented in the non-IT domain?
2. Could you state the concrete steps of the current agile process within the
organization/project?
3. Did you establish and maintain close and effective customer collaboration and if
so, how?
4. What are the advantages to the original process?
5. What are the disadvantages?
9.5.1. Looking further
1. Would you do anything in a different way?
2. Where do you see this leading in the future (based on your organization)?
3. What are the plans?
9.6. Interview questions
9.6.1. Introduction
1. Could you please tell me about yourself? Your educational background, and
current position/role.
2. Could you please describe your organization and the organizational unit you
work for?
88
3. Do you have any experience with agile methods/Scrum and how long?
9.6.2. Experience agile outside of IT
1. (For consultants) Do you have experience with implementing agile
methods/Scrum outside of IT? Can you give us concrete example(s)?
2. (For host organizations) Do you have experience with implementing agile
methods/Scrum outside of IT in your organization? Can you give us concrete
example(s)?
3. How did the move to applying the agile way of working begin? How and why
did you start applying agile methods/Scrum outside of IT?
4. (For consultants) How did you get involved in implementing agile/Scrum in
different organizational units?
5. How do you usually get requests to help at implementing agile/Scrum?
a. Who requested your involvement, initiated the change?
b. How got that person inspired in implementing agile in a non-IT domain
in the first place?
6. (For host organizations) How did the change (to implement agile/Scrum in the
non-IT department) start?
a. Who initiated the change?
b. How got that person inspired?
7. What was the vision?
9.6.3. Change process / Introduction process agile in domains other than IT
1. How did you initiate or lead the change?
a. Did you used a specific change process to manage the change?
b. Could you give me 5 to 10 concrete steps on the change?
2. How did the concrete change differ to the original plan?
3. What where the assumptions when you started?
4. During the change, were you the project manager of are you the team lead?
a. If applicable, why did you choose to focus on this part?
5. Did you achieve the original goal(s)?
6. Did you experience any challenges during the change process?
a. What was the motivation to change?
b. How did the team get the capacity to make the change?
c. Was there an opportunity (created) to support the change?
7. Looking back could you define success factors for the change?
89
9.6.4. Process now
1. How is agile implemented in the non-IT domain?
a. What the practices/routines/rituals/ceremonies did you implemented
[Stand-up, reviews, using boards, timebox, etc.]
b. Which practices or routines were useful?
c. How did you change / adapt any of those (changed timing, frequency,
explanation, goal, etc.)?
d. What is the reason some practices are no longer used?
e. What were the barriers to adoption?
2. Could you state the concrete steps of the current agile process within the
organization/project?
3. Did you establish and maintain close and effective customer collaboration and if
so, how?
4. What are the advantages to the original process?
5. What are the disadvantages?
9.6.5. Looking further
1. Would you do anything in a different way?
2. Where do you see this leading in the future (based on your organization)?
3. What are the future plans within the organization?
4. Can you imagine other domains where those Agile practices/routines can be
applied?
(Where does it make sense, where not?)
5. Is there any advice you would like to share with other organizations?
9.7. Altered Interview questions used with participant 9
Interview questions Thesis research
9.7.1. Introduction / ethical considerations
Participation is voluntary, the responses will be made anonymous, asking for agreement
to record
9.7.2. Experience agile outside of IT
1. How do you usually get requests to help at implementing Agile / Scrum?
a. Who requested your involvement, initiated the change?
90
b. How got that person inspired in implementing agile in a non-IT domain
in the first place?
2. What was the vision?
9.7.3. Change process / Introduction process agile in domains other than IT
1. How did you initiate or lead the change?
a. Did you used a specific change process to manage the change?
b. Could you give me 5 to 10 concrete steps on the change?
(I need these steps for later analysis. Most important result of interview)
2. How did the concrete change differ to the original plan?
3. What where the assumptions when you started?
4. Did you achieve the original goal(s)?
5. Looking back could you define success factors for the change?
9.7.4. Process now
1. How is agile implemented in the non-IT domain?
a. What the practices / routines / rituals / ceremonies did you
implemented [Stand-up, reviews, using boards, timebox, etc.]
b. Which practices or routines were useful?
c. How did you change / adapt any of those (changed timing, frequency,
explanation, goal, etc.)?
d. What is the reason some practices are no longer used?
e. What were the barriers to adoption?
9.7.5. Looking further
1. Where do you see this leading in the future (based on your organization)?
2. Can you imagine other domains where those Agile practices /routines can be
applied? (Where does it make sense, where not? ... ask for specific examples)
3. Is there any advice you would like to share with other organizations?
91
92
10. Appendix C - Code book
Code name
Description
#
codes
1 Motivation
What motivates organizations to apply agile
outside the IT domain? is it crisis or is there
another drive?
Poiesz states that: Motivation refers to the goals
0
1.1 Experience
Description of the method and role the
respondent has experience with applying the agile
way of working outside IT.
60
1.2 Need for change
crisis, competition is gaining, org need to lower
costs (cheaper), organization too complex
35
1.3 Inspiration
What of by who got the organization (or initiator)
inspired to make the move to agile?
61
1.4 Return on in Investment
Statement of what was expected by the
organization to be the result of the new way of
working.
44
1.5 Objectives
Defined goals/targets set by the organization
when implementing the agile way of working.
38
1.6 Industry
Industries the respondent has experience in
applying the agile way of working.
23
1.6.1 Domains
Here all domains are mentioned. Both the
domains where respondents have experience but
also the domains they think agile could be applied
(or not).
30
2 Used methods
What methods are used by the different
organizations when applying agile way of working
outside the IT domain?
This could be translated into the external
conditions.
Poiesz states: Opportunity refers to the external
conditions.
0
Data
collection Open
coding Axial
coding selective
coding
93
Code name
Description
#
codes
2.1 Framework
Method used by the organization
45
2.2 Success factors
What are critical success factors: start small,
senior level commitment, management vision,
customer focus.
0
2.2.1 learning organization
Ways the organization is developing their skills on
applying agile.
40
2.2.2 Challenges
Description of issues and challenges to overcome
when applying agile outside of the IT department.
89
2.2.3 Success factors
Actions, examples, results and consequences
when applying agile outside IT that make the
implementation successful.
73
3 Change design
How they did the implementation: started small,
move to big - started with one team -> success ->
commitment - learning journey
Poiesz states that capacity is: Capacity refers to
the instruments
0
3.1 Capability
The way an organization or team secured the
competent and efficient implementation of the
agile way of working.
0
3.1.1 Knowledge Management
An expression of knowledge management
performed during the agile way of working.
5
3.1.1.1 Education
Education or training the respondent had
followed.
17
3.1.1.2 Training
To master a new skill, you must learn and
practice. For agile way of working this means take
the team/organization along the new path.
18
3.1.2 Learnings from applying agile
Short tips, tricks or interventions during the
application of agile that are given by the
respondent. Not being challenges or Success
factors.
30
3.1.2.1 Experiment
1
3.1.2.2 EnergizeTeams
1
3.1.2.3 HardWork
1
3.1.2.4 KickOff
1
3.1.2.5 MakeChoices
1
3.1.2.6 MasterBeforeAdjust
1
3.1.2.7 NoFear
1
3.1.2.8 OrganizationalNeed
5
94
Code name
Description
#
codes
3.1.2.9 RightPeople
3
3.1.2.10 StartSmall
2
3.1.2.11 BeFlexible
6
3.1.2.12 TeamFocus
5
3.1.2.13 USeTheRightMethod
2
3.2 Change Strategy
A description of the steps involved in the
changing the way of working in to an agile way of
working.
61
3.2.1 Decision
Who is making the decisions during the change
process.
8
3.2.2 Guiding coalition
Arranging a group or team to help the changing
organization or teams start using the agile way of
working.
11
3.2.3 Evaluation
Is the change evaluated after or during the
change?
12
3.2.4 Plan
Creating a change plan.
16
3.2.5 No plan
Was there a plan at the start of the change?
10
3.2.6 Coaching
Mastering the agile way of working is to train or
coach the organization in becoming agile.
25
3.2.7 Starting event
The organization or team is introduced to Agile
way of working during a starting event.
7
3.2.8 Change support
Things, products, processes, etc. used to make
the change to agile working, not being the
standard change processes.
26
3.3 Initiation
This describes the person or organizational unit
who initiated / started the move to agile within
the organization but outside the IT domain.
27
3.4 Being flexible
Statement of the organization or team being able
to adopt to the change.
4
3.5 Involved management level
The involved management level described by the
respondent and the way management has to be
involved according to the respondent.
28
3.6 No change in way of working
Examples of issues why the team doesn't want to
change the way of working into the agile way.
6
4 Routines
What are the practices organizations used when
applying agile way of working within their
organization?
0
95
Code name
Description
#
codes
4.1 Impact
What is the impact of the used methods?
Popularity or external pressure on the choice
rather than potential fit in context.
0
4.1.1 Future of agile
What does the respondent say about the future
of agile? Where is leading to?
20
4.1.2 Organizational changes
What was the impact on the organization when
applying agile way of working outside IT.
45
4.1.3 Do agile not being agile
Organizations and people tend to adopt a new
method/framework because it is hyped. In agile
this is often called: they do agile but don't be
agile. You have to be agile to profit from the
method/framework and to use it to gain an
advantage on the competition.
13
4.2 Survey the customer
Interaction with the customer is described by the
respondent.
6
4.3 Role
What is the role the respondent has played in
applying the change to an agile way of working?
Was this a change manager or a specific agile
method/framework role, etc.
5
4.4 Ritual
The rituals used by the non-IT teams or
organization when applying the agile way of
working.
90
4.5 Rituals altered
When implementing a new way of working by
using a frame work some rituals will or will not fit
the organization. These rituals will be altered or
skipped by the organization.
45
4.6 Important rituals
The rituals that the respondents define as useful
in the move towards agile way of working.
14
96
11. Appendix D - The interviews
11.1. Interviews (Pilot-Phase)
The first interview was with an employee of a small company presenting itself as a
company that helps organizations to become Agile by using Scrum. This company
focuses exclusively on customers outside IT.
This company provides training and gives advice to organizations when they are
changing their way of working ay application of Agile or Scrum within different
industries, mainly in relation to marketing departments.
Interviews two and three were held with participants who worked at the same
organization; both are freelance employees and were hired to act as Agile coaches
within the marketing department. The marketing department has two hundred
marketers, who are divided into fourteen Scrum teams. These teams are coached by
three Agile coaches.
During the pilot-phase, the first interview was held via phone; the other two interviews
were held face-to-face at the financial institute where the participants worked. All
interviews were recorded; were put into a transcript, and were sent to the participants
for a final revision. Participant two stated that the transcript was not a reflection of the
interviews and that s/he would respond with an adapted version. The participant did not
in the end provide a revised version of the transcript. The initial transcript was used
during the pilot phase.
11.2. Interviews
This section describes that interviews that took place after the pilot phase.
The fourth interview was with a participant from Switzerland. The interview took place
via Skype and was recorded and transcripted for review. The participant returned the
transcript with some adjustments. Four items were changed to accord with the wishes
of the participant. Three revisions involved changing some unclear wording (question
1.1 should have read “software development” and not “software developer”); in
addition; the description of the tasks the interviewee carried out was corrected
(questions 4 and 7), and in one instance (question 6), the transcription was amended to
reflect the precise answer.
97
The fifth interview was with a consultant from an international organization providing
services in strategy, consulting, digital matters, technology, and operations. The
organization is a partner with more than three-quarters of the Fortune Global 500 and
with expertise across more than 40 industries and all business functions. The participant
has had 5 years of experience with Agile transformations. The interview was held face-
to-face at the participant’s office. The participant has international experience with the
application of Agile. At this moment in time, the participant is involved in consulting
clients during transformations towards Agile and trains people in Scale Agile
transformation for organizational leadership and operational level employees.
The sixth participant has had six years’ experience with applying Agile at a marketing
department in the energy industry. The participant’s interview was conducted face-to-
face. The participant has had experience working with Agile at different organizations.
At the energy organization, the move to agile started at the business level and involved
steering the IT department towards Agile ways of working. The examples used during
the interview originated from his/her experience in applying Agile at the marketing
department.
Participant seven lives in the United States. The interview was conducted using Skype
and recorded for transcription. The participant has had more than ten years of
experience in helping organizations to become more Agile. The focus has been on the
governance within the organization. In the last fast few years, the participant has
discovered the connections between various Agile methods. The participant has written
several books on alternative governance models and is currently working on a book
looking at the use of Scrum in organizations.
Interview eight was also conducted via Skype with a Ph.D. student, who is engaged in
research on Scrum on the topics of how Agile can be used for physical product
development and how to apply the principles from the software industry into the
development of physical products. The research approach of the participant has been
designed like a Scrum project. The participant had limitations on sharing information
due to a confidentiality agreement with the organization on which his research is
focused. Despite this agreement, the participant participated in the interview.
The interview with participant nine was altered. The altered questionnaire has been
added in section 14.3. The participant had only 30 minutes for the interview, so the
questionnaire was shortened to fit this timebox. The interview was held via Skype. The
98
participant did not have any hands-on experience in applying Agile methods outside of
the IT domain, but as public speaker, he has followed development within the IT
domain. The participant gave his view on the development in the domain based on his
knowledge and experience with clients. Because he plays an advisory role in terms of
Agile, he often does not see how implementation plays out in a real-life context.
The tenth interview was held face-to-face in the office of the participant. The participant
has had experience in the financial industry applying Agile within IT teams. At this
moment, the participant is working at one of the biggest retail organizations in the
Netherlands and is responsible for implementing the agile way of working at the HR
Department. The implementation of an Agile working at this team was brief. Scrum was
used during a small project. This project has finished, but the experience formed the
foundation for the next steps he will take. Next year, the organization is starting a
program of focusing on customers and Agile ways of working will form the foundation.
Participant eleven was recommended to me by participant seven. They are writing a
book together, uniting the governance experience of participant seven and the Agile
experience of participant eleven. The interview was held on Skype. The participant has
more than ten years of experience with Agile. In 2003, she co-authored about “software
development in large projects”.
Interview twelve was held face-to-face at the office location of the participant. The
participant has recently changed jobs and an important goal in this new job is the
application of Agile working at his current assignment. The experience of the participant
was based on the application of Agile working at a large financial institute in the
Netherlands. This organization offers insurance, savings, mortgages, and investment
services. The participant was working at the marketing department and was co-
responsible for the online services of the organization.
Participant thirteen is employed at a consultancy firm which advertises their success on
implementing Agile ways of working outside the domain of IT. The organization offers
consultancy services and Agile training. This participant was found via internet searches.
In addition, participant eighteen and nineteen were found via the same search since
they work(ed) at the same organization. In addition to consulting and training client
organizations, the organization itself adopted Agile ways of working years ago. The
director has published a book on Agile ways of working and the organization also has
created its own tools to help clients implement Agile.
99
Interview fourteen was held via Skype. The participant lives in Colombia and is the
owner of a consultancy and training company. The participant was found via the
internet, where he has published a presentation on his using Agile during construction
projects.
Interview 15 was held face to face at the office of the participant. The participant works
in the communication department at a Dutch university. Using Agile formed part of his
previous job, but he also wants to apply it at the university. This participant was found
via my supervisor’s professional network.
After a search on Agile/Scrum/education contact was made with a small organization
that focuses on the implementation of Scrum at schools. This organization directed me
to participant 16, who has had several years of experience in implementing Agile and
specifically with using Scrum with schools. The contact was by e-mail and the interview
was done at an external location (restaurant) face to face. The participant gave me a set
of items they use when implementing Scrum at schools. This was a set of cards, a poster
with the process being used, and a description of roles.
Participant eighteen was recommended by participant six. They had worked together on
implementing Agile. The interview was rescheduled several times due to missed
appointments by the participant. The interview was held by phone (it was initially
planned that we would meet face to face).
The participant for interview eighteen was found via a website search mentioned at the
interview with participant thirteen. The participant had just left the organization, but
LinkedIn contact was made. Due to holiday and work appointments, this interview was
held in November 2017. The interview was done via Skype.
This last interview was initiated after contacting the company of participants thirteen
and eighteen. Contact was initially made via e-mail and the interview took place by
phone. When the research subject was introduced, it became clear that the expertise of
the participant was not with non-IT applications of Agile, but only with IT applications.
The non-IT knowledge the participant had was based on hearsay from fellow-workers.
Therefore, the interview was ended and not transcribed or added to the results of this
report.
100
