Is agility fueling organizations towards profitability?

Let me begin this blog by relating one of my travelogue experiences. A known taxi driver drives me in his car to the Mumbai airport every week from the last 4 years. The car is about 8 years old, poorly maintained, and has tugged a good more than 300000+ kilometers; has by all means attained end of life, good enough to be dumped, and reap benefits from its scrap. As an enduring passenger, I have been containing the noisy tractor-like ride in his car due to my acquaintance with him and also believing his long false promise of a new car on its way to replace this one!

Week-on-week he comes with the same car and asks me if I noticed any evident difference in terms of travel experience. He would spend good amount of money replacing the old parts (like the tires, cars’ engine, AC, etc.) with better ones, beautifying it by a coat of varnish, etc.; the expenditure now almost exceeding the price of purchasing a 3-year-old second hand car. I honestly said a big NO each time he asked me and also wondered why he was investing on this old car when a new car according to him was arriving in the next 3 months!! This fetish behavior of patching the old car in anticipation of some miracle resulted in the loss of many good loyal customers (as they were fed up of the continued bad bumpy ride with no respite in sight in the form of a new car).

During one of my recent rough ride in the taxi, I realized how well this experience was analogous to what many organizations undergo during their agile journey. They have every agile practice in place; right mindset, best practices, roles/ceremonies/artifacts well defined coupled with communication, motivation, and empowerment. Even with such a robust agile framework, the teams/organizations lack agility to adapt to the changing customer requirements and deliver in a fast paced manner. Although in reality, organizations want to go fast (like any new car) by adopting agile but unfortunately are stuck with poorly maintained legacy codebase (like the old taxi). Any amount of replacement, beautification, superficial modification, or adopting new methodology/technique without addressing the deep-rooted problems might temporarily mask the real problem thereby breaking ‘transparency’, one of the 3 legs of empiricism (for scrum to be effective, each of these 3 pillars – transparency, inspection, and adaptation must stand and be supported).

When such projects are assessed, in all probability the hidden truth is that the organizations carry a herculean technical debt in terms of complicated and poorly maintained legacy codebase (just like the old car) with little or no attention to the engineering best practices, poor feedback cycles, no automation of unit./integration/regression, poor re-factoring and code reviews, etc. Based on the assessment findings, organizations need to perform a cost-benefit analysis and decide whether it makes sense to fuel such projects and take appropriate corrective actions immediately rather than wait for some magic to happen overnight in an organization/product by just adopting agile. If not, (like the taxi driver) organizations will fail to deliver/meet customer expectations, not be profitable, and loose out longstanding clients.

Therefore, for organizations in their attempt to keep pace with the competitive world it is not just enough to adopt agile methodology but should imbibe agility in their DNA. Varnishing an old car may give it a new look but the driving experience will remain the same; the same applies to organizations as well. In most cases, change/expected results may not be visible by just refactoring in bits and pieces (replacing the defective parts) but it may call for a complete eradication of the existing system (significant remarkable/dramatic one which would be a winning selling pitch for the organization; in the car analogy it is like buying a new car) and re-designing/re-writing the software to bring in a new vibrant spectrum.

Upon this cleanup and novel thought it is now time to think how to drive this concept (new car) effectively and efficiently! Adopting the rich agile ethodology along with adhering to solid engineering practices at this juncture would act as a fuel to propel the team/project/product/organization, accelerate, and drive towards success!

With the legacy issues addressed and best engineering techniques embraced, agile adoption certainly triggers agility and benefits the organization by delivering fast-paced, feature-rich, competitive, and user-beneficial products of significant business value!

Evidence-based Estimation

An analogy I can think of is… I want my dart to hit the dart board, and not necessarily the bull’s eye…. as it calls for a lot of details which apparently is missing during estimation. However, if my dart doesn’t hit anywhere on the dart board… it’s almost like shooting in the dark; a very disappointing estimation scenario.

