There are three main roles in the Scrum method of software development.

1 – Product Owner

2 – ScrumMaster

3 – The Team

In this article, we will review the two roles in the Scrum methodology: the Scrum development team and the ScrumMaster.

Scrum Development Team

• Cross-functional team that is able to communicate with others on team, such as developers, analysts, marketers, etc.

• Is able to be self-managing and self-organizing

• Makes commitments to product owner during each sprint

• Is able to work with autonomy regarding how to best meet commitments

• Is able to collaborate

• Is successful working in a team room – with everyone in the same room

• Is willing to work the job long-term; turnover is not good for Agile or Scrum

• Works on a team of approximately seven people, plus the product owner and ScrumMaster.

Key Term!

Scrum

Scrum is a management process that focuses on software development using incremental and empirical methods. It places emphasis on management and teams, and an open line of communication. It is a very simple framework for often complex and complicated software development projects.

Also, Scrum is a rugby analogy that lets a team self-organize and makes quick changes.

What Makes a Good Team?

The Scrum team is unlike any other team in business. Loosely defined, a team is a group of people who are joined together with a common goal. There are marketing teams, sales teams, support teams, and many, many others.

But the Scrum team is different.

First, there are only about seven people on the team, and they work together all day, everyday, and usually in the same work space, if possible. Agile and Scrum teams stay together for a long time. This is because it takes time for people to become a real team. People are human, they must learn to know and trust their fellow team members. On average, it takes 18 months for a team to become a high performing team.

Imagine the team from ABC developing the product for XYZ hotels. There are seven of them, and they are together every day in the same work space. They meet every morning, and talk all day long. Can you imagine what would happen if one member didn't like another member? Or, if one member thought he was too big for his britches and tried to flaunt his power? It wouldn't work very well and the team would soon fracture.

In a successful Scrum team, there will be varying opinions and attitudes when it comes to attacking and solving problems. This is good to have, as it allows the team to engage and discuss the problems and seek the opinion of everyone on the team. If it is a good team, every member is heard and the decisions made are based on the team, as a whole.

An important consideration when thinking of teamwork is that no one individual team member is able to succeed on his or her own. It is all about the team. And software development is NOT a team activity. Normally a project manager manages it. There is the designer, the developer, the testers, and architects, as well as the engineers and analysts, and normally they can all succeed individually.

In the Agile environment, the team must be able to motivate each other. Team tasks have frequent feedback or progress, and help the team as a whole. Agile and Scrum teams are self-designing. This means that the product owner, the ScrumMaster, and the development team all decide together the direction their product will take, how the work will be done, and who will do it.

Challenges of Scrum Teams

Self-designing and self-organizing teams often outperform larger traditional teams. The small, family-sized teams are almost able to self-organize naturally, especially when certain conditions are met:

• All members are committed to the same short-term goals

• All members are able to gauge the team's progress

• All members can watch and observe each other's contributions

• All members feel safe to give constructive feedback

It takes time to organize a good Scrum team, and self-organization takes even longer. In fact, the team could perform worse during earlier iterations than would a more traditionally formed team. This is an understood fact when organizations choose to use the Scrum product development method.

Because of the small size, disagreements will happen. This is totally normal and healthy and expected. The team's performance can be based on how the team handles these disagreements. If everyone gets angry and storms off to lunch, then that is not a good sign. It is important that even small disagreements are handled as soon as possible.

In rare occasions, there can be a single negative person on the team. This person will often very negatively affect the team, as a whole. Furthermore, when this happens, it is difficult for the team to remove the negative member. It is often at this point that the ScrumMaster will step in and make suggestions on how to handle the team member who isn't keeping his end of the deal.

What Roles Do Scrum Team Members Play?

We have already established that each member of the team co-organizes and shares responsibilities. However, there are still roles that need to be filled. After all, a team of seven developers would not work, would it?

Here are the main roles that need to be filled on a Scrum development team. Just remember, in Scrum, no one person is responsible for any one role.

Architect – This role leads the technical direction of the system. It is responsible for:

End to end cross-functional design and communication

Working with the PM to prioritize features

Testing architectural elements with a testable design

Facilitating technical decisions and receiving feedback on the overall design

Making alternative design concepts

Making sure the design goals are met

