My Right-Hand Man at the Left-Hand of the US Ex-President.

Till some time back I was part of a SaaS Product Org and I had a colleague who was one of my best Product Managers. I can say he was my right-hand man. And even though for quite some time now we are on different paths in life, we are still well connected and still in touch.  Last week I met him in B’lore and he told me about the following chance incident which happened to him. In his own words, it was not a “once in a lifetime” incidence, but a “once in multiple lifetime incidence”.   I am writing about *HIS* experience in first-person narration style as if *HE* is telling you the story….

 -=-==-=-=-

I was traveling to attend a conference in Europe and to visit a few customers in the US. The conf got over and I took a flight from Munich to Atlanta. I boarded the plane and settled in my window seat. The boarding was over and all passengers were in their seats. But the air bridge was still engaged to the plane. It was a kind of lull and we all were expecting that we will start rolling any moment.  The seat on my right was empty, and I was feeling happy that I can stretch myself and have a bit more relaxed flight. Business Class is anyway comfortable, but having an empty seat in business class is a god sent gift. 

While I was planning my relaxed flight, a tall and burly man dressed in a pitch-black suit came in. Very slowly, looking here and there as if searching for his seat, he walked to the empty seat on my right, opened the overhead compartment, took out my laptop bag, and asked me if it was mine. I said yes. He kept my bag back where it was. He also kept the bag he was carrying next to my bag and then he did something strange. He slightly raised his left hand, just enough so that his arm was close to his mouth, and said, “All Good”. I could clearly listen to his words “All Good”. Looking at his burly frame and his mannerism, I had a weird feeling that I am watching some action movie. This guy was oozing authority and a no-nonsense kind of air. After saying those 2 words “All Good” he sat in the seat just behind my row. 

At this time I realized that there was an empty seat behind me and also one across the aisle.  Then it was quiet for about a minute or so.  And then suddenly one more burly man entered the plane and turned left and went somewhere in the front section of the plane. After 10 seconds another guy entered the plane whom I had seen before but I could not quickly recognize. He straightway walks to the empty seat on my right. All he is carrying is just 2 books. He stows the books in the front compartment and sits next to me. Immediately after taking his seat, he turns to me, extends his hand to me, and with a broad smile he says “Hi, I am Bill Clinton. How are you doing?”   I was so shocked, that I could barely manage to say, “Hello Sir, my name is Digesh”.  Now 2 more black-suited men enter the plane, one takes a seat just across the aisle and another disappears somewhere toward the rear side.

I saw thru the window that the air bridge is already pulled back and I hear the announcement from the pilot that we are about to start rolling.

By this time passengers on our right and front and behind had understood who is the passenger sitting next to me and why those 4 hefty men in black suits were in our plane as passengers. I was trying my level best to recover from the shock and think about what to speak and more importantly whether to speak with my co-passenger. Surprisingly my co-passenger was more interested in me rather than the other way around. On the next 9 Hours flight, we were talking for at least 7 hours. He took short 2-3 naps, but apart from that, we were continuously talking. So much so, I even dared to crack a joke with him asking him whether the call sign of this flight is Air-Force One.  To which he reacted with a roaring laugh and said No No No. I noticed the passengers across the aisle wondering who is this guy cracking jokes with the Ex-President of the USA.

Today I just wonder why this Ex-POTUS should take so much interest and ask so many questions to a common guy from India like me. Why he spoke so much and so many things to a common guy like me. He said, he was in Germany with family but Hillary and Chelsey flew back to USA 2 days back, and he extended his stay as he was scheduled to give a speech at some conference. He asked me about the Customers I will be visiting in the US. I told him I am visiting (A-FortuneTen-Company-Name-Here) in Atlanta and (A-Huge-Communications-Company-Name-Here) in San Jose.  He took great interest in the kind of work we are doing for that communications company and asked many questions. And then he casually told me "I know Mr. (A-BigShot-Name-Here) very well and he sits on the board of that communications company. If you need any help talk to him and give him my reference".

It was all so surreal and like a dream. So much so, he clinked his wine glass with mine. I had read about the Zero Emails he sent as the POTUS. And by now I was feeling so comfortable speaking to him, that I decided to verify that. So, I asked him whether it is true that you did not send a single email as POTUS? He said it is mostly true. So, I asked him “How you managed it?  (Just look at how idiot or arrogant I was while asking such a question to the Ex-POTUS). But he did not mind the question at all.  He squinted his eyes, thought for 2-3 seconds, and said, “Ummm...I never felt any need for that”. He himself opened the topic about the relationship between our 2 nations when Shri. Bajpaiji was our PM. He said though the relations were not at the best, he had great respect for Mr. Bajpai.

By now everyone on the plane knew who was the special passenger on our flight. Many came to his seat and requested a selfie and surprisingly he did not say no to anyone. And this way, we spend almost the entire flight having casual discussions about many topics. Was it my arrogance and stupidity to talk about so many things with the Ex-POTUS? Or was it his quality of making someone comfortable to talk to him?  Maybe it was the latter. Because he always looked forward to listening to what I was talking about. But the real shocker was yet to come.

