Translating the Scrum to a translation agency : applying the Scrum framework in a non-software development company

(1)

Translating the Scrum to a translation agency

Applying the Scrum framework in a non-software development company

Student: Tijmen de Wit // 10683895

Faculty of Economics and Business

MSc in Business Administration, track: Entrepreneurship and Innovation

(2)

2

Preface

Joyce Carol Oates once beautifully said: ‘The first sentence can’t be written until the final sentence is

written’. This is the final chapter that is written, and this master thesis is also my final chapter as a

student. Looking back it was an intense but profound period of my life. In the end I can say this thesis brought me a lot of experience and it feels like a great foundation for starting with my professional career.

First of all I would like to thank all the people of the organization Concorde who have made it possible for me to do this research. In particular I would like to thank Anouk, who with her enthusiasm got me to dig in this new subject. I was excited to explore a subject that was entirely new to me, and it has given me a lot. I got the chance to have a look behind the scenes of practical management issues which were underexposed during my study. This combination makes that I feel I have formed a solid basis for the next step in my life in search for a professional career. Further I would like to thank my team members who have made it a wonderful and a very instructive experience for me. Last but not least, I would like to thank Dr. Wietze van der Aa for supervising my master thesis.

Tijmen de Wit

(3)

3

Abstract

Most companies are not having a shortage of good ideas but rather find it difficult to convert good ideas into products and services. This thesis attempts to explain how the Scrum framework might help convert good ideas into products and services. The Scrum framework was initially designed for the development of complex software products in highly complicated environments. In the literature was found that the Scrum framework might be useful outside the context of software development. First have been investigated to what extent principles of the Scrum framework are already being used outside software development. These findings are complemented with a single case study. During a period of six months the researcher has joined two projects in a service organization that have been carried out in Scrum. Second, interviews are held with key people who were involved in the Scrum. The results show that the Scrum framework can be adopted in the organization without much adjustment. The main difficulty is that the Scrum framework is designed for projects that require a team working full time on the project. In the studied organization this was not the case. Furthermore it was found that the Scrum is easy to learn, but hard to master. In conclusion the results showed that the Scrum can be used as a framework that offers a complete transparent set of elements that can help with the implementation of ideas. It also helps spreading ideas around the organization, which is especially helpful for ideas that have to do with business processes or other novelties that are used within the organization.

Keywords: Scrum, Agile, Innovation, Idea conversion, Idea development, Idea implementation, Case study

(4)

4

List of Figures and Tables

Figures Figure 1: A schematic view of the Scrum framework ... 8

Figure 2: The Scrum process overview ... 10

Figure 3: Created tree Nodes in Nvivo ... 20

Figure 4: The product backlog is estimated by the team by doing ‘planning poker’ ... 22

Figure 5: The Scrum board containing the user stories on the left and the (individual) tasks ... 31

Tables Table 1: Evaluation of the possibility of the agile execution of typical types of projects ... 17

(6)

6

1. Introduction

News, political statements, websites, movies, product literature, software, safety information, labeling, digital games and customer support are all translated every day in over 500 major language pairs worldwide. And with the continuing globalization it is not surprising that the worldwide

language services market is growing at an annual rate of 8% the last three years, with a current market estimated at 40 billion dollars (www.gala-global.org). It is not surprising that the market is full of translation agencies, in the Netherlands alone there are over a 100 agencies. And all of the

translation agencies seem quite similar. The market itself is also changing rapidly, most notably due to technical progress. Everybody can nowadays make use of machine translation like Google Translate. New apps like Skype are given the ability to translate spoken words instantly to any language. Even more salient is the development of robot technology and artificial intelligence, which was discussed extensively by the vice-prime minister of the Netherlands during the congress of SZW in September 2014. He stated that computer translation has gotten much faster than human

translation, and control a much broader vocabulary. He is concerned that it will take over the jobs of translators, and the market will be out of business. However, this statement may be seen as a little overanxious, to quote Prof. Alan K. Melby: ‘’translation is so intellectually complex that if machines

can do it really well, they will also be able to accomplish all other intellectual tasks that humans can perform, the impact on life in general will far overshadow any impact on translators’’ (Zetzsche,

2013). Although there is no need to be afraid, it is clear that technology and innovation is becoming more and more an important subject of this market.

Innovation is a concept that can be explained as a process where ideas are generated and transformed into implementable business products and services (Majaro, 1988). Most companies are not having a shortage of good ideas but rather find it difficult to convert good ideas into products and services (Hansen & Birkinshaw, 2007). These difficulties are often caused because of tight budgets, conventional thinking and strict funding criteria. Concepts that have been selected for further development eventually end up nowhere because the organization is too busy doing other things or fail to see their potential (Hansen & Birkinshaw, 2007).

This is also visible in the company that this thesis will focus on. This thesis will focus on the organization Concorde Group Global Translation Services (further referred to as Concorde). Concorde is a translation agency and an intermediary for interpreters. Within the organization innovation is an important part of the company’s strategy which reveals itself in the company’s vision. However, voices from the management indicate that there is room for improvement. Good ideas remain on the shelf or end up nowhere. To improve the development and implementation of ideas the management introduced the Scrum in the organization.

The Scrum is a metaphor for the game of rugby and was initially designed for the development of complex software products in highly complicated environments. The Scrum is an easy framework that has been used in leading edge software companies with significant success (Schwaber, 1997). Also more recent Jalali and Wohlin (2012) found that the Scrum is a widely used framework for software development. Recently there are some trends that the Scrum is also being used in a non-software development context, see for example Barton (2009), Pope-Ruark (2012) and the TED-talk by Bruce Feiler in 2013. More salient may be that the widely used Stage-gate process is incorporating

(7)

7 elements of the Scrum (Cooper, 2014). This is not entirely surprising since the Scrum framework has its roots from new product development (Schwaber, 1997). From an academic point of view however, there is not much research of the Scrum framework being used outside the context of software development. In fact, Stare (2014) analyzed thirty-three articles that examined the agile approach (‘agile’ is an umbrella term for different approaches, the Scrum is an agile approach) in the last decade and only three did not discuss software development projects and none of these specifically examined the Scrum. Dingsøyr et al. (2012) argues that the effectiveness of agile approaches (which includes the Scrum) in different project/organzational contexts needs to be studied for future research. And while many agile practices like the Scrum claim to be facilitating innovation, Abrahamsson et al. (2009) pleads for more supporting evidence between the true ability of agile approaches and innovation. Lastly Hamel (2006) stresses the importance of discovering new ways to organize, lead, coordinate and motivate. Can the Scrum be this novel approach that may enhance competitive advantage for users of the Scrum in the translation business?

