A good concept that fails to deliver
The concept of the product owner, who represents the business’ interests in Agile/Scrum software development activities, seems like such a good idea. But in practice many product owners fail to deliver. Either they don’t have the enough insight into what actually goes on in the business, or they haven’t got the authority to take decisions. Or both.
These major issues are often worsened by the fact that the business hasn’t appointed a product owner to represent them, so the IT department ‘comes to the rescue’ and fulfils the role itself. This is just asking for trouble.
Don’t let me mislead you. I’m no agile guru. But I hope that I am a good observer of current IT affairs. I’ve recently become aware of concerns about the effectiveness of product owners in agile development activities, resulting in compromised return on the business’ investments in information and related technology. So I’ll be discussing the product owner role and hopefully giving you some ideas about how to approach it. And I’ll be extending the discussion beyond development and deployment to IT operations and looking at how the business actually gets value out of their investments. That’s why this post is called Full Product Ownership – to emphasize that the product owner role has to be continuous, holistic and embedded in the business in order to be effective.
Scrum roles
Many people associate Scrum with Agile and it is certainly a popular approach for iterative and incremental agile software development. It is however, not the only tool in the toolbox. XP, Lean, Kanban and Agile Project Management are amongst the other tools that need to be used in a balanced way.
The three key Scrum roles are product owner, a development team and scrum master, who all work as a unit to reach a common goal. It is based on concepts such as
- A product backlog of items that the business needs
- Sprints that take up to a month to produce a usable bit of software
- Daily scrum meetings or stand-ups to ensure that everybody is working effectively
- And reviews and retrospectives at the end of each sprint
Product owner is a business role
The product owner is a business role – he or she represents the stakeholders and is the voice of the customer. The product owner provides the team with requirements and specifications for instance in the forms of user stories. He or she prioritizes them and adds them to the product backlog for the team to work on. So what’s the problem? Well, simply that good product owners are as scarce as sheep with five legs (this is a Dutch idiom meaning a rare talent that everyone is looking for).
It’s proving to be difficult to find product owners who have both the ability to take decisions about priorities, as well as the insight into what actually happens in business operations and what functionality is needed to address the specific business issues. A product owner who has to shuttle back and forth between the development team and the business not only makes things as agile as treacle, but also potentially compromises the return on investment if the requirements get lost in translation.
It takes two to tango
A more fundamental concern however is that some product owners don’t work in the business but are part of the IT function – not exactly the ideal position to be effective business representatives. What’s behind this? Isn’t the business able to designate a key player? Aren’t they aware of the risks? Or is it corporate politics and are they creating a situation in which they can always blame the IT function if anything goes wrong? It’s been known to happen. If information systems aren’t significant business assets, then fair enough, the business may have more important things to focus on and the choice may be justified. But how often is that the case? It takes two to tango, and only when IT’s business partners operate at a high level of proficiency, are they able to realize the potential value from their investments.
Product owners simply have to be part of the business. To quote Arie van Bennekum, co-author of the Agile Manifesto, they do not represent the business – they are the business, and often from the future user organization. Managers do not know what business operations needs – only the future users are able to assess the value of information for their business processes. The problem is that you need the best people and that they – by definition – are busy. So the manager has to facilitate their participation in development activities.
Product ownership after development
But it’s no good just acquiring the right systems – which in itself is quite a challenge – you’ve also got to ensure that the users use them effectively and efficiently, otherwise the business doesn’t get to realize the potential value of their investments. Let’s take a look at the kind of issues that the business is concerned with:
- How much should we be investing in IT as opposed to other resources?
- Are we investing it wisely?
- How well are we acquiring IT solutions from external service providers or delegating it to the IT department?
- Are our users using the information systems as intended and therefore getting the envisaged return on investment?
- Is our information and are our information systems protected from abuse?
- And finally, from a governance point of view, can we demonstrate that you’ve got this under control?
While the first three points are related to ‘development’, the other points are on-going concerns that have to be addressed. This is what I mean by Full Product Ownership: ownership that extends beyond development and addressed the rest of the information system lifecycle, ensuring that the user organization gets a good return on their investments, and makes additional investments to keep the information system up to date.
IT is not a matter of life and death
So not only does business management have to free up time for their best people to participate in temporary IT development projects, they also have to appoint people to fulfil the Full Product Owner role on a permanent basis. The only valid reason not to do this is when IT is not an important business asset. To paraphrase Liverpool football club manager Bill Shankly, “IT is not a matter of life and death. It is much, much more important than that”.