We landed in Atlanta and while taxing in, the pilot made an announcement/request that we are having Mr. Bill Clinton as our co-passenger and all are requested to be seated till the Ex-POTUS and his Secret Service Agents are disembarked. There was a loud cheer and clapping in the plane. The plane came to halt, the bridge was attached and the door was opened. The Secret Service Agent behind my row had already taken his bag (I think that bag must have been of the Ex-POTUS) from the overhead compartment and was standing next to us, waiting for the Ex-POTUS to get up. The Ex-POTUS was still talking to me. When he noticed that the Secret Service Agent was waiting for him, he quickly got up. He got up and said, “Come”.  I was shell-shocked. The pilot had announced that all passengers should be seated till the Ex-POTUS leaves the plane. I also know enough that while on the plane, the pilot’s word is the law. Not obeying the pilot (or for that matter any crew member) could land you in serious trouble. And here was the Ex-POTUS asking me to get off the plane with him. I was dumbfounded & did not know what to do. He saw me confused, and said again “Come, join me”.

At this moment I simply got up, took my laptop bag from the overhead compartment and we started walking out. Myself, the Ex-POTUS, and his 4 Secret Service Agents.  Within no time we reached the Immigration area.  He pointed me to one of the counters, shook my hand, and said “Good luck. Let us meet sometime in the future”. And the Ex-POTUS and his 4 SSAs quickly walked away from me.  

I had visited the USA dozens of times before. I was never roughly quizzed as such by any immigration officer, at any time. But never before I was allowed to enter with zero questions also.  The immigration officer would ask me at least where I am going, which Org I am visiting, etc. This time it was going to be different. I strongly feel the officer had seen me coming with Ex-POTUS. The officer took my passport, simply stamped it, said welcome to the USA, and gave it back to me. No smile as such, but no question also.

I never talk about this with strangers because they are more likely to feel that I am pulling a fast one on them.

-==-=-=-=-=-=-=-

I completely agree with my friend and my ex-colleague. 
Someone who listens to such a story can easily feel that it is just an imagination.

Till you see this… 

Few Simple Tweaks to Boost Value Shipping

I have used following simple tweaks to produce great benefits in our endeavor of shipping value to the market.
To implement these tweaks we spent zero money and it does not ask for any certification either.  All it took was an open mind and some practice.  
Maybe this could help your teams too.

1) Parallel Testing:: It needs some mindset change. All it requires is Dev+QA participation while PM/PO is describing the User Story and a common desire by Dev+QA to produce good code.
An additional benefit of this practice would be, QA fols stop thinking that "Logging MORE bugs" is the yardstick of their performance.
They would inculcate thinking that NOT allowing a bug to creep in, is their real yardstick of their performance.

Even a mason knows the right time to use his plum bob is, while building the wall, not after building it.

2) Merge Columns:: On your wall board (whatever board you call it) you should not have 2 separate columns for “Development” & “Testing”. Having these 2 columns is as good as giving a license for having silos for "Dev" & "Testing".
Just merge these 2 columns into a single column and call it “Building”. You will see the magic it brings in terms of team collaboration, particularly between Coding and Testing functions. 
A work item (UserStory / UserStorySlice) in this column becomes joint ownership of Developers & Testers. It will come out of this column, only when Developers AND Testers feel happy about it. 
You will see how radically it reduces to and fro between Dev & QA.

3) Vertical Slicing:: Slicing User Story needs zero money. Though it needs some practice by PM/PO. It also needs some change in the way PO & Dev decide to ship. It needs some curtailing of ambition for Shipping the entire User Story in one go.
This sounds a bit counterintuitive, but this is extremely effective as it avoids a good amount of wastage from being built.

4) Information Radiator:: Radiating only those metrics that matter is crucial. Deciding your North Star metrics involves some thinking, actually a good amount of team thinking, (sometimes involves heated arguments within the team). A team needs just 2 things for an  Information Radiator
(a) a brutally transparent way of working and (b) a large monitor placed in a common area.
Placing your Information Radiator in the corridor on the way to the coffee machine is a perfect choice. Radiating the information to ALL (within the team as well as outside the team) is the key. The money spent on the large monitor will be paid back 100 times in a matter of 2 months. 

Information Radiator nudges us to focus on the right questions and helps us to avoid wasting time on bike-shedding.

5) Acceptance Criteria:: Start working on a UserStory only if it mentions some Acceptance Criteria (even if it is minimal). Inculcating this discipline of mentioning Acceptance Criteria costs zero money and this practice will reduce the chances of getting a boomerang from the customers. It nudges the PO to develop good outward focus and that hugely helps the PO while describing the User Story to the team.
At the same time, the team (particularly the Dev Team) must keep in mind, insisting on Acceptance Criteria is just to nudge ourselves for a better discovery process. It should not be treated as a Contract. 

Well-Refined Backlog

Who does not want to have a well-refined backlog?
Unfortunately “well-refined” does not have a universally accepted definition. Neither it is a DIN standard. 

So, any team, any org can have its own interpretation of a “well-refined” backlog. 
Here is my interpretation of what I mean by “well-refined” backlog. It consists of 5 aspects.

1:  User Stories should/must be sliced. The thinner the slices, the better it is. 