Research goal

The goal of this thesis is to evaluate to what extent the Scrum framework is valuable for the development and implementation of new ideas that are selected in a non-software development context. Therefore the research question is:

What are the implications of using the Scrum for the development and implementation of new ideas in a non-software development organization?

In order to answer this main question, the following sub questions have been formulated as well:

Sub questions:

- What is the Scrum and how does it work?

- What are the (theoretical) foundations of the Scrum framework

- What is known and what can be expected about using the Scrum framework outside software development?

This thesis will, through an exploratory case study, seek to uncover how the Scrum framework might help develop and implement ideas in the translation services company Concorde. This company has implemented the Scrum framework in their organization which gave the opportunity to study this implementation from the beginning for a period of six months. Multiple Scrum teams have started in which two I have joined. This allowed me to see from close by observation how the implementation of the Scrum worked out. Furthermore I have collected data by interviewing participants of the Scrum in the studied organization. The goal is to deliver a broad set of ‘lessons learned’ that can be used for future implementations of the Scrum framework and for future research in more specific areas.

This thesis consists of six chapters. Chapter two addresses the current state of literature about the Scrum framework. It will present to what extent the Scrum has empirical evidence, where it comes from and what is known about using it outside software development. Chapter three will elaborate on the methodology that was used for this research. Then chapter four will present the results of the case study that was done within the studied company. The discussion and implications of this research will be discussed in chapter five and finally chapter six will address the limitations and propose directions for future research.

(8)

8

2. Literature review

2.1 The Scum framework

The Scrum is one of the many so called ‘agile’ software development methods, which is an umbrella term for several iterative and incremental software development methodologies, which all share a common vision and core values (Fowler & Highsmith, 2001). The Scrum framework was first discussed by Jeff Sutherland and Ken Schwaber at an annual programming research conference in 1995 (OOPSLA). They found, by studying the common software development process, that traditional development approaches were not suitable for empirical, unpredictable and non-repeatable processes. The Scrum framework is originally developed for managing software development projects and is freely available to anyone through the Scrum Guide (Schwaber & Sutherland, 2013). The Scrum is a framework used to manage projects and to stimulate collaboration using iterative, incremental practices. In short it is an ‘inspect and adapt’ framework that has three roles, three ceremonies, and three artefacts designed to deliver working software in Sprints, usually 1-4 week iterations (Scotland, 2005).

The Scrum Guide emphasizes that the framework is not a process or a technique for building products, but you need to employ various processes and techniques yourself that suit your situation. This implies that the framework is usable in other contexts than software development. However, no research has been done to see how this works out and what processes and techniques suit the framework. See Figure 1 for a schematic overview of the Scrum framework. Next the Scrum framework will be explained according to the official Scrum Guide (Schwaber & Sutherland, 2013).

The Scrum Framework

The Sprint The Team Artifacts

Time-boxed Review Retro Product Owner Developers Scrum Master Product- Sprint- Increment iteration Backlog Backlog

Figure 1: A schematic view of the Scrum framework

2.1.1. The Sprint

The main element of the Scrum is the Sprint. The Sprint is a time-boxed iteration of max 1 month where a potentially releasable product increment is created. In the Sprint the team commits itself to a certain amount of product backlog items that from that moment cannot be changed anymore during the Sprint. The Sprint consists of three ceremonies:

- The Daily Scrum is a short time-boxed meeting where the team inspects the work since the

last Daily Scrum and estimates what will be done before the next Daily Scrum.

- At the end of each Sprint a Sprint Review is held where the Development team presents the

work that is done to its stakeholders. This informal meeting is intended for feedback and collaboration with their stakeholders.

- The Sprint Retrospective is the meeting where the Scrum Team evaluates the process of how

(9)

9 are team dynamics or when they are actual processes, should be brought up during the Sprint Retrospective. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

2.1.2 The Team

An important part of the Scrum is the team. The teams should be cross-functional and self-organizing. To achieve effectiveness and efficiency of the team the Scrum Framework provides three roles:

- The Product Owner: The Scrum teams do not work with a project manager but instead a

Product Owner needs to be designated. The Product Owner is responsible for maximizing the business value delivered by the team. The Product Owner is one person and is responsible for managing the Product Backlog and is the person who accepts or rejects the delivered work of the team. The reason this to be one person is that it reduces chaos for the team. With one Product Owner there is no confusion for the team. The Product Owner should be a knowledgeable, empowered and engaged person.

- The Development Team: The developers are basically the persons who do the actual work.

Mostly they will be referred to as the team. They are responsible for transforming items from the product backlog in potential shippable products. Teams should be small enough to remain nimble and large enough to complete significant work. They are self-organizing, cross-functional, and no individual titles are given. The Scrum guide advices 6 (+-3) members. - The Scrum Master is the individual who facilitates the entire process. The Scum master is the

servant leader that ensures the team is delivering value, the Scrum master empowers the team. The Scrum Master removes impediments and keeps the process healthy. This person can be part of the development team at same time.

2.1.3. Scrum Artifacts

The Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. The Scrum Artifacts are:

- The Product Backlog is a requirement list by all stakeholders that is managed and prioritized

by the Product Owner. The Product Backlog is dynamic; it can be changed all the time. Anyone can add items to the Product Backlog, but the Product Owner is the gate keeper: this person decides whether an item needs to be added and prioritizes all (new) items. Although this is not specified in the Scrum Guide, the Product Backlog is usually set up in ‘user stories’. Good user stories most have the following characteristics (INVEST): Independent, Negotiable, Valuable to users or customers, Estimable, Small, and Testable (Cohn, 2004). The Product Backlog has estimates created by the team during the Product Backlog Refinement meeting. - The Sprint Backlog is the set of Product Backlog items that the team, during the Sprint

planning meeting, commits to do in one Sprint. What is committed in the Sprint Backlog cannot be changed anymore during the Sprint.

