A modern fable: Where the Product Owner role came from

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:

  1. 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.
  2. 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.

find the cost of your paper

Sep 13, Grand Remembrances

Today is Grandparents Day in the United States. Being a Grand is a special honor. I feel very blessed that my wife and I have two grandchildren. We were able to visit them today. Yes, we are still being cautious with the coronavirus, but we also find it very difficult to not see them when they live so close. So today we did drop by to visit Jacob (age 10) and Sophia (age 7) along with their parents. We brought donuts and caught up with them. Our grandchildren are still pretty young and this is a precious time in their lives – and ours!

I wish I had known my grandparents better. We never lived in the same place. Dad was a career Air Force pilot, so we moved around a lot. But we did get to see them once in a while when they would visit us, or we them.

A Plague of Giants

There are five known magical ‘kennings’ or types: air, water, fire, earth, and plants. Each nation specializes in of these kennings, and the magic influences the society. There’s a big pitfall with this diversity of ability and locale–not everyone gets along.

Enter the Hathrim giants, or ‘lavaborn’ whose kenning is fire. Where they live the trees that fuel their fire are long gone, but the giants are definitely not welcome anywhere else. They’re big, they’re violent, and they’re ruthless. When a volcano erupts and they are forced to evacuate, they take the opportunity to relocate. They don’t care that it’s in a place where they aren’t wanted.

I first read Kevin Hearne’s Iron Druid books and loved them (also the quirky The Tales of Pell), so was curious about this new venture, starting with A PLAGUE OF GIANTS. Think Avatar: The Last Airbender meets Jim Butcher’s Codex Alera series. Elemental magic, a variety of races, different lands. And it’s all thrown at you from page one.

But this story is told a little differently. It starts at the end of the war, after a difficult victory, and a bard with earth kenning uses his magic to re-tell the story of the war to a city of refugees. And it’s this movement back and forth in time and between key players in this war that we get a singularly grand view of the war as a whole. Hearne uses this method to great effect.

There are so many interesting characters in this book that I can’t cover them all here. Often in books like this such a large cast of ‘main’ character can make the storytelling suffer, especially since they don’t have a lot of interaction with each other for the first 3/4 of the book–but it doesn’t suffer, thankfully. And the characterization is good enough, despite these short bursts, that by the end we understand these people and care about what happens to them.

If there were a main character it would be Dervan, a historian who is assigned to record (also spy on?) the bard’s stories. He finds himself caught up in machinations he feels unfit to survive. Fintan is the bard from another country, who at first is rather mysterious and his true personality is hidden by the stories he tells; it takes a while to understand him. Gorin Mogen is the leader of the Hathrim giants who decide to find a new land to settle. He’s hard to like, but as far as villains go, you understand his motivations and he can be even a little convincing. There’s Abhi, the son of hunters, who decides hunting isn’t the life for him–and unexpectedly finds himself on a quest for the sixth kenning. And Gondel Vedd, a scholar of linguistics who finds himself tasked with finding a way to communicate with a race of giants never seen before (definitely not Hathrim) and stumbles onto a mystery no one could have guessed: there may be a seventh kenning.

There are other characters, but what makes them all interesting is that they’re regular people (well, maybe not Gorin Mogen or the viceroy–he’s a piece of work) who become heroes in their own little ways, whether it’s the teenage girl who isn’t afraid to share vital information, to the scholars who suddenly find how crucial their minds are to the survival of a nation, to the humble public servants who find bravery when they need it most. This is a story of loss, love, redemption, courage, unity, and overcoming despair to not give up. All very human experiences by simple people who do extraordinary things.

Hearne’s worldbuilding is engaging. He doesn’t bottle feed you, at first it feels like drinking from a hydrant, but then you settle in and pick up things along the way. Then he shows you stuff with a punch to the gut. This is no fluffy world with simple magic without price. All the magic has a price, and more often than not it leads you straight to death’s door. For most people just the seeking of the magic will kill you. I particularly enjoyed the scenes with Ahbi and his discovery of the sixth kenning and everything associated with it. But giants? I mean, really? It isn’t bad enough fighting people who can control fire that you have to add that they’re twice the size of normal people? For Hearne if it’s war, the stakes are pretty high, and it gets ugly.

The benefit of the storytelling style is that the book, despite its length, moves along steadily (Hearne is no novice, here). The bits of story lead you along without annoying cliffhangers (mostly), and I never got bored with the switch between characters. It was easy to move between them, and they were recognizable enough that I got lost or confused. The end of the novel felt a little abrupt, but I guess that has more to do with I was ready for the story to continue, despite the exiting climax.

If you’re looking for epic fantasy with fun storytelling and clever worldbuilding, check out A PLAGUE OF GIANTS.

The post A Plague of Giants appeared first on Elitist Book Reviews.

The Artwork Of Gary Choo

Gary Choo is a concept artist/illustrator based in Singapore. I’ve know Gary for a good many years ( 17, actually ), working together in animation studios in Singapore like Silicon Illusions and Lucasfilm. Gary currently runs an art team at Mighty Bear Games, but when time allows he also draws covers for Marvel comics, and they’re amazing –

The Art Of Gary Choo
The Art Of Gary Choo
The Art Of Gary Choo
The Art Of Gary Choo
The Art Of Gary Choo

To see more of Gary’s work or to engage him for freelance work, head down to his ArtStation.

The post The Art Of Gary Choo appeared first on Halcyon Realms – Art Book Reviews – Anime, Manga, Film, Photography.

27