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.