Gamification, Agility, SMs, etc.

Yesterday I came across someone who said  “…So it's my responsibility to gather all scrum masters and make them to play virtual games, anything simple on agile, scrum or SAFe…” 

Yes “make them play”,  that is what he said.
Doesn’t it say a lot?  

Gamification is helpful, but as they say… “Everything in a context”, gamification is also helpful in some contexts.

Small kids have little interest in learning addition, multiplication, and division. But their teachers know that kids are not mature enough to understand that they cannot make a good living without knowing arithmetic. So, to teach them arithmetic their teacher uses gamification.

Can we say the same thing about software building teams that they do not understand the importance of agility in software building? And someone (typically a SM) should use gamification to teach them agility? I just hope it is not the case with your team.

Solving any business problem by building software in itself is creative, exciting & satisfying process. Being agile is simply a sensible way to increase your chances of making that process commercially rewarding too.

If a team needs gamification for learning agility, the picture is not promising to me. I was wondering if I am alone in thinking this way.  Apparently, not.
Some believe that Gamification is simply a manifestation of the paternalistic style of management and some go a step ahead and say that it encourages Taylorism in Software Development.
I doubt whether any team would strive for that.  Particularly a team which aspires to be 'self-managed'.

I have also encountered Agility games, which were solely rewarding rote learning the new vocabulary. Now such games are not only just useless, but they are actively damaging. Damaging because they instill a wrong and dangerous belief in team members that agility is about learning new terminology.

Some teams trying to “Be Agile” get drifted towards acquiring more and more vocabulary and searching for new trends. In the process, they lose focus on their End-Objective. Some teams even start their journey of “Being Agile” w/o any common agreement on their End-Objective.
What can be more damaging than that?

Coming back to that “make them play” stuff.

Sometimes we come across “checkmark features” in a product. 

Is this gamification stuff also becoming a “checkmark activity” for SMs? 

What, How, and When & Whether

It is common for a PO to get deeply involved in What, How, and When.
And it is very correct too.

But PO is responsible for something else which is far more crucial than all the three above.
That "something else" is "Whether", and it comes even before What, How, and When.
Seeking an answer to "Whether" needs Outward Focus.
Outward Focus is of course crucial throughout the product life cycle, but it is million times more crucial before you commit yourself to a risky initiative like building a product.

When it comes to building an intangible thing like a software product, however hard we try, we can not bring down the risk level to Zero. All we can do is try to foresee potential risks and try to reduce risks.
Building a Product Vision Canvas helps us to reduce the risks by validating our hypotheses.  

Hypotheses like...

• The problem we are trying to solve
• The Unique Value our solution aspires to offer
• The way customers are managing their life in the absence of our solution
• Market and size for our solution
• Our cost and revenue projection
• The runway available for us

As Steve Blank says... Nothing-Important-Happens-In-The-Office (NIHITO), it is crucial that PO validates the above hypotheses with a sharp outward focus.
It is a must for PO to seek inputs on these hypotheses from the market/prospects/trade shows/SMEs/etc, and discuss/brainstorm with as many stakeholders as possible, and rate her confidence level for each hypotheses herself when she validates these hypotheses.

The real magic happens when one puts a pen on paper.
Self-rating the confidence level of each hypotheses validation is exactly putting pen on paper.

Something like this...

Generally, we (we all humans) find it easy to give a rosy picture to others as well as to ourselves while we are talking. 
But when we put a pen on paper, (of fingers on keyboard), the invisible parser in our mind kicks in, and we find it comparatively difficult to present a rosy picture w/o sufficiently validating it.  That is just the way, the human mind works. Why not make use of it?

When your system nudges you to validate your hypotheses and rate your confidence level for that validation, it helps you to take a bit more educated decision on "Whether". 

- - - -
Let me know if you like this/find this useful.
Surely let me know if you disagree. 

The words we use: MVP & WVP

Since its birth in 2001, the word MVP gets used/discussed very often by folks involved in software building; particularly product building.

