Seven Things I Wish I Had Known When Starting Out as a ScrumMaster

Historical anchor: May 16, 2012. Republished with a present-day author's note on August 30, 2026.

A present-day note from the author

I wrote the article below in 2012, when Scrum was an important part of how I understood software delivery, teams, and professional responsibility. I would not write every sentence this way today. I do not want to erase the distance between then and now.

What changed

Today, I begin with whether a team is solving the right problem, not with defending a process. Any process is not a solution. A solution is a solution.

Several recommendations in the article are more categorical than I would make them today. One ScrumMaster serving one team can be a useful signal about attention and overload, but it is not a universal law. Fear is not a reliable source of excellence. And "do not manage" is too blunt: controlling people is different from providing coordination, coaching, judgment, and accountable leadership.

I would now place the work in a larger frame: project leadership under uncertainty. A forward professional does not merely operate a framework. The work is to read the situation, make commitments visible, create conditions for sound decisions, and help people move toward an outcome without pretending that the process can think for them.

My understanding of "done" has also deepened. A Definition of Done remains valuable, but completion must be grounded in observable evidence and adapted to the risks of the work. That line of thought later led me toward the Usable Definition of Done, or UdOD.

What survived

The movement underneath the article still matters to me: pull over push, team outcomes over individual activity, self-management over dependence, visible commitments over vague status, explicit completion conditions over assumption, and leadership that does not depend on formal authority.

Scrum gave me a practical vocabulary for those ideas. I preserve this article because it records an important stage in how I learned them, practiced them, and eventually learned where the framework ended.

The surviving 2012 article

Historical note: I submitted this article to Scrum Alliance on May 3, 2012, and received confirmation that it had been published on May 16, 2012. The Internet Archive preserves the published page as it appeared on May 23, 2012. This Almanac edition is based on my complete surviving submitted manuscript. It contains 3 active reference links, while the surviving editorial correspondence records 5 restored references, so small editorial details may differ from the final published page. The argument and period-specific language are preserved. Spelling, punctuation, and web formatting were lightly normalized in 2026.

Typically, when an organization starts using Scrum, it is not unlikely that the person chosen to play the role of ScrumMaster is coming from some sort of managerial background. The organization expects that the manager, so called "Master," will get the Scrum project delivered with her managerial expertise along with 2 other projects she is managing.

Now that expectation itself is the first impediment to be dealt with.

If not, it is almost certain that the organization would not get the benefits that it should have gotten otherwise out of the same Scrum project. Remember, there are no RIGHT ways to fulfill the WRONG expectations.

I wish I had known the above fact when I first started playing the role of a ScrumMaster several years ago. Following are 7 more things I wish I had known when starting out as a ScrumMaster.

1. Work on one, and only one, project

If you chase 2 rabbits, you will not catch either.

Russian proverb

Eventually, you might catch the 2, but it might kill the whole purpose. Consider this: even if you are 100% committed, when you choose to work on, let us say, 2 projects, you imply that you are only 50% committed to each project. Now, that is a disservice to the organization you serve and to the customers your organization serves, is it not?

Mikael James contributed a resource on what makes a great ScrumMaster that highlighted this point effectively. Here was my take: "An adequate ScrumMaster may handle 2 or 3 teams at a time, but the most effective ScrumMaster chooses to handle 1 team at a time."

Many ScrumMasters know this but do not take a stand because it seems like a risky proposition. You are working on only 1 project, and if that fails, you will be a failure.

That is the whole point. That fear will bring the best out of you and inspire you to bring the best out of your Scrum team.

2. Focus on improving team effectiveness

It is okay if it comes at a cost of individual efficiency. Team effectiveness makes all the difference. Building great software matters, regardless of who does it.

In Scrum projects, focus on individual efficiency is an impediment. Here is the chief reason: to achieve individual efficiency, team members may keep away from practicing Scrum principles such as transparency and collaboration. For example, if a team member is focusing on achieving individual efficiency, she may choose not to communicate information that might be useful for the project so that she can use that information to prove that she is individually more efficient than other team members.

Reflect on the quotation attributed to Margaret Carty: "The nice thing about teamwork is that you always have others on your side." It resonated with one of the prime agile principles: customer collaboration over contract negotiation. Inspire your team members to consider every other team member as the customer with whom they have to collaborate and bring the desired result out.

