Absent ScrumMaster, poorly defined requirements, inexperienced team, absent product owner, impossible goals. Sometimes things go wrong even with Scrum projects. This article describes my professional experience in replacing the ScrumMaster of projects that are in difficulties. I'll talk about how the new ScrumMaster should avoid hasty decisions, reconstruct the history of the project (don't fall into the same hole twice), analyze the situation, and talk to people before proceeding with the project development.
At the beginning
A long time ago, when I was in graduate school, a teacher said, "Only Loulou Gasté and Morris Albert can live from feelings. Computer scientists should live based on facts." His idea is simple and functional: If your environment supports 100 simultaneous connections, you shouldn't sell this environment for 101 simultaneous connections just because you think that never will 101 people connect simultaneously. Murphy's Law will show you that you are completely wrong.
However, while we're creating software, we're also working with people, and they are not exact science. Even in a small project, you'll have a lot of people involved: the team, ScrumMaster, product owners, clients, users, external teams. Sometimes you'll have to use your feelings to do the job.
Here I'd like to talk about the feelings surrounding the ScrumMaster (SM) in a difficult situation — specifically, when you assume the SM role in an ongoing project after the fall of another ScrumMaster.
First of all, let's look at the ScrumMaster role description: "The ScrumMaster helps the product group learn and apply Scrum to achieve business value. The ScrumMaster does whatever is in their power to help the team and product owner be successful" (Deemer et al, p. 6). Jeff Sutherland puts it this way: " . . . he or she serves the team by helping remove blocks to the team's success, facilitating meetings, and supporting the practice of Scrum" (Sutherland, p. 23).
So that is exactly what people expect from the ScrumMaster. He (or she) is the one who will serve the team and the product owner, helping them achieve their goals. When he's unable to do so, the team and the product owner will probably "fire" him from the project. A team that doesn't have faith in the ScrumMaster will take one of two possible decisions: They will raise a new ScrumMaster from the team, or they will call a ScrumMaster from outside the project. I will talk about the second option.
In recent years I've been called a few times by Scrum teams in trouble. The SM was not active and the team and the product owner were having serious problems. They weren't achieving business values; actually, most of them were unable to understand what value was for the business. The product owner was changing requirements every minute; even the sprint backlog was receiving and losing user stories more than once a day. The sprint planning and daily meeting were falling by the wayside. The relationship between these teams and their respective product owners was a mess. In short: It was hell.
If you've built a strong career as a ScrumMaster, you will be called to act in such scenarios. What should you do? Use your feelings? Not yet.
Gather all the facts
You shouldn't use your decision power if you don't know anything about the real situation. Your best friend is not a reliable source; and on projects that are having problems, everybody is pointing fingers at everyone. First you have to find facts that tell you the project history. Search for:
- What happened?
- Who did it?
- How did it happen?
The product backlog is your primary source. Search for understandable stories, epics that are or were performed, different versions of the product backlog. How were stories prioritized? Is there any Sprint backlog? Try to construct the project's history.
Use additional information, such as software configuration tools and source code. If you are a nontechnical ScrumMaster, I highly recommend that you to find someone with technical expertise. By examining the source code, you'll be able to find unnecessary rework, poor quality, bug nests, and gold plating. If the team uses a configuration tool, you'll be able to see how, when, and by whom these items were introduced. In some projects, when the product backlog is completely outdated, these two sources will be the best places for you to search for facts.
There are several other artifacts that you can use to trace the project's history, like server logs, meeting agenda and minutes, presentations, and so on. However, never ask someone to send you emails that you hadn't received yourself. Then people will think you're engaged in a witch hunt.
Now that you have the facts, can you use your feelings and make a decision? Not yet.
Talk to people
The facts are too cold. They tell you what happened, when it happened, how it happened, and who did it, but they don't tell why it happened. How can you discover that? Talk to everyone.
Before starting the conversations, take a good look at the situation. Is the team united or are there divisions? Perhaps the team can't stand to stay in the same room with the product owner? There are "fight meetings"?
Don't try to unite everyone in a single room and have an RD (relationship discussion). The groups will probably attack each other and you'll be the responsible for make the hell even hotter. Try to identify the groups. Once you've done this, you'll try to answer some questions based on the facts. Why was this done? What was happening when this was done?
Try not to be invasive while you're doing this. Where I live, we like to talk about problems in a cafe, at kiosks near the beach, in bars or restaurants while we're having lunch. Try to find a good place for each group or individual you need to talk to. Be reasonable. Don't take very religious people to bars, or people who hate the beach for a pleasant stroll in the sand.
You'll lose some days by talking to everyone, but it is the only way to find out how the project got into this mess.
Make a decision
You have all the facts and you heard all the parties. Now it's time to make your decisions. What you should keep in mind is this question: Why are we here? And the answer is: To satisfy the customer by adding value to his business with high-quality software through a motivated and self-managed team.
Confront the main issue
Throughout my life working with Agile models, I've created a checklist that helps me put the project back on track. I have to begin by asking myself a straightforward question: Can this software be done?
To answer, you should evaluate the team, the product owner, the goals, the deadlines, and yourself as ScrumMaster. If your answer is "No," stop right there. It's better to say, "This project can't be done because of this or that," or "I'm not able to be the ScrumMaster of this project because of this or that," than to take on the ScrumMaster's responsibilities and end up destroying the project and your career. Be transparent, don't hide anything, be honest with yourself.
Rebuild the communication
Rebuild the communication inside the team and between the team and the product owner. This will take a lot of effort, but it has to be done. They need to work together or the project is doomed.
Hold meetings with key people (client, users, managers, sponsors) to reaffirm the commitment that they will receive the expected/contracted product and be able to add value to their business. In this moment, you have to be confident. Watch out for your body language. You will have to regain their trust within minutes.
Clarify the development process
Reunite everyone (now you can put them all in one room) and put out all the rules of Scrum software development in a clear and objective way (papers, meetings, responsibilities, goals, etc.).
Convince the product owner and team members about their importance to the project.
Rebuild the product backlog with the product owner. Stimulate small stories, and use the minimum viable product (MVP) to maximize the ROI and increase user feedback speed.
If the software produced so far is full of bugs, do whatever you can to reduce the bugs to zero. Press the panic button to interrupt the current sprint if necessary. Try to be bug free. (I know, it's not easy.)
Eliminate any performance problems. If the product owner or users are complaining about software performance, look at it as a bug — a huge bug.
Get expert help
If the team is a junior team and they're having difficulties in defining a development strategy, find a senior developer and make him a technical facilitator. This senior can be integrated to the team but, in my opinion, the best solution is to make him a mentor or a coach to the development team. As ScrumMaster, you shouldn't program. You can do that, but you shouldn't. Because while you are programming, who is removing impediments? Who is supporting Scrum practices? Who is helping the product owner? And the most important, who is protecting the team?
Eliminate team members or try to switch the product owner. Yes, you read that right. There are some situations in which you will have to do so. Sometimes a person's position is unsustainable in the project and you'll have to cut him from it for the good of others. Before you do that, though, be sure that you, as ScrumMaster, have exhausted all the possibilities for putting this person back in the project. Make sure you're not using him or her as a scapegoat for your own incompetence. If you are using the project member as a scapegoat, soon you'll be in the same position as the previous ScrumMaster whom you just replaced.
Create your own recovery list
I created this list of the steps above based on articles and books that I've read, as well as my professional life experience. I strongly recommended that you develop your own list, but if you don't have any, you can start with what you've read here.
I don't always follow every item on the list, by the way. It depends on the project and how bad its condition is.
It's never easy to take on a project that's in a difficult situation and transform it into a successful one. You'll have to expend a lot of effort just to take get it back on track. You'll have to be paleontologist, psychologist, bug killer, judge, coach, and — of course — a great ScrumMaster.
Deemer P, Benefield G, Larman C, Vodde B. The Scrum Primer. 2010.
Sutherland J. The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process. 2007.