Scrum defines three roles: product owner, team, and scrum master. It is actually very simple. And for the team it’s great to have one person – the product owner – to deal with the really difficult stuff. That is the VVIP, the users and why the whole thing just will make money in the market.
The key responsibility of the product owner (according to the scrum guide from scrum.org) is that the product backlog is communicated and maintained so that the team works on those items providing the optimal value. That is of course really important. Even if it says little about what needs to be done so that somebody actually knows what provides the optimal value. Well this is a product managers job, anyway.
When it comes to software development for internal departments, there is usually no product manager. And not surprisingly, we don’t seem to have that many product owners.
The difficult question to answer is who should be the product owner.
An internal software serves various groups from the business. They are the users of the new software. They are loaded with their daily work, that’s why they need the software anyway. While being experts in their line of business, they are usually amateurs when it comes to software development projects. As they all have to profit from the software, a product owner recruited here would result in a committee. The conflicts of interests between the groups will for sure result in endless discussions and a development team building instant legacy instead of value. Having a committee as a product owner is not desirable.
There is usually one person who is entrusted with the money for the project. This person reports to those that granted the money. So this person could fill the product owner role. For all, this person has the money and is not a committee. But the business responsible is, again and quite often, an amateur in software projects, loaded with daily business, and in danger of being kicked-in the but by the peers form the business departments because they don’t get what they want. And finally, grooming a backlog is on a level of detail the business responsible does not want to go. In this case, the team will not get a product owner but somebody who tries to take cover in the most effective way, which is blaming the development team.
So finally the software development team. This team comes in after the business people created a full and detailed specification of the system. The software development team can establish a product owner from their ranks, to copy the detailed spec into a backlog.The result is that this poor chap is just flattened in the conflict between hey-we-already-wrote-what-we-want-and-this-is-all-the-features-and-mine-first and we-can’t-deliver-more-while-keeping-up-at-least-some-quality-please-someone-decides-whos-features-to-do-first, and that-is-not-agile unless that person is a super hero.
The point is, the concept of product owner, while very helpful for the development team, seems to be a too simple construct for the raging conflicts in almost any company.
I have seen successful projects (project budget between 4 and 20 million Euro) having a more sophisticated model and it worked very well. Here are the persons and their rough achievements.
- One person connects with all the VIP and ensures that they agree on the vision, and the main milestones. This person is basically entrusted with the money. The person therefore influences the milestones, sets the main goals, and reports to the upper management. I’ve seen senior managers from IT department play this role very successfully, the business responsible with the money can do this job as well, if this person has some backbone and a decent standing with the peers in the management.
- Persons from the various departments are entitled to act in behalf of their department and to drive the needed change process so that the new software can be used. They also ensure access to users and business know how. These usually have been team leaders and senior staff with a good standing in their department. Business analyst can replace them to some degree.
- A few persons close the gap between the guys from the departments, the users, the VIP and the development team. So they lead the discussion about vision and major milestones so that a feasible milestone plan is established; about what can be delivered and the change this will bring for the department; about details of the user interface and the impact on the user’s work. They really understand why the software system is worth the money and what it needs for the product to be a success. They also have all the risks, dependencies to other projects, migration and roll-out under control. Typically, this position is something for those with experience in project management, requirements engineering, and having usability engineering expertise is a really great asset as well.
- One or even a few person from the team ensures that all the parts of the system build on common and agreed principles. That’s a senior software developer or a software architect.
- One or even a few persons from ensures a great user experience over all parts of the system and especially creates the styleguide, wireframes for the deveolopers. A user experience designer is well suited for this position, there are also some exceptional software developers that can do this while implementing the stuff.
Just thinking that one product owner could do all these jobs when already managing the VIP can be all full-time position by its own seems a bit naive. Thus agile process frameworks that deal with projects that need more than a person year worth of work have more sophisticated role models.
If you also feel such a need for your projects, you might check the role model from DSDM Atern. They distinguish sponsor, business visionary, project leader, team leader and technical coordinator. This role model is founded on a wider base of projects than the one implied by the lists above. Here is a site showing a chart of the DSDM Atern role model.
My learnings: If in a project the product owner is not up to the task, it might not be the person, it might be the role model that needs adaptation. It is very likely that the simplistic Scrum role model is not fit for the task at hand.