- The Increment is the sum of all the completed items during a Sprint that must be in useable

(10)

10

2.1.4. The Scrum process

In summary this looks like this (see figure 2). A Scrum project starts with a vision of anything that needs to be developed. The product owner creates a plan for maximizing the ROI by creating a product backlog with the items prioritized on top than will most likely generate value. Before the start of the sprint the product owner gets the team together to get input for the desired result, priorities and acceptance criteria. In this stadium, also called the product backlog refinement, detail and estimates are added to the product backlog by the team and the product owner. Then the team decides to how many stories they can commit during the next sprint and the first (individual) tasks are composed. During the sprint, the planned activities will be executed with the aim to deliver the desired results. This is an incremental and iterative process to extend and improve the product. Every day starts with the Daily Scrum meeting where each team member answers three questions: What have you done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Scrum meeting? What impediments do you encounter? A sprint has a fixed duration of two to four weeks. The created product or result should meet the agreed acceptance criteria. Both functional and non-functional requirements are defined in the Definition of Done related to the sprint. The result, which is delivered at the end of the sprint, is of the right quality, and as complete as possible that it can be implemented, defined as a shippable increment. At the end of the sprint a review meeting is held, where the result is demonstrated to and accepted by the stakeholders. After the review, before the next sprint, a retrospective meeting is held with the team to evaluate the process and to make improvements (Schwaber, 2004).

(11)

11

2.2 Why the Scrum?

As mentioned earlier ‘agile’ is an umbrella term for several iterative and incremental software development approaches, which includes the Scrum. Abrahamsson et al. (2003) performed a comparative analysis of the most used agile software methods. This analysis gives reason to believe that the Scrum is transferable to other domains than software development.

According to Abrahamsson et al. (2003) the Scrum is explicitly intended for managing agile software development projects and unlike most other agile methods, the Scrum leaves the choice to the developers which software development techniques, methods and practices to use. Further it uses abstract principles instead of concrete guidance. Whereas other agile methods provide concrete guidance like practices, activities and work products at different phases of the software development life-cycle. More important Abrahamsson et al. (2003) classifies the Scrum as situation appropriate, which means that a method can be adjusted to different situations. Lastly Abrahamsson et al. (2003) states that the Scrum is one of the few agile methods that has some empirical support. This will be discussed in further detail in the next section.

2.2.1 Empirical evidence of the Scrum framework

Although the Scrum framework is widely used and it might be applicable outside software development, it is important to establish whether the Scrum framework has some empirical evidence. The Scrum framework was originally not designed from reliable and systematic research but is derived from subjective practical experience (Abrahamsson et al., 2003). Schwaber and Beedle (2002) claim that the Scrum framework has been established though thousands of Scrum projects, but none of them are cited which make you wonder whether it is proven wisdom or folktales. This indeed gives no reliable evidence on the real usability and effectiveness of the Scrum framework. However, there are a few studies which have tried to validate the Scrum framework.

Abrahamsson et al. (2003) performed a comparative analysis on different agile methods and found one empirical study that tested the Scrum framework. In this study the researchers concluded that the Scrum is appropriate for projects where requirements cannot be defined up front and chaotic conditions are needed to be anticipated throughout the product development life cycle (Rising & Janoff, 2000).

Dybå and Dingsøyr (2008) also did a systematic review to present empirical findings on different agile software development methods, including Scrum. The systematic review included qualitative and quantitate studies published up to 2005. The Scrum was only studied in one empirical research article, which they found worrying since they state that the Scrum is very popular in the industry. In this article Mann and Maurer (2005) studied the impact of the Scrum on overtime, and customer and developer experience was studied. They found that the introduction of the Scrum led to a reduction of overtime and that all the developers saw that the Scrum fostered more customer involvement and communication. The developers were also more satisfied with the product and they all would recommend the Scrum for future projects. In addition the customers were also more positive and responded that ‘they are more involved and therefore are being held accountable earlier

in the process for any changes and concerns that have or had to be considered’ (Mann & Maurer, 2005, p. 8). Furthermore Dybå and Dingsøyr (2008) concluded that agile methods in general are more

suitable for small teams than for larger projects. Lastly they found that it is not necessary to abandon traditional project management principles, the stage-gate for example seems to work in conjunction with the agile principles (Karlström & Runeson, 2006). A limitation was found that team members are

(12)

12 less interchangeable in agile teams and that it works best with experienced development teams. On product quality no hard evidence was found.

Moe et al. (2010) studied team performance and looked at the several mechanics that the Scrum therefore has in place, such as the team roles. They argue however that the Scrum offers no clear advice on how to become self-managing. In their study they found that the Scrum master focuses more on command-and-control than providing direction and support for other team members. Their study backs up previous studies that trust among the Scrum master and the team is an important component for collaborating to provide value-added ideas. Further they argue that there is a vast literature on teamwork that is very relevant for Scrum and deservers more attention.

Lee and Xia (2010) empirically researched the teams’ autonomy and diversity aspect of agile practices, aspects which are also to be found in the Scrum. They found that software teams should first prioritize the performance goals of time, cost, and functionality, which will determine how much autonomy and diversity the teams should require on these dimensions. They also found that standardization of processes, tools and methodologies can be helpful for managing changes, cost and time.

Cohn (2010) states that the Scrum leads to higher productivity and lower costs, improved employee engagement and job satisfaction, faster time to market, higher quality, and improved stakeholder satisfaction. He made those statements based on studies done by Mah and Lunt (2008), Rico (2008), Greene and Fry (2008), and an online survey by a popular development magazine (Ambler, 2008) and agile tool vendor VersionOne (2008). These studies do not come from scientific journals and therefore the statements made should be taking into consideration with caution. In the study by Mah and Lunt (2008) productivity was measured by taking effort, schedule and technical difficulty into consideration. Mah and Lunt (2008) found a statistically significant increase of 16% on productivity in comparison with traditional teams. The survey by Rico (2008) showed a median productivity increase of even 88%. This is explained by the fact that this research included that Scrum teams are less likely to build functionality that is no longer needed, because of the frequent feedback, time-boxed sprints, and the ability to reprioritize each sprint.

