If I took my car into the garage to have a cam belt changed (note to self, must schedule that in) I wouldn’t consider standing around telling a mechanic which tools he should be using or how to go about removing each bolt. He is the expert, and already knows the best approach to take. So why do so many product owners/managers fall into this trap where they dictate to their development team how something should be done?
I work with a great development team who I regard as the people best placed to solve a problem. I’d like to think that as a product owner, I don’t prescribe exactly how something should be done. I think some of this comes from having a development background myself and not particularly enjoying being told how to do my job in the past, whilst someone stands over me.
Telling developers what to do doesn’t allow for much (or any) discussion to take place. Overall, the team won’t understand or appreciate the reason or goal behind what they are being told what to do. This scenario in my opinion, results in a team who won’t respect you and will not trust your decision making. Later on, you’ll be told that things will take longer as you were not clear with what you said you wanted. Does any of that sound familiar?
From my experience, there are several approaches to improve this situation but there are three things you should consider trying to form the basis for a healthy team.
Create a shared vision
You need to be confident in what you are building and more importantly WHY! If you don’t know why you are building something then you need to get that straight very quickly. When you know why you are building something you need to make that clear. Everyone will have their own world view and understanding and you need to align that throughout the team.
This doesn’t have to be overly complicated and I would recommend using the Agile Inception Deck to help you out with this. When you’ve completed it. Print it out, and stick it to a wall so the team see it daily. Refer back to it regularly.
If nobody is aware of the vision you will fail sooner or later.
Deriving scope from goals
From your vision, it should now be clear to everyone what the goals are. Whether it’s to increase newsletter sign up conversions or increase revenue by x % thankfully your team now knows this. What you are building should be attributed to a goal – otherwise it isn’t worth doing! Reassessing what you are building needs to happen frequently. Not just at say, sprint planning but throughout your sprint. Continuously. This allows you to really question whether adding the bells and whistles is something worth doing.
Recently I began reading the book “Specification by Example” written by Gojko Adzic which came highly recommended from my colleague Darren Taylor, who knows a lot about this stuff. Here is a worthy snippet that details this much better than I can:
Many teams expect a customer, a product owner or a business user to come up with the scope of work before the implementation starts. Everything before that is often not considered as a problem in the domain of a software development team. Software delivery teams expect business users to specify exactly what they want, and then the teams will go and implement that. This is supposedly how the customers will be happy. In fact, this is where the issues with building the right product start.
Implementation scope represents a solution to a business problem or a way to reach a business goal. By relying on customers to give us a list of user stories, use cases or anything like that, we in effect ask them to design a solution. Business users are not software designers. If they define scope, the project does not benefit from the knowledge of the people in the delivery team. This often results in software that does what the customer asked for, but does not deliver what they really wanted, or is functionally incomplete.
Instead of requirements that are already a solution for an unknown problem, really successful teams Derive Scope from Goals. They start with a business goal that the customer wants to achieve. They collaboratively define the scope that achieves that business goal, starting from the desired business effect. They allow the team to come up with a good solution together with the business users. The business users focus on communicating the intent of the desired feature, the value that they expect to get out of it. This helps everyone understand what is needed. The team can then suggest a solution that is cheaper, faster, easier to deliver or maintain than what the business users would come up with on their own.
A good working environment
Don’t be a control freak! That won’t get you any bonus points with the team; and trying to control everything will simply make you stressed out and useless. Your job as a Product Owner/Manager isn’t to control and rubber-stamp everything, it is simply to ensure that everyone heads in the the right direction and you deliver things that meet your goals.
Discuss how you will tackle your goals entirely as a team. Make everyone feel involved. You are working on the product as a team (you are still entirely responsible by the way), but you should start to see that members of the team are more motivated and helpful through being involved. They will suggest solutions that you would never have even dreamt of (and are guaranteed to be the better option).
By making the team involved from beginning to end they will care more about what they are delivering as a whole. They will go that extra mile because it’s better for the product. Where as before, why should they bother? Anything they did would only end up making you look good to upper management.
When you make it clear that you value everybody’s opinion on how to reach a goal you can have an open discussions. Of course, you will have to act as the filter sometimes and suggest that things make not be in line with the goals but it’s better to allow everyone to be heard rather than being scared to voice their ideas at all.
You’re working with the same people day in, day out so it’s a good idea to try and get along. Be open and honest (whilst being diplomatic). Try and have fun too by the way! Just don’t forget to keep everyone moving in the same direction.
Of course there will be non-believers, but hang in there. This isn’t something that you can change overnight. It will take time. But as long as you are consistent they should come around.