Get certified - Transform your world of work today

From Hybrid to Scrum

01/14/2012 by Stefan Conrad

Identifying the problem

It's difficult to change learned behavior, and even harder to change group habits. This is one reason I've had so many difficulties establishing Scrum in different companies in Germany. Most of my clients understand that Scrum has a lot of potential and bears the chance to shorten time-to-market or the delivery of high-quality software, but. . . . And there we go again: "Scrum, but. . . ."

My first approach in getting rid of that problem was to go back to the basics by trying to convince my clients that Scrum is a good alternative to classic project management. I have to admit, I failed. I can't say if my clients were too stubborn or if I wasn't good enough in convincing them, but I had to look for different methods.

So I tried to find out why many German people are so negative when it comes to Scrum. I started in a good old-fashioned way: interviewing people. First was my business partner and longtime friend Max, who is a ScrumMaster himself but a business analyst at heart. He analyzes everything from a neutral point of view, referring to best-practice approaches and personal experience. My question was, "If you have one, what is your problem with Scrum?" The answer was short, easy, and sounded convincing to me: "Requirements. Germans love to have documents, proof to refer to in case differences occur." I tried to verify this statement by interviewing project managers, requirement engineers, and developers who are part of my network.

What's wrong with requirement documents?

Most of the books I read about requirement engineering point out that detailed requirement documents are a bad thing, because requirements become static. But who says we don't want stable, static requirements? Sure, we should have a backup plan in case requirements aren't defined at crucial points or will change at a later stage of the project. And, in fact, we still have that in Scrum. Cohen states that "user stories are a reminder to talk to the stakeholders," and that's something we still could do.

Here's another question: Why not use methods of stakeholder analysis and create a stakeholder portfolio, as we do in classic project management (PM) environments? Yes, I know that working code is more important than documentation, but I'm not talking about code documentation here. I'm talking about process documentation, stakeholder documentation. Many of my clients don't know why they did certain things the way they did them. They managed the project two years ago and can't remember why the software isn't supporting the actual business process, or why they had certain extra functionality. BPMs and a stakeholder portfolio would answer a few questions, but they don't have those documents. So my team has to interview and reverse-engineer to get into the past. In the long run, clients pay a lot of money just to know what happened several years ago. Would anyone know anything about history if there hadn't been people who wrote it down? User stories can answer what has to be done, but not why? it was done, otherwise they wouldn't meet the nontechnical INVEST model of user stories. Besides, requirement documents and documents such as stakeholder portfolios can make for a good base when it comes to decision making or risk management.

I don't want to start a new "but this is not Scrum" discussion. Instead, I want to refer to the Agile Manifesto, which upholds "individuals and interactions over processes and tools." In this case, referring to the results of my interviews, detailed requirement documentation seems to give the project members a certain feeling of security. So isn't the feeling of the individual in this case more important than blindly following the Scrum process? Don't get me wrong; I know Scrum doesn't forbid the creation of detailed documentation -- but it doesn't support it, either.

So what now?

Should we go back to classic PM? No, that's definitely not the answer. I thought a lot about that question and came to the conclusion that there's no reason to question Scrum. I know it works. I consider myself a Scrum Coach even though I'm not a CSC. So I had to find out what I can do to help establish Scrum.

One evening my wife told me that our youngest daughter had started crawling, and that she thought the baby would probably start walking within a few months. This was the moment I developed an idea. What is crawling? Easy—a method for someone who isn't able to walk to get from Point A to Point B. Efficient? No! Working? Yes. Once my daughter feels safe crawling, she'll try to stand up and take her first real steps. Why? Because she sees that Mommy and Daddy aren't crawling anymore, and they moves much faster. Kids adopt things that work from watching their role models. So I thought, "Be a role model, be a coach—but don't overdo."

I went back to the results of my Interview and saw that nobody questions that iterative development works, so we can keep that. Nobody cares if we call it a "requirements catalog" or "product backlog." And so on. I kept the things people are happy with and tried to integrate detailed documentation and contracts into the Scrum process. Figure 2 shows my results:

As you can see, we still have some kind of product backlog that we can manage and prioritize in the ways Scrum suggests. The main difference is that our backlog items are linked to requirement documents like business process models, risk management, and stakeholder portfolios. This enables us to work out a contract with documents you can lean on. I know that the Agile Manifest quotes that interaction is more important than contracts. But since contracts are crucial in Germany, it's a nice bonus, isn't it? It's also possible to write acceptance criteria by using vocabulary outlined in RFC 2119, which can serve as a perfect base for acceptance and unit tests, for example, in a test-driven environment.

I'm completely aware of the loss of time we experience during the sprint planning stage, but the benefit seems to be worth it. We had a good experience in pulling one member from the team each sprint to serve as a requirements engineer, working with the product owner. (It proved important to choose a different person every sprint.) In the long run, we always saved some time during the development process and while dealing with change requests, since we had requirement documents and business process models. The models made it easy for persons who weren't involved yet to understand what the whole requirement was all about.

Take it to the next level

In my opinion, the use of Scrum "out of the toolbox" might be the goal you want to reach in terms of Agile project management—but not the way you want to start. This is why I think using baby steps leads you there more quickly. Sure, falling helped my daughter learn how to stand up and try again. But if she had fallen too often, she would have been frustrated and perhaps never tried again. Constant failure might suggest that the method isn't working at all. But we all know Scrum works. My job as a Scrum Coach or Scrum consultant is to help customers establish Scrum in their own way. Referring to Bruce Tuckman's model of group development, the storming period has to be managed by the team, otherwise it will never reach the performing period. In my opinion, establishing Scrum works the same way.

Personal experience

In this last section, I want to share my experiences using this hybrid approach of Scrum in Germany. I interviewed employees, asking them about their fears about establishing a new way of working within the company. After that, I worked out some concepts with the whole team to minimize those fears. Documenting requirements and having contracts seemed to be among the most important points in the concept. The team wanted to make sure that the features they develop are the features the client expects. Best of all, not only did the team experience a growing feeling of trust but the clients reported the same feeling. Many clients simply did not want to work without a contract specification.

Sure, there are risks in starting a hybrid. Teams might not want to change what's working. Or they might want to stick with the hybrid forever. This is our challenge, as Scrum consultants: To take them to the next level.