The Scrum Culture

Even though not every project is conducted in an agile way, the numbers are increasing considerably. “In 2002, agile projects made up less than 2 % of overall projects and less than 5 % of new application development projects. Today, agile projects account for almost 9 % of all projects and 29 % of new application development projects […]” (Standish 2011, p. 1). The most popular member of the agile family is Scrum. According to a Forrester survey (2012, p. 15), 81.5 % of the respondents are using Scrum. VersionOne (2013, p. 5) is backing this tendency by stating that 72 % of their respondents are using Scrum at least partially. Other agile methods play a minor role (cf. VersionOne 2011, 2013; Standish 2011; Forrester 2012).

This chapter explains why it is important to define a Scrum Culture, how the goals of the research project were defined, the scientific approach, and the originally expected results.

There are different forms of Scrum, which are found again and again in different companies. Before we can look at how to reach a desired target shape, we must first be aware of the possible target shapes. Those are presented below. With the concepts I have stayed close to Ken Schwaber and Jeff Sutherland, who ensured a common understanding in their book “Software in 30 Days” (2012).

There are several ways to start a Scrum introduction project. This depends considerably on the desired Scrum shape. In some companies, management decides—often after a relaxing and insightful golf duel—that Scrum is to be used throughout the whole company. Sometimes such a decision is the result of “lessons learned” of past projects. In both cases, management is backing the Scrum introduction and provides budget as well as other support.

So let us now get to the point: The introduction of Scrum into an enterprise. Before we get to the “how” of the implementation, we should first look at the “why.” The reasons listed here could possibly help you in elaborating the topic with your management. “Stakeholder management” is also briefly discussed in this chapter. Finally you will learn for which products you should consider Scrum—and for which ones you should not.

Depending on the target state (see Chap. 2) and approach (see Chap. 3), you need to plan and perform a different course of action. The basic steps are the same everywhere though (Fig. 5.1). There is just one exception from this rule: If you implement Scrum PRN through a submarine approach, you do not need the steps outlined below—at least not if this PRN submarine will be sufficient for you into the future as well. In the following section, I refer to the book “Leading Change” by John Kotter (refer to the appendix if you want to know why I did not refer to other authors). In my daily work, I use the procedure described by him to introduce Scrum into organizations and to solve the systemic problems uncovered. It is these experiences I would like to share with you. The phases described by John Kotter (2012) are:

If a company operates successfully in the market, it builds up a pool of processes, structures, and regulations over the years. These are usually very useful and helpful to the organization at the time of their introduction (cf. e.g. Kotter 2012, p. 149). However, often the utility diminishes with time because the world—especially in today’s globalized and fast-paced environment—changes, but the processes remain rigid. If you ask your employees about the perceived benefits of the existing processes, structures, and rules, you will probably find that they are being experienced as a burden rather than an aid. You can prove this—especially for non-production processes—easily with value stream analyses. On the other hand, however, these structures provide footing and safety. Every employee knows exactly where her place is in the overall structure, her power and influence. If you want to implement far-reaching changes, you directly attack people’s safety needs. Maslow clearly demonstrated in his “hierarchy of needs” that “safety” is almost as important for every individual as “physiological needs” and thus a foundational need far from the higher levels of “esteem” and “self-actualization”. This literally means you are shaking your employees at their very foundation. Accordingly, you will encounter resistance, which can stop your change process, even before you have really started. Therefore, you must transport a sense of urgency that is recognized by everybody. It must illustrate that your change endeavor is not only justified but also necessary for survival. Brief: Make the crisis transparent, on which your desire for change is based on (cf. Kotter 2012, pp. 46). You would not undertake a major change effort, if you did not have good reasons. Share them. With smaller changes, it may be that it is not about survival—they are nevertheless usually about long-term profitability and thus competitiveness. There is a reason that you want to change something. Make this reason visible to everyone.