Leads the review of the product designs and offers feedback

Engineering Manager – This role makes certain that work in progress is completed, and understands the product creation process. . It is responsible for:

Rate of production and lead time

Preliminary high-level sizing

Works with architect to improve technicals

Conducts technology investigations

Removes obstacles and bottlenecks

Enforces engineering best practices

Keeps team motivated

Helps in career development of team members

Product Developer – This role is responsible for the creation of the product. It is responsible for:

Estimating the size of the backlog

Translating backlog items into engineering design tasks

Evaluating whether technicals are feasible

Implementing any items on the product backlog

Writing and verifying code that will be accepted

Enforcing product development best practices

Quality Assurance – This role attempts to prevent errors from entering the system, instead of finding them at the end. It is responsible for:

Writing test plans to accept new features

Constantly updating test plans and cases to stay compliant

Notification when production is stopped due to errors

Measuring, defining, and improving quality

Enforcing quality assurance best practices

User Environment Design – This role adds the human factor to the features and design. It is responsible for:

Overall user interface consistency across all iterations

Initial customer research

Interaction Design specifications

Working with the PM to analyze features, so they conform to what the customer needs

Making sure features are implemented as designed

Visual Design, prototyping and usability testing

Operations – This role keeps the products running in production. It is responsible for:

Designing hardware configurations

Setting up staging and production environments

Monitoring post production and troubleshooting products

Work Agreements for a Scrum Team

Work agreements are the self-imposed rules the team agrees to follow to make themselves more efficient and successful. Every successful team needs a work agreement.

Who Writes the Agreements?

The members of the team set the agreements. The ScrumMaster may facilitate the agreement, but it is the team members, themselves, who will set it. The team will also need to review the agreements periodically during sprint retrospective meetings.

The team should schedule a meeting to set the work agreement. All that is needed for this meeting is a whiteboard, a marker, and the team members. Gather everyone in an empty office and try to have some fun with it.

How Do You Write the First Agreement?

Usually the ScrumMaster will start the meeting and set the agenda. He will explain what a work agreement is, and perhaps give some examples. An example could be "Keep meeting notes on Scrum board daily," or "Always be on time for daily stand-ups." These items could be anything that could potentially help the team be successful.

The ScrumMaster will then suggest that the team brainstorms the most important points they want on the agreement. He will also ask the team members to share their ideas with the group.

The team members will then share their ideas, and why they believe their ideas should be a part of the work agreement. The ScrumMaster will take notes throughout and guide the discussion, if necessary.

Once the brainstorm session is over, the ScrumMaster will tell the team to pick the top five ideas they like, and vote on them. After the voting, the ScrumMaster will count the votes and share the top five ideas with the team. These top five ideas will become the basis for the work agreement.

The team must agree that they will all follow those ideas, as they fairly voted on them, and it is the best way for them to be successful. If a team member doesn't stick to any of the agreements, other team members must remind them to adhere to the agreement. Then these five agreements should be displayed in the team's work space.

The ScrumMaster

The ScrumMaster is the person who facilitates the product development team that uses the Scrum methodology. Scrum is a rugby analogy that allows a team to self-organize and makes quick decisions. The ScrumMaster manages this process.

In a game of rugby, teams huddle together in order to restart the game. In Scrum product development, team members huddle together each morning for a daily meeting -- the daily Scrum meeting -- to discuss where they are in the "game."

During the daily meeting, the ScrumMaster asks the team just three questions:

What did you accomplish yesterday?

What do you plan to accomplish today?

Are there any problems or obstacles that need to be addressed?

The ScrumMaster sounds intimidating, but he is not the boss. The product owner is the leader of the project, and the ScrumMaster is simply a facilitator. It is not an easy job though. The ScrumMaster must be able to:

• Help the team find agreement for what can be achieved during a certain period of time

• Help the team reach a consensus during the daily Scrum meeting

• Help the team stay focused and on task, and to follow the agreed upon agreements

• Remove obstacles that are hurting the progress of the team

• Keep the team protected from outside influences and distractions

The ScrumMaster also must be able to help his team use Scrum. The ScrumMaster is akin to a personal trainer. A personal trainer works alongside of you encouraging you to do your exercises, and makes sure you are doing them the right way with the correct form. Hopefully the personal trainer will also motivate you to make sure you keep going and don't cheat.