Let me share my observations about how MVP is understood and used. Everybody knows the full form of MVP (Minimum Viable Product).

But here is the catch.
Many go under the spell that their MVP has to be "VIABLE”. Quickly the focus shifts
from “Let us discover if this is Viable”
to “Let us make this Viable”.
And soon enough this mindset drags the team into “Let us make this Viable, even though it will be bigger than Minimum”.

I think the original idea behind MVP (what Frank Robinson & Eric Ries had in mind) was... “Let us do a bare minimum prototype / crippled down prototype / maybe even crude prototype to showcase it to market/buyers/users so that from their reaction we can judge whether there would be takers for the solution we are building. (A crucial input to decide whether this will be commercially viable)”. 

I am sure the most important thing Frank & Eric had in mind about MVP was Learning & Discovering & Litmus-Testing & Course Correction. 

The last thing they had in mind about MVP was Building; Building something that can actually be put to use.

If the majority of product builders (Smart People, BTW), for a considerably long duration have been treating MVP as a small and early release of their product, maybe it is because the acronym itself communicates a wrong notion. 

Maybe it communicates that “Even though this is Minimum, this must be Viable”. This type of thinking results in spending enormously big time on building MVP, which defeats the very purpose of testing viability. 

In fact, Reid Hoffman hammered this idea when he said… “If you are not embarrassed by the first version of your product you’ve launched too late”.

Now that may sound like a bit of exaggeration to some, but it drives the point. 

So, the way we stopped using “Estimate” & “Roadmap” (and replaced them with these words), we also stopped using the acronym MVP and started using WVP in place of that.

WVP stands for “Whether Viable Prototype”. 

The acronym WVP clearly communicates…

(1) It is a prototype. So don’t be shy of making it small/intentionally crippled-down/minimal/crude as long as it is quick.

(2) It is a prototype. It could be, but need not be, a working software. It can be low-fidelity sketches, even sketches on paper.

(3) It is a prototype, so better use it to get some feedback from market / buyers / prospects / users. 

(4) The word “Whether” in WVP, hammers the point that...
“You are seeking feedback in the first place, because you are not sure whether it is viable or not. So, even if you get negative feedback, don’t lose heart, take it as a large waste of time/money successfully avoided."

   

 

 

 

 

Raodmap & Weather Chart

The words we speak, communicate certain impressions/views/ideas to the listener. 

Strangely, the words we speak, hammer the associated impressions/views/ideas on the speaker's mind too.

Roadmap is one such word.

Roadmap tells me that Pune is 160 KMs from Mumbai and approx 70 KMs from Mumbai there is a tough Ghat section stretching for about 30 KMs, and after that, it is a flat road. Roadmap tells me what to expect and when to expect,  and it gives me confidence and comfort.    

The business of building software is full of unknowns, less knowns, and sometimes even wrong assumptions. When I use the word "Roadmap" while building something intangible like a software product, I create a false sense of confidence and comfort in the listener’s mind.
The more dangerous thing is, I create the same false sense of confidence and comfort in my mind too.

When it comes to building software, very few things / requirements /  specifications are known upfront fully and correctly. But when I create a Roadmap for next 2 or 3 quarters for my product-building initiative, I give this false sense of confidence to others and also to myself. This false sense of confidence & comfort could very well make me lazy and I would not bother to gather feedback with short cycles and as often as possible.  

In our Org, we stopped the usage of the word ‘Estimation’, and replaced it with 'Guesstimation'. Which makes it sufficiently clear that "this is the best educated guess we can make".
We did that because in the software development world, the word "Estimation" has almost become synonymous with "Commitment".
For the same reason, we stopped using the word ‘Roadmap’ as well. Instead, now we say… “Here is the weather chart for the next 2 Quarters.”

A weather chart tells us… “Based on whatever best information we have as of now, we feel the next 2 Quarters are likely to pan out in this way”

Whereas a Roadmap tells us… “Next 2 Quarters will pan out in this way”.