“The shortest way to do many things is to do only one thing at a time.” ~ Richard Cech

Few days ago, I wrote an article for ScrumAlliance.org. The article is about the  Seven Things I Wish I’d Known When I Started out as a ScrumMaster.

One of the things I mentioned there was to work on one (and only one) project.

In the article, I explained why it is important for a ScrumMaster to work on one project at a time. The explanation was simple: Working on one project at a time brings-in required focus to do your best.

I got many comments there. Out of them one of the comment was about the above point. The commentator mentioned that if the organization has gained required maturity about Agile and Scrum, then they can use a ScrumMaster to do “more” jobs.

I had to respectfully disagree.

Why?

Being an effective ScrumMaster is a full-time job. Period.

Unfortunately many organizations that do not have right understanding of Scrum sometimes fail to recognize that a great ScrumMaster has NOT to work on multiple projects at a time.

For example, consider if a ScrumMaster is working on two projects and in order to resolve an impediment in one project, he has to spend several days.

Obviously the other project will have to suffer. At his best, the ScrumMaster will be able to devote 50% of his time to each project, isn’t it?

Also, when impediments are not resolved in timely manner, it frustrates the team members and produces not-so-positive outcomes.

I have seen that organizations that get maximum benefits of Scrum prefer that a ScrumMaster is working on one project.

Then the commentator called me to ask: “Is it a rule in Scrum that a ScrumMaster cannot work on two or more projects?”

No, it’s not a rule. It’s about choosing the right thing to do. Sure, a ScrumMaster can work on multiple projects but most probably with mediocre results. That’s why effective ones do the opposite.

And, the greatest gift an organization can give to a Scrum Team is the gift of an Undivided ScrumMaster.

 

I hear people say, “Yes, we use Scrum in a way that suits our needs.”

When I ask them what does that mean, the most popular answer comes out to be, “We have tailored Scrum to match the way we work.”

“How have you tailored it?” often, I follow up with this question and it goes something like this:

“Generally, we keep four week sprints but sometimes our team completes the work 3-4 days early. So to get the maximum work done from the team, we keep several predefined backlog items in a separate sprint and call it Reserved Sprint. So when we run out of backlog items in the main sprint, our team starts working on the backlog items of the reserved sprint.”

Observe the problem with this innocent looking concept of Reserved Sprint: you think that it is a good thing for keeping the team busy but it conveys something else.

It conveys that your project is not progressing well.

Now, don’t get surprised when you hear this!

I’ll give you its reasoning but first let me ask you this question: Having a concept of Reserved Sprint sounds like a plan?

Yes?

That’s the point. See what the Agile Manifesto says about following a plan.

If you intend to feel relaxed because of a planned activity, you’re hiding from responding to change. That means you’re not doing correct form of Agile.

Concept of Reserve Sprint keeps the team away from doing the most important work. The rationale behind putting some tasks in so called reserve sprint implies that those tasks are of less value. If those tasks were of high value then it would have been planned in the regular sprints.

Instead, inspect and adapt. Work as a team to discover high priority backlog items and start working on it. Great Scrum teams provide value that way.

Scrum is not the rocket science. It could be as simple as looking at Agile Manifesto in this case.

Don’t tailor Scrum. Instead, tailor the software that you produce using Scrum. When in doubt, go back to the basics.