Improved job satisfaction by using the Scrum has been found by a Survey by Greene and Fry (2008) within Salesforce.com. Fifteen months after adopting the Scrum 86% of the employees rated their job as having a ‘good time’ or ‘best time’, in contrast to only 40% before the implementation of the Scrum. According to Cohn (2010) job satisfaction may be positively related with higher productivity and lower costs. He states that a study by Mann and Maurer (2005), that is mentioned earlier in this section, has found that the Scrum leads to less overtime working by the team members, and Cohn argues that this more sustainable pace of working may be the reason for improved job satisfaction. He also mentions that more control over your day-to-day work, seeing the results of your work get used sooner, better collaboration with coworkers, and creating products that are more likely to meet customer expectations may be factors for higher job satisfaction, although no evidence is given.

The study by Mah and Lunt (2008) and the survey by VersionOne (2008) both show improved time to market for Scrum teams in comparison with traditional teams. According to Cohn (2010) a faster time to market is realized by the higher productivity and the fact that Scrum teams are more likely to release increments more often.

Higher quality has been found by Ambler (2008), Rico (2008) and the survey by VersionOne (2008). Rico (2008) for example found a minimum quality improvement of 10% and a median improvement of 63%. Cohn (2010) endorses these results with his own personal experiences. He

(13)

13 states higher quality is realized by working at a sustainable pace which prevents sloppiness, and because of smaller iterations and more often feedback from stakeholders.

Lastly a more recently published paper by Tarhan and Yilmaz (2014) performed a systematic analysis and comparison of development performance and product quality of an traditional ‘waterfall’ process and an combination of agile processes including Scrum. They concluded that the agile process was superior to those achieved by the traditional process based on development performance and product quality.

To conclude it remains to say that the number of studies that follow a sound empirical method and reveal the effect of using the Scrum is scarce. However, tentative statements can be given that the use of the Scrum within a company can lead to significant benefits.

2.2.2 Theoretical roots and criticism

As has become clear by the previous section, the Scrum can be criticized for on the one hand that it has little scientific support, but on the other hand that it is also nothing new. Schwaber (1997) for instance revealed that the foundation of the Scrum framework lies in a new product development approach that was first observed by Takeuchi and Nonaka (1986) with high performance teams in leading companies. They found that successful teams emphasized speed and flexibility by not using a traditional sequential approach, but by using a holistic approach where a multidisciplinary team moves as a unit, like in rugby, hence the name Scrum. They identified six characteristics that encompass this holistic approach which might also explain whether the Scrum framework is effective:

 Built-in instability: The development process is never a clear given thing and this gives a team

natural freedom, but also extremely challenging goals. -This is also the premise of the Scrum framework, since it has been stated that it is inspection and adaption of the process is important (Schwaber & Sutherland, 2013).

 Self-organizing project teams which meet the following three conditions: 1. Autonomy: the

team is free to set its own direction 2. Self-transcendence: teams form their own goals and keep pushing the boundaries that often leads to overcoming the status quo and making big discoveries. 3. Cross-fertilization: The use of multidisciplinary teams, but also by placing a wide variety of personalities into a team is conducive for fostering new ideas and concepts. Another importance for cross-fertilization is to be all in one room. As one team member stated in the research of Takeuchi and Nonaka (1986, p. 140): ‘’When all the team members are located in one large room, someone's information becomes yours, without even trying.’’ – 1. In Scrum teams autonomy is given by involving them in clarifying the Product Backlog and in having the final judgment about what needs to be included in the Sprint Backlog. 2. The Scrum is focused on the result only, which leads that teams are completely free about

how to achieve it. 3. A requirement is that Scrum teams are multidisciplinary and are working

together in one room.

 Overlapping development phases: In the studied companies they found that overlapping

development phases leads to greater speed and increased flexibility, than when using the traditional sequential phases. But they also found some ‘soft’ merits that the overlap caused: enhancement of shared responsibility and cooperation, stimulation of involvement and commitment, sharpened problem-solving focus, encouragement for initiative taking, development of diversified skills and a heightened sensitivity toward market conditions. -The

(14)

14 basic idea of the Scrum is that you deliver a piece of working product at the end of a short period, a sprint, which requires a lot of overlapping phases in a short period.

 Multilearning: Learning is observed on two dimensions: across multiple levels (individual,

group and corporate) and across multiple functions. -Learning at multiple levels is not directly included in the Scrum framework, but at multiple functions is. The idea of Scrum is that members should be able to adopt each other’s tasks. Therefore it is recommended that team formations are not changed too often to encourage team learning.

 Subtle control: Subtle control is used by management to prevent the team running in chaos.

The focus is on avoiding control that may damage creativity and spontaneity. –In Scrum control is assured by two persons: The Product Owner and the Scrum Master. The Product Owner is always one person who is accountable for the Product Backlog, and no one is allowed to tell the team to work from a different set of requirements. The Scrum Master is a servant leader that protects the rules, removes impediments and should assure that teams are self-organizing and become cross-functional.

 Organizational transfer of learning: Institutionalize the lessons derived from successes. –The

Scrum has the Sprint Retrospective. Here the lessons derived from the success can be institutionalized throughout the organization.

As noted above all these elements are somewhat reflected in the Scrum framework. Indeed, according to Nerur and Balijepally (2007) the basic principles of al agile approaches show similar patterns of intellectual evolution that have emerged from other disciplines, such as design thinking and strategic management and also Stare (2013) points out rightly that some basic assumptions of the agile approaches are already widely known from theories of leadership, motivation and communication developed in the 1960s. Rising and Janoff (2000) also showed that most of Scrum’s elements are not new, but revised. They for example asses that the essential idea behind the spiral model by Boehm (1988) is exactly the same as the sprint in Scrum, but the iterations have gotten shorter. To conclude this means that the advantages of the Scrum framework are not all empirically tested, but the different elements of the Scrum framework separately have their roots from more rigor research.

However, Stare (2013) argues that the advantages that are given by some authors to use the Scrum over a ‘traditional’ approach are somewhat flawed. He mentions that these authors wrongly assume that in traditional projects the manager independently plans the project and is the only one who controls and allocates tasks. Second he states that incorrect assumptions are made that members of traditional projects work alone without collaboration and that work is carried out strictly sequential. Another weakness of the traditional approach that is stated by supporters of Scrum is that in traditional approaches pressure on the performers is pronounced only in the last few months, making them completely exhausted at the end. Stare (2013) argues this is not a weakness of the traditional approach but usual a consequence of poor plans and an unorganized manager and/or team. Lastly Stare (2013) counters that a waste of time (and increased costs) when someone waits for predecessors to complete their tasks with the fact that this only implies for pure project organizations where team members are working full time on one project and that this is not the case for matrix organizations that currently dominates the line.

