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