Top Seven Excuses from Product Owner Not To give you what you need
Today's post is going to be from both technical and soft skills areas of the skills that effective Scrum Master needs to have. Using Scrum involves close cooperation between so called Business and IT. and you need things from the business. It can be more resources, requirements, good User Stories, Product Backlog to be ready for next iterations or just simple yes/no answers. On some projects you will meet Product Owner that doesn't want to cooperate, doesn't know about Scrum and Agile or just doesn't want to take any responsibility. Talking to Product Owner, Project Manager or other business representative that is trying to push the issues away from her/him, you will eventually face one of the typical patterns to get rid of you and your "annoying" questions. Below I give you the most popular answers and ways of dealing with them.
The context I have heard that phrase the most was rules of the Scrum framework. There was a time that we couldn't feet User Story because of the Team's capacity. And then you hear "Can't you be more creative?" and following questions: "Why can't we have longer Sprint this time?", "Do wee need all this meetings?", "Can we test it later?". Of course Scrum Master needs to explain why you can not break the rules of the framework you decided to use, but despite that these questions will pop up again. Just be alert, don;t run into discussions about personal opinion and refer to knowledge sources like Scrum Guide, books and training materials.
Very similar idea to the previous one. Can't be creative, be pragmatic :) If you don't have software, don't have enough people, don't have requirements, you can be prepared to hear "Can't you be pragmatic here?". You can easily defend against that saying that using software development which requires User Stories gathered from customers and a team of skilled people to implement it in 4 weeks is the most pragmatic approach that you can imagine. You can also ask which part of the process is not pragmatic for the person asking that question. "Be pragmatic" way looking at the project means also, that this person doesn't really want to change anything in the process or organization.
That's my favourite. It can be in form of a question Aren't we agile? or in form of sarcastic remark Oh, I thought that we are agile.. That shows that the person saying that doesn't want to follow any rules, use cowboy coding ans call it agile. Usually it goes together with keeping all old methods and turning into Agile over night. In that sense Agile is meant as flexible and flexible means be stretchy like a bubble gum. The only way of approaching that way of thinking is explaining again and again what does using Agile development methods mean and that there is not much agile in Agile. There are rules, roles and timeboxes that need to be there for a reason.
Yep, poor Scrum Master or Agile Coach working in environment using one of the three, mentioned so far excuses.
We Don't Live in a Perfect World
Here is the first of excuses pushing the responsibility outside. In this case the only to blame for issues on your project would be the God or any other creator of the world that you believe at. I guess, that you can't talk to her/him, so there is nothing you can do.
The line of defence here is saying completely opposite and getting responsibility to the place and person that should have it. The answer you can give is as follows. "We do live in a perfect world, the world that human intelligence could have created and be happy in. We can not leave in ideal world and that's what meant by this statement. But leaving in and ideal world is not possible and would have been boring anyhow, right? So, in the world that we live in now, you are responsible for this project and [...], so please give it to me."
We Are In the Same Boat
When you translate it that means "I also have similar issues and if nobody is helping me why should I help you". It should make you feel compassion for that person and you should feel ashamed to attack your mate. The way of neutralizing is showing compassion and still asking for what you need to do your job well by using "I understand and ...". Another method is to go for this boat metaphor and using it for disadvantage of that person. "Yep, and the boat is sinking". "Correct, but nobody is steering the boat", "Yes, and the boat is going to crash on rocks soon". That usually brings attention to the issues you are trying to solve.
What Exactly? Could You be More Precise?
Asking for more details has a purpose of buying time or proving that you don't know what you are talking about. One way is to turn it into another question and get the other person to admit what is the real reason: "It's exactly what I told you. Which part don't you understand?" or you can give very low technical details. One way or another your business will be avoiding bogus, time buying questions in the future.
It's not About Money
This is the simplest one. It means "It is about money and you won't get any.". Not much to do here. You can only keep on asking questions about budget and escalate issues with found to higher management.
Never stretch, bend or break rules within your framework, processes or company rules. The very moment you do that, you will loose your authority and handle another useful argument against you: "But you did that previously".
I hope that you will find my tips useful and let me know how it went and what are other excuses that you hear often on your project.