A vast chunk of new teams struggle in arriving at a correct project estimate; with most them failing due to a huge variation (with estimated Vs actual)! Very few succeed in this journey by coming closer to the actual in the initial cycles itself.

Project managers in traditional development focus on detailed scope, so that the cost, estimate, and time are accurate and frozen before kick starting a project. How far this is successful and precise is debatable! In agile projects, during release planning the development team arrives at a high-level estimate for each story in the product backlog normally in story point which aids in finer estimation during sprint planning. This helps the team to get started, rather than wait for all the project details to get finalized.

Story point is an arbitrary measurement of a feature’s size relative to other features and not the time needed to complete a feature. For example, by looking at the picture of the whales you cannot determine the exact age or weight of each whale but can compare the size of each with respect to each other. This is a very handy approach as detailed information to estimate the effort may not be available so early. Story points are used to calculate how many user stories a team can complete in a sprint which is termed velocity.

The story point size assumptions are interpreted using an estimation scale, the most common ones include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), etc.

A team to get started with story point estimating must be clear, synchronous, and agree upon the below aspects (I call it the ‘Five subtle rules’ as they are hidden and work at the back of our mind.).

Common reference – Each team member estimating should have a same reference. For example, the size L to measure a story point size should be the same criterion for everyone in the team. Any conflict with respect to the reference index results in huge variation and wrong estimation. Agreeing upon a common reference is very critical.

Collective wisdom – Estimation is a team activity and hence all should participate in this. Having one person do this will be a huge risk as the margin of error will be high! However, a collective decision helps in arriving at a common estimate which in all probability will be accurate.
In addition, during relative estimation the team should also take into account the effort, complexity, and uncertainty for every story before arriving at a number.

Effort – How much effort a story would take to complete, relative to the reference story.

Complexity – How complex is the story with respect to the reference story.

Uncertainty – How much risk/unknowns a story holds relative to the reference story

Even with this common agreement, it may still take a few iterations for the team before arriving at a common estimation value. With estimation being definitely hard, how do we get the best estimates of story size?

Why not take a closer look at “Evidence-based estimation”, learn from experience, become proficient with every calibration, and adopt during the initial project estimation phase to understand its true benefits!

Here is the approach a team should take to proceed with “Evidence-based Estimation”:

Let’s consider a scrum team of 7 members commence a 2-week sprint of 10 working days. With 6 hours as the effort per day, the capacity would approximately be 7 * 10 * 6 = 420 hours.

  • During the 1st sprint planning meeting, the team begins story estimation from scratch with no story points assigned to stories in the product backlog.
  • A story is picked from the product backlog followed by task and time breakdown for each. This step continues till the estimated capacity adds to about 400 hours/5 stories (considering the average team capacity is 420 hours).
  • Through the sprint, the team works towards completing all the planned stories.
  • Just before the retrospective meeting, the team assembles to story point the completed stories (definitely now with some experience/evidence).
  • Among the 5 stories, the team picks the one with medium effort, complexity, and uncertainty and assigns a story point (keeping the 5 subtle rules in mind). For example, when we take an estimation scale of 1, 2, 3, 5, 8, 13; this story is assigned a story point of 3 and it becomes the common reference story. A closer look at this exercise clearly indicates that the story point number is emerging out of working experience/evidence and not by mere guess work!
  • The team continues story point estimation for all the stories in Sprint 1 (per Step 5) and assigns a value lower, higher, or the same when compared to the reference story point.
  • As the team proceeds from one story to another, the comparative reference points become varied apart from being evident which helps them with better estimation. At this point if the team feels a need to refine the previous estimates, they can. The idea is to get better estimates with experience that are realistic.

The teams may decide to use this estimation during the initial few sprints till they are confident of the process. With experience, the team becomes an expert and are equipped at deriving an almost accurate story point during the release planning (rather than after the completion of a sprint), thereby aiding in better agility and transparency.

A Collaboration Lesson from the Redwood Trees