But the personal trainer can only do so much. They cannot force you to do your exercise. All they can do is remind you of your goals and help you stick to them. If your personal trainer suddenly started yelling and imploring you to do sit-ups, you might just find yourself another trainer.

A ScrumMaster can tell a team that they are supposed to deliver a new feature at the end of the current sprint, but that they failed this time. Then he will ask how can they prevent that from happening in the future.

Because the ScrumMaster doesn't have the authority to give orders he cannot say, "Because you failed to deliver the last iteration, you will stay late and completely redo the code so this doesn't happen again." If he did that, it would change the way the team works, and why the team usually succeeds.

What Is a ScrumMaster?

To become a ScrumMaster, you obviously must know and understand Scrumproduct development. You can learn Scrum on the job, and if you work for a smaller company, you could have a chance of being hired as a ScrumMaster.

However, the term ScrumMaster refers to a certificated professional who has a demonstrated knowledge of the methodology.

A person can become a Certified ScrumMaster (CSM) through the Scrum Alliance, which is a non-profit organization whose goals are to advance the use and understanding of Scrum in software and product development.

In order to become Scrum certified, you must take an approved CSM course from a Certified Scrum Trainer. This is a two-day course that details the entire Scrum methodology. You cannot take this course online, but it is offered in several cities in the United States, as well as internationally. Then you can schedule and sit for the 35-question exam; in order to pass, you must correctly answer 24 questions. The exam is multiple choice. Once you pass, you become certified and are allowed to use the CSM designation with your name.

ScrumMaster

• Extremely knowledgeable about the Scrum methodology and is able to help the team learn and understand the process

• Is able to resolve impediments and obstacles

• Can create an environment conducive to self-organization

• Is able to capture empirical data to make adjustments to forecasts

• Blocks the team from external problems to keep the flow going forward

• Keeps all Scrum artifacts visible and is transparent

• Tries to improve engineering practices

• Is not a manager and has no authority over the team

The ScrumMaster's Checklist

When a ScrumMaster goes to work, what do they do? Well, that can be difficult to answer, because every day is different. But what isn't different are the questions the ScrumMaster should be asking of his team.

Most ScrumMasters handle one team, and this is ideal. They can handle more than one team, but this can limit their role within the team, which could potentially affect how well the team performs.

Assuming the ScrumMaster has one team, these are the questions he must ask of each role.

Product Owner

How is the product owner doing?

Is the product backlog organized correctly, from most important to least?

Are all requests from the customer listed in the backlog?

Is the project backlog manageable? Are there too many important tasks, or not enough?

Does the product owner know how to avoid technical debt?

Is the product backlog available to all stakeholders?

What would help the team -- using charts or printouts?

Can you help the product owner better organize the backlog?

Do the stakeholders know whether the release plan still matches the original?

Did the product owner adjust the release plan after the last review meeting?

Development Team

How is the team doing?

Are team members spending most of their time working?

Do the team members have clear goals and understand those goals?

Do the team members like each other and get along?

Do team members hold each other and themselves accountable?

Are there issues the team is avoiding because they are uncomfortable discussing it?

Are the team members being compliant to the agreements?

Does the sprint backlog actually reflect what the members are doing?

Are there any interruptions, distractions, or impediments?

Is the team task board current and up to date? If not, who should be keeping it up to date?

Are team artifacts visible to the team and easy to use?

Do team members ever offer to help on other tasks?

Is technical debt recorded in the backlog?

Do any of the team members use titles or act more important than other members?

Does the team act as a team?

Engineering Practices

How are the engineering practices doing?

Does the system have a push-to-test button, so members can know if they've broken it?

Is there a balance between functional and automated tests?

Are functional tests being written in the same language as the product they are building?

Do the team members use continuous design?

Do team members pair programming?

The Organization

How is the organization doing?

Is there enough team coordination going on?

Is the coordination being done by the people actually doing the work?

Are ScrumMasters meeting with each other and comparing notes?

Are you allowing your company to be a learning organization?

Is the organization being recognized by trade publications and journals?

Is the organization seen as a leading one in the industry?

A ScrumMaster asking these questions will be proactively keeping all of their responsibilities in their sights, and by using the checklist, they are unlikely to forget something.