Reminder to myself

I jotted a few points that worked well for our team & in our context. So, 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 in 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 the latest release (and using it) is more important than shipping a new release (Repeat *FAR MORE* important than shipping a new 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.

Going 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 something like...
-to win more customers,
-to make our customers happy,
-to expand our market share,
-to serve our global market with our self-sustaining,  carbon footprint-conscious, cutting-edge technology,
- Yada Yada Yada. 

Now add CFO & CEO to the discussion, and you may get one more answer...
-MMM ( Make More Money).    

Consider your answers and decide which answer matters most to you/your Organization before you decide 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 (Telemetry Data Gathering) or
-Setting up standards for the team or
-Defects 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 too very effectively. 

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.

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.

Improving "A"gile Maturity Index

How to improve “A”gile Maturity Index of your team?

Here are a few tips.

Everything boils down to planning. Focus on accurate planning. That involves learning and debating as many ways of planning as possible.  

Soon you will realize that accurate planning is dependent on accurate estimation. And hence learning Estimation is important. There are many ways of Estimating. Learn as many ways as possible. More the better. Involve all team members to decide which is better way of estimating.  There is lots of material available on internet. But maybe you should join some training for getting certified in Estimation. If that certification needs a yearly renewal fee, then it is even better. There are many meetups where endless discussions keep taking place on this topic. You can take help from these meetups also.

When you pick up a User Story for Estimation, you may realize that 4 developers have 3 different story points in their mind.  Involve everybody in a discussion to reach a consensus. After all, what matters to the market is whether you have reached a consensus or not. 

Even bigger thing which matters to the market is your “Velocity”. If there was no consensus about the SP of the UserStory, you cannot plot the” Velocity” graph. Without the Velocity graph, you will be working in dark for future sprints. In fact, planning the future sprint itself could get stuck. You can avoid that risk by reaching a consensus. 

Another crucial aspect for improving "A"gile Maturity Index is Capacity Planning. Maybe this is the most crucial aspect in your journey to be “A”gile. If you are planning for a 2 weeks sprint, you should carefully plan your capacity. Because 10 working days is a long time, very long time. Without Capacity Planning for those 10 long days, anything can happen. So just before the Sprint planning, hold a meeting for Capacity Planning. There are many SaaS tools available for this. Ideally, you should use a tool for this crucial activity. Maybe the selection of this tool involves some time investment for evaluation etc. But that can be done by forming an evaluation committee. Since Capacity Planning is such a crucial ingredient in “Being Agile”, one should not take any shortcuts here.

For a good Agile Maturity Index, team members must do good Collaboration.  Things like everyone showing Respect to everyone else, and everyone trusting everyone else, and one person empowering everyone else, etc are also important for Agile Maturity Index.
There are many consulting organizations who can help you (for a nominal fee) in such very very complex but extremely important areas.    

There are few other aspects also which determine your “A”gile maturity Index; such as  Sprint-after-Sprint 10% boost in Velocity, and Average number of certifications of members in your team, and whether you cross the 15Min upper limit for daily standup, and  whether you really stand (or sit) in your daily stand-up, Etc.
But for any team, however good it may be, it is difficult to incorporate all changes at one time. So, it will be wise to go slow. After all everybody agrees that “Being Agile” is a journey.  

Some people say that the Market does not care about your "A"gile Maturity Index.
They also say that the market does not care whether you are "A"gile or not.
Some people even go to the extent of saying that Agility is not the End Objective but a vehicle to reach the End Objective.

All such opinions should be discarded as edge cases. 
It is certainly worth spending the time, effort, & money to assess ourselves and give an "A"gile Maturity Index to ourselves and enjoy the journey.

Sprint Planning

A few topics (actually quite a few topics) are made unduly complicated in “A”gile circle.  
Sprint Planning is one of them.

Look at these folks enjoying a well-laid-out buffet spread. Guests have a look around the buffet table, they see what they would like the most among the options, and then they serve themselves keeping in mind what size of portion they would happily consume.  

To me, Sprint Planning is not (and should not be) more complicated than helping yourself to a buffet meal.
In fact, I see quite a few similarities between two. 

1::
At the Buffet table, guests serve themselves.
Developers (ideally) PULL the work-items themselves.


2::
Guests have the liberty to pick a small/big portion from any food bowl, keeping in mind what portion they can eat happily.
Developers pull vertical-slices of User Stories, keeping in mind how many slices they can finish within an iteration while abiding by the established DoD.
{After all, there is no point vertically slicing a UserStory, but not building it slice by slice} 

Here is what Ron Jeffries thinks about building it slice by slice.

3::

Guests select food by considering what they like most. 
Developers pull work-items keeping in mind what work would be liked and appreciated most by the Market.
What work would create maximum value for the Market, and hence for the Product, for their own Organization, and hence for themselves.

4::
If the guests need 5-10 mins more (more than what they thought), to finish their meal, then they generally take 5-1o more mins, rather than throwing away the plate with the remaining food because the time is over.  
If the developers need 2 days more (more than the planned duration) to finish the pulled work-items, they take that time to finish the pulled work-items.

5::
When a guest feels the pudding is exceptionally good, and she wishes to have one more small portion, she certainly does that.
If a developer finishes the work-items she had already pulled for the sprint, and if she feels confident that she can finish one more work-item, then she can pull additional work in the same sprint too.
After all the market appreciates how well you serve them.
The market has zero interest in knowing that your plan was accurate and your schedule variance is zero. 

6::
And here is the most important similarity.
Guests can very well use their judgment about how big/small portion of food they should serve themselves.
A developer can also use his/her educated guess (aka guesstimate) to pull just enough slices in the sprint so that she/he can finish the work with the agreed DoD.

But then, many teams do not like this simple approach of Sprint planning. 
And they love to make a big event out of it, which is appropriately called a “Ceremony”. 
I am not surprised with their preference for a complicated approach. 

As Edsger Dijkstra (winner of the Turing Award in 1972) famously said… "Complexity sells better".