The Redwood trees in Muir woods, San Francisco, are some of the tallest and widest trees on planet earth. Some trees are so wide, that it takes 40 grown up adults to make one circle around it! These trees are known to live for thousands of years and each year they grow bigger and bigger.  Most tall trees have roots that go deep down to keep them stable. For example, the roots of the palm tree are as deep as the height of the tree. However, research tells us that though the Redwood trees are the tallest trees on earth, their roots are not deep at all. California has gone through a tremendous number of hurricanes, cyclones, windstorms, tornadoes and earthquakes in the past 2000 years. Any normal tree would have been crushed instantly, but not the Redwood trees. They’ve been standing tall and strong ever since. So, what is the secret behind these trees?

It seems the Redwood trees have some special mystical power. The roots grow outwards instead of deep under the ground. And when these roots come in contact with roots of the another Redwood tree, they wrap around each other multiple times and form a strong bond. Each tree shares a bond with another tree through its roots, and eventually, every single Redwood tree is connected to each other. The roots hold on to one another through the harshest of weather, and keep the family of trees standing tall and strong, together.

The roots of older and wiser trees hold on to the roots of trees just beginning to grow. They’re basically telling them —“You’ll grow big and strong. Reach for the sky and we’ll help you get there. You have the strength of hundreds of trees in the forest because we’re all connected. Our strength is shared together, and it grows together.”

If we dig deeper and try to understand self-organization, a principle very much needed for being Agile, we will realize that collaboration and co-operation are the basic attributes needed to self-organize. Similar to the Redwood trees, Agile team members need to collaborate so that the entire team rises higher and higher. This interconnection helps each individual to grow, inspire and motivate each other. It builds trust and transparency, and at the same time a feeling of safety to explore new hypothesis, innovate and produce a quality deliverable to the customer, with a feeling of satisfaction. 
The Redwood tree example was shared in one of the spiritual  discourses and I found this example so very relevant to some of the Agile values and principles. 

The Power of Anonymous Retrospectives

The Scrum values – Openness, Commitment, Focus, Respect and Courage are the foundation for the behavior and practices in Scrum. It’s difficult for organizations to adhere to these values from the onset of their Agile journey. Agility is about behavior and cultural changes and the values listed can’t be demanded, they have to be earned by creating transparency and is a journey that never ends.

While coaching Agile teams over the years, I have learned that no matter how open and transparent the organization is, there will be some individuals that won’t openly speak up. They are mostly introverts and have a phobia of public speaking. They will limit their interaction to a bare minimum. In some organizations engineers carry the management fear. They feel like they are being observed and anything and everything they say will reflect in their yearly performance appraisal and they clamp up. In either of these situations or situations similar to these, the Anonymous Retrospective helps get the real pulse on the floor. It helps all the participants open up and talk about what they really feel deep within about the organization, the culture, the people, the leadership, the technology, the motivation factor, etc.

So what is Anonymous Retrospective? As the name suggests, all data collected is completely anonymous. The first rule of the Anonymous Retrospective is the data collected has to be truly anonymous and there should be no attempt to tie the same to any individual – either through the language used to describe it or with an handwriting match. What I normally do is I put an empty container in the middle of the room and  give each participant a bunch of Post-its. I ask them to jot down their thoughts on what is working well and the areas that need improvement. I emphasize to the participants that this is a Anonymous Retrospective and encourage them to share their thoughts without having an iota of worry. I then ask them to fold the post-its and put it in the empty container. I normally time box this to around 25 to 30 minutes.

Once everyone is done, I get the container with the post-its and give it a good mix. Then I appoint someone neutral to take notes on their laptop and help me with basic categorization. I pick each note and try to read it as verbatim as possible, except for certain cases where there are personal attacks. I read them one at a time in front of the entire room, the person taking the notes captures it, and then I tear the post-it in front of all the participants and put it in the trash can to maintain confidentiality. This is what I mean by “Anonymous”.