Two more criticism against the Scrum is presented in a blog by Cohn (2014), author of

Succeeding with Agile: Software Development Using Scrum (Cohn, 2010). The first one is that the

(15)

15 many people question whether it generates enough value to warrant the expenses. The second criticism is that Scrum teams have become too focused on ‘checking the boxes’ and are therefore losing the focus on innovative solutions to the problems they are handed. He explains that because teams are getting over obsessed by finishing the stories that they rather play on safe then trying to do anything wild and innovative. The cause of this, he explains, is the movement to shorter sprints of two weeks, which is the norm nowadays.

2.3 Using the Scrum outside software development

As mentioned earlier there is reason to believe that the Scrum might be useful outside the context of software development, however little research about this can be found. Stare (2014) checked thirty-three articles that examined the agile approach in the last decade and found that only thirty-three did not focus on IT projects. In none of the studies the Scrum was explicitly used. One of these studies, however, demonstrated a number of problems of using iterative development principles, which are found in Scrum, in product development. In this study by Berger and Beynon‐Davies (2009) they found problems with stakeholder involvement: ‘In general, stakeholders were initially passive in their

involvement and, although formally empowered, proved reluctant to make decisions outside of their expected positions. Communication within design sessions was also restricted rather than open. Such difficulties impacted upon the project’s trajectory causing delays in meeting key project deadlines’ (p.

567).

Another recently published article about agile methods in non-software context is for the widely used Stage-Gate system (Cooper, 2014). The Stage-Gate is an idea to launch system that acts like a road map for driving new product development projects from idea to launch and is especially useful when having a portfolio of new product projects. From origin it breaks the new product process into sequential stages that are guarded by gates. When the process runs into a gate, senior management, or gatekeeper, reviews the quality of the project and decides whether to continue or cancel the project. The Stage-Gate helps improving the effectiveness and efficiency of new product development (Cooper, 2008). Recently Cooper (2014) have found that successful companies are using a new generation of idea to launch process that incorporates agile techniques. In the basis the new idea-to-launch system still looks a lot like the traditional one with stages and gates, but the details of the process and its function are a lot different. Cooper already mentioned in an earlier paper that the next generation idea-to-launch system incorporates the adaptive spiral/iterative development process that is known from agile software development, but in his recently published paper he also found that companies are incorporating other agile elements such as the short time-boxed increments in which the deliverable is something that can be demonstrated to stakeholders, as is the case for Scrum. He uses an example of a physical production company that successfully adopted the spiral development that is consistent with two core principles of the agile software development which are also be found in Scrum (Fowler & Highsmith, 2001): a focus on quick response to change, and continuous customer or stakeholder involvement in the development of the product. This company however, uses iterations of 60-90 days, which is longer than usually is the case for software development and is recommended in the Scrum Guide (Schwaber & Sutherland, 2013). Another example was given of Hewlett-Packard. They found that the traditional phase review process was excellent for mature markets but not for emerging, fast moving markets and are now using an agile model for growth sectors. And an Austrian producer of hardware is using agile principles when breakthrough projects are needed; when the project is vague or unknown what the project will lead to.

(16)

16 Cooper (2014) however, argues that not all principles of agile development are suitable outside software development. He states that physical product development is different from software because software is almost infinitely divisible. Second he states that software development consists of coding that can easily be broken down in smaller pieces, i.e. increments of working products, which is usually not possible for physical products. Therefore he states that the notion of short time-boxed sprints do not apply as well for physical product development. Nevertheless leading firms are integrating key elements of agile development into their Stage-Gate processes. He found that these companies are using the time-boxed sprints, although with a longer duration than 1-4 weeks, in which after every sprint in a review something physical can be demonstrated. And instead of moving from gate to gate these companies now go from sprint review meeting to sprint review meeting. Second the emphasis is more on results rather than documentation. To conclude, time-boxed iterations have successfully been adopted by successful firms outside the context of software development, although in longer duration. Also the review in which a partial deliverable is shown at the end each sprint has been adopted and has made the gates less relevant.

A problem that Stare (2013) foresees with working in sprints and not knowing the end result upfront and having no pre-defined deadline, is that managers cannot set up new projects because they don’t know when they will finish the current one. This might especially be problematic for the role of Product Owner. Karlström and Runeson (2006) found a similar problem for software development, and they suggest using the Stage-Gate and agile development principles in conjunction, since it can help decision makers sponsoring the project or acquiring the outcome of the project. And they state it helps getting a good balance between agility and discipline.

Also Stare (2013) argues that the main benefit of agile approaches is that the intermediate deliverables can already be used. In this article Stare (2013) did a subjective assessment on the universality of agile approaches. He took a broader view to see to what extent the key agile development principles, which are all to be found in Scrum (Fowler & Highsmith, 2001), are applicable in other fields. For an overview see Table 1.

Less is known about the benefits of the Scrum team roles outside software development. For instance as mentioned earlier, according to the Scrum Guide the teams should be self-organizing and cross-functional. As discussed earlier, Moe et al. (2010) already showed that the Scrum framework does not give clear direction to do so and that in software development it cannot be taken for granted that the roles will facilitate this. And for developing new product or service ideas this might be even more complicated. A study by Jassawalla and Sashittal (1999) revealed that for new product development the benefits of cross-functional teams are not so evident. Managers usually are stuck with the problem why some groups transform into a high performance teams, while others are having trouble functioning better than average. Jassawalla and Sashittal (1999) found that collaborative behaviors are seldom a result from mere membership on teams and are difficult to learn. So the question is whether this is facilitated by the roles of the Scrum Master and the Product Owner.

As has become clear by Cooper (2014) and Stare (2013), the possibility of using partial results is a significant advantage of agile approaches. And based on this Stare argues that agile approaches are therefore most likely useful for the development of services and business process reengineering, since both also satisfy other requirements that are coherent with the agile principles.

(17)

17

√ – YES, possible (√) – possible, but rarely x – not possible

