Call it client, call it product owner, call it product manager, call it functional designer or business analyst, however you want, if this is the guy that gives you the requirements and must accept your work, then this is the MOST important guy in the game.
I used to think that if the team is doing a great job and if the scrum master is doing a great job then all things will be good in the end with more or less struggle. The product will be out there alive and kicking and we will all be happy. But reality kind of stroke me recently: the product will not be out there smoothly if the product owner is not happy. You might have done the greatest software, in time and with a happy team, only to find out in the final acceptance when the product owner is actually testing that he is not quite happy about the result and you did not think of many things he also did not think of, but he was expecting you to think of. You will now say: why is he doing acceptance in the end of the project? And I will reply: because it is only a 1 month project and there were weekly sneak previews and demo on a local machine, but due to the client’s environment there is a final UAT in their environment only at the end of the sprint … And now you will ask: why didn’t they know all that he was expecting? And I will answer: because they did not invest enough time in finding out what he knows and what he does not know about the system and how it works.
Now, the above being answered you will get to my conclusion: did the scrum master really do a good job? (isn’t his role also to understand what makes the product owner happy?) And I can answer to this too because the scrum master is a very close friend of mine. 😉
When the sprint starts and you have a list of user stories you go to grooming, you discuss them, all is clear, acceptance criteria is in there, planning goes smoothly, so for the next sprint the focus of the scrum master is on getting the work done according to the specification. The scrum master will look at development and testing issues, at the speed of the team, at removing all problems, generally making it faster and better. So: the focus is from the beginning on the team!
What about the product owner? The product owner stays with the team during the grooming and then steps away to intervene when there are questions from the team and to participate to the demo. Shouldn’t the scrum master establish a relation prior to the start of the project, find out what the product owner expects from everybody and if he cannot answer ask as many questions as possible? Also work on this relation for the entire life of the project? So, here is where I think this scrum master fucked up the game: 1 month long projects and building relations do not work together if you do not actively think about the fact that they must be made to work together.
All our projects mean relations built in time, expectations raised and lowered in time, lessons learned in time, adaptation to the environment in time. Learning why you fail and how to succeed further takes time. If you do not have the time then you need to prepare, you need to gather all the possible information there is about the environment surrounding the project, all the information anybody has regarding to the product owner, his knowledge and his way of working.
Why? Because in time the scrum game gets under your skin and you know what to look for and how to do it. Understanding the product owner and adapting the approach to him is something that changes with every project and when you are stuck in the same project for a long time this is not under your skin, so you need time to learn how to fail and succeed in this new relation.
I keep discussing with my boss ( she hates being called this, but i like it 😉 ) how important is the stakeholder management and we both agree it is critical! I understand the why, but sometimes I fail to find the how.
With the product owner the first step of the how is understand him, what are his problems and his needs. Leave behind the requirements, understand him as a person and then try to see how this will change your approach to the project. Do not skip this, no matter how short or long the project is!