2: PO should have a fair idea about the Value of each slice. Value as it would be perceived by the Market/Cust. Even though this is always an educated guess, a PO who knows the pulse of users/market will be able to take that educated guess. 

3: Eng folks should have a fair idea about the Cost (Effort) of each slice. A rough guesstimate is preferred rather than chasing the illusion of an Accurate Estimate. In fact, chasing this Accurate Estimate has some seriously damaging side effects.

4: PO should have a fair idea about the Acceptance Criteria of each slice. This will nudge the PO to be outward-focused.

5: PO should have a fair idea about whether this slice is needed now, or it can wait. Again, when PO is outward-focused, s/he can easily take a call on this. 

A well-refined backlog automatically helps the team to prioritize their work as per the RoI it will produce.

A well-refined backlog will help the team to radically reduce the "waste" since the team is encouraged to build, showcase, & seek feedback on slices, rather than shipping the entire User Story. 

A well-refined backlog will save a truckload of time that would have been spent on "accurately" estimating User Stories.
Since the team anyway would not be building the User Story in its entirety, it would be meaningless to estimate a User Story in its entirety.

Agile WoW and Fluff v/s Crux

 A few days back, I happened to see a team discussing enthusiastically about all this "A"gile stuff. I was a mute spectator, but their discussion taught me a lot. 

The discussion was about team agility and related things. Everybody was very vocal and keen to share their point of view. The discussion went something like this....

A: It is not a framework; it is just a toolkit.

B: I think it is more of a mindset than a toolkit.

C: I agree. It is less of a framework or toolkit and more of a mindset and methodology.

B: Let me put it like this... it is just a set of working practices based on values.

A: To me, it appears like loosely worded principles, guiding us to a value system.

B: It is loosely worded, but it is intentionally loosely worded. 

D: What matters is a collective mindset where everyone respects everyone. Giving respect is most important.

B: Don't you think transparency is more important than respect ?

D: No. Respect is very crucial. Once you respect everyone, transparency follows.

B: OK.

C: But respect alone does not mean anything unless everyone feels psychological safety.

B: Yes, psychological safety is very important. How can we improve psychological safety?

D: I read somewhere that you can not improve anything unless you measure it.

B: Cool, how can we measure psychological safety?

A: We can invite HR folks here. They are good at all such things. They must be knowing some good consultants for this.

C: Last week I came across a consultant, & she was talking about Beyond Agile. 

A: Beyond Agile… that sounds so cool. Like Enterprise Scaling and things like that?

C: No, she said now the concept of Enterprise Scaling also has become old.  She was talking about Systems Thinking and Design Thinking and SineFine Framework or something like that.

B: Sounds very exciting.  Should we have some training on these things?

C: Yes, that will be exciting.  I think we have some training budget left, correct?  Or I can manage some more budget if required.

E :  Guys, Can you talk a bit softly?  Please ??   I am on a phone call.  I am talking to a customer to get some feedback on our last delivery.  This feedback could be important to us.

I was wondering whether Agile WoW is an acronym for “Agile Ways of Working" or "Agile Ways of Wording". 
I have been seeing organizations where Wording is winning over Working. 
Unfortunately, Fluff is winning over Crux.

Who Can Empower Others

History shows that a group of empowered people can achieve something which is beyond imagination, provided they are united by a common end objective. Empowerment is meaningless if the team is not committed to a common end objective that holds the whole team together, irrespective of role, irrespective of individual skill set, irrespective of designation, and irrespective of seniority. Robert Oppenheimer is a shining example of empowering a hugely distributed team, working on a frighteningly tight schedule, working in a completely new & unknown domain, like creating the 1st Atom Bomb.

One can empower a team if and only if that person is accepted as the team's undisputed leader, and his/her authority is well-accepted by everybody on the team. But like many other words, “Empowerment” has also become overused, misused, diluted, and maybe a word with a great degree of pompousness. 

The story goes that, one day just before a test match,  Saurav Ganguly told Sehwag..."You are going to be the opener for the team along with Sachin. I expect you to make a solid foundation for the team. And for that, you have to be the opener, you can’t play at #6 of the batting order and make a solid foundation”.  You can watch it here for about 1 Min. {You may like to have Engish Closed Caption=ON}  When Dada told this to Sehwag, Sehwag was scared and nervous. Dada could empower him because Dada was in a position to empower him. We all know the outcome of Sehwag becoming the opener for the team. One of the most destructive batsmen produced by India.

When thousands of people in the stadium shout and cheer for Sehwag, they encourage Sehwag. But by no means they are empowering Sehwag. They simply are not in a position to empower Sehwag or any player.  Do they encourage players? certainly Yes. 

So, I find it a bit bizarre & laughable when someone with 3-4 years experience undergoes some 2-3 days of training, gets himself stamped as a MASTER, and starts telling others that now it is his responsibility to EMPOWER his team members.    

Empowering People

I feel empowering people and trusting people is very important. It is very important in every walk of life, but more so in the knowledge industry where life is full of unknowns, halfknowns, and lessknowns.

Getting agreement on common End Objectives and setting up the right work culture is very important and it works well for empowering people.  In fact, agreement on a common End Objective is the 1st point of my 6 point recipe for Being Agile. 