Additional notes concerning the table:

(1) depending on whether the team develops a retail product or semi-product for a specific client

(2) depending on the desires/requirements of the client (the extent to which the client invented a product itself) (3) if the project also includes the development/modification of IT support

(4) development plan (of prototype, final drawings) based on the conceptual design (product, building) (5) a plan of the introduction of the reengineered process (organisation) on the basis of the designed process (organisation)

(6) applies to services

(7) conditionally, for example: on the basis of the electricity line designs the investor can start looking for a contractor (8) conditionally, for example you can live in a house that does not have insulation and roughcast, and where only the ground floor has been completed

(18)

18

2.4 Conclusions and research gap

In the beginning of this thesis the elements of the Scrum framework have been identified and their workings have been explained. The Scrum framework has been successfully used for years for software development, and some empirical evidence for this has been given. Second, there is established that there is reason to believe that Scrum might be effective outside software development, most likely for the development of services and business process reengineering. Some companies have already adopted some principles of the Scrum framework, but none of them however tested the whole framework in an organization. This thesis will, through an exploratory study, seek to uncover how the Scrum framework might help develop and implement ideas in a service organization. But first based on the literature a tentative conclusion can be given for the research question of this thesis:

What are the implications of using the Scrum for the development and implementation of new ideas in a non-software development organization?

The Scrum Framework

The Sprint The Team Artifacts

Time-boxed Review Retro Product Owner Developers Scrum Master Product- Sprint- Increment iteration Backlog Backlog

Figure 1 (recurrence): A schematic view of the Scrum framework

First of all let’s take a look back on the Scrum framework as is shown above. First look at the Sprint; the time-boxed iterative development cycles are being used outside of software development. In physical product development however, longer sprints are used, because physical products cannot be incrementalized as easy as software. On the other hand, service organization may benefit more of shorter sprints, because service ideas remain conceptual throughout the development process which means interaction between the customer and the service provider is critical. This is also depicted in the last row of Table 1. A second element about the Sprint that needs to be taken into consideration is that the Scrum is designed for teams that are working full time on a project. Stare (2013) however argues that in most organizations people are not working full time on one project. This has implications for the speed of delivering new products (Cooper, 2011). Therefore organizations need to take into consideration the level of novelty and the importance of a fast time to market for projects individually. Since working fulltime on projects outside software development is not so evident, organizations that are adopting the Scrum should take notion of the fact the higher in level of novelty the project is, the more dedicated the teams need to be for it to make it a success.

Thirdly the Scrum Review has been found effective for moving from milestone to milestone, rather than from gate to gate. The Scrum Retrospective is less reflected in the literature, but the importance of institutionalizing lessons from success is explained by Takeuchi and Nonaka (1986), where the Scrum is derived from. For software development, however, has been agued by Cohn (2014) that the Scrum has a lot of overhead because of the amount of meetings it has. This may be even more problematic for teams that are not working full time on Scrum projects which is more

(19)

19 likely outside software development. These organizations that are adopting the Scrum probably need to find a better balance for this, for example by doing shorter or less frequent meetings.

The second element of the framework comprises the Team. For the team not a lot of differences are expected compared to software development. The fact that the Scrum has its roots from thoroughly research by Takeuchi and Nonaka (1986) can therefore be considered as a solid basis, although a little dated. But elaborating on the workings of a team can fulfill a whole another thesis. It, however, acknowledges the importance of cross functional an autonomous teams for complex projects that are uncertain in outcome. New are the roles of the Product Owner and Scrum Master. These are set up to enhance the probability for a project to become a succession, i.e. to enhance the performance of the developers. The expectation is that the roles, mainly the Scrum Master, will provide a small facilitator for this, but a deeper understanding of team workings are needed for organizations who are adopting the Scrum. For the role of the Product Owner a difficulty has been found that the end results are unknown when working in short sprints, which make it difficult getting sponsors and approval for projects, or acquiring the outcome of the project.

The last element is the Scrum Artifacts. It has already been concluded that the increment, or in other words the possibility that a partial result can be used/exploited, is expected to be significant advantage of the Scrum. And this is most likely possible for services, because service ideas remain conceptual throughout the development process and where interaction between the customer and the service provider is critical. For software development has been found that the dynamic product backlog has been found useful to steer the project more easily, which makes it more flexible and adaptable to the situation. Second the team is more involved, because it participates in estimating and clarifying the product backlog, and is responsible for how much is committed for the sprint backlog. It has been found that teams in software development are inclined to be focused too much on finishing the backlog items and therefore lose the focus on innovative solutions. This is probably also something to be aware of outside software development. What also remains to be seen is how multiple backlog items that are committed in a sprint will lead to a partial useable/exploitable result at the end of the sprint.

As shown above there are some loose ends from the literature review about using the Scrum framework outside software development. Therefore in addition to be able to answer the research question more thoroughly, and to be able to confirm previous statements, the workings of the Scrum framework in a non-software development organization will be analyzed. Through an exploratory study, it will seek to uncover how the Scrum framework might help develop and implement ideas in a service organization.

(20)

20

3. Research Method

The Scrum has been studied in numerous studies over the time, but rarely in a non-software development organization. Therefore it remains a practice that is not well understood. In order to be able to answer the research question a qualitative single case-study is selected. According to Yin (2003, p. 13) a case study is ‘an empirical inquiry that investigates a contemporary phenomenon

within a real life context; when the boundaries between phenomenon and context are not clearly evident; and in which multiple sources of evidence are used’. This approach was selected because it

enables to gain a broad understanding of the workings of the Scrum framework within its organizational context. With a qualitative approach broad concepts and theories can be tested in particular cases and it can provide insights that are difficult to produce with quantitative research (Gephart, 2004). And due to the fact that the use of the Scrum in a non-software development context has to be analyzed rather than tested, and appropriate conclusions have to be made, qualitative research is the logical option. Gephart (2004) argues that qualitative research can provide bases for understanding social processes that underlie management. And by doing qualitative research you are able to get exposed to important management issues and concepts that may enrich the field. In addition qualitative research gives the researcher the opportunity to follow the processes as well as the logic behind it from the beginning to the end, which makes it discovery oriented as well as deep and detailed (Reichardt & Cook, 1979).

