The ScrumMaster plays a pivotal role in helping the team adopt the spirit of Agile. They need to bring the team to an understanding of why certain practices are important. I know for many years as I lead ScrumTeam I have failed in getting the team to understand why we use certain practices.

Here are some qualities of a good ScrumMaster:

1. Be a listner.
   They need to really understand the team. How are the team members relating to each other? Are they really working together? Do they respect each other?
2. Be a Team Coach
   They take responsibility for the team’s adoption of Scrum. It is important to monitor the teams progress toward adopting the practices of Scrum.
3. Be a Team Member Coach
   The team is made up of individuals. The ScrumMaster takes interest in each individual so that they can achieve their maximum potential. Each individual will accept the tenants of Scrum in varying degrees. We need to know where the individual is in their own adoption of Agile.
4. Be Humble
   They are not doing this so we can enhance our personal resume and show everyone what we have done. We take pride in what the team is doing. It is what the team has accomplished that makes a difference. The ScrumMasters roll is that of a servant-leader.
5. Be Passionate About Agile
   A good ScrumMaster really believes in what they are doing. They have an enthusiasm for Agile. They have been trained and are continuously doing self training in Agile. They want to do the best job they can.
6. Leave it to the Team
   A good ScrumMaster does not make decisions for the team but lets the team make their decisions about the process. The ScrumMaster will train and guide the team but will not make decisions for the team.

There are other traits that are good but the ones I have listed I consider to be critical. Unfortunately I have not witnessed these qualities in most ScrumMaster I work with.

• Do you ever think of a member of the team as a problem that has to be fixed or do you really try to understand his or her reason for their behavior?
• Do you spend time learning about a team member’s hopes and aspirations?
• Do you know the names of their significant others?
• Are you really concerned with their professional and personal growth?

I know this may seem necessary because we are technical professional like dealing with one and zeros and not with the soft sciences. But as a leader it is important you really know the members on you team not about them. But I must warn you that you must be sincere in this venture. You must check you own attitudes about team members and make sure you are really concerned about them.

The team is willing to be a leader and will take on the risks. Because of this can do mentality I wanted to have all who were interested to view our first sprint demo. So what I did was use the largest distribution list for our department for our invitation list. Well this was a mistake and really caused the team to become very uneasy. They pointed out that we had overcome many obstacles in this sprint but there was not really much to show for it in the demo. We have completed one user story well and it is “done” according to our new standards of acceptance but it was only one user story.

They were correct. Perception is everything and we only have a “simple” user story to display for all of our work the last 3 weeks. The extended stake holders would not really understand what was involved in what we accomplished.

So I canceled the original meeting and invited a much smaller group to stake holders to the sprint demo. A lesson learned on consulting the team before make a major decision on who to invite to our sprint review.

In an Agile team it is critical that each member has the same vision and goal. Unless the team is first the team will not succeed. When team members are more concerned about their own individual gaols instead of team goals you have lost the team focus.

Unless we can all capture the same vision we will fail. Oh, we may get a product out the door but will it be the best product we could have produced if we were focus.

In order to produce quality team work  and capture the vision we have to spend quantity time together. This means working side by side with each other for hours a day. Time spent together ends up creating a team works together well an helps keep them focused on the vision.

1. Other Projects
2. Personal issues
3. Lack of hardware
4. Lack of team synergy

Other Projects

These can range from pet project from a manager to the previous project a team member was working on. Also, there always seems to be an emergency project that needs to be worked on.  All of these affect the velocity of a team and may affect if the team is able to finish the user stories it has committed to. It is important that the ScrumMaster communicates to the management and product owner how much other projects are affecting the team and when they become major impediments. I my role as a ScrumMaster this has been the most prevalent issues I had to deal with. It is no fun when you have to tell a resource manager you report to that they are affecting the viability of a project.

Personal Problems

All of us face time when we have family issues or have physical problems that need attention. Unfortunately our jobs may be the cause of many of our problems. Our jobs cause stress that may affect our health and our families. It is important that we create a healthy work environment that does not cause excessive stress. Employees need to have time with their families and time for recreation to keep a healthy body. A good exercise routine leads to a more productive employee and less visit to the doctor. If we keep to a 40 hour work week we will have time to spend with our families.

Lack of hardware

It in uncalled for that companies invest in adequate hardware for their employees. Niceties such as dual large monitor, powerful laptops and large disk drives are cheep compared the cost of a employee. Necessary hardware should be available to the employee without having to go through excessive red tape. Also the supporting  build and testing environments should be setup and supported from the beginning. There is no excuse for the lack of good hardware.

Lack of team synergy

So often a team is a team in name only. So often the individuals are just working on their tasks and nothing else. If they finish early they will find something that interests them to do and not even consider what other task they can work on.

In a productive team the members learn how to leverage each others strengths. They work together for a single purpose. There is no individual recognition. We as a team work together toward the goal of finishing the sprint goals. Each member makes sure they do their part by taking on available tasks.

Let me give you an analogy. Let’s say you by a new delivery van (yes we need to help the economy right now) and you want to start using it in your business. Now you want to make the most of this asset. So you decide that you will drive it at 100 miles hour and that you will not take it into the shop for routine maintenance because you will not be able to make deliveries with it. How long would your new new delivery van last? Is this the best use of your new asset?

Developers cannot be constantly running at peak speeds. Eventually they will wear out. Also, they need to be able to work on skill improvement and have a chance to expand their horizons. Slack time in the schedule is important just for the sake of sanity.

Having a developer working on multiple projects is bound to wear them out. This can be displayed in lack of enthusiasm, increase sick days or just plain bad attitude.

This is very frustrating because TDD is the proven way to create quality software. Also, developers are going to resist using tools that do not enhance their job and the quality of their software. Who wants to add more time to an already tight schedule to develop test that one cannot use.

I was informed that our culture does not value testing by the developers. Oh, there have been directives that all new code will be unit tested but because good tools have not been provided this type of testing is spotty at best.

To do our job efficiently and produce top quality code we need to have environments that support us not hinder us.

Well we have gone through two major product releases and the team is really coming together. They have learned to work together and leverage each other strengths.

One thing I am learning it to look for the little changes in Agile adoption. Over the months these little changes accumulate and make for some very significant changes in an organization.

This is prime example of the individual not thinking as a team member. This individual must realize they are a member of a team whose goal is to produce a successful product. We need to adjust to the needs of the team.