But if an educated & adult person is not excited about the work, then no amount of effort and persuasion can empower that person. So, I find it completely laughable that some Orgs keep one person in the team with a full-time responsibility to EMPOWER other members in the team.
In fact there is a framework that has devised a special role for this, the person in this role will keep EMPOWERing other people. Often this person is also tasked with equally nebulous & lofty things like being the FACILITATOR. Since this person generally comes with a MASTER stamped on him, this person also starts genuinely believing that EMPOWERing people is his responsibility.
Nothing else can be far from the truth than this.   

I am writing this today because I saw this video which touched a chord.   

Making Retro Interesting

A common (actually too common) question I see from SMs is... how do I make our Retro interesting? 

Many kids do not find arithmetic interesting. 
But the teacher knows that future life will be tough for kids without knowing arithmetic. So, the teacher devises ways to make arithmetic interesting by gamification.   

But that is not the case with educated, smart, adult people working together for solving a real-world problem. 
Writing software to solve eal-world problems is inherently an interesting process.
Many teams do Retro to make this process more efficient. So the Retro itself also should be interesting.

But the question I face from countless SMs is... "how to make our Retro interesting for everybody?"

Now here is an observation. I rarely see questions like...
- How to make our market discovery interesting?
- How to make our story slicing interesting?
- How to make our testing interesting?
- How to make our feedback gathering interesting?

Are these not crucial for building good software?
But the question is always...
- How to make Retro interesting?

There could be two reasons for that.
(1) Maybe they are learning / communicating / sharing / adapting as they go on a day-to-day basis, rather than waiting for the iteration to get over and rather than waiting for the Retro. Hence they find Retro as a waste of time. If that is the case, then it is an ideal way to work.  

(2) Or maybe they are not interested / excited / proud about their work in the first place. In that case, there is no way they will find the Retro interesting despite how hard the SM (or anybody else) tries to INJECT the interest in it.

In such a case, the problem is much more severe & completely different. Naturally, the solution also would be different. This is so perfectly (and somewhat bluntly) described in just 2 minutes in this video. 

Gist for those who do not understand Hindi:
It is the DUTY of the team leader to present the end-objective to all in the team, in a very crisp and clear manner. Those members who fall in love with that end-objective, will give their best to achieve it. They will be committed to achieve it by working along with every other team member, because they understand that it is the end-objective for the entire TEAM.  
But those members who do not fall in love with that end-objective, should not be part of that team. It is not good for them, and not good for the team.

Is it Difficult to be a Stingy Product Manager?

Is it difficult to be a stingy person?
In real life & at a personal level, No.

Is it difficult to be a stingy PM in a professional life?
Yes. Very difficult.
At least that is what my observations tell me.  

If you are a stingy person, naturally you will spend less. 
And even if you spend, you will ensure that you get the maximum out of what you spend. I think that is a fair assessment.

Imagine a PM.
Typically, s/he has a mountain of Backlog in front of him. And he wants to finish that backlog as much as possible, as fast as possible. And that attitude & drive works well for his reputation in his organization.
He is considered an ambitious person.
He is considered a go-to person by his top bosses, by stakeholders. 

Now imagine another PM.
S/he is rather stingy.  She does not hesitate to reply “No”. People say that she replies “No” too often.  She always picks up that smallest feature/enhancement which can produce the highest WOW reaction from the market. She knows that to get WOW from the market, she has to deliver value to the market. Not only deliver Value to the market but this Value must be perceived and appreciated by the market also. She always works and plans by keeping the RoI in mind. And she guns for the highest RoI. She is not driven by some meaningless & actively dangerous metrics like Story Points or Velocity for gauging success. But she keeps a laser-sharp focus on delivered value every Month/Quarter etc and the market feedback.

And here is the catch. To gauge WHAT would create the highest WOW from the market, she must know what would be perceived as “Valuable” by the Market.  For that, she needs to be extremely outward-focused. She is generally able to distinguish between Market Needs and Market Wants. For that, she gathers market feedback often, on a regular basis. She makes the Market Feedback transparent and visible to everybody on the team.  And she uses this feedback to do course corrections as & when required, as early as required. 

That way she avoids producing waste to a great extent. She knows that if any waste gets created in the product, just removing that waste from the product also takes some development effort. And it makes the team demoralized as well.  But being stingy she ensures that the likelihood of generating waste is very less. 

And to top it all, she does not consider her job is to ship more stuff. She thinks her job is to create more value for the product and for the market. She knows that being stingy helps her (and the Org) to ship better value faster. She also knows that creating more value for the market is the way to create more value for her organization and for herself.

Just like a comedian does not think his job is to tell more jokes to the audience.
A comedian thinks his job is to extract more laughs from the audience.

3 Types of Metrics

"We water our Mango orchard twice a week". 

This is a typical example of a Process Metric. 

"We produced 3 Tons of Mangoes last year." 

This is a typical Output Metric.

“Last year, our Mango orchard made a net profit 84 Lakh” 

This is a typical Outcome Metric.

If we are responsible for running a chemical plant, then monitoring every smallest parameter is crucial and extremely important. Not tracking a parameter can even be life-threatening.  

