In this article, I am going to have a look about top 4 misconceptions about agile adoption. Agile methodologies are being adopted by companies at an increasing rate and that’s really encouraging. To quote a recent article by Harvard Business Review titled “Embracing Agile”
Agile innovation methods have revolutionized information technology. Over the past 25 to 30 years they have greatly increased success rates in software development, improved quality and speed to market, and boosted the motivation and productivity of IT teams.
However, are we really adopting agile in the right spirit? The Harvard Business review article, further states
But a serious impediment exists. When we ask executives what they know about agile, the response is usually an uneasy smile and a quip such as “Just enough to be dangerous.” They may throw around agile-related terms (“sprints,” “time boxes”) and claim that their companies are becoming more and more nimble. But because they haven’t gone through training, they don’t really understand the approach. Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them.
All of us have understood Agile in a manner, that suits our deep rooted understanding of software development practices & principles. Having spent more than couple of decades in the IT sector, I can related to these myths and misconceptions. But adopting agile with these misconceptions does not allow us to reap the benefits of agile development.
The thought behind this article is to bust these myths. I have picked up top 4 myths about Agile adoption.
Agile is a framework and several software development methodologies have been conceptualized based on Agile Concepts e.g. SCRUM, Agile Unified Process, Extreme programming etc. But somehow, we have come to a point where Agile has become synonymous with SCRUM and everyone seems to think that way.
Couple of reasons could be responsible for this – Scrum is simple to understand and the marketing force behind it. Lot of organizations are supporting it with full razzmatazz. Owing to this, other equally powerful Agile methodologies are being overlooked.
One of important downsides of this misconception is that we are not even evaluating the other Agile methodologies, which might produce better results for a particular situation.
Dave Thomas, one of the creators of Agile Manifesto in 2001 laments about commercialization of Agile but lack of understanding of the Agile philosophy in this thought provoking video titled “Agile is Dead”
Common perception is that if scope can’t be fixed upfront, fixed priced contracts is not feasible. This is a completely misplaced thought process.
Let’s do a reality check. The fixed priced contracts are a way to de-risk themselves for future cost escalations (from customer perspective). Customers are in the driver’s seat and they will never agree to keep the costs open, for obvious reasons.
Another reality, When we estimate the effort/cost for the fixed priced contracts, are we really accurate in estimation. In my career, I have come across several way-off budgetary estimates. It’s natural because budgetary estimates are done at a stage, when we know the least about the project requirements.
Another reality, most of the projects, executed using non-agile methodologies, are challenged (delayed, cost overruns or failed) with incorrect comprehension of requirements being one of the top reasons. We have no reliable study which suggests quantification of re-work but we certainly have data, which suggest that these re-works result in challenged projects.
My view is that, if we consider the range of re-work to be 20-50% (and add to that the spoiled relationship with the customer & bad appraisals back home), adopting Agile methodologies is not a bad bet (if we can map 20-50% of re-work to bloating of requirements).
This is deadly. Many managers believe that Agile is nothing but multiple waterfall iterations. Dividing the project into multiple small iterations and doing it waterfall way is the Agile way.
So how do we go for it? We gather all the requirements upfront and get a sign off and then start delivering the modules in an iterative manner. Each time a module is ready, we go to the customer, demonstrate the module and give them for testing. The development for the next module starts or even better, we can form parallel teams to carry our multiple modules simultaneously. Does it sound cool?
The approach discussed above is a workable model but it’s definitely not Agile. Agile is much more than just being iterative.
This is more of a corollary to the previous point but certainly needed a mention. Software teams looked at a project from masters, transactions and reports perspective. But customers never understood this classification, they expect modules, which is meaningful for them.
Agile MVP or Minimum viable product is about delivering a feature, which is usable and implementable. Division of the MVP has to be driven from that perspective. Henrik Kniberg‘s blog post Making sense of MVP (Minimum Viable Product is a must read if you really would like to get a grasp of MVP from grounds up).
Serious commercialization of Agile movement has shifted the focus towards getting the Agile TAG. But does Agile really offer serious benefits? I don’t need there is any confusion on that, but what are these benefits.
I discussed and explained the benefits of agile adoption from a Project manager’s perspective in one of my business analyst classes. Here it is: