The Hitchhiker’s Guide to Killing Agile (15/?)

Sadly, […] a terribly stupid catastrophe occurred. […] it is the story of that terrible stupid catastrophe and some of its consequences. 

It is also the story of a book, a book called The Hitchhiker’s Guide to Killing Agile, not an Agile book, never published on Agile website, and until the terrible catastrophe occurred, never seen or heard of by any Agile team members.

Nevertheless, a wholly remarkable book. […]

It begins with a channel…

Among the stumbling blocks obstructing the long route we took to survive The Hitchhiker’s Guide to Killing Agile, we are yet to talk about one of the most common mistakes organizations may make when they decide to work within a Scrum framework.

Let’s imagine you are running a business which started many years ago in what we would now call “a traditional way”, being most of the interactions with your customers at that time handled in a physical place.

For the sake of simplicity, let’s assume your organization is a bank.

So, at the beginning, you expected your customers to show up at the bank office in order to carry out whatever operations they needed (withdraw cash, borrow money, deposit their savings, get a mortgage, invest in shares, etc.).

As time passed, the well accepted debut of a physical machine made it possible to perform some of these operations at any time and not necessarily inside the bank office. Thanks to the ATM, your customers started withdrawing cash, paying invoices, topping up their cell phones, etc. just outside the entrance of your branch.

Later on, other interesting innovations were introduced: with the spreading of the Internet, the online version of your bank became available. Which means, your customers were not required anymore to go to a specific place to perform their usual transactions: now they were also able to do them from home.

The arrival of smartphones and their powerful and versatile apps has made it possible to go even further: now your customers can do all that from wherever they want.

At the same time, the way all these innovations are being developed has undergone important changes: most companies have apparently moved from a classical waterfall model to an iterative and incremental approach.
They might say they have adopted Scrum to develop their products, for example; but is this true?

Every time they appoint someone as Online Bank Product Owner or Mobile Bank Product Owner, it seems to me that not only is the role of the Product Owner often misunderstood, but that they have also forgotten what their products and services really are.
They don’t give me the impression of being really aware that their apps, their web sites, their automated teller machines and their physical offices are not the products/services a bank is intended to provide: they are communication channels with the customers instead.

After all, what’s a bank?
Well, according to Economics Help web site, “A bank is a financial institution which is involved in borrowing and lending money. Banks take customer deposits in return for paying customers an annual interest payment. The bank then uses the majority of these deposits to lend to other customers for a variety of loans. The difference between the two interest rates is effectively the profit margin for banks. Banks play an important role in the economy for offering a service for people wishing to save. Banks also play an important role in offering finance to businesses who wish to invest and expand.  These loans and business investment are important for enabling economic growth.”

And what’s the main purpose of a bank?
According to the same source: “keep money safe for customers; offer customers interest on deposits, helping to protect against money losing value against inflation; lending money to firms, customers and home buyers; offering financial advice and related financial services, such as insurance.”

Thus, what are their products?
Well, interests, loans and a bunch of other financial services.
Are maybe their webs, apps, ATMs and offices a reason to open a bank account?

In other words, what’s the point of putting someone in charge of a channel and labelling them as Product Owner?

I guess the main reason why the Product Owner is so named is the fact they are in charge of the product, isn’t it?
Would have they been supposed to be in charge of a channel, the name for their role might have been… well, Channel Owner maybe?

It’s also worth noting that, according to the Scrum Guide, “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.”
So, are you sure that separating your products/services per channels is going to help maximize their value?

Are you aware of what will most likely happen instead?

Well, chances are every Channel Owner will start focusing on their own channel of responsibility.
What’s more, the need to fight for a budget will foster competition over collaboration.
Coordination with their peers won’t be encouraged at all.
As a channel improves, the existence of another one will be probably forgotten*.
The lack of a systemic view will make everybody lose the big picture.
All in all, nobody will take care of the real product/service, nor of all your customer needs.

Again, are you sure this is the best approach to manage your business?
The fact that many companies through their Agile journey make the same mistake doesn’t make this issue less serious.

By the way, a Product Owner is not supposed to be a technical leader either.
After all, if they didn’t need to be experts in physical offices construction and decoration, nor in ATM hardware and software, why would they now need a strong expertise in web and mobile apps development?

As a matter of fact, according to Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, there should be “at least one very experienced engineer as part of the team”, since their mentoring role is crucial to make the crew achieve autonomy and self-organization.

So, should you need a technical expert while working within a Scrum framework, they should definitely be part of the development team.

In other words, if you want to make the most of Scrum, you “just” need to make sure your Product Owner knows your business and to let them focus on the product.

If you feel you can’t do that, this means either your organization might not be ready for Scrum —by the way, if you haven’t changed your organizational structure and processes, you are not doing Scrum— or Scrum doesn’t suit your way to work.

All in all, if you make your alleged business people focus on channels, you might end up running a channel surfing business…