Groucho Marx once famously observed that outside of a dog a book is a man’s best friend while inside of a dog it’s too dark to read.  We could use a similar analogy to talk about Agile planning and say that good planning does not happen in a vacuum because either it’s too dark, cramped, and dusty to plan in there if you’re thinking of this vacuum http://bit.ly/1mNOBPK or else it’s incredibly hard to breathe if you’re thinking of this vacuum http://bit.ly/1jqJBRS.  And neither is a good place for planning.

Effective and realistic Agile planning does not happen in a vacuum isolated from any other influences beyond the development team itself.  This is true not just externally – where good planning leans heavily on market intelligence and strategic insight about product direction – but also internally.  Plans for the development of one product may intersect with plans for another product built on the same underlying architecture.  Plans in the mind of the product manager may conflict with ideas that the design team envisions for the coming months, and these plans may in turn conflict with areas that the development team feels need attention.  As I continue writing about Agile planning, it is important to recognize the context in which this planning occurs.  Several of the past few posts have focused on the external context as I’ve discussed the need for solid market intelligence and holistic strategic goals.  Here I want to share some thoughts about the internal context for Agile planning, and to talk specifically about what happens when different plans collide.

First let me share briefly about the organizational context in which I serve as a product owner.  We are developing several different products targeted at specific market segments with overlapping but slightly different needs.  We also have a large group of internal users of our products who rely on them to empower the advisory and consulting work we offer.  These web-based products rest upon the same database and architecture and are increasingly accessed via a web face that is coalescing around common design themes.  Some of our clients use only one of our products while others integrate several in their workflow, making a unified user experience across these products important.  And all of this software development has accelerated in the past couple of years as we aggressively expand into new market opportunities even as we collectively figure out the best ways to apply Agile methodologies to our development efforts.

While in general we work well together across our different development and consulting teams, there are definitely times when our plans collide rather than coincide.  Two teams may have different perspectives on the best way to redesign parts of our website (while the designers themselves may have yet a third view in mind).  Two product teams may have conflicting views on when certain functionality should be prioritized for development or on the shape of new features that will be used across our client base even if they are first developed by a single team.  Product managers may want to enhance existing features or add new ones while development leads and testers may stress the importance of refactoring existing code to eliminate costly technical debt to make automated test coverage more comprehensive.

In theory these conflicts could be resolved by appeals to power or expertise: the ‘most senior’ person could insist on getting her way or the ‘expert’ in a certain area could mandate that everyone follow her opinions.  But in an Agile environment that values open communication and collaboration across self-organizing and empowered teams we strive to find a better way to navigate the inevitable collisions that occur across our team plans (more on this in my next blog post).  And in this navigation product owners can play a vital role.

I have written before about the image of a product owner as the bridge connecting different people involved in the development process (you can check out some of my earliest thoughts on this here if you’d like: http://wp.me/p2BePD-r).  Hopefully without egregiously overtaxing this metaphor, the product owner serves as a multi-pronged bridge spanning the gaps potentially separating coders, testers, designers, product managers, and even distinct product teams so that all of the relevant stakeholders can engage in the set of conversations required to avoid or work through these collisions.  (And if the idea of a multi-pronged bridge goes too far, maybe view this as a web of interconnections with the product owner as the web-slinger – and who wouldn’t want to do that: http://bit.ly/1krM0Hm).  In a context with several inter-related products the team of product owners collectively plays a strategically important role ensuring that the relevant factors are given appropriate weighting in deciding how to navigate potential conflicts both within and across teams.  Strong product owners do this in at least four key ways which I will comment on briefly below recognizing that each one could be a separate blog entry on its own.

1. Facilitating communication. A focus on communication is of course crucial in the light documentation environment of Agile development, but it becomes especially crucial when potential collisions arise.  Regular formal and informal settings for communication among the product owner team members allow them to spot potential conflicts as they emerge and sometimes avoid them through fostering the right discussions ahead of time.  Once actual conflicts within or across teams surface regarding priorities or development direction product owners can facilitate conversations involving the relevant people who can work out a solution soon after the issue becomes apparent.
2. Articulating trade-offs. In their roles working with the team to move product development forward, product owners are often in a position both to recognize and to explain the potential trade-offs involved in pursuing one path over another.  The ability to help all parties involved in potential conflicts to grasp these trade-offs can allow the team to decide more objectively how to proceed when two ideas or teams are headed on a collision course.
3. Recognizing opportunities for leverage or cross-product benefits. Because they see across products in the portfolio and because they have perspective on the product roadmap I talked about in my last blog post, product owners can also be uniquely well positioned to recognize opportunities for one team to leverage the efforts of another to enhance both product lines.  Teams might rearrange items on their backlog to tackle larger problems together or determine that both teams need to redesign one aspect of the product workflow to benefit both teams in their ultimate goals.  Regular conversations across the product owner team help to bring such opportunities to light, allowing the development teams to capitalize on opportunities to leverage both new development and refactoring efforts for greater mutual benefit.  This type of collective ‘backlog mining’ can of course benefit from the insights of folks beyond the product owner team as well, as the wider set of people focused on product development corporately find the best path forward for the entire product portfolio.
4. Taking a dispassionate perspective that helps the entire team weigh the relative merits of competing plans. In addition to facilitating communication, articulating trade-offs, and recognizing leverage opportunities, strong product owners can also help the teams navigate potential collisions by offering a wider perspective.  Product managers focus on understanding and solving the persistent market problems of their target market, while developers and designers concentrate on the specific strengths of their respective disciplines.  Good product owners, with their emphasis on building the best products in the best ways, are able to bring a larger focus on the process itself.  The best Agile product owners are passionate about the way the team collaborates to develop the best product or set of products, allowing product owners to help the set of stakeholders weigh the relative merits of conflicting plans and determine the optimal path forward.

Strong product owners can offer a unique viewpoint when worlds collide.  Having (hopefully) strong relationships with one another and across the product management, architecture, design, and development teams, good product owners can help the organization navigate these potential collisions and reach strategically beneficial conclusions that strengthen the company’s entire product portfolio.  Of course, product owners are by no means the only members of a strong Agile team who can help with this navigation (that would be too simple).  In the interdependent web of architects, coders, testers, designers, product managers, and product owners, all members need to prioritize communication and a willingness to make trade-offs that benefit the entire company.  Even as product owners look across projects to recognize opportunities for leverage they must also expect to learn about these opportunities from other team members who can see potentials for conflict or convergence related to design, database, architecture, and codebase areas that product owners might not be aware of (which is a great reason to encourage regular team meetings of designers, architects, testers and others just as there ought to be regular team meetings of product owners).  While there are particular ways that product owners can facilitate this cross-team collaboration, they are by no means the only ones seeking to successfully navigate through potential conflicts.

Finding or making a way through possible collisions is a vital role in Agile product planning for growing organizations with an inter-related set of products.  The ability to serve as a bridge or facilitate a web among the many relevant stakeholders can make a crucial difference in the successful evolution of a product and the growth of the entire team involved in this development.  Fostering the kind of communication and collaboration necessary for the various self-organizing development teams to all move the product portfolio forward coherently is a challenge for product owners, but success in this endeavour is vital for both good Agile planning and strong product development.  Nurturing this strong web of relationships of course won’t allow the team to avoid conflicts altogether because in truth it’s not that simple.