Originally published on LinkedIn on 3-Aug-2016 (The Agile Fairy Tale)

And the team continued to deliver working software every two weeks, happily ever after…

A nice fairy tale ending. If you think about it, fairy tales have a typical construct, which concludes in a happy ending after the main characters undergo some hardships. And people usually live happily ever after. Can the same be said for software development teams and organizations?

When the waterfall methodology was embraced by the industry, it had the premise of providing a structured way of delivering software applications and products. The waterfall methodology can be seen as a success, from the perspective of adoption across the industry; practically, every software development initiative was seen running on this methodology. The methodology worked, although the same cannot be said for the projects, for various reasons. These reasons called for some drastic and radical change in the way software was being developed. And so, 17 gentlemen came out with a disruptive artifact called as “Agile Manifesto”. The Agile Manifesto was a product of the collective experience of these gentlemen, bringing in varied thoughts and disciplines (from other industries as well) to converge on a common and shared understanding in the form of Values and Principles.

The software world slowly started adopting the Agile Manifesto. Some methodologies and frameworks shot into prominence, while others faded away. As the popularity increased, people tried to apply Agile to different environments and contexts. Some tried to create new frameworks to cater to enterprise requirements, while others recreated methods originally used in other industries like manufacturing. Teams and projects lapped up these frameworks and methodologies. A whole new industry emerged, providing training, certifications and consulting on Agile. Before long, the core construct and philosophy behind Agile started to take a back seat, with people focusing more on processes, metrics and tools.

How often do we hear these statements?

• We are Agile, because we stand up every day for 15 minutes
• We are Agile, because we have setup a Continuous Integration server for our project
• We are Agile, because we use the most popular Agile tool for planning and tracking our backlog and iterations
• We are Agile, because we measure velocity every iteration
• We are Agile, because the whole team is trained and certified in Agile
• We are Agile, because we have an Agile Coach with the team

Here are some questions (out of many) which come to my mind, when I hear such statements.

Q1. How effective are the daily stand-ups?

1. These 15 precious minutes are used to talk about yesterday, today and impediments
2. This time-box is used for re-planning and daily course correction

Q2. How effectively the Continuous Integration server is being used by the team?

1. It is used to show that a tool is being used as a tick-mark on the Agile checklist
2. Corrective actions are taken frequently based on feedback provided by the tool

Q3. How effectively is the planning and tracking tool used?

1. It is used to provide beautiful dashboards to the higher management
2. It serves as an enabler for collaboration among distributed team members

Q4. How is velocity used by the team and stakeholders?

1. It is used to provide a data-point for reporting
2. Product Management uses the velocity for projecting future outcomes

Q5. How effective are the training and certifications in day-to-day work?

1. These are used to gather some beautiful acronyms that can be suffixed to one’s name
2. The learning is applied to make work more useful and fruitful

Q6. How effective is the Agile Coach’s presence with the team and the organization?

1. The Coach is being used as an ornament to declare “WE ARE AGILE”
2. Some serious efforts are made to change the team and organization under the Coach’s guidance

Unfortunately, in most of my career, I’ve seen ”1.” as the first choice answer to most of the above questions. I guess this happens when the delicate, yet robust philosophy of Agile is mass-marketed as a panacea for all ills. Teams and organizations tend to cling to the accessible peripheral aspect and ignore the deep meaningful core, still expecting the fulfillment of marketed promises. And when the expectations come to naught, Agile takes all the blame.

Well, this fairy tale started in 2001, slowly gathered momentum and transformed into a movement. A movement where every other team and organization has set one of the goals to be Agile. But, this movement lacks a key ingredient; the understanding and acknowledgement that Agile is not the goal.

If we keep Agile out of the picture for a moment and try to imbibe the following, Agile will most probably sneak in:

• Focus on the business goal
• Trade short-term gains for long-term objectives
• Don’t disrespect people (employees, customers, even investors and shareholders)

I am quite sure that this fairy tale is not going to end very soon. As with any other fairy tale, we are in the midst of some challenging times and I believe that better sense will prevail. People will start understanding that “Early and continuous value delivery happens only with collaboration, discipline and focusing on the customer’s needs (not wants)”. The realization will dawn on teams and organizations that Agile is not a magic box of solutions, rather it is a mirror for them to see deficiencies in their current way-of-working.

And some day, I hope, teams will continue delivering working software every two weeks, happily ever after…

Disclaimer: The opinions expressed in this post are the author’s own and do not necessarily reflect the views of the author’s current or previous employers.