If we are in the knowledge industry, particularly if we are involved in creating something INTANGIBLE (like software), then process Metrics are almost useless, if used in isolation.
They should be used hand-in-hand with Output Metric.

In the knowledge industry, Output Metrics are almost useless, if used in isolation. 

They should be used hand-in-hand with Outcome Metric.

Generally speaking, Sr. Management in any company is interested only in Outcome Metrics.
Because Outcome Metrics reflect how our work is helping our business. 

Sr. Management may shift their focus from Outcome Metrics to Output metrics when they are not happy about Outcome Metrics, or Outcome metrics are not shown to them at all. 

If your Sr. Management is looking at Output Metrics, that is not a good sign for the team.

Sr. Management shifts their focus from Output Metrics to Process metrics, when they are not happy about Output Metrics, or Output Metrics are not shown to them at all. 

If your Sr. Management is looking at your Process Metrics, treat it as a red flag.
A big bright red flag for the team.

A Good Multitasking

There is only one type of multitasking which is not bad for Developers. In fact, it is damn good.
And that is… Coding along with Testing.

Unfortunately, a very large number of developers treat the Testing activity as not part of their work. 
A large number of Testers think that Testing can start only after developers throw their code above the wall in Tester's compound. 
Most unfortunately many Organizations feel it is the right way of building software.

All these things are not only wrong but almost a crime.

If you really want your team works like a well-oiled engine and ship better value faster, ensure that testing takes place as coding/development progresses.

Even better would be the testing performed by the developers themselves as they go along.
A QA Engineer should be mainly paid for visualizing potential pitfalls as early as possible, writing suitable Test Cases for them, and providing those TCs to developers as early as possible. They should not be paid for catching more bugs, but for allowing fewer bugs to creep in.

Skills, Qualities I look for in a Product Manager

I have spent quite some time, fighting product-building battles from trenches. In the process, I have got a liberal dose of mud, sweat, bloody wounds & scars. In these battles, the soldiers in my battalion were Testers, Designers, Developers, and very importantly Product Managers.

Sometime back a founder asked me about the skills/qualities he should look for in his Product Managers.  So here is what I jotted down at his request.

- Ability to observe the Market and find a void/opportunity in the Market.

- Ability to sense the changing trends in the Market.

- Ability to see a Market Need which may have been fulfilled by others, but can be fulfilled better by us.

- Ability to ensure Need/Solution fitment.

- Ability to explore and carry out SWOT analysis.  Each situation does not ask for every aspect of PESTLE analysis, but taking a conscious call is critical.  

- Ability to gauge ** whether we can make money ** out of it.

- Ability to sell the Market Need internally in our own organization and get some budget/funding to build SOMETHING to fulfill that Market Need. A truckload of funding appears better but it can be actually dangerous as well.

- Ability to curtail the ambition and build that tiny, small, crippled-down, crude, unpolished, basic version of the solution (aka MVP) for that Market Need and showcase it to the Market and seek feedback, so as to Validate our hypotheses.

- Ability to decide (based on the feedback) whether to  (a) Continue or  (b) do Course Correction or  (c) Pivot  or (d) Drop the idea.

- Ability & willingness to accept the fact that Product Building business is sprinkled with many unknowns, half-knowns, and less-knowns.

- Ability to maintain the rhythm of ship-small, ship-often to tackle the risks arising from half-knowns and less-knowns.

- Ability to sense risks before they hit us.

- Ability to be extremely stingy and identify **that** specific portion of work that will give the highest RoI. (Here are my thoughts on how to be a stingy PO. It needs some practice, but it is possible).

- Ability to be a bit thick skin if you are shunned by prospects/market/anybody (which you will be from time to time).

- Ability to read the pulse of Market/Cust/Prospect/Competition/Sales/whatever.

- Ability to inspire and make the entire team your equal partner in the battle.

- Ability to choose between right and right (making a choice between right and wrong is very easy).

- Ability to be honest, open, & candid and own the goof-ups made by you.

- Ability to remain curious and keep eyes and mind open to seek new ideas.

- Ability to gather data, analyze data & use data. (Cust Acquisition Data & Prod Usage Data being the most critical).

- Ability to convince others when your answer is NO.

- Ability to say NO, even if others are not convinced.    

Product Managers typically have a mountain of backlog in front of them. So, this last one is quite a crucial quality for any Product Manager….
- Ability to decide  ‘what_is_needed_now’ & ‘what_can_wait’.   (in short,  WNN v/s WCW )

 

Magic of Merging Columns

Try this simple change in your Kanban Board.
Merge “Development” & “Testing” columns in a single column and call it “Building”.
Needless to say, any work-item will pass this "Building" column only after a joint concurrence by Dev & QA.

To implement this, maybe you will face some reluctance.
Maybe they will say "why to change when it is working fine".
Maybe you will face vehement resistance.
Maybe they will say "this is not the way it works here".

If they tell you any of the above, it is a sign of they are striving for local optima. 
But if you manage to change it, just in a matter of few days you will see the power of visualizing TCs in advance.
You will see a reduction in ping-pong between Dev & QC.
You will see the magic of parallel testing.
You will see the boost in quality just in a matter of a few days. 

