So who decides when someone has to?

In my previous (long) post I talked about navigating potential conflicts that can emerge in Agile planning when a company has an inter-related set of products.  I suggested that product owners have a valuable role to play in navigating these collisions by facilitating communication, articulating trade-offs, recognizing leverage opportunities, and offering a wider perspective.  I also made clear that responsibility for each of these four areas must be embraced by all members of the development teams including designers, architects, coders, testers, and product managers.  I further made the (bold? naive?) statement that in an Agile environment that values open communication and collaboration across self-organizing and empowered teams everyone involved strives to navigate the inevitable collisions that occur across team plans without appealing to position, power, or expertise as trump cards to force compliance.  This all sounds nice in theory, but how do such ideals stack up against the real world of product development?

Here I must admit that my answer to this is partly shaped by my good fortune in being part of an organization that values striving for ideals.  Founded on principles and consciously pursuing multiple bottom lines, the company in which I currently serve as a product owner challenges every employee to be the best versions of ourselves and to seek the best ways to face and resolve conflicts within and across teams.  In a company where we seek to recruit, hire, and retain people based on character and values as well as skill sets we can both expect a higher level of adherence to the ideals I upheld in my last post and legitimately hold people accountable for doing so.  We certainly aren’t perfect, but we may have a higher than average willingness to seek ideal solutions in our honest pursuit of our goal to make a difference and not just a profit.

Of course, in truth it’s not simple.  We don’t always act or think in accordance with our stated ideals, and even when we do we still have different perspectives and sometimes conflicting agendas.  As each product team also has to be conscious of its own bottom line and not simply what might seem best for the company as a whole, there can be an understandable element of game theory that emerges around product decisions.  If one team builds a new feature first then that team will likely bear the higher cost (both financially and in terms of development time) and so it might be ‘cheaper’ to leverage someone else’s development than to collaborate and share the costs together.  If cross-team projects can be broken into their own separate development ‘threads’ with separate resources then the normal product teams can get more done by keeping ‘their’ developers working on ‘their’ priorities while a separate team of developers can be assigned to some cross-team projects.  And since every team worries about controlling its expenses all teams can fall into arguments about the proper ways to allocate the costs associated with projects that benefit multiple teams or the company as a whole based on how much they ‘wanted’ these projects or when they would have prioritized them on their own.  In spite of our shared base of common ideals we have yet to find an easy way to sort through these complexities and continue to search for the best approach to resolving the conflicts that arise from them.

While it doesn’t solve all of these difficulties, perhaps a metaphor might shed some light on one good way to frame the issues.  As usual, I will probably stretch this metaphor close to its breaking point so please bear with me.

In an orchestra each member and each section seeks to do its best both to play its own parts and to harmonize with the whole.  In an orchestra each person seeks to be the best she can be in full collaboration with other members and in overall pursuit of the music itself.  Each recognizes the valuable contributions that others can make and knows that the most beautiful music comes not from dominating others but from playing well together.  While at some times and in some pieces certain parts of the orchestra might gain more prominence, all together know that their unifying goal is to thrill the overall client base and keep them coming back (and paying) for more.

Agile principles and corporate strategy set the music we strive toward as we look to build the best products we can in the best ways to fulfill our purposes and achieve our multiple bottom lines.  Product owners, product managers, coders, testers, designers, architects, DBAs – all strive both to be the best they can at their roles and to collaborate effectively.  Working in concert with each other and our principles puts our potential conflicts into a broader context and motivates us collectively to pursue the best experience for our clients consistent with serving them sustainably and profitably.  Thinking along these lines certainly won’t eliminate conflicts, but it creates the right mindset for navigating them when they arise.

The context for working things out when well-meaning people pursuing the same overarching goals have different perspectives on the best way forward involves some forum for mutual conversation and decision making (think of this forum as the conductor of the orchestra if that doesn’t stretch the metaphor too far).  Some team of people meeting regularly to assess overall product strategy and help assess if each team is making wise choices can keep the entire product organization abreast of best practices.  A cohort of product managers and product owners must surely be a key part of that decision making team when clarity about the best path forward does not emerge organically from the teams themselves.  However such a group would likely also benefit from the valuable contributions of design, development, and architecture leads as well whose technical knowledge and development wisdom could offer helpful perspective in crafting product portfolio priorities.  Ideally – and in my experience this ideal is realized more often than you might expect – decisions about product direction rarely need the intervention of such a group; instead their regular discussions serve to foster a broadly collaborative environment in which solutions to potential conflicts emerge from those most directly involved and impacted.  But knowing that such a team can be appealed to when necessary provides helpful boundaries for resolving conflicts because in truth it’s not that simple.