To implement the changes in the organization, you need a guiding coalition. One person alone is usually overburdened with driving the change (cf. Kotter 2012, pp. 52). So you need a team. It must consist of the right people, be properly organized, and be constantly present for those affected by the change. Our focus is still on the Scrum introduction: Since you now know why you want to introduce Scrum (or what your urgency is), in this section you will learn who has to drive the changes in your organization.

Quite often, employees are not initially convinced that radical changes are necessary at all. Even in the face of an outstanding urgency the majority of staff usually accepts the problems but does not accept that significant change is necessary to resolve the issues. They accept a vacation freeze or forced overtime rather than break their entrenched patterns. Even if you manage to make your employees willing to accept changes, frequent disagreement and confusion are still prevalent. Therefore, it is important to clearly define the direction of change. “Vision refers to a picture of the future with some implicit or explicit commentary on why people should strive to create that future” (Kotter 2012, p. 70). It allows your employees to follow your leadership.

The communication of your vision is a clear leadership responsibility. Only someone who knows your vision has a chance to follow it. Most managers communicate far too little, especially in large change efforts. Sometimes they transport diverging or contradicting messages through different channels. Both mistakes cause your change project to fail (cf. Kotter 2012, p. 87).

Once you managed to communicate urgency and vision in a way that motivates your employees to follow you, it is time to let everyone participate in the change. In other words, you need help because you will not be able to implement everything yourself with just the guiding coalition. All-encompassing change does not happen all of a sudden, but rather person by person. Your task now is to turn affected parties into involved ones.

You have analyzed your urgency, developed your vision down to the details, and communicated it so vividly that even the cleaning staff knows exactly where the journey is headed. You have also empowered your employees on a broad basis and removed the biggest obstacles. Excellent! If you now believe, however, the work is done, and you could sit back, then you are mistaken. Even if you really have done everything that is needed for your long-term success, this is only true for the moment. To keep the motivation of your employees high for the long run—and your own, of course—you must also ensure short-term success (cf. Kotter 2012, p. 123). In this chapter, you will learn why this is so important and what you should heed.

You have achieved initial success in your change initiative. Employees and colleagues are informed and follow your lead. Everybody is aware of the urgency and strategy. You have the feeling that everything runs by itself. You are exhausted, since you have made tremendous efforts in the last weeks and months. It is time to rest. A little vacation would be spot on right now (cf. Kotter 2012, p. 139). The sun’s heat, a secluded beach, the warm sea water—wonderful!

Do not fall into that trap and persevere instead. This chapter teaches you why and how.

Once you have achieved success and your change process is in full swing, you face the task of making your work become sustainable. Only if you manage to firmly embed the new values, standards, and approaches into its culture, can the organization be so deeply affected that even your departure would not cause the changes achieved to be reverted (cf. Kotter 2012, p. 153).

Time and time again, there are situations in which a very large project team or even an entire company is looking to transition to Scrum. Quite often, these teams are not only large, but also scattered around the globe. A Scrum introduction in such an environment is extremely demanding for the change agent and all those involved in change management. You need to know the specifics of such an endeavor and coordinate across all the departments and staff, whether they are involved or just impacted. Mistakes made in this respect will immediately multiply themselves.

The following case study is drawn from real life, although it is no accurate reproduction of any single one of my projects. It is included here to make the often abstract theory outlined in this book more tangible and accessible. Depending on the circumstances you, the reader, are facing, certain aspects of it might seem exaggerated or unrealistic. However, you might also see yourself reflected in other elements of it. This case study is presented in a way that conforms to the eight steps of Kotter (cf. Kotter 2012).

You have learned about the different shapes of Scrum. You know how you can get to these different target states. Furthermore, you are aware of the eight steps you have to take from an organizational development perspective in order for your Scrum introduction to succeed. The case study illustrated the practical application of what you have learned. The comments in the appendix regarding roles, artifacts, events, and methods may give you some more food for thought.

