in Scrum for Beginners

How to Deal With the Product Owner Coming from Waterfall Background?

How to Deal With Product Owner Coming from Waterfall Background?

Last week, I got this question from one of my ex-colleagues, Victor.

Victor is a ScrumMaster of a newly formed Scrum team. They were on their 3rd sprint. Their sprint length was 3 weeks.

Victor described me his situation:

  • The Product Owner, who happens to be the Product Manager as well, was coming from waterfall background.
  • The Product Owner was senior to all the team members.
  • The fear was that because of the Product Owner’s background in traditional methods, the team would be giving ‘Status Updates’ instead of inspecting and adapting.
  • The Product Owner was open to Scrum, but he seemed to have a lot of baggage of his own accomplishments in other practices though Victor hadn’t experienced it personally.

“I was taught that there is no point of Scrum if each team members don’t self-organize and don’t inspect and adapt – how do I deal with this situation?” Victor asked.

My answer:

No matter the background, no matter the title, the Product Owner is a part of the Scrum team and acts as a team member.

If each team member gives best of her efforts with 100% of ownership of the tasks she owns up, probability of product success, or early failure to learn from and iterate, increases.

Now, if the Product Owner is open to Scrum, then he’d appreciate himself playing the role of the Product Owner and not just playing the conventional Product Manager.

So as the ScrumMaster, you talk to him and inspire him to play that role. If the Product Owner is not playing the Product Owner role – then this is an impediment that needs to be resolved and you need to own that part no matter if he is senior to you or not.

ScrumMaster does not lead any formal authority to resolve the impediments.

Now if I look at your particular case, there is no mention of him not playing the Product Owner role. It might just your perception that because he is so senior you will end up giving status updates and won’t self-organize.

Play your role regardless of who is who in the team. Self-organize. Talk to the Product Owner. Organize a dinner or a tea-party with the whole team. Break the barrier of your perception.

Understand and let every team member understand why you have opted for Scrum.

Is it beneficial to the organization?

Sure.

Is it beneficial to you personally?

Absolutely.

When you just don’t do Scrum but live it, you grow as an individual. You grow because of a simple reason – you unconditionally own up the battle that you have picked. You don’t blame others. You self-organize and lead yourself to get shit done.

Good things come to people who get shit done. When the shit is done, all what remains is good, isn’t it?

Conclusion:
More often than not, new Scrum team members get carried away about their perceptions rather than what are the facts. Instead of thinking about titles and seniority and all such mumbo-jumbo, focus on playing your role and get better at it.

Will you do everything right the first time?

No.

Will you commit mistakes?

Yes. For sure.

Learn from Your Mistakes and make your product, your organization, and your life better.

  • Devang Tank

    Nice one 🙂

    • Thanks Devang – The point is, it is never who’s who, it’s what we do 🙂

  • Often someone has to translate Agile and Scrum to Waterfall stakeholders on many levels. Mutual inspiration, and iteration will serve the team well. Hang in there.

    • Thanks Allan for sharing your views. Mutual inspiration is the keyword. Cannot agree more.

  • Parthiv Kansara

    The other way around is to ensure the Product Owner (from Waterfall background) how he would be able to get the desired information (status update in Waterfall) which enables to do his part of the job. Here mainly, when there are multiple roles being played, everyone would think about doing his/her part of job perfectly. In order to achieve maximum, the Scrum Master has a responsibility to explain the Scrum Team, how they would be able to do their part of the job with utmost precision utilizing Scrum/Agile. It’s more about providing that clarity at the beginning when the Scrum Team is being formed so that after few Sprints, this kind of situations does not arise. When you already know that PO is coming from a Waterfall background, you should always double check for these un-clarities at the start, as a Scrum Master to ensure smooth sailing. Correct me, if I am going wrong anywhere.