When development resembles the ageing of wine

Tags

agile, one voice, product manager, Product Owner, scrum, wine

Once upon a time I was asked to help out a software product company.  The management briefing went something like this: “We need you to increase productivity, the guys in development seem to be unable to ship anything! and if they do ship something it’s only a fraction of what we expected”.

And so the story begins. Now there are many ways how we can improve the teams outcome and its output (the first matters more), but it always starts with observing what they do today and trying to figure out why.

It turns out that requests from the business were treated like a good wine, and were allowed to “age”, in the oak barrel that was called Jira. Not so much to add flavour in the form of details, requirements, designs, non functional requirements or acceptance criteria, but mainly to see if the priority of this request would remain stable over a period of time.

In the days that followed I participated in the “Change Control Board” and saw what he meant. Management would change priorities on the fly and make swift decisions on requirements that would take weeks to implement. To stay in vinotology terms, wine was poured in and out the barrels at such a rate that it bore more resemblance to a blender than to the art of wine making.

Though management was happy to learn I had unearthed to root cause to their problem, they were less pleased to learn that they themselves were responsible.  The Agile world created the Product Owner role for this, and it turned out that this is hat, that can only be worn by a single person.

Once we funnelled all the requests through a single person, both responsible for the success of the product and for the development, we saw a big change. Not only did the business got a reliable sparring partner, but the development team had a single voice when it came to setting the priorities. Once the team starting finishing what they started we started shipping at regular intervals, with features that we all had committed to.

Of course it did not take away the dynamics of the business, but it allowed us to deliver, and become reliable in how and when we responded to change. Perhaps not the most aged wine, but enough to delight our customers and learn what we should put in our barrel for the next round.

The mythical Product Owner

Tags

agile, Product Owner, scrum

“He’s just there”, Jeff Sutherland replied to the question where we could find this mythical person. Balancing between business and technology, having the vision and the time to guide the team but also go out there and meet the users, empowered by the business, the one “where the buck stops”, yet with technical knowledge to understand the developers needs. Sometimes it’s easier to spot mythical creatures than true Product Owners.

Over the years I have seen very few persons embodying all these properties, but those I’ve met learned me what to look for. Gave me a reference model so to say. But the best Product Owners I’ve met, all failed this omnipotent description, but rather had built a team around themselves that compensated for their weaknesses.

So rather than having a single Product Owner, you would have a team that acts as Product Owner, a team in which you typically find: Business Analysts, Product Managers, Project Managers, Designers or Release Managers.

And what do they do? well they all have their specific competences, but the focus of the Product Management team should be the business value. What will a feature cost and what is its return on investment, how do we measure this? How does it fit in the overall picture? The problem invariably becomes how to align these people and have them talk with one voice to the team.

More overhead? Yes. Necessary given the complexity of the task? Yes again. We can insist on a single product owner, but in many cases, we’ll fail, and the committee of Product Owners provides a workable solution.

P.S. be careful with committees: “a camel is a horse defined by a committee”