Originally published on LinkedIn on 17-Oct-2015 (Agile is not the Goal!!!).

When I started with one of my recent engagements as an Agile Coach, I inquired the team about the reason they decided to move to agile from the traditional way of working. The team being part of the vendor team in a client-vendor environment, I had expected a specific answer. And the answer was as specific as I expected: “The client has asked us to move to agile”. I could have stopped at that point in asking further questions, but couldn’t help prodding further. Somehow, I was not able to get a satisfactory (at least to me) answer. When I discussed this with the Client Stakeholder (CS), the below conversation ensued.

After exchanging pleasantries,

TP: So why do you think agile will help you out in this project.

CS: We have to speed up our delivery capabilities, so that it improves the time-to-market of new features and enhancements to the product.

TP: But we already are delivering enhancements to production every 2 months. And I think given the constraints of technology, the challenges in revamping the organization structure and other business factors, this time frame is good enough.

CS: Yeah. That’s right. But we want it to be quicker than the current situation. Probably releases every 1 month.

TP: OK. What else do you see which needs improvement?

CS: Nothing more. Just reducing the production roll-out to, maybe, 1 month duration.

TP: So we are ready to merge the Dev & QA organizations starting today, to enable 1 month releases.

CS: Not right now. This will take some more time as all the stakeholders are not yet aligned.

TP: Then it will be difficult to achieve the objective, because the separation of Dev & QA will prevent us from delivering something every month. The kind of technology we are working with, we won’t be able to deploy a lot of automated tools, hence manual activities will continue, which is another reason of not speeding up the deliveries.

And the conversation went on for some more time. There were other constraints, such as identifying the right Product Owner, teams located in different time zones etc. What came out of the discussion was that the client organization had a mandate of moving to agile and they had a specific deadline.

Well, this was just one such instance. I believe there are many more such cases which the agile community is currently grappling with. 

Finally what you get out of such initiatives is aptly described by Mike Cohn in one of his recent blog posts as “Iterative Waterfall”. Or some version of “mini-waterfall within iterations”. And we still brand it as Agile. Why?

May be, the world is so obsessed with Agile that everybody is struggling to keep up with the pace of adoption/transformation in other organizations. And I feel the essence of the philosophy is fast getting relegated to the background.

“Let’s follow some Scrum practices without changing the existing organization structure.”

“Let’s procure some high-end tools for DevOps without bothering with the business stakeholders’ on-boarding.”

“Let’s have the requirements frozen up-front and have Dev team deliver in iterations.”

Well, these are some patterns which I have witnessed among others, and I am sure many of you have also seen such instances. Agile is being made into a goal of adoption/transformation, which I feel is a very disturbing trend in the industry.

If one really wants to transform, one needs to have a vision which has to be shared by the whole organization. And to reach that goal, Agile can be one of the means. But, definitely, Agile cannot (and should not) be the goal!!!

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