After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”
I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.
Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.
At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.
Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?
Recognizing the impact of change
A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.
The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.
Scrum as a form of Change Management
I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.
A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.
One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.
As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:
- Do we both understand and support the team’s mission and goals?
- What are the product goals?
- How can we best help the team achieve those goals?
- Are there any conflicts between the team and product goals?
- When our goals or methods are in conflict, how will we resolve them?
- In what ways will I be supporting your success as an SM/PO?
- How will we keep each other informed and engaged?
- Should we have a peer/subordinate/other relationship?
So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.
Martin Aziz
Blog
@martinaziz
LoyaltyOne
Affiliated Promotions:
Please share!
Great article – and very timely. I was talking about this with a PO yesterday. This will start a lot of great conversation!
Thanks Martin for the post.
Indeed these questions are very valid and the answers for them would lead to good working ground rules.
Now I wanted to point out that:
“Should we have a peer/subordinate/other relationship?” needs a 3rd person and that too with (probably) higher authority to help sort out with this question.
Good insight Amit, thanks for sharing that.
When I look at the questions, and they are by no means comprehensive, the goal was to focus on engaging in dialogue. To understand the position of the other, even if it can’t be resolved without outside help or direction. I suspect for many of the questions, depending on the situation, the help of a 3rd party could be needed.
Very insightful. Communication is a key component of any relationship be it SM/PO or team.
A very good article with the communication aspect being true in all projects regardless of whether the organization uses waterfall or agile or is going through a transition. Communicate, communicate, communicate. Don’t point fingers.
If your PO defines his own personality with Authority, Leadership and Subordinatism – what then? Every question you asked (great questions!), in my situation, I would have to answer at the expense of the SM and the Dev Team. PO wants to be left alone, but wants full performance with no expense, be it fiscally or personally. What then?
Thank you for sharing this Martin. I particularly appreciate the suggested questions. This is a great starting point in discovering our collective participating in a very dynamic partnership.
Thank you for sharing this article.I liked it. Scrum/Agile methodology in general gives you a lot of freedom in how you implement it. However you should avoid changing the essence of the whole process. These project managers are commonly referred as Scrumbut. The common suggestion is that you start to implement Scrum as-is until you understand it properly and then decide for yourself what you might want to change. After a while you may find that you don’t need to change anything at all. For more information please visit http://www.scrumstudy.com for more insights on Scrum & Agile methodologies.
Hi Martin,
My name is Meghan Robinson and I’m with an organization called Scrum Alliance, specifically representing our AgileCareers team. AgileCareers is the only job board dedicated to connecting Scrum and Agile organizations with qualified, passionate, Agile professionals.
We have just announced the launch of our new AgileCareers site and are looking for exceptional Agile and Scrum article content to post on our AgileCareers News blog (http://bit.ly/AgileCareersNews)
I would like to ask permission to highlight your “THE SCRUM MASTER AND PRODUCT OWNER AS LEADERSHIP PARTNERS” article on our blog!
This content will be exposed to thousands of agile and scrum employers and job seekers, in addition to our 450,000 Scrum Alliance members. If you’re interested, please send me an updated version of your article.
Thanks and I look forward to hearing from you soon.
-mrobinson@scrumalliance.org
Hi Meghan,
Sorry for the delay in getting back to you.
This is Rachel writing. I manage the Agile Advice site for BERTEIG. You are welcome to use the article with a link back to Agile Advice please. Thank you.
Hi Martin! Really like your article! Sometimes communication problems can make quite a confusion. In my office http://zaven.co/ we barely have this kind of problems, But I will recommend this article to my colleagues! Cheers!