Anonymous Retrospective will generate plenty of data which has to be validated for its accuracy. Once all the data points are collected, work with the participants in the room to finalize the categorize the data, and generate information by connecting data in each category together.  Following this put an action plan together to address each category. Most likely you will need multiple sessions to do this… but remember you now have some solid facts with which you can incrementally introduce improvements. This is what the power of Anonymous Retrospective is!

I am happy to hear your thoughts.

Sachin Tendulkar – An Agile Case Study

Yesterday Sachin Tendulkar, my Hero, a cricketing legend, the GOD of cricket called his retirement after he plays his 200th Test Match on the Indian soil.

This was indeed an emotional moment for me as we not only share the same birth year but plenty of good memories and achievements in my career are tied to Sachin’s achievements. It will be a shame on my part if I don’t blog about him and pay respect by relating the same to the “Agile Values and Principles” he has demonstrated during his entire cricketing career of 24 years.

Sachin, as a child dreamed of playing Cricket for India and he fulfilled his dream by passionately living and breathing cricket everyday for 24 years of his life – and the records he has achieved over his career speak for themselves.

He always leads by example be it batting, bowling or fielding and keeps laser sharp focus on the goal every time he is on the field.

He is not only a Self Motivated individual himself, but also a motivation for millions of cricket fans around the world.

Sachin is a mentor and coach to so many young Indian cricketers, of which some were not even born when he debuted his cricketing career at the age of 16.

One can’t find a better example of regular inspection & adaption than Sachin. Cricket as a game has changed a lot in 24 years – from Test cricket (5 days), to one day (50 overs), to T20 and Sachin has not just kept abreast  in all formats of cricket, but also excelled in each format which is no small feat. He always planned his innings, but at the same time adapted and responded to changes as the situation demanded.

As for the impediments,  Tendulkar has been stricken by so many injuries during his career spanning more than two decades. In addition to the injuries, the media and general masses (the stakeholders)  had also given him so much negative flack at times. But time and again he has come back with a bang, silencing his critics and delivering to their expectations. He just knows how to move forward in the face of impediments.

Sachin Tendulkar surely had bad years (sprints) in his career. But what made him stand out from the rest is the realization that there is a certain problem and honestly working on it and then coming back stronger every time.

Now, isn’t this what Agile is all about?

Sachin, you will always be missed on the field (though, we get 2 more opportunities to watch you in action).
However, the legacy you have created will live for generations to come! uses agile development offshore to roll out internationally


This article ties to the ongoing work I have been doing with the International Teams in TESCO as an Agile Coach in Bangalore since January 2011.

Overall, Computer Weekly covered the article well just with a minor correction: “Deliver the Beer” was a first internal release to validate Agile Software Development was the correct approach. Czech Republic had a first fully functional grocery website.

Ran my first Half Marathon the Agile way

The Worli Sea Link

On January 20th 2013, I ran and successfully completed my first Standard Chartered Half Marathon in the beautiful city of Mumbai in an Agile way. What an awesome experience it was. 

My skill level with running: Novice,  I had put around 90 km of  a total run in a period of 3 months during training. Just for comparison, average runners put around 100 to 150 km in a month. 

The most I had run at one go was 10 km in the time period of 1 hour and 20 minutes.

 Motivation: To help the Udaan foundation raise funds to support 2 under privileged students for a year.

Release Planning:

Release Goal: Run 21.097 Kilometers in under 3 hours, which is the qualification time.

Approx Velocity (Based on past experience): 7.5 kms / hour.

Total Sprints needed: 21 / 8  =  Approx 3 sprints of 1 hour each.


Sprint 1: The amazing Mumbai weather, the Worli Sea Link being the start location, and a total of over 16,000 participants in the 1/2 Marathon, created an atmosphere that one has to experience and can’t be described. All this was motivation enough for me to build a constant pace of about 7 minutes and 30 sec per km for the first hour. The stakeholder (that’s me:-) ) was very happy with the outcome of Sprint 1 and decided to continue with the release. The Retrospective revealed a improvement area of slowing the pace down a bit as certain impediments around fatigue and pain had been logged.
The velocity achieved by end of sprint 1 was 8 km. 



