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.
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.
Have you ever worked on a team project at work? If so, was it successful? Explain why or why not.
Have you ever played on a sports team? Was the team successful? What lessons from playing on a sports team could be used on a Scrum development team?
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
Providing visibility to product quality
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.
Work agreements must be reviewed at the end of every sprint, usually done during the retrospective meeting. If the team feels they are doing extremely well on one of the agreements, they can vote to replace it with another. This is an ongoing process that is totally owed by the development team. The ScrumMaster only guides and makes suggestions.
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.
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.
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?
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?
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?
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.