Last year I had the privilege of being part of an awesome team. In previous years I have mostly been on the facilitating side. Making the switch to being a team member again was educational. It was fun to apply the knowledge I gained over the years about team dynamics. Yet, experiencing what it is to be on a team, what struggles you face and how hard it is to implement this knowledge was even more interesting.
Though, for me, the most interesting thing was how we were up and running in no time. A single person who knew none of us before the project, handpicked us. All he had to go on were individual interviews. This resulted in a team of people acquainted in varying degrees, ranging from friends to hardly-ever-talked-to-that-person-before colleagues. I expected this team to take a long time to become productive. Nothing could be further from the truth. After about a month, we took off. Afterwards, we analyzed what made us so successful and allowed us to make such a big impact in such a short time. There wasn’t just one reason that explains how we managed this. But one reason surfaced pretty quickly, and we all agreed: we started off in the right way.
When we started, we didn’t have a product owner. We didn’t even have a clear assignment. At first this felt crippling. But as soon as we realized part of our assignment was to figure out the assignment and scope it, we took responsibility for our outcome. Because we lacked a product owner, we took ownership of the problem, like it was our own.
How we did that? Without us realizing then, we followed Simon Sinek’s advice. We worked our way through his Golden Circle and started with Why. Before we did anything, we asked each other:“Why are we here? Why are we put together? What is our purpose?”. In the first weeks of our project we did nothing else except discussing this. Within our team, but also with our stakeholder. We wrote lengthy documents, described all the problems we noticed, and the opportunities we saw. And we shared it with our stakeholders. Based on the feedback we got we refined it. We kept doing this until there was nothing more left than a single sentence. A sentence everyone of us agreed upon.
Although the process took a rather long time, and it sometimes felt wasteful, I’m convinced it set us up for success. From the moment we settled on our Why, and after that our How, we checked everything we did against these sentences. If we thought it didn’t contribute to our purpose, we didn’t do it. We kept doing that, even until the last weeks of our project. Not only did this approach help us separate the valuable and invaluable tasks from each other. It also helped us explain our project to stakeholders and others effected by it.
Luckily, many projects start off better than ours. Those have a product owner. One who is the expert on the problem to solve. The person who takes it upon him- or herself to make sure scope, vision and requirements are crystal clear before a project even reaches the team. This is also what most people expect of a product owner. To have a vision on what it is he or she wants and to convey this to the team. Preferably, this vision is accompanied with a product backlog that makes it even more specific what needs to happen.
I agree that it is up to the product owner to take responsibility for a clear vision and to make sure someone manages the product backlog. I disagree with the set in stone project definition that typically comes with it. Some years ago Google researched what it takes for a team to be high performing. One key dynamic was:“Impact of work”. By just telling a team what is expected and what it is they need to do, won’t help people realize the urgency and importance of their work. As a result, they won’t take full ownership or responsibility for outcomes.
That’s why I argue that the product owner’s first obligation is to make sure a team understands the Why of a project. Not by showing them the vision and presenting the backlog. The best way to create this understanding is by jointly creating it. Remember the saying? “I hear, and I forget. I see, and I remember. I do, and I understand.” The team needs to understand and agree on the Why before it can take the next step: word the How. These two steps are essential steps for teams to understand what success looks like and reason about actions to achieve it. The product backlog is a derivative of these two; a list of items that will contribute to them. If a team completely understands its Why and How, the backlog might not even have to be built by a product owner anymore because teams can create their battle plans themselves.
When a team truly understands why they are put together and how their success looks like, they can take ownership of their project. They will act as a sparring partner for the product owner, leading to better results. Not only this, they will have an increased sense of purpose.
I challenge you, for your next project, take a step back and start with Why. If you did, please share how it worked out for you in the comments.
If you want to know how we managed our backlogs in this project, have a look at my previous article about Results Driven Backlogs
