Taking on a Project in Difficulties

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?

When?

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.

Reaffirm commitment

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.

Restart

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

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.

Conclusion

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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

LetΓÇÖs see first the prioritization.In projects that are not in difficulties the prioritization should be done by the Product Owner. He knows the most important stories and he is the responsible for that. ΓÇ£The Product Owner has the following responsibilities: ΓÇª Prioritize features according to market valueΓÇªΓÇ¥ (Sutherland and Schwaber, The Scrum Papers, p. 14). If your PO doesnΓÇÖt know how to prioritize, you can ask him / her. ΓÇ£What is your biggest problem?ΓÇ¥ Try to identify the stories that will solve the problem and put them in the top of the Product Backlog. Than you can ask him ΓÇ£Besides that, what is your second biggest problem?ΓÇ¥ and put the stories related to that in the second level or prioritization. Repeat this process until all the PB is totally prioritized.In projects that are in difficulties you need to see if the problem is the Product Owner. My mentor Rodrigo de Toledo (http://www.rodrigodetoledo.com) always says that you have to ask why. Why the PO is not priorizing the Product Backlog? Than you will have an answer. This is not your final answer. Based on the answer, will have to ask why again and repeat this process 3 or 5 times. With this you will know the root cause of the problem and you will be able to treat it.ΓÇ£In Scrum, the Product Owner is the one person responsible for a projectΓÇÖs successΓÇ¥. (IN: http://scrummethodology.com/scrum-product-owner/). So, if you have tried everything and your PO is still unable to do his job, you should try to change him. Otherwise you will put the project on a boat going at full speed straight for the rocks.

About Inspect and adapt.ΓÇ£Only the team is able to inspect its own habits and to decide what and how to change.ΓÇ¥ (IN: http://marcbless.blogspot.com.br/2011/05/agile-principle-12-inspect-and-adapt.html). My current team is using a hybrid model of Lean Kanban and Scrum, so we donΓÇÖt have ΓÇ£sprintsΓÇ¥ as defined by the Scrum Framework. We have biweekly meetings of retrospective where they talk about what went well and what went wrong. When something went wrong we start a brainstorm trying to discover the root cause of the problem. Any problem can be discussed in a retrospective meeting technical or not. This seems simple, but it is extremely difficult. The root cause is always hidden and in some cases you will have to expose peopleΓÇÖs mistakes. Avoid it as much as possible, but sometimes will be obvious that the error was caused by you, Scrum Master, a member of the team or the Product Owner. The important thing is to know and convince the other participants that retrospective meeting is not a witch hunt. ItΓÇÖs a prerequisite for the continuous improvement process.After the Retrospective the team organizes itself to implement our decisions. I also like to ΓÇ£inspectΓÇ¥ our customer needs. At the biweekly Review I like to invite the Product Owner, client, users and sponsors (itΓÇÖs never easy to bring him/her). This is a great time to receive feedback from every major project stakeholders. They can give new views, something that the Product Owner will have to adapt in the Product Backlog.