Solution Convergence: Marrying Business, User Experience and Technical Input

My product owner was upset when I told her she couldn’t have the widget that she had agreed with the User Experience (UX) Designer. The problem was the design was not technically feasible. To get a great solution to meet the business requirements three parties – business, user experience and technical – must agree on the approach. That negotiation is what I call “Solution Convergence”.
Continue reading

Product at the end of its life cycle? Try the Scream Test

One of my teams was responsible for maintaining over 3,000 applications, utilities and audience facing services. We didn’t know who owned or cared about the majority of these. This mysterious majority had been commissioned in the mists of time by people who’d moved on. 3,000 was too many and we needed to cut. Our only recourse was the “Scream Test”.
Continue reading

What do I do when There is More Than One Product Owner

The product owner defines what the development team is meant to build and the order in which it is built. What should you do when the Product Owner responsibilities lie with more than one person?

The short answer, that works in simple situations, is get the business to pick one. However things are not always so simple and there are situations where you will need more than product owner. I’ll outline a few scenarios, both good and bad, which for the purposes of this post I’ll characterise as Many Kings, Pretender to the Throne, and finally Chief and Indians.
Continue reading

Three Strategies when the Product Owner is Disengaged

Karine doesn’t show up. She has a good reputation and was previously the product owner on a run away success. But on your project she seems quite distracted by other commitments. What she is working on is all good stuff and related to the wider programme but it means Karine often misses the important meetings with your development team. When she does turn up the team are very happy with the input she provides. They’d just like it more often. Much more often.

Phil doesn’t show up. He is a colleague of Karine and is product owner on another work stream within the same programme. Phil’s development team never sees him at all as he is entirely focussed on external communications.

Mike doesn’t show up. He’s the external customer and commissioned you and your company to build some software. He knows his business inside out but he’s never been involved in software development before. And Mike is quite busy and doesn’t often make it to your offices. When he does come in he talks to the CEO and not the developers.

I’m sure elements of these scenarios will sound familiar to you?

You’ve got a a big problem if the Product Owner does not show up to the key meetings of the Agile Heartbeat or is otherwise not engaged.

To address this problem you’ve got three options: Educate, Delegate, or Escalate.
Continue reading

How to Manage a Vague or Dynamic Product Backlog

In response to my request for questions along the lines of what do I do when … ? Jo asked:

What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.

In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:

  1. Normally vague/dynamic
  2. Completely vague
  3. Massively dynamic

The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.

The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.
Continue reading

Side Bets and Sweeties in Organisational Change

People don’t resist organizational change!People resist being changed!

The Communication Toolbox

My current programme is using new, bespoke software to drive organisational change. So I need people to change what they’re doing. A lot of people. As a first step I need them to adopt our new software. So I am always looking for ways to push the software roll out. In an earlier post I described one approach we use for encouraging adoption: Foot in the Door Technique. In this post I look at two other methods – which we call "Side bets" and "Sweeties".
Continue reading