Debunking Agile Myths
Despite the steady adoption of the Agile delivery approach by organizations of all sizes, I continue to observe misgivings or myths among IT and business leaders considering Agile. The spirit of Agile has always been to embrace business change rapidly and demonstrate progress at shorter, regular intervals. However, the belief that this is accomplished by disrupting existing operational processes and adding more responsibilities on staff isn't necessarily true.
The reality of Agile generally lies somewhere in the middle of the change continuum.
Let me outline the top 5 myths out there and try to clarify my position on each one of them -
Myth # 1: Agile means "No Planning" - This one is probably the most egregious myth of them all and hence on the top of my list. Agile requires planning but it is carried out in a different way. The idea is to NOT take a big-bang planning approach as who knows what the future might look like in 2 months and beyond. So Agile takes a more adaptive, iterative approach that takes into account the upcoming 4-6 weeks or ~3 iterations (assuming 2 week sprints). Basically, you divide work into smaller chunks and commit to reviewing your plans on a regular basis.
Myth # 2: Agile eliminates project documentation - If you misinterpret the Agile Manifesto, there isn't much I can do about it. “We value working software over comprehensive documentation” doesn't mean that you skip documentation. The manifesto is there to guide you on how to prioritize your project activities. You must include documentation in your estimates and include corresponding task(s) in your definition of done.
Myth # 3: Agile requires co-located stakeholders - Agile emphasizes ongoing (i.e. daily) interaction and collaboration amongst stakeholders. Hence people assume that team members must be co-located for Agile to succeed. However, given the variety of communication and collaboration tech available these days, this is no longer the case. Tech tools can facilitate all of the daily/weekly Agile ceremonies, amongst distributed team stakeholders, in very effective ways. I've used Google Hangout, Skype, and Slack with high success when executing my client projects.
It really comes down to the "what" on an Agile project, not the "where" or "how" with regards to communication and collaboration.
Myth # 4: Agile reveals final product at the very end - In the old-school approach, you never starting coding until all of your requirements were locked down. While this approach might work for Nuclear Power Plant and Sky Scraper development projects (all details known upfront), any uncertainty or unanticipated changes in processes or requirements can result in expensive delays. Contrast that with Agile where you plan for uncertainty by requiring a high-level plan at the very onset of development, with the details to be iteratively elaborated as the system is built. This way stakeholders have a reasonable view of the near-term outcomes (like a specific feature during the current iteration) and as well as the long-term vision (articulated by the completion requirements and constrained by team velocity, funds, duration, etc.).
Myth # 5: Agile is just "hacking" code - Hacking means slapping code together without any design or architecture thinking. And if you are doing that, you are defying one of the core tenets of the Agile Manifesto (i.e. “continuous attention to technical excellence and good design enhances agility”). Software development standards, patterns, and best practices are the bread-and-butter of high performing agile teams. So stop confusing Agile with Hacking!
The above 5 common myths can result in critical blockers for anyone trying to implement agile in their company. But if you have the right information, you can quickly bust these blockers and keep moving on your Agile journey.
***
P.S. If you liked this article, it would mean a lot if you hit the LIKE button or share with your network.
About me: I am passionate about solving problems using my product, process, and analytical capabilities. Write to me at [email protected] if you think your team or organization can use my help.