PO and Product Ownership

From whatever I have seen, the title of Product Owner does not have a universally accepted definition, and that is fine. Orgs have their own ways to position the title of PO which suits their culture. 

Some of the ways, Orgs describe PO as…

one who owns the backlog,
one who writes the User Stories,
one who is a domain expert,
one who gathers requirements,
one who is the market representative,
one who plans roadmaps,
one who manages stakeholders,
one who takes it to the next level,
one who answers queries from Dev team,
one who you-name-it.

I have written a bit longish version here about the qualities I like to see in a PO.

But in shortest form, I would say PO as someone responsible for C-to-C ( Concept to Cash ).

Or I-to-I ( Idea to Invoicing ), which is same as C-to-C.

It is obvious that the PO cannot do single-headedly all the things required for C-to-C.

That is why the organization suitably augments the PO by whatever help/skills s/he demands.

But the fact remains that the PO is responsible for C-to-C.

If someone cannot accept that responsibility, s/he is not yet ready to own the product. 

Undue Criticism about Story Points and Velocity

I don’t understand why there is so much criticism, confusion & commotion about Story Points & Velocity.

Sometime back we got an order for a huge boiler. It was to be shipped from Hyderabad to the client refinery location near Mumbai.  6 days after the boiler left our factory & started the journey, I called the truck driver & asked him how far he had reached. 

He told me...
"For the last 6 days, we have been consuming 8 cans of diesel per day. But from tomorrow, we will surely consume at least 9 cans of diesel on daily basis. In fact, we have set a target for ourselves to increase our consumption by 10%."

His answer made me very happy.  
I thought I had every reason to be happy.

Management by Magazine

I have seen intense debates over management by KRA v/s management by OKR. 
I have also heard about micromanagement, paternalistic management, management by empowerment, and management by you_name_it.

And then there is something called Management by Magazine. This is how it works.

Imagine someone who is very good at smooth talking and persuasion is traveling from Mumbai to B’lore. Before boarding the flight, since he has nothing much to do, he is browsing thru the magazine stand in the shiny book store. All these shiny bookstores at airports sell the sure shot Mantra for success in life, success in business, eradicating the competition, how to become the better of yourself, whatever you can think of.  

Our hero of this story finds a particularly attractive magazine which has a cover article about a new framework. A framework that throws new light on how to change your software-building organization. Since the article presents lots of success stories, he gets very excited. 
To top it all, this framework also has a new version. Now there is no turning back for our hero.  On the flight, our hero spends a solid 30 minutes reading that magazine (long enough to be an expert) and he is convinced that the new framework is *THE* solution for the reincarnation of their Org ( Org 2.0 as he prefers to call it).   

Our hero returns to office. Using his best abilities in smooth-talking, liberally sprinkled with the new buzzwords he had learnt in the flight, he is able to convince the top brass about this new shiny framework.

The “Org 2.0” wind start blowing in the conference rooms and in the corridors.  Org 2.0 becomes THE topic in the cafeteria, as well as at the sutta corner. HR folks are called in and they are made the cheerleaders for Org 2.0 drive. Consultants are searched at a frantic pace. One of the consulting firms is finalized.

Now the real fun starts.
“As is” is documented through extensive interviews.
“To be” is presented in rosy sleek slide-decks.
Roadmaps are chalked out.

And this way the framework installation process begins. Installation of the latest version of that shiny framework. The journey towards Org 2.0 begins. 

The Shepherd by Frederick Forsyth

The Shepherd (published in 1975) is undoubtedly one of the best stories written by Frederick Forsyth.

It is said that Forsyth wrote this story as a gift to his wife, and later it was published as a book. The story is about a young pilot of the Royal Air Force flying from his base station in West Germany to England on Christmas eve of 1957. It has become a tradition for many Radio Stations in US and Canada to broadcast the audio version of this story on every Christmas Eve. 

The Black & White sketches in this book are a masterpiece and they enhance the thrill of reading this book.  Here is the audio version (approx 30 Mins) along with the original sketches from that very very gripping book:  

I was in Germany in 1989 (actually West Germany at that time) & while returning, I spotted the “de Havilland Vampire” jet fighter plane (which is actually one of the characters in this book by Frederick Forsyth) displayed in the aircraft museum on the terrace of Frankfurt Airport.  Here is a photo of that plane I shot using a film camera.

Yes, there used to be cellulose film cameras in those days. 

Story Points Usage by Agile Teams & Australian Camels

In Australia, there are about 1 million feral camels.  Today, they serve no purpose. In fact, they make a serious negative impact on the environment. Camel is not a native animal in Australia. So the real irony is, these feral camels in Australia is a completely man-made problem.

Anyway. This post is not about camels in Australia; this is about Story Points.

For a long time, estimation in software building was simply about “the time” it would take to do some work. Today the priests of this new religion tell us not to estimate our work in Time.
Most of the disciples of this new religion go by that. So, they prefer to use some kind of T-Shirts or cards, and a vast majority of disciples use some kind of Points for Estimation. Irrespective of what this new religion says, the business still needs an approximate time-peg for the deliveries. Business needs to know... What is your approximate time-peg to complete this piece of work?
Now it is a fair question. “A”gilists tackle this fair question by taking 1 of the 2 ways.

1: Some “A”gilists tell the business folks that “this is not the way it works in “A”gile. Work should not be estimated in time”. And this becomes the biggest reason why so many business folks think that “A”gile is just a new age fad. 

2: Other “A”gilists agree it is a fair question. So, they start a convoluted process to convert Story Points to Time. But there is no such thing like standardized Story Point. Naturally, Story Point to Time is a fertile land of confusion and never-ending debates.  All this could have been easily avoided if Estimation was NOT done in Story Points in the first place.

Actually, no framework says that it is mandatory to estimate work using Story Points. And still, most of the “A”gile practitioners, treat Story Points as if it is the soul of being agile. The fact is completely overlooked that even Ron Jeffries (the man who is considered to be the inventor of Story Points), publicly said that he feels sorry for inventing Story Points. And still, Story Points are treated by most “A”gile practitioners as if their team's ability to ship better value faster depends on using Story Points.

But the real damage is in the side effect of using Story Points. The side effect is, usage of Story Points promotes a culture where a team starts celebrating *The EFFORT*, rather than celebrating *The OUTCOMES*. And this is how the race starts to burn more & more Story Points in a Sprint. Soon enough an easy way is discovered for burning more Story Points; simply by gaming the Estimation. The ultimate manifestation of this gaming is working towards… Sprint after Sprint x% increase in Velocity.
What can be a better example of gaming the numbers?

Hmmmm, Story Points...

Just like Australian feral camels, SPs serve no purpose.

Just like Australian feral camels, SPs make a serious negative impact on the work culture.

And just like Australian feral camels, SPs is completely a man-made problem.

It will be interesting to know what Ron Jeffries said about Story Points, Velocity, etc. “Slice down thinner, you will achieve more”.

After all the real objective is achieving more.
'Estimating Accurately' was never the real objective.