When worlds collide

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.

Summary on my next two posts

It has been a little while since I’ve been in a good rhythm with my blogging but I am trying to get to one now.  I want to work through the remaining posts in the current arc about Agile planning.  Believe it or not I work hard to keep my blog posts concise.  I think a lot about product development and have many ideas I am eager to share, but I try to keep each individual post relatively short and focused.

My next post has grown beyond that.  As I tried to summarize my thoughts on how to handle some of the conflicts that can emerge around Agile planning I found I had too much to say to write a brief post.  I looked for ways to break it into smaller chunks but could not come up with a coherent way to separate the ideas I wanted to express.  So unfortunately my next entry is going to be a bit long, and there are a couple of lingering issues that I will put into a separate post beyond that one.

For those tempted to dismiss the next entry with a TL; DR (that is, too long; didn’t read) I give you the highlights here.  Hopefully this whets your appetite for digesting the full post later.  Thanks.

When conflicts emerge in the planning for the development of inter-related products there are four keys to navigating these conflicts successfully:

  1. Facilitating communication
  2. Articulating trade-offs
  3. Recognizing opportunities for leverage or cross-product benefits
  4. Taking a dispassionate perspective that helps the entire team weigh the relative merits of competing plans

Good product owners can help with these, but of course, in truth it’s not that simple.

Meditations

