In my last blog post I wrote about how the product owner facilitates good decision-making when the team faces the need to make tradeoffs. This time I want to talk about another challenging responsibility for strong product owners: protecting the development team from unhelpful distractions.

Anyone who has been reading this blog knows that perhaps my favorite image for the role of product owner is a bridge. Product owners help to connect the business users with the technology team, and the voice of the market with voice of the engineers. Regular two-way feedback across this bridge is one of the hallmarks of successful Agile software development and a key distinguishing feature that sets Agile apart from traditionally silo-oriented waterfall development (in which requirements and specifications are passed along in sequential steps that keep the programmers separated from the end users). A strong product owner keeps this bridge clear by fostering good communication and facilitating easy access for all members of the development team.

But sometimes the product owner needs to be a barrier rather than a bridge.

With its lack of emphasis on specifications documents and rigid multi-month planning, its value on flexibility and responsiveness, and its stress on the importance of short development iterations and quick feedback from users, Agile can appear chaotic in its approach and utterly porous in its planning. This can leave some people outside of the development team with the impression that all feedback and critique will be acted upon and that the team is open to spontaneous redirection whenever a new idea surfaces. And this can lead, unfortunately, to what Dilbert fans know as ‘seagull management’ in which someone outside the team flies by, poops on the team and its work, and flies off leaving the team to clean up the mess.

Good product owners – and strong software development organizations – know that Agile does not function this way. Agile uses a planning process geared toward promoting a flexible and focused response on solving identified market problems. The team and the process can be highly responsive, but Agile is not chaotic; in fact Agile emphasizes the discipline of keeping the team engaged on the most important feature or fix rather than bouncing reactively each time someone has a new opinion about what should be worked on. The self-organizing nature of the Agile development team certainly requires good fuel from the market intelligence that the product manager and product owner gather; but this is very different from allowing the random fodder of outside opinions to drive the way the team works or the things it works on.

How can an effective product owner protect the team from the distractions of responding to ‘seagulls’ in the development process? There are at least four ways that product owners can help.

1. Make sure that people throughout the organization understand what sprints are. Knowing that the Agile methodology promotes a much more nimble response to changing market intelligence than the traditional waterfall approach can help people outside of the development process feel more comfortable that new information will be incorporated into the plans for what gets built when. This in turn can head off some of the anxiety that prompts some ‘seagulls’ to fly in with their seemingly urgent requests to abruptly change focus.
2. Second, the product owner can help communicate what sprints are for. Each two-week development cycle has the twin goals of creating the next step in the process of producing and releasing working software on the one hand and planning/designing/prototyping what will be created in future sprints on the other hand. Sometimes high-priority fixes or features are identified mid-sprint that require the team to shift plans; in general however even these important items can be placed on the development backlog and given high priority for the next sprint.
3. Part of why even seemingly urgent items like fixing identified glitches often get pushed to the next sprint rather than interrupting the current one relates to the third part of how good product owners protect the development team. Effective product owners explain what constitutes legitimate fuel to feed the sprint. When the Agile process works well, sprint plans are made around market-tested ideas that have been identified by the product manager and given at least preliminary attention from the designer and coder so that the team can hit the ground running with an idea about how to solve a problem. Most ‘seagulls’ fly by with unformulated ideas, undeveloped opinions, or anecdotal information gleaned from their latest interactions with clients, prospects, or competitors. None of this provides adequately developed market intelligence to direct the work of the development team.
4. This in turn leads to the fourth way that the product owner can help protect the development team from needless distractions; she can make sure people know to funnel ideas through the sprint process. The Agile planning and prioritizing process usually does a good job at gathering and vetting potential user stories for the development team to work on; people with useful feedback can be encouraged to offer it through this process. Sometimes the simple fact of needing to provide suggestions and criticisms through an established framework will deter certain ‘seagulls’ from giving their less valuable feedback. Funneling the feedback through the planning and prioritizing process often allows the product owner and product manager to determine which ideas to reject or push off until later, which ones need further investigation to determine their market validity, and which ones should be brought into the development pipeline in the near-term or long-term. There is a great video about this process I would recommend to folks who want to learn more about it (http://www.youtube.com/watch?v=502ILHjX9EE).

When the Agile planning and prioritizing process is allowed to work as designed, the product owner can use this process to protect the team from many unhelpful distractions. At other times, the product owner can simply insert herself as a barrier rather than a bridge to the team, intercepting ‘seagulls’ before they swoop over the team and make a mess. This is a less glamorous part of the product owner role, but it goes along with helping the development team feel both focused and valued. Following the Agile framework and being willing to ‘take one for the team’ can go a long way toward protecting the team from the distracting impact of ‘seagulls’ on the development process. Of course, in truth it’s not that simple.