Sprint 2: Using yesterday’s weather as a forecast for velocity and keeping the retrospective improvements in mind I planned sprint 2 with a goal of achieving 7 km instead of 8 km in the next hour. I nicely built a pace of 8 minutes and 15 sec per km. The face-to-face cheering of the crowd, the loud music by DJ’s throughout the route, and the cause of the run lifted my spirit and kept me motivated throughout sprint 2. By the end of sprint 2, I had completed another 7 km and had achieved a total run of 15 km. The product backlog showed 6 km of a run remained for the minimum marketable functionality to there by achieve the release goal. The stakeholder was again very happy with the achievements and decided to continue with the release. The retrospective did not reveal any major improvement area other than suggesting to slowing down the pace even further. 


Champions with Disability

Sprint 3: With 15 km of a run complete and only 6 km remaining, the stage was set correctly for the final sprint. However a little after 1 km in the final sprint there were 2 new impediments – cramping and thoughts of quitting the race. To manage the first impediment, I switched from run to walk and started hydrating myself every 100 meters. The exhaustion was causing my second impediment to grow stronger and stronger putting the entire release at a risk. As I was battling these thoughts of quitting the race,  I passed by the “Champions with Disability” on the other side of the road. The smiles on the faces of these participants with special needs and their attendants was  just the motivation I needed for me to cruise through the remainder of the race. 

And I completed my first half marathon in 2 hours 49 minutes and 42 seconds!

Agile Coaching: Are your retrospectives effective?

Are you in a situation where your team(s) has been practicing Agile for a while and teams are following ceremonies meticulously, but still there are no significant improvements sprint over sprint or release after release? If yes, I have some antidotes that I will share through series of blogs that you can experiment with.

One of the Agile principle is, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. This in a nutshell is Continuous Improvement (CI) and one of the ceremonies that assists you in implementing CI is Retrospectives.

Start with Retrospectives: Ask these questions.

  • Are the retrospectives effective? 
  • Are the team members open & honest?
  • Is there a good flow and exchange of information that is fact based that the team can relate to?
  • Is enough flavor added to each retrospective to ensure that they don’t become monotonous?
  • Is the facilitator neutral? 
  • Did the team put the action plan for the improvement areas after root causing the problems? 
  • Is the team taking at least one improvement idea that they are in total control of instead of relying on parties outside their team?  
  • Is someone within the team held accountable to ensure the improvements are put in action?
  • Did the team reflect back on the improvements implemented in the retrospective that follows?

My observation as a Agile Coach has been that teams are generally very enthusiastic to begin new work as soon as current work is completed and they cut corners or miss on Retrospective entirely thereby missing on a important Agile Principle – “Inspect and Adapt” 

Tesco’s Success Story with Agile Adoption



Over the past 2 years I have been helping Tesco’s Dotcom International Grocery Home Shopping (IGHS) group in the capacity of Agile Coach to build their eCommerce Platform. Tesco Dotcom’s challenge was to take the world’s largest grocery website international to multiple countries outside UK as quickly as possible and be the market leader. 

As the saying goes, “The proof is in the Pudding” …. By using Agile as a Software Development Methodology  with a  combination of Scrum, XP, Kanban and lean principles of choice, Tesco was able to launch their Dotcom operation to new countries regularly and is currently live in 5 countries within the span of just over 2.5 years. This group with several Agile teams distributed across 2 geographies was able to bag 4 major awards within the organization, including the “Tesco – IT project Cup” of the year.

It is my privilege and honor to be part of a journey with this passionate team that was constantly hungry to take the Agile adoption from one level to another tirelessly through continuous Inspection and Adaption and both the passion & Hunger continues….

1 2 3 4 5 6