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".  

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.

  

Metrics for Agile Transformation

In a meeting today, one gentleman who is driving Agile Transformation in his Org asked me this age-old and evergreen question…. What would be the best metrics for Agile Transformation?

Honestly speaking, even though this is a syntactically correct question, it is almost a meaningless question. 
But rather than being so blunt to that person, I asked him… What is the expected end-objective from this Agile Transformation?

Then there was a long & uncomfortable silence.

So, I simplified & broke down my question.
I asked him... what amount of money your Org is spending on this Agile Transformation?
He said… approximately N per month.

So suggested to him that, he should approach his CFO or CEO and tell them…. “Thanks for giving us a budget of N per month for Agile Transformation, but we are not even clear what is expected from that Transformation”.
He said… that would not be a very good move for his future :)

I continued... Using somebody else's "Best Metrics" will not be a good move for your future either. And deciding the best metric w/o knowing the end-objective from Transformation will not be a good move for your future either.

Until you are clear about the expectations from Agile Transformation, any metric is equally good or equally meaningless.

Few (Fashionable) Words We Use

If you have to embrace someone, s/he has to be another person.
You cannot embrace yourself.
Can you?

To embrace something, it has to be out of you.
You cannot embrace something which is an intrinsic part of you.
Can you?

What does it mean if I say… I embrace honesty.
You may start thinking, this guy is embracing honesty, because it is NOT an integral part of him.

Few words have become really fashionable these days. Especially in the consulting world. These words come in handy to impress the audience. One of these fashionable words is “embrace”.

Right now there is a scholarly article in front of me on LI; which says, “One should embrace integrity”.

What? Embrace integrity??  What does that even mean??

One can (& one should) embrace diversity.
Because diversity stems from the people around you.
People who belong to a race, which may not be yours;
belong to a Social strata, which may not be yours;
they may have educational background, which may not be same as yours;
they may even have a thinking style, which may not be yours;
they follow a religion, which may not be yours;
they may speak a language, which may not be yours;  
I think you get the idea.

But embracing integrity????    Hmmm.
The day is not far, when some scholarly management consultant will write..."we must embrace honesty". 

Role of a Product Owner, Business Analyst, and Project Manager

Yesterday, I happened to be a mute spectator of a heated (but mostly jugglery with words) discussion about what is a Product Owner, Business Analyst, & Project Manager.

After the discussion, I thought of penning down my thoughts about the same. So here is my simplified, no mumbo-jumbo, but fairly accurate summary of these 3 roles.

Well, fairly accurate according to me. YMMV.

Also, take it with a pinch of salt :)

(1) BA

BA: Last 3 weeks I was at the Customer's location. 
I just finished the documentation. This is how those people work.
These are the customer requirements.
And these are the non-negotiable requirements.
Dev Team: Hmmm.... but it will take 2 years to complete this?
BA: Who cares? Not my baby.
Project Manager: Forget making any profit, we will lose huge money if we have to complete this.
BA: Who cares? Not my baby.

(2) Proj Mgr
Proj Mgr: Guys, this is what we are going to do.
Dev Team: Hmmm...it is huge work.
Proj Mgr: I know. I am working to beef up our team. I will get an additional budget soon.
Sales Rep: We have committed to the final delivery and complete hand-over by the end of Nov.
Proj Mgr: Good. We will meet that, as long as you have not committed the year.

(3) Product Owner

VP Sales: Coke wants this ABC feature in the next 3 months.

PO: We have already checked the market pulse about it. Nobody else even remotely showed any interest in that feature.

VP Sales:  Coke has been our big Customer. Are you telling me that we can refuse the ABC feature to Coke?

PO: All I am telling you is, this ABC does not fit well in our product vision. And if my team shifts focus on ABC work for the next 1.5 months, my product will remain weak in TMQ area, which would be bad.

I know 6-7 customers who say that we should strengthen TMQ. And at least 1 prospect who said they can consider us only if we give them some commitment to strengthen TMQ.

Naturally, I am going to choose what will give us the highest RoI.    

 

  

Biggest (Unexpected) Beneficiaries of this "A"gile stuff

There are 2 types of businesses that are the biggest unexpected beneficiaries of this "A"gile stuff.

(1) Sticky-Note manufacturers. 
A vast majority of teams think Sticky-Notes are absolutely essential for an agile team; which works quite well for these manufacturers. For Sticky-Note manufacturers, "A"gile movement was a rather unexpected boon. But it was nothing as compared to this 2nd industry, for which it was a windfall.   

(2) Framework Training and Certification Industry.