To summarize, the qualitative case study is exploratory in nature, process and discovery oriented, which gives the possibility to the researcher to properly investigate and make own conclusions on the research topic. This is especially useful since this thesis is moving in a fairly understudied research area.

3.1 Data collection

The unit of analysis of this thesis is the organization Concorde Group Global Translation Services (further referred to as Concorde), that is studied for a period of over 6 months. Concorde is a translation agency and an intermediary for interpreters. The reason to choose for this company is twofold: 1.) Concorde is a non-software development organization and is implementing the Scrum framework during my research period. 2.) I already work in this company as a part time employee; therefore it is easy for me to get access to company information and respondents.

There are different data collection techniques possible for a case study, such as a combination of interviews, observations, documentary analysis and questionnaires (Saunders & Lewis, 2012). The main source of data will be observations and interviews. Gephart (2004) distinguishes several observational methods including participant observation which I will use. Participant observation involves direct social interaction in the field with subjects and events. According to Gephart (2004) it is common for a researcher to play the role of a member of the group studied and to use subjective experiences as critical data. Data has been collected for over six months by being part of two Scrum projects as a member of both teams. This way I was able to experience the implementation and workings of the Scrum from close. Of many Scrum sessions I have been documenting how things are going, what is going well, what is not going well. The first weeks I have been strictly documenting every session. After the second sprint, after about two months, less documentation is kept, since in the researcher eyes less noteworthy events happened. On the one hand it can be argued that less strictly documenting could lead to missing relevant documentation of events that not seemed so relevant when it occurred. On the other hand it led to a

(21)

21 more clearly, transparent amount of documentation, instead of abundant, repeating and more cluttering documentation. And this was preferred over possible missing relevant events.

Second, seven semi-structured interviews are held with different Scrum team members and the product owner, six months after the adaptation of the Scrum framework in the organization. There is not chosen to do interviews in an earlier phase of the research period. This could have provided the research with more data specifically on the implementation of the framework in the organization. It was chosen not to do so since the scope of the research is already rather broad.

The persons are selected by using purposive sampling. This sampling method is particularly useful when collecting qualitative data. The researcher will choose the participants by his own judgment who will best be able to help answer the research question (Saunders & Lewis, 2012). The criteria were based on the people who were involved in the Scrum during the research period and who have at least finished two sprints. In total twelve people were directly involved in the Scrum during the writing of this thesis, of which seven are interviewed. Five of them have at least finished six sprints and were involved in the Scrum from beginning to end. Another two were involved in two sprints. Lastly another five just started with their first project in Scrum and are therefore chosen not to be interviewed.

Semi-structured interviews are collected since this is the most suitable technique to capture the experiences of the participants of the application of the Scrum framework and its individual elements. A semi-structured interview is therefore particularly useful since you can decide to ask additional questions to find out further details and explore your objectives more in depth (Saunders & Lewis, 2012). The interviews were conducted by the researcher and recorded with a voice recorder, transcribed within two days and validated with the participants for added rigor and to offset unintentional observer bias (Patton, 1990). This is important since close exposure to the study of the case may biases the findings.

Lastly data has also been collected from attending a Scrum workshop and visiting a software development company that implemented the Scrum for over three years. Brief notes of these events are taken.

3.2 Data Analysis

After all the data was collected it was analyzed and coded by using the analyzing program Nvivo. According to Saldaña (2012) coding is a heuristic - an exploratory problem-solving technique without specific formulas to follow and is the initial step toward an even more rigorous analysis and interpretation for a report. Since the personal documentation and the interviews led to a cluttering amount of data, it is important to have a structured manner for doing the analysis, and coding is useful manner to do so. According to Saldaña (2012) to codify is to ‘arrange things in a systematic

order, to make something part of a system of classification, to categorize. When codes are applied and reapplied to qualitative data, you are codifying a process that permits data to be segregated, grouped, regrouped and relinked in order to consolidate meaning and explanation’ (p. 8). For the

analysis in Nvivo, several codes were set up corresponding to the aspects of the Scrum framework as is depicted in the literature review. Since these codes are based on the literature, they are set up in a deductive manner (Miles & Huberman, 1994). First I set up the three main themes according to the Scrum framework: The Team, The Sprint and The Scrum Artifact and then broke them down in the remaining categories. Basically the experiences by the participants are assigned to the different elements of the framework. Second the code ‘Ideas Development and Diffusion’ was created. This code is centered on how the Scrum can help develop ideas into viable products or services, and how

(22)

22 the Scrum can help spread developed ideas within and outside the company. This code is created to give a good overview of results that were already assigned to the multiple previous categories, but it also contains results that could not be assigned to one of the previous categories. Also the code ‘Introduction Scrum’ was created for assigning text that had to do specifically with the implementation of the Scrum framework. During coding the ‘Scrum General’ code was created for data that might be relevant but could not be categorized in one of the existing codes. Based on this data the two codes ‘Quality’ and ‘Efficiency’ was created. See Figure 3.

Although Saldaña (2012) argues that all coding is a judgment call since we bring our subjectivities, our personalities, our predispositions, and our quirks to the process, rigor has been ensured by using the Scrum framework as a leitmotiv.

(23)

23

4. Findings

In this section the implementation of the Scrum framework will be described within a particular organization. This chapter provides an overview of the results of the observations and interviews. The results of the interviews are shown as quotes and will be leading. The results of the observations are given when additional information is found relevant that was not explained by the interviews. First a short introduction will be given of the company. Second will be discussed whether the framework is properly implemented by using the ‘Nokia Test’. Then this section will continue with the results of the implementation of the Scrum framework (section 4.5).

4.1 The company

The company Concorde Group Global Translation Services is the largest translation company of the Netherlands. Besides translations it offers interpreters and language training. It states to be ahead of the competition by delivering an innovative workflow. The majority (over a thousand) of the translators and interpreters are freelancers. The organization itself employs 130 people. During the writing of this thesis they started to use the Scrum framework for multiple projects. Every project has the same product owner and the same Scrum master. The Scrum master is also part of the development team.

4.2 The ‘Nokia Test’