Even though not every project is conducted in an agile way, the numbers are increasing considerably. “In 2002, agile projects made up less than 2 % of overall projects and less than 5 % of new application development projects. Today, agile projects account for almost 9 % of all projects and 29 % of new application development projects […]” (Standish 2011, p. 1). The most popular member of the agile family is Scrum. According to a Forrester survey (2012, p. 15), 81.5 % of the respondents are using Scrum. VersionOne (2013, p. 5) is backing this tendency by stating that 72 % of their respondents are using Scrum at least partially. Other agile methods play a minor role (cf. VersionOne 2011, 2013; Standish 2011; Forrester 2012).

This chapter explains why it is important to define a Scrum Culture, how the goals of the research project were defined, the scientific approach, and the originally expected results.

This chapter describes the approach taken in my research. It shows the considerations taken, the approach chosen, and how the research was conceived and conducted.

This chapter describes the approach on organizational culture taken, culture model selection and the enlargement of this model.

In order to understand a culture, one has to know where its origins are and how it evolved. Ken Schwaber and Jeff Sutherland presented Scrum for the first time at the OOPSLA conference in Austin, Texas, in 1995. At this point they had already been working together for several years. Both had huge experience as software developers, project managers, line managers, and owners of IT companies in the United States of America. They were struggling with the status quo of dealing with software development, specifically waterfall project management approaches. At that time, projects and companies they were involved in were failing and due to the pressure they were feeling, they went in a different direction. At the same time, lean management and empirical process control as well as iterative and incremental development practices were emerging and impressed Ken and Jeff. Especially the works of Babatunde Ogunnaike as well as Takeuchi and Nonaka (1986) influenced them (cf. Schwaber and Sutherland 2012, p. 27).

This chapter describes the origins of Scrum and shows the results of literature research regarding the Scrum Culture.

To get an impression of the result quality of the survey, a brief summary of the setup and general results is provided in this chapter. In addition, the findings from the survey are explained here.

Having reviewed literature, the OCAI analysis and the findings from the open questions, a pattern becomes apparent. All findings point in the same direction, in that there is no fundamental gap between literature and the expectations of individuals (cf. Sect. 22.​6). While it was not clear at the beginning of this study if something such as a “Scrum culture” existed, it is now obvious that indeed people expect Scrum to work and succeed in conjunction with certain circumstances, values, and rules. Since people tend to project their expectations onto organizations and shape them accordingly, an impact on organizations has to be expected. This impact will be similar across a multitude of enterprises, therefore it can be said that Scrum has inherent cultural characteristics. A Scrum culture does exist.

There are many organizational change models out there. Most only describe change efforts in a general way, but some are specifically applied to a Scrum context. This book focuses very much on Kotter’s approach and I want to explain the reasons. In order to do that, I will first briefly describe four different models, starting with two specific to Scrum. Then I will compare all of them and explain my choice.

On the following pages you can see the text and questions of “The Nature of Scrum Survey”. Open questions can be identified by the open textbox. The online version of the questionnaire contained the same questions in the same order. In addition, you can find all research details, including the detailed statistical outcome of the survey.

Scrum is a very simple framework, consisting of just a few meetings, artifacts, roles, and some rules that bind them together. The Scrum Guide is the official definition of Scrum (cf. Schwaber and Sutherland 2013) and contains only 16 pages. This section gives a brief overview and stresses the most important aspects. For a more in-depth view into Scrum, other professional literature is recommended (e.g. Verheyen 2013). One important thing to know is that Scrum views itself merely as a framework, existing in the context of an organizational environment, and being filled with meaning by other methods that complement it (for some examples, see Fig. 24.1). No project—or product development endeavor—will be successful by using only Scrum—complimentary practices are always needed.

The following methods are not prescribed by Scrum but complementary and need to be selected depending on your specific context and situation. Many teams find them valuable for their daily work and use them. Of course, there are many more methods available as well. I just wanted to share a small sample of the most common ones with you.