Collectively they are also referred as Agile Industrial Complex (AIC for short). I don’t look down upon them. In fact, I respect them because they are extremely smart in identifying business opportunities, & even creating business opportunities. Under this AIC umbrella, many brands of “A”gile are available. A company can choose whichever brand of “A”gile suits them.

There is a certain brand of "A"gile that assures companies that in a span of 2-3 days, they can change the company staff into MASTERs of “A”gile.

This brand evangelizes that for becoming “A”gile, having one MASTER in a team is a must. A MASTER who will spread the “A”gile values within the team, empower the team, safeguard the team from outsiders, etc.  Some people ask if the cost of making a MASTER is so minimal (just 2-3 days effort), then why not make everybody in the team a MASTER.
That way everybody in the team will automatically know “A”gile values rather than depending on one MASTER for spreading those values. Everybody can empower each other rather than depending on one MASTER to empower all others. And everybody will be capable of safeguarding the team from 'outsiders' (whatever that means).
But such questions and such thinking is not acceptable if you buy this brand of “A”gile.

All said and done, this brand is selling very well. After all, which company would not like to be “A”gile so fast and with so little investment?

This brand is shipped with a User’s Guide. All the retailers of this brand tell endlessly that this brand recommends Empiricism.  But on the cover page of this User’s Guide, it is printed “The Rules”. Not guidelines, not suggestions, not recommendations, but Rules. When you are required to live by Rules, it is obvious that you must follow the Rules verbatim, to the dot, with no deviation allowed; that is why they are called Rules. The Income Tax Dept has "Rules", they do not go by "Guidelines". The game of Chase is played by Rules; not by Guidelines. 

So how this “Rule book” can be used to encourage Empiricism is something left to the people who buy this brand.  If a buyer goes back to the retailer saying this brand is not working for him (which is not unheard of), the retailer always has a ready answer… “You must be using this brand in the wrong way”.   
One may ask… if the right way of using this brand is known, then why these retailers do not tell the same to the buyers?  For which the retailers again have a ready answer; they say…   “This is intentionally left incomplete so that buyers should practice Empiricism”
How a Rule Book can be intentionally incomplete, is something left to the people who buy this brand. Just imagine the Rule Book published by The Income Tax Department is intentionally incomplete. 

If a company is large, has deep pockets, and most importantly if its managers love their turf and do not want to lose control, then a premium brand of “A”gile is also available for them.

This premium “A”gile brand is specifically designed for companies where managers want to create a good façade of “A”gile, but do not want to lose their nut-bolt level control.

Managers of such companies do not face much challenge convincing their decision-makers to buy this brand, even though it is very costly. It is quite possible that managers find it easy to convince their decision-makers to buy this brand BECAUSE it is very costly. And often this brand is sold directly to the decision-makers & managers without involving team members.

It is a well-known human psyche to associate higher cost with better quality. This is somewhat equivalent to what used to happen 50 years ago.  50 years ago, in the IT world, they used to say “Nobody ever got fired for choosing IBM”.   In short, when a company buys this brand of "A"gile, the decision makers are happy because they think that they have bought the best “A”gile for the Company. The managers are happy because their turf and their power will not be challenged.

Once you buy this brand of "A"gile, it comes with beautiful infographics which are very impressive to see, a list of recommended meetings that saves you from thinking on your own, and its own terminology which gives you instant gratification when you start using these new words. All of this is shipped free of cost.   

To install this brand of "A"gile, an Org must have special people with special certificates, which are not shipped for free. 
This brand is very very prescriptive, which is fine with managers. In fact, they are happy about it. This costly brand of “A”gile is so prescriptive that this brand goes on to decide at what time and for how long your team should have a lunch break.  

Any brand which is prescriptive has a great hidden asset. Managers can treat such prescriptive “A”gile brand as their insurance policy against failure to meet their business goals. They can easily point to the prescriptive way of working and claim that they have been working exactly as prescribed.   

One of the top organization’s (Spotify) top coach (Joakim Sundén) summarized his years of 1st hand experience in these 3 steps.

(1) Face your difficulties and think yourself.
(2) Solve your problems yourself.
(3) Profit. 

 
Actually, there are only 2 steps & the 3^rd one is the result.
In those 2 steps, the word “yourself” appears 2 times. This means it demands quite some thinking on your part, and devising working practices yourself. Naturally, this is not appreciated much by many prospective customers shopping for an “A”gile brand for their organization.

And then there is "a"gile.
To start with, "a"gile is just an adjective.
A team (or an organization) can be less "a"gile or more "a"gile, rather than getting stamped as "A"gile by a specific brand.