A Damaging Side Effect of Story Points

For a long time, Estimation is considered a top skill. Today most of us are told not to estimate our work in Hours or Time. The sad part is most of us believe in it.
This is because there is a notion in this new religion that Estimation of work should not be done in Time. Instead, the disciples of this new religion insist on using some kind of T-Shirts or some kind of cards or some Story Points for Estimation. 

Irrespective of what this religion says, the business still demands some time peg for the deliveries. All they want to know is... What is your approximate time peg for this work to get completed?
Now that is a fair question. Many experts also feel that it is a fair question.  And because it is a fair question, a convoluted conversion starts from Story Points to Time. But there is no standardized Story Point, and no two teams agree on what is "1" Story Point. Naturally, Story Point to Time is a rich land of confusion and never-ending debate.  All this could have been easily avoided if Estimation was not done in Story Points in the first place.

The baffling thing about this Story Points is, that it is not even mandatory. No framework says that it is mandatory to estimate using Story Points. And still, most of the “A”gile practitioners, treat Story Points as if it is the soul of being agile.

So much is the obsession for Story Points, that the fact is completely overlooked that even the person who is considered to be the inventor of Story Points, publicly said that he feels sorry for inventing Story Points. And still, Story Points are treated by most “A”gile practitioners as if it is part of the Constitution and their team's ability to ship better value faster depends on using Story points.

And this gives rise to the real damaging side effect of using Story Points for Estimation. (Maybe unintentional but still serious damage for the team). The damage is, Story Points usage sets a culture where a team starts celebrating The Effort, rather than The Outcomes. The race starts to burn more & more  Story Points in a Sprint, simply by gaming the Estimation. The ultimate manifestation of this gaming is, Sprint after Sprint 10% increase in Velocity. 

What can be a better example of gaming the numbers? 

Complexity Sells Better

Adopting a new framework in a large team is a tough job. 
If it is being enforced/pushed from the top, it is quite likely that it will become a regimental way of working and will just result in some cargo cult practices.

For organizations, following a certain framework may not produce the expected business results.
But for many Sr Managers, it surely acts as a safety net.
Particularly if that framework certification is costly.

When you are expected to *follow* a framework or a transformation Guru or both, you are relieved from using your own judgment, relieved from making your own observations and relieved from taking responsibility for your own actions.

No wonder you see hundreds of discussions/advice in LI forums, where you can read these words…  "as per XYZ guide, you should be doing so-and-so things; or else you are not XYZ compliant".  Clearly, the entire focus here is on being "XYZ" compliant; not on boosting Value Delivery to market.

You may not believe this but there is actually a framework, that even tells you how many *Hours* of a meeting we should have to plan the next 10 weeks of work AND at what time we should take a *lunch break* during that meeting.
And all this minute-level planning for the next two and half months duration in the name of being agile.
This framework certification is selling pretty well even though it is damn costly.
Maybe it is selling well because it is costly.
It also comes with a detailed & complicated-looking infographics and its own set of buzzwords. Which is a bonus. 

40 years back, they used to say  “Nobody ever got fired for choosing IBM”.
The same "safety net” mindset plays when a mid or large organization tries to follow some "A"gile framework in a verbatim manner like a doctor's prescription.  

The more the cost of adopting that framework, the more costly the certification, the more elaborate & convoluted infographics and diagrams of that framework, and the more complex rituals of that framework, the decision-takers of these mid/large organizations feel safer.  

As Edsger Dijkstra famously said... "Complexity sells better”

Cigarette & Framework

Yesterday I came across an article on LI.
The author was quite annoyed and he was complaining that… “XYZ framework is killing us”.

Here is a somewhat different way to look at it.

It is like saying, the cigarette is killing me.

A cigarette is a non-living thing. It does not force me to do smoking. For that matter, nobody forces me to do smoking.

It is my conscious decision to smoke which is killing me.

Along the same lines, if I say that XYZ framework is killing me, it is just externalizing the problem.
It is not mandated by law that I follow XYZ framework or TMQ framework or ANY framework for that matter.
Using any framework is a person’s (or Team’s or Organization’s) own conscious choice. Any intellectually honest person or a Team or an Organization should take ownership of their conscious choice.

 

 

Habits and Muscle Memory

(This is something I wrote quite some time back on my phone on 14 Sept 2020 from a COVID Hosp)

 

Today morning I was waiting for my turn for the daily check-up in COVID Hosp. There was a queue of 10-12 patients and even though there was ample space, I was surprised to see all of them were standing very close to each other; almost *touching* each other.

Now they were well-educated people, and they must have been hammered at least 10,000 times in the last 5 months by no other than our PM. Our Prime Minister has been telling us relentlessly ... Do Gaj ki Doori, Sabake Liye Jaroori.

But all that relentless hammering was meaningless when it comes to their natural behavior. Our natural behavior is not driven by knowledge or data. It is driven by our deep-set habits. From childhood, these habits are set like a drip-irrigation system. And it is very difficult to accept something new, even if it is obviously logical and obviously beneficial.

In our professional life also, we are drip-irrigated from the early days to believe that solving complex problems is cool.  So, it does not come naturally to us to look out for some simple work that can give more value to customers.

