Scrum roles

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.

About the author
Mitch Lacey
Author: Mitch LaceyWebsite:
Agile Software Practitioner, Coach and Author at Mitch Lacey & Associates
Mitch Lacey is an agile practitioner and trainer. Mitch has been managing projects for over fifteen years & is credited with many plan-driven & agile projects. He is the author of "The Scrum Field Guide", a book targeting teams adopting Agile and Scrum practices. Mitch honed his agile skills at Microsoft Corporation, where he successfully released core enterprise services for Windows Live. Mitch's first agile team at Microsoft was coached by Ward Cunningham, Jim Newkirk & David Anderson. While at Microsoft, he transitioned from Program Manager to Agile Coach, working hand-in-hand with groups throughout their transition to Agile practices. After Microsoft, Mitch was the Agile Practice Manager at Ascentium Corporation where he practiced agility on the projects he ran every day while coaching customers on agile practices and lessons on agile adoption worldwide. As a Certified Scrum Trainer (CST), PMI Project Management Professional (PMP®) and Agile Certified Practitioner (ACP®), Mitch shares his experience in project and client management through Scrum Alliance Certified Scrum courses, agile coaching engagements, conference presentations, blogs & white papers. He has published many papers including “Adventures in Promiscuous Pairing”, “Transitioning to Agile: Key Lessons Learned in the Field”, "The Impacts of Poor Estimating - & How to Fix It", a variety of papers for Microsoft and "Immersive Interviewing - Building Great Agile Software Teams". He has presented at Agile Alliance Agile 2006, 2007, 2008 and 2009 conferences, the 2008 Better Software Conference and the 2008 - 2013 SQE Agile Development Practices conferences. He has managed tracks for the Agile conference since 2008 and was the conference chair for Agile2012 and Agile2014. Mitch has served on the Board of Directors for the Agile Alliance (2011-2012) and the Scrum Alliance (2010-2011, 2014).

Past Events

Our Services

Contact Us

Bosnia Agile
Milana Preloga 12, Sarajevo 71000
Bosna i Hercegovina

This email address is being protected from spambots. You need JavaScript enabled to view it.