Luckily there is no manufacturer that sells “a”gile.

A team can strive to be "a"gile just by keeping in mind these 3 simple things... 
(1) Bite small.
(2) Chew well.
(3) Seek f/b often.
That’s all it takes to be “a”gile.  
But let me add 2 more simple things to elaborate it a bit further.

(0) Be humble. Being humble is not only a good personal characteristic, but it makes good business sense also. Being humble nudges me to slice thin, build small, and ship small /showcase small. Not being humble allows me to pretend that I know all the market needs and user requirements well enough.  IT world is littered with examples of what happens when someone assumes that s/he knows the biz requirements upfront. Here is a shining example of not being humble. 

(1) Bite small.

(2) Chew well.

(3) Seek f/b often.

(4) Use that feedback regularly. If the f/b is +ve, great. If that f/b is -ve, use that f/b to do a quick course correction and to avoid building a lot of waste.

The first time I get a -ve feedback, I tend to learn that "Byte small" (aka Slicing thin) would be a really smart move because it can help me avoid creating a big waste. I can easily make it a standard practice by ensuring that only Slices get added in Iterations and never a whole User Story. After all, it will be ridiculous to Slice a User Story, but not build it Slice by Slice. 

The first time I suffer a lot of to-and-fro between Dev and QC, I tend to learn that parallel testing is essential for "Chewing well". I should not treat Testing as a separate activity that can be done after writing code.
I can easily make "Parallel Testing" a standard practice by having a single Column on the Flow Board for Writing code and Testing. This small change ensures that both (Developers and Test Engineers) take collective credit & collective responsibility for "Quality" or "lack of Quality", “Done” or “Delay in Done”. 

This collective ownership quickly culminates into a better collaboration between Dev & QC, deeper involvement of QC folks while discussing User Story, and most importantly QC providing Test Cases early enough to Dev which hugely helps Developers.

 

The first time users would give me lukewarm and indifferent feedback for my hard work, I would realize that the market has zero interest in knowing how hard we have worked for shipping that new Release (aka Number-of-Story-Points). I would realize that the only thing that matters to the market/customers/users is whether my new Release made their life easy? whether my new Release made their work faster? whether my new Release made them more competitive? 

That lukewarm feedback from Market can help me to develop an outward focus. It reminds me to keep an eye on RoI while planning the work.

Honestly “a”gile is quite intuitive and common-sense oriented, but there are few folks who need to do some unlearning to get it. This unlearning can be attributed to the kind of hammering done on them to teach them “Project Planning”.

And in spite, of "a"gile being so simple & intuitive, many Orgs prefer to go by one of the many available brands of "A"gile, which are quite often loaded with nebulous theories, inflated mumbo-jumbo terminology, patented frameworks, deliberately added complexity & ambiguous vocabulary. 

After all what Edsger Dijkstra said 50 years ago, is valid even today.
He said, “Complexity sells better”.

User, User Story, INVEST criteria etc.

A good User Story should pass the INVEST criteria; at least, that is what they teach.

Allen Holub describes a User Story as…

“An expectation from software as expressed by the *end user* so that the software would help the *end user* in his/her **DOMAIN LEVEL WORK**.   
(Paraphrasing is mine, it may not be verbatim as Allen described).

Allen also mentions a popular example of “Login User Story” to describe what is not a User Story.   
“As a user, I want to log in, so that I can update my books of accounts” is not even a User Story, because “Logging in” is not a domain level work for an accountant; otherwise, it would have been covered in textbooks of accountancy.

Now some of these expectations can be expressed by a large number of users, and some by very few users.
Some expectations may take lots of work, and some can be fulfilled with very little work.
Some expectations are technically challenging to implement, and some are quite simple.
Some expectations can be fulfilled, some are impossible to be fulfilled, and some may not be fulfilled because of a conscious decision of the Product Manager.   

They teach that as per INVEST criteria, a good User Story should be

Independent,
Negotiable,
Valuable,
Estimable,
Small, and
Testable.

INVEST is easy to remember. It is a nice sounding mnemonic. One can talk about it for a long time in any "A"gile class. The real question is, how useful this concept is to tackle real world challenges?
Here is my take on INVEST. Needless to say, YMMV.

(1) Independent:

In the very early stage of any new product/project/endeavor, a US can be independent of other USs. But as you progress, any new US would mostly be dependent on some other already built US.  Because we always build some new feature/functionality on top of what is already built.

It is also possible that some US cannot be built unless some other US is built. In short, for the majority of USs in any product this "I" is a myth.

  

(2) Negotiable:

Negotiate actually means … “to confer with another so as to arrive at the settlement of some matter”.    

Settlement? Hmmm… we hear a lot about “Not a Contract but Conversation”.  We do conversations for better understanding and deeper discovery. Deeper discovery will most likely lead to better & more apt functionality/solution.

Provided our focus is not on settlement thru negotiation. 

PO:              With the help of this software, a Regional Manager should be able to assign Sales Targets to Sales Reps. The assigned target is always Quarter-wise & Product-line wise.
Dev Team:   Ok. But can we have the target as a single collective number?

PO:              Ummm. No. That is not how it works.
Dev Team:   I am just trying to negotiate to make it simple.   

PO:              Got it. But that simple implementation is not how the world works.

Dev Team:   I understand. But I am just trying to negotiate. A User Story should be negotiable.

PO:            Good. You have negotiated. But it does not change the expectation of users.
Dev Team:   This is not a good User Story.

PO:              Why?

Dev Team:   It is not negotiable.

 

(3) Valuable:
Some User Stories are extremely valuable for the users; some could be less valuable.

But can you imagine any PO, any team, working on any User Story which does not produce ANY value?

So, why mention explicitly “valuable” as a required attribute of a US?

The folks who teach us about INVEST actually mention that the "V" is for Valuable or Vertical.
{ Translation:  as long as you have a "V" and as long as you can make that cool sounding mnemonic, it is OK }

The same folks who teach us INVEST, also maintain an agile glossary in which there are 2 terms starting with "V"; "Velocity" and "Vesrion Control" but apparently "Value" is not fit to be in that glossary even though it is worth having it in INVEST.  

Every User Story will be valuable is a given; what matters is which US is more valuable than others. Because that influences the RoI, which in turn influences the prioritization. 
islandBRIDGE encourages a PO to assign a value to each User Story like this...

islandBRIDGE suggests using the FPGP mantra to give a ballpark number for the value of a User Story. {Obviously there could be diff/better ways }

(4) Estimable:
Dev Team:   This is not a good User Story.
PO:             Why?

Dev Team:   We can not estimate it. Actually, it is not estimable, so we cannot work on it.

PO:           If you want to know more, ask me more questions, ask for more details. I can provide all details, edge cases, etc. But estimating is something that you can do better than anybody else.

Dev Team:   We already have all the details. But it is not estimable. 
PO:             Ummm

 

(5) Small:
Dev Team:   I fully agree that this is a critical User Story; but because it is big, it does not fit in the required criteria of a good US.

PO:            Of course, there will be big User Stories and small User Stories. We cannot say a US is good or bad depending on the size. BTW, what is that criteria?

Dev Team:   It should be small.
PO:             What?

Dev Team:   Yes. A good User Story should be small.
PO:             OK, how small?

Dev Team:   Small enough to be completed in 2 weeks.
PO:              Completed by whom?

Dev Team:   By us.
PO:             So, what do we do now?

Dev Team:   Split it into small User Stories.
PO:            Maybe you should seriously rethink "what is a User Story". You can split a User Story in small slices; but when you split a User Stories, you will not get many smaller User Stories. You will get many small slices of a single User Story.  
Just like when you split a Country, you do not get many smaller Countries, you get many States of the same Country.
Of course, we can deliver a big User Story,  by delivering many small slices.  
In fact, it is a far better approach to slice a User Story (whether it is Big or Small) and seek early feedback after delivering the first slice or first few slices.

Dev Team:   Yes, that is what we are saying.
PO:           No. You are not saying that. If you say Slices are the same as many small User Stories, then you are using the term “User Story” as a placeholder for a piece of work. And using the term User Story in that fashion has some serious negative side effects.

{Whether a User story is Big or Small, it is always a good practice to make Slices of a User Story, build the User Story Silce by Slice. That way there is an opportunity to build Slices, showcase Slices & keep seeking feedback rather than shipping the entire User Story at one go. This way quick course correction becomes possible and creating big waste can easily be avoided.
islandBRIDGE goes one step ahead and allows to add only Slices in the backlog of a Sprint/Iteration, rather than adding a User Story. In fact, it is very natural for a User Story that few Slices are shipped, few are pending and few could be even dropped as you build and seek feedback. }

  
(6) Testable:
Keep aside a User Story, can there be any functionality/feature, however small,  developed in any software which cannot be tested? Seriously?? 

If someone tells me that this US is not testable, I would say there is nothing wrong with the US; but something wrong with the Tester!

So why explicitly mention that a User Story should be Testable?
Maybe just to have a “T” so as to make that cool sounding mnemonic of INVEST.

 

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."