We are brainwashed to think that carrying more work in our hands makes us look more capable. So, it does not come naturally to us to think like... Let us focus on just these 3 vertical slices, the remaining work should wait.

We are brainwashed to consider multitasking is cool. So, it does not come naturally to us to think Multitasking is nothing but a diluted effort.

The funny thing is hundreds of software professionals happily give a good amount of money to learn these simple & logical things based on common sense, in a 2 days training program and then go back to their offices just to fall back into the same old working style within a week. 

And all these people are highly educated, and intelligent folks. It is not that they lack intelligence or logic. Not at all.
It is the power of drip irrigation and old habits and muscle memory that beats logic, intelligence, and common sense.

{ In this article I have used words "we", "us" etc.  Read it as "Most of us" }

 

Prerequisites for agile journey.

Companies & people across the world are investing truckloads of money to be “A”gile.

There are many service providers (from Agile Industrial Complex) who are more than happy to make these companies “A”gile. These service providers have developed their own frameworks, their own tools, their own terminology, their own philosophies, their own roles, and even their own types of meetings. All agree that being "A"gile is a time-consuming, money-consuming, demanding, and exhausting journey. 

Surprisingly none of these service providers educate me on what prerequisites I and my team should fulfill before we start this arduous journey of being "A"gile.

Here is another thought.
If you and your team want to be 'a'gile (<> "A"gile) in your thinking and working, using a framework is not at all a mandatory thing. 
But before you start your agile journey, I will strongly recommend you keep these prerequisites in mind. 

Here are those 3 prerequisites.

1. Burning desire to do better in terms of the team's common end-objective.
   (This assumes that the team agrees that there should be a end-objective for the entire team, agreed upon by the entire team, rather than person-specific or role-specific objectives.)
   
   
2. Having an open mind and keeping curiosity alive. 
   (Those folks who prefer rote learning from various rule books or guides are less likely to fulfill this prerequisite. Using these Rule Books can be a great way to establish Rule Adherence of your team; not agility of your team.)
   
   
3. Willingness to maintain complete transparency.
   (Nothing can teach a team better than a transparent working environment. Displaying your team's Information Radiator in a common area where anybody can see it, magically changes the team's thinking. It will save you from bikeshedding. It will nudge you to ask the right questions, which will nudge you to take the right actions.)   

When a team (or an Org) is about to start its 'a'gile journey, I strongly suggest they step back a little from their busy schedule and spend some time together to give a thought about whether they fulfill these 3 prerequisites.  

If they fulfill, they are already at a jumpstart position.

If they don't, at least they will start working on it.
In fact, it will save them a lot of wasted effort, time, and also money.
When a team does not fulfill these prerequisites, all they learn will be some cargo cult practices from rule books and adherence to certain ceremonies of certain 'A'gile framework.  

  

 

Recipe for "being agile"

 I think this “being agile” stuff is simply bloated with rituals and ceremonies which actively encourage you to “Adherence to Process” rather than “Ship Better Value”.

It is also sprinkled with tons of buzzwords, newly coined nebulous ideas which can be discussed endlessly but can never be concluded.

So here is my ridiculously simple and easily actionable recipe for “being agile”.  It is very short, and it works for us.

Intangible Things like Software

Civil Engineering & Software Engineering. The context is not the same.

Too often I see principles of Civil Engineering being used in Software Engineering, like BDUF and elaborate Gantt charts, and WBS, and….

For a long time, it was OK. But the world has changed, and almost everything has become frighteningly fast. Be it Cricket, making a movie, or building and launching software. 

As PaulGraham said, if you are running on the road and if you want to come to a halt, all you have to do is incline your body a little bit backward, and you will stop quickly. But while skiing if you want to halt, and if you do the same trick of leaning backward, you will have a spectacular fall.

Using principles from one context in another context could be a bad idea, even if those are solid and proven principles. Manufacturing tangible goods (like pens, shirts, airplanes) and building intangible things like software are quite different contexts.

For tangible goods, specifications are known & frozen before you make them.
For intangible things, specifications start evolving as you start making them.

In Civil Engineering it is perfect to adopt the policy of Ready-Aim-Fire.
In Software building the right way is…   Ready-Fire-Aim-Ready-Fire-Aim-Ready-Fire-Aim-Ready….

The context matters.

User Story

One need not be too fussy and fastidious about words and terminology we use as long as the intent is clearly communicated and the action plan is well communicated. But sometimes usage of a wrong word leads us to think in a wrong way.  For example, ‘Testing Story’ or ‘Technical Story’ or “Hardening Story” or “Design Story”.   I have even come across “Training Story”, no kidding.

In reality, there is no such thing. There is just ‘User Story’.  

As Allen Holub says, a User Story is an expectation from the software as expressed by the end user so that the software helps the end user in his/her **DOMAIN LEVEL WORK**.   If User Story does not relate to the Domain level work of the User, then it is NOT a User Story. Naturally “Ability to Login” is not a User Story for accounting software, because login is not domain-level work of an accountant. Had it been a Domain Level Work of an accountant, it would have been covered in Accountancy textbooks. 

Most of the people I come across use “User Story” as a code word (or a place holder) to package any kind of work. They also feel that unless they use this code word, their Agile certification will be taken back 😊. 