The second book I want to share brief thoughts on here (the one I referenced in my earlier post on Wolfe’s A Man in Full) is a modern translation of The Emperor’s Handbook by Marcus Aurelius.  Translated by David V. Hicks and his brother C. Scot Hicks, this modernized version of the meditations of a Roman emperor and general is something I’ve been tweeting about for months as I slowly read through it.  If you follow me on Twitter (@asbiv) or if you read my blog post about this book back in January (http://wp.me/p2BePD-2X) you know that I have found Marcus Aurelius’ thoughts on life, suffering, character, and purpose interesting even when I disagreed with him.  I have also really enjoyed the pithy and modernized language that the Hicks brothers use in their translation; it makes this book of Stoic philosophy easily approachable for contemporary readers.  And as I mentioned in the other book review I recently wrote, I was delighted to see how intertwined some of the themes in The Emperor’s Handbook were with those of Thomas Wolfe’s novel A Man in Full – though perhaps I would not have been surprised if I had remembered that both books were on the same list of recommended books found here (http://blogs.hbr.org/2012/10/11-books-every-young-leader-mu/) and that I blogged about here (http://wp.me/p2BePD-W).

There are of course some keys areas on which I differ from Aurelius in looking at life.  I don’t believe in Zeus or the other gods he references (although the fact that he uses Zeus, God, the gods, and Providence almost interchangeably may suggest that Aurelius also didn’t take these deities too literally).  I think pain, disappointment, heart-ache, and suffering are real and not simply a matter of an inaccurate perspective on the world and our experience of it that we can change at will.  Beyond this I fundamentally disagree with the inherent dualism in Marcus Aurelius’ worldview – the notion that the mind is true and eternal while the flesh and all physical existence is fleeting, unsubstantial, unimportant, and ultimately something to be denied and risen above.  My own view is that life must be understood as it is experienced: as holistic and corporeal beings whose bodies are just as much a part of us as our hearts and minds.  We cannot ‘rise above’ our bodies and the physical aspects of life because we are our bodies and we live as physical and spiritual persons in a world with real substance.

In spite of this significant philosophical disagreement with Aurelius and the wider Stoic perspective, I still found this book encouraging, interesting, and thought-provoking.  As I read this book I regularly tweeted quotes from it, mostly about the simple joys of being alive, our ability to choose virtue and wisdom even in the face of hardship, and the importance of keeping our own brief lives and pains in wider perspective.  I like the idea that no matter what we go through in life we have a fundamental ability to choose how we respond and that with those choices we can display our true character even when confronted by oppression or suffering.  I appreciated Aurelius’ repeated declarations that life is short and we are far less important than we tend to think of ourselves; this attitude reminds me to be humble and to take myself and my concerns less seriously.  And I resonated with his assertion that we should never allow other people and our desire to please them to control our lives or diminish our goals.  Plus I found many of his ancient observations both relevant and humorous in our post-modern context.

So while I cannot embrace everything from The Emperor’s Handbook I did truly enjoy the meditations on life, leadership, and character that Marcus Aurelius offered in his writing.  He didn’t make me a Stoic, but he did remind me to take myself and my problems less seriously, to remain true to my character in the face of both suffering and flattery, and to strive for a virtuous life no matter what obstacles I encounter.  Like most books I read (or movies I watch) I found elements I liked as well as those I disagreed with, but that should come as no surprise because in truth it’s not that simple.

A Man in Full

I mentioned in a recent update that I wanted to add another page to my blog where I can put in brief reviews of some books that I’ve been reading.  Two books I’ll be writing about soon that relate closely to the work I do are Grow by Jim Stengel (about how ideals power growth and profit for thriving companies) and Winning the Story Wars by Jonah Sachs (about the power of compelling stories in corporate marketing).  But before I get to those I want to write about two other books that tie well together; one is a modern novel by an author with several books that have been adapted into movies and the other is an ancient book from a Roman emperor and philosopher.  I had no idea these two books connected so well when I started reading them both earlier this year; but now that I have finished both I wanted to share some thoughts about them.  I’ll write below about the novel and in my next post talk about the philosophical work.

The novel is called A Man in Full and was written by Thomas Wolfe, author of Bonfire of the Vanities and The Right Stuff among numerous other novels.  It focuses on an inter-connected set of men in Atlanta near the end of the 20th century and involves issues of race, class, sex, power, and purpose.  Like other of Wolfe’s novels (in my opinion) this one takes a little while to get going as we are introduced to the wide cast of characters, four of whom emerge as the main actors in this vast plot.  Once the story gets moving in earnest the reader is pulled along a wild ride of success, failure, intrigue, and satire that makes this a humorous as well as an insightful read.

What ties this novel to the second book I will write about is the central place that Stoic philosophy occupies for one of the main characters who first encounters a book on the Stoics while in prison.  This man (Conrad) becomes something of a ‘Stoic evangelist’ seeking both to live out the ideal of wisdom in the face of tragedy and to encourage others to take the same approach to life.  The potential influence of Stoic philosophy on modern life added an intriguing element to this novel for me because I was currently reading the writings of one of the last great Stoic philosophers Marcus Aurelius.

Unfortunately (again in my opinion) it was at the climax of A Man in Full and Wolfe’s portrayal of how Stoicism might impact the central dilemmas of the novel’s protagonists that this otherwise strong book fell apart.  I felt the same way years ago when I finished Wolfe’s earlier Bonfire of the Vanities; the conclusion of a strong book about race, money, and power in modern America ended with the main characters making choices that seemed not to fit with their portrayal throughout the book.  Instead each of these books ended abruptly and in an unconvincing manner, giving the impression that Wolfe was not quite sure what to do with the grand ideas introduced in the novel.

Although (spoiler alert if that matters to you) Charlie Croker’s apparent embrace of a modernized version of Stoicism at the novel’s conclusion mars an otherwise gripping book, I still enjoyed reading A Man in Full; I also look forward to sharing some of my own reflections on the contemporary relevance of Stoic philosophy when I post my next book review shortly.  And I encourage you to read Wolfe’s novel for yourself and form your own opinion because in truth it’s not that simple.

Product Roadmaps

I watched a lot of movies in the 1980’s and 90’s, including many of my favorite movies of all time and quite a few that I routinely watch again. Mixed in with those are a great many others that tend to blur together in my memory, especially when I also saw the sequels. I learned recently just how blurry some of those movie memories have become as I tried to remember a specific movie involving a map that was burned or tattooed on to one of the characters (and before you ask it wasn’t Waterworld or Prison Break, neither of which I’ve seen). The scene in Raiders of the Lost Ark where the amulet gets burned into the one guy’s hand is close, and the rolicksome search for the treasure map in Romancing the Stone captures some of what I was trying to remember, but neither of these is right either. After racking my brain for weeks and asking several people to help me think of where this plot element comes from, I’m starting to wonder if I simply combined aspects of several movies into a scene not actually found in any.

Why does any of this matter? Because for my next blog post about Agile planning I want to talk about the product roadmap. I’ve already written about the broader context of planning for software development in an Agile environment, discussing the overall planning framework and the crucial importance of listening to the market when creating long-range vision for how a product or a portfolio of products and services will evolve. As I focus now on what a product roadmap is and how to develop one, I wanted to root my observations in the context of a cool movie I remember that stresses how valuable a good map is when embarking on a journey to find true treasure. In spite of my inability to remember where I saw the scene I wanted to use (or my grudging admission that maybe such a scene only exists in my addled memory), I do want to share some thoughts on product roadmaps, specifically about who wants what from a roadmap and the most important things a good roadmap provides. Hopefully my thoughts can offer some useful direction in helping you craft a roadmap that guides your team toward the treasure of a great product.

If you follow me on Twitter you know I’ve been reading a lot about product roadmaps in the past few months and tweeting out links to some great things I’ve found (and if you aren’t following me on Twitter then please do so @asbiv). There are lots of great tools available to help create a product roadmap (I found this one from ProductPlan through a link from someone I follow on twitter: http://bit.ly/N8e48p). Placing the product roadmap within the broader context of the Agile planning onion that I discussed a few posts ago, crafting a roadmap fits within the product level of planning. Planning at the product level involves creating a 12-24 month plan about key features to add or enhance. Planning at this level also offers a time frame for when these new capabilities are expected to be available for users.

What specifically is a product roadmap? The answer to that question is closely tied to a second question, namely, who wants what from a product roadmap? When the sales team or the development team asks to see the product roadmap, what are they looking for?

Generally when the sales team asks to see the product roadmap they want to know how aggressively to sell the new features being developed and when they can promise enhancements to prospective clients. If clients or prospects want to see the roadmap they often want to know when specific capabilities that they want will be ready for them to implement. If the management team asks to see the product roadmap their concern generally is how well product development is tracking with the planned time frame and budget previously articulated. And for developers themselves the primary reason they want to see the product roadmap is to know what new functionality is on the horizon so that they can start high level planning for this development.

While a product roadmap might shed light on all of these concerns, none of them quite captures the key aspects of a good roadmap that product owners are looking for. A product roadmap is not designed to be a Gantt chart or a project plan that shows a set of development commitments to be delivered over a given time period. It is not a static document developed at the start of a project and then left untouched. In an Agile development environment, a good product roadmap is a planning tool reflecting the current best idea of what features will be worked on when. It is more about product priorities than about delivery dates, more about product themes than specific features. The development process always involves uncertainty, but the product roadmap represents the best thought from the product manager about what the most important features are and the order in which the team will work on them. The roadmap should not whipsaw from sprint to sprint (any more than a driver should start heading to Boston, then after a couple of hours start heading toward Houston, then later that day start driving toward Miami). Well thought out roadmaps may change based on new market intelligence or technological innovation but fundamental product priorities ought to be more consistent (just like driving from Baltimore to Boston might involve a detour to New York depending upon traffic patterns or the chance to meet a friend but the trip should still head toward Boston).

In an Agile planning process, the product roadmap provides all of the stakeholders (from prospects to developers) with a sense of where the product is heading and what the highest priority areas for new development are. At the same time, the roadmap also provides some indication of what probably won’t be developed (just like the drive along the east coast to Boston will not involve a stop in Chicago). Roadmaps communicate the focus and priorities for product development and that means both what is most important to work on and what has not yet made the list of high-value features. Again, priorities can change with new market input, but in the Agile planning process the product roadmap reflects the best current thinking on where the product is headed over the next 12-24 months.

A product roadmap that reflects development themes and priorities rather than strict time commitments squares well with Agile thinking about product development. It may not answer all of the questions that sales folks, senior management, potential clients, and even developers have about what will be delivered when, but it does communicate current expectations on the order in which enhancements will be worked on. In a development methodology that emphasizes continual iteration and learning along with the ability to respond to new information about market shifts, client needs, and technological innovations, this type of product roadmap is both more useful and more realistic than a static set of feature commitments made at the start of a development process. Of course, the tension of balancing these Agile principles with the demand for some reliable commitments means that in truth, it’s not that simple. 

I’ll be back

Although life continues to interrupt my blogging plans I do intend to get back to writing regularly soon (http://uproxx.it/1jUE9k1). I will resume (and even complete) my series on Agile planning plus I want to post some book reviews on good things I’ve been reading. I’ll actually start another ‘page’ on the blog for book reviews since these are slightly tangential to the main focus on being a Product Owner. So look for more fresh content here in the weeks to come. Thank you loyal readers for your patience. I would really like to get back to writing weekly again but in truth it’s not that simple.