The Scrum framework allows situation appropriate modifications (Abrahamsson et al., 2003). This raises a major question with the implementation of the Scrum in a non-software development context; namely to what extent can you tailor the framework to your situation. Within the agile community there is often discussion whether an organization actually was doing Scrum when they said they ‘tried’ it (Green, 2011). It is important to evaluate whether an organization has implemented the Scrum as it is proposed by this framework. The ‘Nokia Test’ is an effective approach to do so (Santana et al., 2009). Although the test may arguably be too minimal, it has been stated that it provides a good core of Scrum that will prevent you from the most common flaws. Second, as stated earlier, the Scrum needs to be adaptive and therefore the test cannot be too comprehensive. This is necessarily true for this case study since the Scrum is implemented in a different context.

The test has been confirmed by the Scrum master. The Nokia test considers of the following questions:

Adopted Are you doing Scrum?

✔ 1. Iterations must be timeboxed to less than 4 weeks

?/✔ 2. Software features must be tested and working at the end of each iteration

✔ 3. The iteration must start before specification is complete

✔ 4. You know who the product owner is

✔ 5. There is a product backlog prioritized by business value

✔ 6. The product backlog has estimates created by the team

X/✔ 7. The team generates burndown charts and knows their velocity

✔ 8. There are no project managers (or anyone else) disrupting the work of the team

(24)

24 As table 1 one shows Concorde passes every phrase except ‘The team generates burndown charts and knows their velocity’. Each question will now be discussed briefly.

The first question relates to the duration of each sprint. In the case of Concorde all the projects have iterations less than 4 weeks. The second question is literally in the context of software development. However, every Scrum project within Concorde ends its iteration (sprint) with a sprint review where the results are shown to its stakeholders. Therefore this question can be tentatively checked. The third question can be checked since sprints have started before specification was complete. The fourth question is checked because every Scrum project within Concorde has a product owner as described by the Scrum Guide. The fifth and sixth question comprises to whether there is a product backlog and whether it is estimated. In the case of Concorde every product backlog is specified and prioritized by a product owner, based on business value. Every story is written by the product owner in the form of business value. Then during the backlog refinement meeting the product backlog is estimated by the team by ‘planning poker’, so both questions can be checked.

Figure 4: The product backlog is estimated by the team by doing ‘planning poker’

The seventh question is about monitoring progress, which according to the test should be done by making a burndown chart and measuring velocity. The Scrum Guide does not provide clear guidelines for monitoring progress, only that it has to be transparent to all stakeholders (Schwaber & Sutherland, 2013). However, in Scrum progress is usually measured by velocity. Each story can be expressed in units such as t-shirt sizes or story points (Cohn, 2010). According to Cohn (2010) velocity is very hard to measure for teams who just started with Scrum. Until a team has sufficient historical data, any estimates remain very risky. There is no clear answer for how much data you need, except the more the better. During a Scum event in Amstelveen a professional Scrum master told that a new team usually needs about six sprints before it starts to pay off and a team can make right predictions. Cohn (2010) states that you can expect this to happen from the fourth sprint, but this should not be taken as a rule. He states that it can differ a lot when changes occur, such as changing team members. During the writing of this thesis one team has just finished sprint six. Velocity has been measured from the beginning, first in t-shirt sizes and since sprint 5 in story points. However, there is no burndown chart yet in use to visualize the progress. But it can be stated that the burn down chart

(25)

25 would not have been of much use. As Cohn (2010) stated some teams need more time before accurate estimations can be made. This applies especially for this situation since the Scrum is applied in a different context. In the situation of Concorde it was observed that the stories for example are a lot different than they are in software projects. Therefore the estimations are much harder to do, because there are no good examples available. However, during an interview with the Scrum master, after sprint six, she told me: ‘It is time that we figure out how the burndown chart works and how to

design this.’ To conclude, within Concorde the Scrum teams are using velocity to measure progress,

but are lacking visual burndown charts. This may be due since the organizations is relatively new to Scrum, but the organization is aware of the burndown chart as stated by the Scrum master.

Lastly question eight has been takin into consideration: There are no project managers (or

anyone else) disrupting the work of the team. Although this was sometimes the case in the first sprint

of the first project, the Scrum master confirmed that the teams are now autonomous and there are no project managers, or anyone else, disrupting the work of the team.

To conclude, according to the Nokia test it can be stated the Scrum is sufficiently implemented as is proposed by the framework.

4.3 Introduction of the Scrum in the organization

Before the introduction of the Scrum, new ideas that where turned into projects could be considered as an ad hoc approach. During multiple interviews it became clear that there was no dedicated process. New ideas had to be implemented between the acts of the job. The Scrum was introduced in the organization by the innovation director, who has taken the role of Product Owner. She felt that good ideas remain on the shelf or end up nowhere, and the organization was in need of result oriented control. She explains that the organization recently introduced a new work design, in Dutch commonly known as ‘het nieuwe (samen)werken’. In addition a Scrum team member explains that the introduction of the Scrum fits in the organization because of this new work design, and she mentions it was also an imperative: ‘Concorde is in a kind of transition, in which we want to give people ownership, in which the top-down approach is reduced. We would have had a lot more resistance for the Scrum if this transition had not yet started.’ (139-141, 147, ST member 5)

The implementation in the organization was nevertheless not without a struggle, which the following citation makes clear: ‘In the beginning everybody thought we were just in meetings and that we didn’t do anything.’ According to one in the beginning this led to a conflict: ‘Colleagues argued that I was gone all the time. I learned that it is important to instruct your colleagues what you are doing (…) Now everybody is familiar with the Scrum and they understand that the Scrum is not voluntarily, and that we are not only sipping coffee, but actual work is done.’ (28-31, 140-142, ST member 4)

An important element for a smooth introduction might be that the Product Owner spent much time on the composition of the first Scrum team. She explains: ‘When I decided I wanted to do the project in Scrum, I elaborately thought about who I wanted to be in this team. First I thought that it was only important to have the right skills for the implementation, but then I came to mind that it is more important to have people who I could make enthusiastic for the Scrum method, who have an open mind for new things, and who would like to see some changes within the organization.’ (37-42)

4.4 Modifications of the Scrum

The Scrum is usually used by software developers who work fulltime on a project; working in the Scrum is their fulltime job. This was not the case in the studied organization. Therefore the time-boxed daily sprints have been modified to fit into the organization. Since everyone has his work

Translating the Scrum to a translation agency : applying the Scrum framework in a non-software development company