Dominik Maximini researched the cultural aspects of organizations that are using Scrum. He published the findings of his research, together with principles for implementing Scrum and suggestions on how to apply these principles and a case study of a Scrum transformation, in the book The Scrum Culture. The book page provides download links for the table of content and a sample chapter.
InfoQ interviewed Maximini about researching the culture of Scrum and conclusions from this research, how you can use Scrum to implement Scrum, establishing a sense of urgency for agile adoption and tips for making changes stick in an organization so that they become embedded into the organizational culture.
InfoQ: What made you decide to write a book about the Scrum Culture?
Maximini: In my day-to-day work as Scrum coach I encounter failed Scrum implementations all the time. The people involved usually state their "corporate culture" as the number one reason for these failures. When talking to top managers, they often do not know what they are up to when they start with an introduction of agile methods. They just see improved time to market but fail to note the far-reaching changes, affecting their whole enterprise. Unfortunately, there was no comprehensive literature I could point these people to. They had to trust my word, and often didn't. So I decided to do some serious research and publish it in a hardcover book that literally gives "more weight" to the content.
InfoQ: Your book mentions that understanding the culture starts with the Scrum vocabulary and the jargon that it uses. Can you give some examples of this which explain why this matters?
Maximini: For somebody practicing Scrum this point is difficult to understand because the words are used naturally. However, when you meet somebody not familiar with the framework, the matter is completely different. They will start asking "what's that" whenever you use a Scrum phrase such as Product Owner, Scrum Master, Sprint, Definition of Done, Impediment, and so on. If you look closer at the meaning of the words Scrum proposes, the weight of the underlying concepts becomes apparent. There is a reason why the roles have "weird" names and there is a reason why the iteration is not just called iteration. The new names force you to think about their meaning. Once you realized that a Product Owner literally owns a product, many implications of this role become clear. In addition, it is harder to map existing traditional concepts to the "new world" if the terrain of this new world is already filled with meaning. A "project manager" has a hard time finding his spot in the middle of Scrum Master, Product Owner and Development Team, for example...
InfoQ: Can you briefly describe how you researched the culture of Scrum?
Maximini: I read tons of Scrum books until I realized that most authors didn't have a clue about corporate culture and only talked about their personal experience, not about scientific study. So it was weak evidence. Then I read a multitude of books regarding organizational culture and looked for a "dominant" definition. I realized there was nothing such as "the single dominant definition", but could make a decision that best fit what I was trying to achieve - a Scrum culture definition for a business context. At this point I knew Scrum and organizational culture, but did not have any data on the cultural aspects of Scrum, so I had to conduct my own research. Luckily, I already knew the different questionnaires available, chose the dominant one, augmented it with some important additional culture aspects, and ran the survey across different Scrum conferences and mailing lists. Once there were more than 200 qualified results, I worked with an excellent statistician to validate the outcomes. Then, after three years of work, it was clear that there actually is a Scrum culture.
InfoQ: In the research your concluded that "the glue that holds Scrum organizations together was described as loyalty, mutual trust, and commitment (...)". Do you have examples of this?
Maximini: Hopefully, everybody has examples of this - with Scrum or without. If you ever worked as part of a well-working team, you experienced it. People fully trust each other, feel like being in it together instead of being on their own and put in their cumulative sweat during nights and weekends, if necessary. In such a team environment, people feel extremely loyal to the team and thus to the project and employer (in this order). This is true for any team approach. Since Scrum is focusing very much on the team, loyalty, trust, and commitment are natural and indispensable culture components.
InfoQ: Another conclusion from the research is that most people in Scrum teams are intrinsically motivated. Can you elaborate what you think causes this?
Maximini: I might be mistaken, but I do not believe anything causes this. I believe people are born this way. People love to think and bring in their ideas. You can see this in your little children: They want to learn and try everything and do not expect to get anything back in return, except the fun of trying it. However, many people are changed through our educational system, society, and strictly hierarchical business organizations when they grow up. So what we have to do is take the barriers away and light the motivational spark again. This is something Scrum does by its setup and by promoting self-organization. Scrum even provides a firebug, called Scrum Master, who helps fan up the flames in people.
InfoQ: You mentioned that in a Scrum culture managers refrain from closely controlling people. What if a company is currently using a command and control style to manage the organization. Any suggestions how this can be addressed?
Maximini: Wow, tough topic. Bluntly speaking, command and control is not compatible with Scrum. As soon as you allow Scrum to spread throughout the command and control enterprise, there is a clash of cultures and only one will survive. On the one hand command and control is more effective in a production line environment, and it is usually also the dominant approach in the organization. So it has the home field advantage and is the primary source of "gravity", drawing people back to the old way of doing things. The Scrum Culture on the other hand is more effective in development and research environments and is what more and more people demand from their employers. Sadly, if you don't work actively and persistently against it, usually command and control wins in the long run - and the organization loses their innovative employees. If you want to make both work, you can put Scrum into a controlled environment (e.g. a department or project) and remove the old leadership style there while preserving it for the rest of your organization. Some organizations like Carl Zeiss and Deutsche Post actually spin off divisions for some innovative topics and allow them to grow different cultures.
InfoQ: Can you describe how you can use Scrum to implement Scrum in an organization?
Maximini: As every developer knows, one has to eat one's own dog food. This is true for Scrum introductions as well. Implementing Scrum usually takes several years (you certainly aren't done after two days of training and one week of coaching!), so you will have a long list of things to do. This list is your "transition backlog". The highest-ranking person advocating Scrum should be the Product Owner. The product is nothing you could ship, but the organizational culture, including the processes and teams doing Scrum. You also need somebody knowing Scrum in depth - make her the transition Scrum Master. On top of that you need a whole lot of people doing the actual work. They are your Development Team. Some organizations have one team making decisions and one team doing the work, but I personally experienced better results if the people making the decisions also have to get their hands dirty. This helps them set priorities and stand behind their decisions. Since you have to organize this bee-hive in the context of overburdened calendars and unavailable meeting rooms, you will want to schedule some meetings anyway. Give them clear goals and use them as Sprint Plannings, Reviews and Retrospectives. Also do Daily Scrums, even though you might have to fall back on "Weekly Scrums". If you heed this advice, all transition team members will learn Scrum by doing Scrum and you will realize quick and incremental success. If you try to introduce Scrum by using a traditional project plan, nobody knowing Scrum will take you serious.
InfoQ: Do you have examples of how to establish a sense of urgency for adopting agile?
Maximini: I cannot tell any organization why they should introduce agile methods. They have to know THEIR reasons, not mine. What I can tell you though is that you should look at the business side. Developers usually cherish the level of freedom they gain with Scrum, but management is not interested in this. They want hard facts and numbers. So get them some numbers. Think in terms like "time to market", "revenue per employee", and "innovations per month". Some might even care about "customer satisfaction" or "employee satisfaction". Take a look at what is most important for your organization at this point in time. Never ever introduce agile methods just to use agile methods. They are no end in themselves, they are a means to achieve something. Sometimes organizations need something different than "Scrum" or "Agile". So find out what your organization really needs, see if Scrum can help you there and prove this with numbers. If you fulfill this chain of evidence, urgency should not be your problem.
InfoQ: Pilot projects can be used to introduce Scrum in an organization. Can you give some advice on how to do them?
Maximini: Get top management support first and choose a project of high importance. Make sure it is not a suicide mission - you don't want to fail with your pilot project. Then get carte blanche to do whatever you need to do in the pilot. This allows you to do everything "right" and leaves you with less foul compromises. Once you are there, the rest should work as well as it can in your context. Just make sure you communicate ten times as much as you would usually do - to your stakeholders, management, and everybody interested or related to your pilot. The real work begins after the successful pilot because you usually lose carte blanche and have to start changing the organization step by step. One of my customers did 26 pilots before Scrum was introduced as a standard option for new projects. With every pilot the incarnations of organizational gravity found reasons why this specific pilot was so special that the method did not apply to their own context and a new pilot project had to be started.
InfoQ: Do you have tips for making changes stick in an organization so that they become embedded into the organizational culture?
Maximini: Repeated success combined with strong top management support is the only thing that makes changes stick. In addition, corporate procedures, which are manifestations of culture, have to be changed. Nobody will believe that you truly want to deliver features every two weeks if a simple procurement request takes three months to journey through the organization. These procedure changes must includes all appraisal processes early. Every employee has to be evaluated on the desired behavior - who doesn't adapt is demoted, gets a pay-cut, or even fired. People who comply are promoted, get a pay-rise, or public praise. This might be considered harsh, but it is the primary way organizations make sure certain behavior sticks or not. Of course, this has to start at the top.
About the Book Author
Dominik Maximini is an experienced Scrum Master, Trainer and Coach at NovaTec Consulting GmbH, where he helps teams to live up to the values of Scrum. His vision is to carry the fundamental values of Scrum - like openness and honesty - into various company environments.