Common Language and "A"gile

In the aviation industry, their terminology is universally agreed upon and universally understood. So, whether an Air France Pilot is landing in Warsaw or a Lufthansa Pilot is landing in Denver, the terminology used by the Pilot and ATC at Warsaw or Denver is same, English.
When ATC says... "You are cleared for 26L" it is exactly the same for the pilot whether he is landing in Warsaw, Denver or Mumbai.   

In the knowledge industry, where the raw material is nothing but ideas & thoughts, it is utmost important that communication is crisp and w/o any corruption. 

Why am I thinking about this today?
Because I have been seeing too many scholarly articles again and again for too many years on the same subjects like... 

- What is a User Story
- Can a Testing Story be treated as a User Story
- Can we assign Story Points for a Bug
- Relation between Epic & User Story 
- DoD vs DoR
- Common misunderstandings about the role of a Scrum Master
- Confusion between Product Backlog & Sprint Backlog
- Whether Agile is a framework or a methodology or a mindset or yada yada yada.

Sometimes I think Agile WoW is no longer Agile Ways of Working; it has become Agile Ways of Wording.

Can you imagine 2 people in *ANY OTHER FIELD* working for 20 years *WITHOUT*  having a common language and common understanding about the terms they use on a daily basis? 
‘A’gile professionals have managed that unbelievable feat. 

Identify Herbie in your team

Remember The Goal by Eliyahu Goldratt?
Remember Herbie and his overweight backpack?
No doubt Herbie had good intentions when he packed lots of canned food & iron skillet.
He must have thought that the canned food and skillet would help him on his hike. But that turned out to be the problem for him, and he turned out to be the bottleneck for his team.

Are you in the business of building software?
Are you shipping something valuable fast enough?
If yes, then congratulations. You have achieved something that thousands of teams strive for.

But if you are not, or if you strive for more, then maybe there is a Herbie in your team.
In your case, your Herbie will not be a person, but the canned food and the skillet will be taxing your team for sure.
In your case, the iron skillet will be in the form of pompous, nebulous, impressive, and weighty terminology.
In your case, the canned food will be in the form of canned processes & ceremonies, in the form of meetings with rigid structure, in the form of a warning that your processes are immutable, in the form of a waiting period for the next version of THE GUIDE, which allows you to change your thinking.
Maybe your Herbie is carrying tins of canned food, whereas a few energy bars would have worked better.

In The Goal, Alex Rogo took all the canned food and the skillet from Herbie and distributed them among all the boys.
In your case, you should simply discard it.

Of course, one should not go on a hike using just floaters.
If you want ultralight gear to help your endeavor of shipping something valuable fast enough, talk to me.
I have ultralight gear for you.
The same gear with which we built something, which is being used by dozens of Fortune500 Orgs.

Reminder to myself

I jotted down a few points that worked well for me and my teams while building SaaS products.  Though these learnings are from my context, I trust they are fairly generic. So, there is a very good chance that it could work well for you too.

Product Vision Canvas::  
This is the most crucial homework a Product Manager could do for Hypotheses Validation. I will do this carefully before 1st line of code is written because it can save me a trunk-load  of cash burnt.
 
Hypotheses ::
Hypotheses validation does not get over with Product Vision Canvas.  Every User Story is a hypotheses. And that is why it should be built Slive-by-Slice.
 
Unknowns::
Accept the fact that there would always be unknown variables.  My job is to reduce unknowns and reduce impact due to unknowns.
 
Bite small, Chew well::
Make vertical slices of User-Stories. Never deliver a US completely at 1st shot. Deliver small slices (but often). If I screw-up, at least I will screw-up less and make quick course correction.
 
Shift Left::
Cultivate shift-left mindset across the team. That will safeguard me from unpleasant surprises (well, mostly). Shift-left is not waterfall.
 
Prioritization::
RoI would be my only criteria for prioritizing work (barring requirements related to statutory/legal/patent/security/etc).
This means while prioritizing, I should have a fairly good idea about the "value" & "Cost" of the work I will undertake. 
 
