This story is a fictional account of how the Product Owner / Customer role may have come about. It’s purpose is to illustrate why so many companies have so many problems with this role. After the fable, the article continues with some examples showing what some companies are doing differently.
Once upon a time there was a team implementing software. They had just been staffed to a new large project which would be released as a series of releases. They met with the Business Analyst to learn the requirements of the first release. They developed a solution, then showed it to the Project Sponsor. The Project Sponsor was not happy. “This is not what I want”, he said. “You will have to redo these 3 parts completely.” And so the team reworked those parts, showed them to the Project Sponsor, and life was good.
The team started the next release, and the same thing happened. The Project Sponsor liked some of what they did, but other parts they had to completely rework.
One day when the Project Sponsor was not happy, the team said in frustration, “If you are not happy with this then come and sit with us and show us just what you want us to do”. The Project Sponsor agreed and sat with the team for a couple of days until the problems were fixed. Everyone was happy.
The team said, “This worked so well, come and sit with us all the time and tell us what to do.” The Project Sponsor said, “I cannot possibly do that, I have another job”. So the team said, “Then send us someone you trust completely to tell us what to do and agree that if our work is acceptable to that person then you will also accept the work.” The Project Sponsor agreed to do that for the next release.
The Project Sponsor sent one of the best of his staff to sit with the team full time for the whole release cycle. This was just as good as having the Project Sponsor sit with the team. When the Project Sponsor saw the finished work, he was happy.
The team said, “This is the way we should always work. There should never be someone between us and the Project Sponsor, though having one of his best people worked out.” And the Project Sponsor thought, “This is not sustainable. I cannot give up my best people forever”, but he said nothing because everything was in fact working for this project and he would worry about how to address the issue later on a different project.
That team was led by someone influential in the software development community, someone who did a lot of writing and speaking at conferences, and so the word spread. Teams with the same frustrations embraced this model and insisted on it with their Project Sponsors. A short term fix born out of frustration and immediate need, that was not grounded in root cause analysis, became a recommended solution for everyone.
Unfortunately, this story did not have a happy ending. When that project was finished and the product released to end users, they rejected it. It did not meet their needs. One thing the Business Analyst had done was work with the end users, so by removing that person from the team, there was no one looking out for the end users. The Project Sponsor and his staff were not in touch with actual end users and their needs. Ultimately this project was a failure that wasted millions of the company money.
This model of the customer sitting full time with the team, that was an impulsive solution to the problem of the team having to do rework due to the Project Sponsor being unhappy with the results, introduced two intractable problems:
- It is not sustainable for the business to remove Project Sponsors or members of their staff from their day-to-day work to sit full time with an implementation team to tell them what to do.
- It removes the voice of the end users from the project (UX as it exists today is too much about design and not enough about the actual human beings using the product. It is insufficient.)
What is needed is a determination of the root cause of the initial problem and fix that. Since this is a fable, we can only guess at the root causes. These are some things I have seen in my career that have caused exactly the problems described above:
- The Project Sponsor changed their mind at some point and did not communicate the new requirements to the Business Analyst.
- The Business Analyst spent too much time with the end users and did not cross check the information with the Project Sponsor.
- The Business Analyst was not trained or know how to do the role.
- The development team ignored what they were told by the Business Analyst.
- The development team did not review documentation provided by the Business Analyst.
I am seeing a number of different approaches to resolving these issues.
Microsoft recently published some articles about the 5 year Agile journey they have been conducting in their developer division. They have found they need 2 Program Managers for each team of about 10 implementers. (A Program Manager combines the responsibilities of Product Manager, Business Analyst, and Product Owner.) This allows each one to spend half their time on the work they need to do on the business side and half their time with the Agile team.
Menlo Innovations does custom programming. Their customers are other companies. The customer is not on-site, the users are not on-site. Menlo has High-Tech Anthropology teams who coordinate the work between the customer, end users, and their own XP teams. Each XP team has a pair of Solution Anthropologists working with them.
A lot of projects still have a traditional Business Analyst role. But they understand that they have to train and mentor their Business Analysts. They do not just put any warm body in the role if they want that person to be effective. They typically train their Business Analysts in a broad range of skills, including things such as mediation, negotiation, and effective communication.
I just talked with a Business Analyst today who recently got a top award from her company for effectively negotiating the requirements and release schedule between the business unit that was the customer, the actual end users, and the Agile IT team implementing the solution. This was a very tricky situation, and she was personally credited for making it work to everyone’s advantage. She is highly trained in not only Business Analysis but also in Sociology and Leadership.
In all three of these examples, the team is not getting input from one person (the customer, the Product Owner). Rather the team is getting input from the customer and many, many users filtered through one or two people who directly interact with the team.
At Microsoft, the Program Managers are responsible for being closely in touch with the market and the end users, and they bring that knowledge with them when they sit with the team. The same is true of the Solution Anthropology teams at Menlo and the well-trained experienced Business Analysts I meet.
We do not have to remove a business SME or Project Sponsor from their full-time jobs to make Agile work. We need to provide trained, experienced people who know how to negotiate the best results for the customer, the users, and the teams who implement the solutions.