Scrum roles
- Details
- Hits: 35747
Scrum is elegantly deceptive. It is one of the easiest frameworks to understand yet is one of the hardest frameworks to implement well. I say “implement well” because Scrum’s inherent simplicity can seduce us into thinking it is easy to do, when in reality it can take years to do it well. Scrum seems to go against all that we have learned in our many, many years of waterfall development. It stands to reason that it will take us a while to unlearn our bad habits and adjust to a new reality.
Scrum Master
A race car has gauges and sensors to help monitor the engine and it also has oil. Without oil, the engine would grind to a halt, destroying itself in the process. The oil is everywhere, keeping the parts of the engine working smoothly, cooling them and ensuring they perform well under stress.
The Scrum Master is like that. He has embedded sensors and gauges that allow him to identify when the team is not performing to its ability and he has the skills (lubrication) needed to assist in correcting the issues. Being the Scrum Master is a hard job. A good Scrum Master is someone who can read non-verbal communication, is comfortable with conflict, is an effective communicator, can build trust and earn respect, and understands team dynamics. A good Scrum Master can evolution-ize development. He can build trust not only in the team but with customers as well.
Product Owner
The Product Owner's primary goal is to ensure the vision that was asked for by the stakeholders/customers is being executed by the team. The Product Owner does this by working with the stakeholders to understand the functionality of the system under development. From there, the Product Owner will write user stories or work jointly with the customers to write them. The stories go into the Product Backlog.
The Product Owner manages and represents the interests of the stakeholders and customers.
Think about the car model from the Scrum Master section. If the Scrum Master is like the oil and sensors in the engine, the Product Owner is the driver. The product owner points the car in the correct direction and makes the minute course adjustments necessary to stay on course and deliver results. She represents customer and stakeholder interests. Her job is to establish, nurture and communicate the product vision to the team and the other stakeholders, manage the project return on investment and project financials and make decisions about when to create an official release (with customer and stakeholder input). The Product Owner is the one person ultimately responsible for the success or failure of the project. She decides what is developed, when it is developed, and whether that which has been developed meets expectations.
Scrum Team
The core team is the engine of our race car. All the driving and lubrication in the world is no use without an engine. The core team executes the Product Owner’s vision with the help of the Scrum Master. The team is comprised of the people needed to deliver the work –developers, testers, architects, designers – anyone who is needed. A core team is ideally made up of full-time people dedicated to the project. The team is responsible for managing its work, its commitments and the execution of those commitments.
Most Scrum material will say that the ideal team size is seven, plus or minus two people. I prefer even numbers as it facilitates better XP engineering practice integration. The team is just that, a team – roles and titles should be removed as it helps build the camaraderie around the team. The goal is to remove the mindset of “I’m a developer and I only write code” and shift the attention to “I’m a team member who is responsible for delivering this work and I cannot do it alone” – enter the team. On a Scrum team, testers may write code and developers may write tests – cross functionality is a good thing.
