Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More
Introduction
Scrum is a framework that is easy to understand but difficult to master. One of the reasons for this is that the roles in Scrum and their interactions with each other can be confusing.
Today we’re going to be talking about the three key roles in Scrum.
All three of these roles need to come together and work as a single team to be truly effective. These should not be seen as silos of specialism with a “them & us” type mentality. The three roles must operate as a unified unit, the scrum team.
The Product Owner defines what is needed and helps the team prioritise the work and accepts the outputs from the team.
The Engineering Team, do the work to give life to the product owner’s vision.
And the Scrum Master coaches the Scrum team to continually inspect & adapt to help deliver continuous improvements that help the Scrum team to operate more effectively.
These are roles, one person on the team may play a combination of roles e.g. Developer and Scrum Master. Equally the Product Owner role is just one part of the job of someone in Product Management.
The Scrum Master
Let’s start with the Scrum Master role. The Scrum Master is more than the team’s administrator. Setting up and chairing the various meetings and calls that the Scrum ceremonies call for is a tiny part of the role. Ideally, the team should be able to run these ceremonies without the Scrum Master being present.
The Scrum Guide, which by the way if you’ve not read, then I highly recommend it as its a short (18 page) read that explains Scrum practices and the required mindset in a clear & concise document.
Anyway, the Scrum guide highlights the importance of the Scrum Master in mentoring & coaching everyone on the team in Scrum, this includes QA, Dev and Product Owner, as well as acting as a servant-leader and facilitating change to maximise the value created by the team.
So, Scrum Masters are the keepers of the Scrum process for the team, ensuring that the Engineering Team & Product Owner follows Scrum practices and continually inspects & adapts to improve efficiency.
Being a servant-leader means helping the team to remove impediments and ensuring the team has what it needs to make progress. It’s not about directing the team in a command & control style.
The Scrum Master provides services to the other two Scrum team roles (Engineering Team & Product Owner) as well as to other Scrum Masters. They help ensure that the Product Owner’s vision is understood by the team and help the Product Owner get the best value from the team.
They help the team to be able to do their best work. And they help other Scrum teams to learn from successes and setbacks experienced by their team.
To be a good Scrum Master you first of all need to understand Scrum and be a good communicator. You also need to be a good listener, both to take on ideas from the team but also to listen out for signs that the team is struggling, even when the team doesn’t admit it. You need to be able to help the team, by removing impediments and by helping them understand the Product Owner’s vision.
A Scrum Master is not simply an administrator or meeting chair
The Scrum Master role is a combination of referee, coach, facilitator and champion of the Scrum way of working
Product Owner
The Product Owner role is a complex and challenging one. Product Owners always have their eye on the product vision and the longer-term direction that the product needs to progress towards.
Their time is divided between:
- the Stakeholders both internal and external customers, understanding their requirements, concerns and ideas
- and the Engineering team, providing direction on what the product needs to do, communicating and answering questions to help the engineering team understand what is needed.
An effective Product Owner needs to listen to both of these groups, provide direction, make decisions, trade-offs, and communication that drive the product forward whilst always keeping the long-term product vision in mind. A complex and demanding set of activities.
The Product Owner is a key part of an effective Scrum team. They own the inputs into the team and the outputs from the team. The Product Owner is highly dependent on the Engineering team to create what is needed to meet the Product Vision that they, their stakeholders and clients have for the product.
The Product Owner takes ultimate responsibility for the work delivered, they are the ones that have to stand in front of clients and internal customers promoting the work that has been created, put yourself in their shoes and try to think about and appreciate how challenging and stressful that must be.
This slide focuses on the Product Owner activities that relate to the Scrum role. Keep in mind someone in Product Management will have additional responsibilities outside of the Product Owner role that also contributes to their extensive workload.
The Product Owner wants the team to be successful, their success and the success of the product is dependent on the team delivering against the product vision. So Product Owners are approachable (they are not scary monsters that we should fear talking to), they will answer the Engineering teams questions and would rather do that then feedback at the end of the sprint that what was delivered was built on a misunderstanding and was not what was asked for.
Product Owners first and foremost need to understand the product, at a really deep level. AND they need to understand the customer and their needs. Their vision and focus aren’t on the next two week Sprint, it’s on the opportunities and hazards 6, 12, 18 months down the road.
They are unwilling to compromise on the acceptance criteria, quality and completeness of the work completed because they know the customer won’t compromise either. Just like we won’t compromise on quality ourselves when we are customers, think about your mobile phone, what would you do if it didn’t work in an easy to use and consistent way…. you’d change phone (and possibly OS).
Product Owners also need to understand Scrum, its processes, practices and how to define and explain the requirements in terms that the Engineering team can relate to.
The Product Owner is focused on the WHAT, not the HOW.
The Engineering Team
The Engineering team are very much focused on the HOW. This is the collection of individuals working together to fulfil the vision communicated by the Product Owner. This is the group that brings the vision to life and creates the product. Different people in the team may have different specialisms and they must work collectively to accomplish the work by being willing to help on every story. Otherwise, we end up with team members doing their own thing and hindering the progress of the wider team just like in this man in the boat.
A key element of Scrum is that the team is self-organising, this means that the team can self-manage to get the work completed, swarming on issues and helping each other to collectively deliver on the commitments that the team have made for the Sprint. The team makes those commitments, they are not forced on or dictated to the team. The team is empowered to discuss the tradeoffs with the Product Owner and agree on what can realistically be achieved in any given sprint at the start of the sprint. Sure the Product Owner may challenge and strive for the team to deliver more, and the team and Product Owner will come to a mutual agreement of priorities and commitments that the team will meet. Not trying to meet, but commit to meeting.
The Engineering team has collective responsibility for getting backlog items to Done. Not just one person’s work done but the whole item completed and ready for use… or “Done Done”.
If I tell my wife I’ll go to the grocery store to do the shopping for dinner tonight and when I get back she’s busy dealing with the kids. I don’t leave the food on the kitchen counter and say I’ve done my bit the shopping is done, it’s ready for you to cook (and then go hungry whilst waiting). I start cooking or helping her to cook dinner.
The Engineering team, therefore, needs to be willing and able to help each other regardless of specialism to maximise the value & user stories completed at the end of each sprint, and by completed we mean “Done Done”.
Ongoing reflection on what is and is not working is also needed so that the team can inspect and adapt not only to reduce and remove technical debt but to also improve ways of working to the benefit of the team and the product.
A good, if not great, Engineering Team combines excellent technical skills with communication skills. The ability to listen to and ask questions of Product Owners to build an understanding of the business need.
Collectively as a team make the commitments and then deliver on them.
Be willing to step outside their specialisms to help the team as a whole.
The ability of the team is more important than the abilities of any individual team members.
0 Comments