BugFixes is not value addition::
I don't reward myself when I fix a bug.  Maybe I stop frowning at myself when I fix it.
 
Telemetry Code::
Track the Behaviour of Customers. It helps to get VoC. In fact, it provides a massive amount of feedback (just like VoC)  w/o asking a single Q to any Customer.
 
Infrastructure::
Defining coding style/Coding practice/Improving developer productivity/Improving security/Building automation/Infrastructure for CI/etc are more important than building features. (Repeat, *FAR MORE* important than building features.) Most talented/capable minds should handle this, rather than building features.  

Feedback::
Seeking market feedback on your previous release (and using that feedback) is more important than shipping the next release (Repeat *FAR MORE* important than shipping the next release).  

A Small Change in a Spelling

In the Agile Industrial Complex, the biggest factory ships a 12-page guide which they call 'Rule book'. Customers buy this Rule book from one of their numerous retail resellers.

Many customers go back to their retail reseller and complain that these rules are neither helping them to ship value faster; nor it is improving their life in any way. In all such cases, the resellers have a ready answer…  “Those Rules are left intentionally incomplete. You should experiment and adapt.”
Sometimes poor customers gather their courage and ask…If something is incomplete, how it can be called a RULE? And when something is incomplete, why do you print "DEFINITIVE Guide" on the cover page?
But asking such questions is almost blasphemy in this new religion.

Looking back, when they quietly changed ‘a’gile to ‘A’gile, very few noticed it.
But that was the time when the die was cast.
That was the time when an adjective was changed to a proper noun.
And then many brands were built around that proper noun. Many smart people (I deeply respect their business acumen) spotted a huge business potential in that small spelling change. The business model was to stamp people as MASTER and demand money for that.
There were (& are) millions of folks who paid for that stamp of MASTER with its literal meaning (i.e. someone having exceptional skill, knowledge, proficiency, and authority on a subject.) Many organizations also took the stamp of MASTER with the literal meaning and spent loads of money to get their people stamped as MASTER.

It seems these days there are very few Orgs who believe in the literal meaning of MASTER. Nevertheless, they continue to hire these MASTERs to update their JIRA.

When it comes to ‘a’gility (with small case 'a'), all a team needs to know and follow is….
- Collectively decide your End-Objective. 
- Bite small.
- Chew well.
- Ship small & ship often (because Speed matters).
 - Get f/b often (because Direction & Course Correction also matters).
- Take collective ownership of the level of accomplishment of your End-Objective.

This is a simple approach to be an 'a'gile team.

The problem with this simple approach is, it lacks the lofty aura.
It lacks pompous theories. It lacks complexity. Naturally, very few organizations show interest in it.
Complexity & inflated mumbo-jumbo sell better in the corporate world.

Prioritization

A never-ending and always engaging discussion thread among software product building teams is the Prioritization of Product Backlog.
To me, it is not (& should not be) a never-ending discussion topic, if we have clarity about one question.
That question is, WHY we are building this.

Discuss this with Sales folks & Developers and you may get answers something like this...
-to win more customers,
-to make our customers happy,
-to expand our market share,
-to serve our global market with our self-sustaining, innovative, state-of-the-art, carbon footprint-conscious, cutting-edge technology,
- Yada Yada Yada. 

Now, add CFO & CEO to this discussion, and you may get another answer from their side, something like...
-to MMM ( to Make More Money).    

Consider all the answers and decide which one matters most to you/your Organization before deciding how to prioritize.

Here is my super simple way to prioritize the backlog. (YMMV)
- What gives better value, do that now. (Value to the Users/Market, and hence Value to the Product, and hence Value to our Org)
- What gives better value with less effort, do that right now.
- All other stuff should wait.  
It is that simple & straightforward.

