Collaboration and Product Ownership

I’m presenting a paper, Great Scrums Need Great Product Owners, at the Hawaii International Conference on System Sciences.

The presentation is part of the Agile mini-track co-chaired by Jeff Sutherland and Hubert Smits. I co-authored the paper with the senior member of my product team, Ilio Krumins-Beens.

We survey literature to describe pragmatic and collegial relationships which satisfy the definition of collaboration and honor roles while barely tapping or actually working against the potential of a project and its participants. These limited forms of collaboration are common not just in our industry but within agile projects.

A common interpretation of the call for a single Product Owner is that the development team itself should play little part in shaping the vision and value priorities of a product backlog, focusing instead on efficient delivery of those priorities.

One of our major sources are the What’s Worth Fighting for series by Andy Hargreaves and Michael Fullan on collaboration in education.

The disempowering climate faced by teachers is a direct parallel to that faced by software developers disengaged from the business vision and value priorities of their work.

“… [W]e have collectively 45 years of teaching experience and nobody has ever asked us our opinion about anything where it would actually be put into action. And yet I’ve got to have more experience with junior [children] than a lot of the people who are telling me what I should be doing with them. And I think that is very frustrating… I think I could help bring a lot to it and nobody ever asks, no one ever asks what we think. They just go ahead and proclaim and we have to follow.”

Its tragic how talented, experienced people are not allowed to bring their full selves to their work.

We contrast this with unbounded collaboration between a product owner and team. In unbounded collaboration an individual’s contribution is not constrained by their role or status.

It is a collaboration built upon high-performance, mutual respect and deep trust. The product owner walks a tight rope, engaging the team in an evolving product and business plan while guiding the project toward her vision and high-level goals. The team is passionate about the product they are building and feel personally accountable to the product’s success.

We argue that this kind of collaboration is at the heart of agile values and is a characteristic of the knowledge-creating companies upon which lean principles are based.

I’ll write more about unbounded collaboration, it’s opposites, practices we’ve used and what we’ve learned.

Story Card Hell

I was recently asked the following question:

“I’ve been dropped into a situation best described as “story card hell.” How do I reduce complexity of the software project planning without losing features?”

The project was to replace an existing system. The behavior was largely known. As a result, the initial planning generated enough cards to feel like, “way too much detail up front.”

My answer:

Don’t lose the work you’ve done but don’t place more value in it than it has.

Step back to think of the application as a phased set of releases. Talk with the team and product owner about a way of delivering the system in meaningful pieces that customers could (and hopefully will) use. Get creative with defining those steps as long as they lead you down a path towards your ultimate goal.

Once you have that road map. Do an exercise with the team to group your existing stories into those releases. There will be a natural tendency to add and change stories. That’s fine but don’t get too distracted by it. The main point is to get a sense of the relative size of the releases and move the bulk of the stories out of your immediate planning concern.

Now focus on the first release. Spend more time on those stories but still not with the scrutiny of an iteration plan. Make/allow the team to live with ambiguity. Set up an agreed upon rule of thumb for how much bigger a “theme” is from a real “story” and let the team know it’s okay to discuss these things at the “theme” level.

Story Cards

Then prioritize your release backlog. Have the team chunk the remaining vague stories/themes into future iterations for that release. This is your release plan. Expect it to change. Again, you’re getting a rough sense of how many iterations in the first release and moving later stories out of your immediate concern.

Now you can focus in detail on the stories for the next one or two iterations without getting drowned in details. Don’t be surprised if future stories become irrelevant or drastically change as you get to the iteration within which they fall. It’s okay.

My answer was based on what we’ve tried to do at Oxygen with coaching on release planning from Hubert Smits.

Here’s the full thread off LinkedIn.