The Product Owner's Role in Team Building


The Product Owner's Role in Team Building


Foosball

Self-organising, self-managing teams are at the heart of Scrum. Everyone knows that. Most people are clear that, as an agile coach, the Scrum Master bears the main responsibility for growing the team.

Less understood is the idea that everyone in a Scrum team has a role in team building if it is to be successful. Geoff Watts has written about how collaborative behaviour is a skill that has to be acquired individually by members of the development team.

But what about the product owner—what can she contribute?

Let’s segue into the world of team sports for clues to an answer. Jose Mourinho is possibly the most successful club coach currently in world soccer.

He has been a head coach since only 2002, and has spent two of the intervening years on gardening leave, yet his teams have already won an astonishing 24 titles in four different countries: Portugal, England, Italy and Spain. He has coached two sides, Porto and Inter Milan, to be European Champions.

What is it that he knows about team building that we don’t?

Mourinho has famously said that a group of individuals is just that, and they only become a team when they are “seduced by a common objective.” He not only identifies the trophies the team should target for the season and sets objectives for each and every game, but also for every single training session.

His record suggests he’s on to something. But the operative word in the phrase quoted above is “seduced.” In other words, the group has to take ownership of the objectives themselves, and commit to helping one another deliver them.

Moving back to Scrum, it is the product owner who sets targets and identifies objectives. She upholds the vision of the product for the business. She will probably map out release goals on a product roadmap that she maintains.

She will typically open a sprint planning meeting by pointing to the value expected at the end of the upcoming sprint, and will agree on a sprint goal with the development team before the meeting has finished.

Setting goals is one thing; however, convincing everyone that they are the right goals is something else. This is where the team building aspect kicks in. It requires intensive collaboration with customers and stakeholders on the one hand, and with the development team on the other.

An engaged product owner is, in my experience, a minimum requirement for building successful teams.

Scrum Masters can help product owners by coaching them on the responsibility not only for “what” work needs to be done (by ordering the product backlog appropriately), but also “why” it needs to be done.

The more a development team understands the rationale behind an objective, whether at product, release or sprint level, the more likely they are to deliver on the “how.”

Let’s take the sprint goal, for example. It is often narrowly translated as the set of product backlog Items (PBIs) or stories that the team pulls into the sprint. Great product owners will try and get the team excited about the sprint’s value proposition before asking it to forecast how much work it can take on, and choose the PBIs from the top of the backlog that best fulfil that idea.

The sprint goal can be agreed as a name for the state the product is expected to be in at the end of the iteration, or, alternatively, as a short statement describing the value it brings to the customer. These are not the only two forms the sprint goal can take, but they are probably the most common.

I personally like to post the sprint goal somewhere on the Scrum task board as a permanent reminder to the development team of what they are currently trying to achieve.

There are a couple of advantages to separating the sprint goal out from the team’s forecast in terms of PBIs. First, it allows the product owner to report the target to customers and stakeholders in business terms they can understand.

Secondly, and more importantly, it gives the development team a reference point – a compass if you will – which can frame any decisions they might have to make in adjusting the sprint backlog in the face of unforeseen circumstances.

It also gives them some wriggle room; if they find they have overcommitted in terms of their forecast, they can discuss how to de-scope by choosing the PBI with the least impact on the overall sprint goal. Teams build their cohesion and their agile fluency through making such decisions.

Soccer coaches often talk about their role ending once the team has crossed the white line onto the pitch. Once the game starts, the team has to make collective decisions about how to defend and how to attack as the opposition’s game plan unfolds.

A development team’s ability to act autonomously also rests on the preparation that takes place before the sprint starts. The product owner’s role in that preparation should not be underestimated.



 

Alan O’Callaghan is principal product owner at Emerald Hill Limited, a U.K.-based agile and Scrum consultancy he founded in 2008.

Learn More
comments powered by Disqus