Of course, to take that straightforward decision, I need to do some homework.
- I need to know where the VALUE is.
- For that, I need to be sufficiently outward-focused & understand the Market.
- I need to understand the difference between ‘A Particular User’ and 'Market'.
- I need to scout for the Right Market Needs.
- Finally, I must know that the 'Right Market Needs' are those, which are most sought after / painful for the market, AND most rewarding for our balance sheet.
In short, it all boils down to NIHITO, as Steve Blank said.

A few exceptions to the above super simple thumb rule for prioritization could be the work that involves…
-Work required to ensure ease of CI or
-Writing instrumentation code ( aka Telemetry Code ) or
-Setting up standards for the team or
-Defect fixing or
-Work required to acquire patents or
-Fulfilling statutory mandates or
-Derisking type of work or
-A strong demand from extreme-extreme-high-value existing customers. 

Work from all these categories does not (should not) pop up every day.
For routine Prioritization decisions, the above formula is super simple, and it works very effectively as well. 

VUCA, LFBs, etc.

I see around me, that many people liberally use words like complex, complexity, complicated etc, and then put a great emphasis that these words do not have the same meaning.  

Someone told me that a new shiny Agile framework has appeared in the market, where the disciples of this framework spend half of the time explaining to each other how Complex is not the same as Complicated.  Maybe it serves them some purpose.

Another word that is being thrown around liberally is VUCA. Discussing VUCA is just another manifestation of the same thinking… “Making things complex”.

Our world has always been a VUCA world and it will always be a VUCA world.

About 160 years ago, when the raw cotton supply to the textile mills in Manchester was abruptly cut off due to the American civil war, it was a VUCA world. Textiles mills in Manchester found another supplier, and found a way around it. Because of that incident, the city of Mumbai prospered and eventually became the financial capital of India.

When Neanderthals met Homo Sapiens 60’000 years ago, it was a VUCA World. It was a tragedy for Neanderthals, and a victory for Homo Sapiens.

To me VUCA is just one more LFB (Latest Fashionable Buzzword).

Saying that… “Today We Live in VUCA World”, is like saying “Today We Breathe Air”. 

Buzzwords are like cocaine. Both do a spectacularly good job for creating illusion.

Agile Framework, Chemical Process Formula, and ATC Tower

You are in the business of building software. And you want to build software in an agile way.
That sounds great!

Are you thinking of using some Agile Framework?
Not a bad idea.

You have a wide choice of Frameworks to choose from. 
You can select one that suits your organization's pocket, suits your organizational culture, suits your team's appetite to learn exciting mumbo-jumbo vocabulary, suits your inclination toward cool infographics, and finally (probably this matters most) which Framework your Consultant sells to your organization. 

Have you already selected a Framework?
Great.

Now this small tip could help you a lot.
No Framework can ensure your success, and no framework can be the cause of your failure.
A Framework is not a well-defined formula. 

A well-defined process formula for a chemical compound assures the final product as expected, if the mandated ingredients are provided and if the mandated process is followed.

Unfortunately, the Framework in which you are placing your unwavering trust without asking any questions is not a process formula. And certainly not a chemical process formula.

Treat your Framework like an ATC tower, and no more than an ATC tower.

{ The ATC tower seen from my terrace, and the inspiration of this article }

ATC tower provides directions and a point of reference for the pilots. Folks in ATC tower will take care that no other plane collides with you and you will not collide with another plane. 

But when it comes to landing the plane, pilots have to make decisions themselves depending upon their current context. Context like...

- altitude of the airport,
- visibility,
- ambient temperature,
- air density,
- cloud cover,
- runway length,
- wet/dry runway,
- weight of the aircraft,
- wind direction, etc.

In the same way, the Framework you have selected will provide you some guidelines.
But you (& your team) are expected to have situational awareness & based on that make many decisions yourself. Decisions like...

- what is worth building,
- what should be built now & what can wait,
- what is the bare minimum stuff we should build,
- how to get frequent market feedback,
- are we on the right track or whether we need to change track,
- what we should treat as our yardstick for success,
- and most importantly what defines our success.

Treat your Framework like an ATC tower and not like a Chemical Process Formula.
That way you will have a better chance of success.