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.

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::
Guests serve themselves at the Buffet table.
Developers (ideally) PULL the work-items themselves.
A work-item can be 
a) Big fix: the earlier the better.
b) Spike: at times, this is also required.
c) User Story Slice: but never a complete User Story.


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-slice(s) 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 they can finish with reasonably good confidence.
And sometimes, just like the chef recommends a signature dish, the Product Manager guides the developers towards work items that would create the greatest impact.

Just as each dish is clearly labelled, the Product Manager and the Architect keep the Product Backlog well refined and the User Stories well sliced, making it easy for developers to understand and confidently pull work items.

While walking to their table with their plates in hand, guests should look happy.
When the sprint plan is made, the developers should feel confident.

Good Sprint Planning begins long before the Sprint Planning meeting. Product Backlog Refinement is where most of that work happens.
In fact, 80% of the sprint planning work must be ready before the sprint planning meeting starts. 

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 than the planned duration to finish the pulled work-items, they take that time without feeling guilty 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 how accurate your plan was, and your schedule variance is zero. 

6::
Guests don't pick food that someone else must partially eat before they can continue.
Developers should avoid pulling work that is heavily dependent on another developer.

7::
And here is the most important similarity.
Guests can very well use their judgment about how big/small a 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 by their preference for a complicated approach. 

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

Glass Wool Effect

Glass wool is/was used in thermos flasks because glass wool is a poor conductor of heat. You can enjoy cool lemonade from your thermos flask even on a hot sunny picnic day because of the glass wool.

Many years ago, I found myself in a software building team which reminded me of this Glass Wool Effect. It taught me how bad this effect can be for the business and it also taught me how to tackle it.

Our team size was about 18 consisting of developers, testers, PO, designers etc. We also had a separate Tech Support team who worked closely with Customers to educate them, do the hand-holding, and solve their problems. Frequently Tech Support Team and Developers had long discussions (many times heated discussions) about the problems customers face.

The Tech Support opinion used to be “Developers do not really understand how Customers use our product and how to solve their problems”. The Developer’s opinion used to be “Tech Support folks do not know how to use the product and how to provide support”.

In short, the Developers were living a life like lemonade in a thermos flask, completely isolated and safe from the heat of customers. They were completely oblivious to the heat from the real users.

To be fair to Developers, it was not their fault.

Somehow our Org had created a working practice that Customer Interaction was exclusively reserved for the PO and Tech Support. A working practice where Developers job was just to write code. In Agile lingo, their job was just to complete User Stories. To make the matter worse, they were using metrics like… Velocity, #of Stories Completed, Health of Backlog, yadda, yadda, yadda. They were doing all this very diligently. But at the same time these developers had absolutely zero outward focus.  It never struck them that all these metrics are worthless, in absence of the metric of Market Feedback.  

All these developers were extremely sharp and hard working. The root cause for customer complaints was that the developers were not PERSONALY exposed to them.  The glass wool effect. I decided to remove the glass wool so that the lemonade will realize how hot it is outside.

I removed 4 developers from the Dev team for a duration of 3 weeks and told them that they should work closely with Tech Support folks and help them to solve Customer issues. Developers were anyway convinced that Tech Support folks lack product knowledge. So, they took this challenge happily. Within just 2-3 days, these Developers realized that the way they were visualizing the product is not same as the way it was being used in market. They quickly understood what kind of problems real users face. More importantly they started appreciating the challenges and the work of Tech Support folks.

Just after 1 week, I could conclude this experiment which I had planned for 3 weeks. The outcome (& the learning) was…. There is absolutely no substitute for the first-hand interaction with real users.  After that 1 week, the interaction between the Developers and the Tech Support was completely changed. Their team work became exemplary. Developers started showing willingness to talk to Customers with (or even without) Tech Support folks. Because they had realized that 1 Hr spent with Customers can give them big insight and that can help them tweak the software and to plan further work.

Once the glass wool effect was tackled, it became a win-win game.

In fact, a win-win-win game.  

Working Hard to Solve a Problem That Does Not Exist.

( Credit : EnJoy It) 

Here is a good & hilarious example of working hard to solve a problem that does not exist.
Do you see a similar kind of hard work around you?
Well, I do.

Here are a few examples of solving non-existent problems from the "A"gile circle...

• Doing an endless comparison between various frameworks and nailing down every minutest difference between any two. (An indication that Org wants to be a passenger on the bandwagon. This could also be an indication that the stakeholders do not have a common agreement on the End-Objective) 
  
  
• Investing huge energy & time to do better and better Estimation. 
  
  
• Measuring Velocity. (A clear sign of celebrating Effort, rather than Outcomes)
  
  
• Trying to maintain steady Velocity (Completely a wrong ambition)
  
  
• Obsession with Capacity Planning & endlessly searching  for “THE BEST” template for Capacity Planning
  
  
• Working hard to invent novel ways to “Add Fun”, particularly in Retrospective
  
  
• Seeking more and more ways to do self-assessment of team's  "A"gile Maturity
  
  

In all these cases, the intentions are not bad. 
But having bad intentions is not a must to go on the wrong path.

How to focus on problems that are worth solving?
Well, one approach could be...
Laser sharp focus on the market and having an outside-in view.  Laser-sharp focus on the market could lead to: 

• Gathering market feedback frequently 
• Finding out & doing THAT piece of work that would generate maximum RoI
• Releasing in shorter cycles, (at least building & showcasing in shorter cycles)
• Working with thin slices, which would enable showcasing in shorter cycles
• Working with thin slices, which would safeguard us from generating big waste

All these problems are worth working on. And when you work on them, it creates +ve impact on business. 
Business of the Customer as well as yours.