So they try to force-fit any kind of work using this Agile syntax ...“As a XYZ I want to do ABC”.
And in the process, they do not hesitate to use Developer in place of XYZ. 
That is, they themselves become users of their work, just to satisfy the “Agile syntax” of a User Story.

Business Agility

A couple of days back one Agile Guru called me. I thought of taking that opportunity to ask him one question that had been in my mind for quite some time.  Here is a gist of it.

-Hello, can I ask one question?
--- Sure go ahead. 

-What is Business Agility?  Is it that type of agility so as to improve the business?
---Ummmm, yes. But what you said sounds too simplistic.

-So how would you describe Business Agility in an impressive & non-simplistic fashion?
---Business Agility refers to the rapid, continuous, and systematic evolutionary adaptation and entrepreneurial innovation directed at gaining and maintaining competitive advantage.

-That sounds really impressive. But does that boil down to agility to improve the business?
---Yes. In simple words, that is correct.

-Is there any other type of agility, apart from Business Agility?
---Ummm, yes. You can say Technical Agility.

-If Technical Agility does not help to improve business why one should go for it?

---beeeep beeeep beeeep. Suddenly his phone went dead.

Coca-cola, Agile, FOMO

Think about Coca-cola.
Are they doing good business? Obviously yes.

Are they forcing people to buy their drinks?
Certainly not. People buy Coke using their free will. Does it do any good for people? I don’t think so. For that matter, any sugary, carbonated drink is bad for your body.

But that is what *I* think.

People need not think the same way as I think.
Obviously drinking carbonated drinks must be doing something good for people. Maybe it is instant gratification, or appearing cool, or a sense of being part of a progressive generation, or whatever.

A few days back I read that Kent Beck thinks of Agile as a devastated wasteland because this Agile stuff has become a few religious rituals being carried out by people.  Maybe it is true. IMO there are more and more frameworks giving birth to more and more rituals.  And there are thousands of organizations and individuals who are spending millions of hard-earned $ to become a citizen of this wasteland by following these rituals.

But here is a point...since they are doing these rituals by their own free will, they must be getting something in return. Maybe following some rituals makes them really more valuable to their business, or it is the instant sense of belonging to a high-tech tribe, or a feeling of looking cool, or avoiding the FOMO, or some may even use these rituals as a safety net.

Just like buying from IBM was a great safety net in the past. In fact, about 40 years back it was a well-known phrase that “Nobody ever got fired for choosing IBM”.

Whether it is carbonated water or frameworks, due credit must be given for their superb marketing.  The biggest beneficiary in this Agile Industrial Complex is the Training Industry & the Certification Companies.

Nothing wrong with that.
Everybody wants to be “A”gile in a simplified, assured, time-tested, certified way.

And those who are already "A"gile certified, want to boost their “A”gile Maturity Index.
These are good days for AIC.

Metrics

I dislike using any metric related to StoryPoints, since it actively disconnects a team from the Market and from the end-users.

That disconnect is positively dangerous because it conditions everybody’s mind to celebrate the Effort, rather than celebrating the Outcome. 

What is the right metric for Outcome?

(1)
Needless to say, the audited balance sheet is the best Metric for Outcomes.  

But for that one needs to wait till the end of the financial year, it is a long time. Actually too long to take any meaningful corrective action.

(2)
The second best option can be the Metric that represents "Value shipped" per Week/per Month/per Quarter or whatever. 

Typical resistance/reluctance from a team to any metric related to Value is, that it is difficult to measure Value. Which is kind of true. 

But that can not be a good reason to settle for a metric that indicates nothing but Effort, like Velocity. 

That would be like saying... since it is difficult to obtain protein, let us settle for carbohydrates alone.

The effort is (mainly) an educated guess by the Engineers, and the Value is (mainly) an educated guess by the Product Owner. 
Both are educated guesses.
A metric related to Value_added_to_Product is worth tracking.  
When a team thinks about the Value of a piece of work, they can start thinking about the RoI of their work. And in turn, it leads to prioritizing their work based on RoI. 
A team can not do that unless it is an outward-focused team.

(3)
It is also of utmost importance to use Voice-of-Customer as a metric, which helps the team to validate the ‘Educated Guess’ made by the PO about the Value.

VoC Feedback helps the team to understand what is the "Market Perception" about the Value they have shipped. 

VoC also nudges the team to do the Course Correction as & when required, as quickly as required. 

Interviewing users is extremely useful to understand Usage Experience, Ease of Use, etc.
But a well-designed product with good Instrumentation Code built into the product itself delivers tons of Usage Data to the Product Managers & Dev Team w/o asking a single question to the end users. This is a very powerful way to gather invaluable & unbiased usage data.
A well-designed product also (often) means that it is built with Feature Toggle capability. That would help the team to do A/B Testing quickly and gather VoC Feedback accurately.  

Metrics that indicate Value and VoC, nudge the team to be more & more outward-focused. And a team can not be "a"gile unless being outward focused. 

I am talking about "a"gile , not "A"gile.

To be "A"gile, there are lots of certifications available from multiple vendors of the Agile Industrial Complex.