3. Do not manage. Facilitate.

This might be a difficult one for a manager, but it is important to understand that Scrum is based on the principle of self-organization that requires facilitation, not management. So any attempt to "manage" the team members is anti-Scrum.

Pete Deemer wrote an article on the manager's role in Scrum. Here was my take on it.

What not to do:

1. Do not make decisions on behalf of other team members.
2. Do not assign work to team members.
3. Do not keep track of what team members are doing.
4. Do not incorrectly "own" other team members' work.
5. Do not engage team members in status meetings.

What is okay to do:

1. Help remove impediments.
2. Organize one-to-one mentoring sessions for team members.
3. Give inputs on how to make features better.
4. Collectively participate in hiring new team members.
5. Help plan career-development activities for team members.

A manager's role is about doing things right and complying with standards, whereas a facilitator's role is about doing the right things and creating. Both require different types of skills, so get convinced that this is what you want to do or explore other, out-of-Scrum options.

4. Establish work-life balance as early as possible

Too many people, including Scrum team members, do not know how to live until they interact closely with death. They spend the best of their time chasing what I call "the fool's gold" by neglecting their health, relationships, and other important pleasures of their lives.

The result is burnout, unhappiness, half-hearted work, and mediocrity at its best.

For each Scrum team member to perform at her best, it is important that the work team members pick is not so much that it requires long hours and weekends in the office at the cost of their health, relationships, or other important things.

Reflect on a direct concept from Ken Blanchard and Spencer Johnson's The One Minute Manager: "People who feel good about themselves produce great results." By ensuring work-life balance, you make people feel good about themselves, do you not?

Someone asked me the other day whether a 40-hour workweek contributes toward good work-life balance. There are no right answers. It differs from situation to situation. It could be more, maybe 48, or less, maybe 32, depending on various parameters. The point is to find a win-win way for the team and organization that helps the team produce great results.

5. Ensure that each team member knows what "done" means

The problem with the definition of done is that it is relative. For the person carrying out the work, "my part of the work is done" equates to done. Producing software is a complex activity, and it is important for all team members to understand what exact state conveys that it is done or accomplished.

So when a team member says that a particular feature is done, how would she ensure that it is done as per the expectation?

Dhaval Panchal wrote an article to help teams figure out what "done" means. Here was my take:

Definition of done is a non-static, auditable checklist influenced by reality. So, as a team, identify the "potentially shippable state" for a feature, a sprint, and a release at large, and commit to accomplishing the tasks according to the definition of done.

6. If a team member is not thrilled by and committed to the project's purpose, the ScrumMaster is not doing the right job

Consider the example of a music band. All the artists, along with their conductor, work in sync to achieve a common goal: produce great music. Even if 1 person is out of sync, the music is out of order. Scrum teams are no different. All Scrum team members, along with their ScrumMaster, work in sync to achieve a common goal: produce great software. So if 1 team member is out of sync, the software feature might be out of order.

Now that is an impediment that the ScrumMaster must remove.

7. ScrumMaster is not the boss

Anyone trying to be the boss of other team members is anti-Scrum.

Unlike managers, a chief characteristic of a ScrumMaster is to be a "servant leader." A ScrumMaster is more of a coach to the team than a boss. She facilitates what the project needs to accomplish to deliver according to the definition of done.

Although they have some authority over the Scrum process, many new ScrumMasters struggle to play the servant-leader role with no formal authority over team members.

The ScrumMaster's role is similar to a health coach who helps you follow a health routine, including food habits and exercises, in the correct way. A good health coach will inspire you to learn about the benefits of activities such as the right diet, yoga, and exercise. The health coach has no formal authority. He cannot force you to follow a routine that you do not want to follow. Instead, the coach connects you with the health commitments that you have made.

A ScrumMaster is expected to make a difference without formal authority over team members. That requires a 360-degree change in mindset, and hence it might be difficult for new ScrumMasters. But it is said that opportunities come wearing the masks of difficulties. So make a correct choice.

In summary

If you are aware of the above things and still not able to practice them in your Scrum projects, probably there are still some gaps to be filled. These gaps are opportunities for you to shine as a leader beyond whatever your title is in your organization. Go make that change happen.

Related

• How #SCRUM tweet began
• When Scrum Mattered
• Scrum, Then and Now series
• What Does "Done" Mean in a Startup?
• Forward Professional series