6 Common Misconceptions About Agile....
And What You Can Do About Them
Over the past several years, I have helped many organization adopt Agile practices in effort to improve team performance as well as overall organizational execution. Throughout my journey of helping people make difficult changes to doing work in a different way, I have learned many lessons that can be shared across all types of groups, teams, organizations, specifically about what “Agile” is (and isn’t). It is my hope that you will find some of my learnings to be useful to you as you embark on this same journey to Agile excellence.
- Agile will solve all of your problems
Since I have dedicated tremendous amount of time, energy, and personal funds to develop a career helping people do work in a better way, it is only natural for me to have become an advocate (or evangelist of sorts) when it comes to Agile engineering. However, having said that, I will also be the first to raise my hand and tell an organization that Agile may not be the “silver bullet” for your organization for a number of different reasons.
According to the 12th annual State of Agile report, recently published by Collabnet/VersionOne, the leading causes for failures in Agile projects are primarily related to organizational factors, such as: (1) Organizational culture at odds with agile values (53%), (2) General organization resistance to change (46%), and (3) Inadequate management support and sponsorship (42%). The data tells us that Agile is not an universal remedy to all problems for all organizations, simply because some organizations simply do not yet (or ever will have) the conditions necessary for Agile to be applied effectively.
- Agile is simple to implement
Agile principles are very simple and easy to understand. Anyone with some common sense should be able to at least get a grasp of the foundational concepts behind Agile as a whole. However, to apply Agile practices within a real-world scenario to solve business problems is not quite as easy. Deploying Agile tools and practices on the surface may seem fairly straight-forward; many organizations I have worked with attempt to make this transition on their own by sending a few people to Scrum training, and expect results immediately. Unfortunately, any meaningful transformation will take time and perseverance; depending on the size of the organization, such a transition can take months or even years. For example, Microsoft Corporation, which has applied Agile engineering practices for years, has only recently began to see tangible benefits.
- There is no discipline in Agile
For those folks who have limited knowledge or experience in Agile, it is easy to misconstrue what actually happens with an Agile team. From afar, it may seem like the team is “having too much fun” or “goofing off” since a lot of the team collaboration utilizes non-traditional tools and techniques; a senior executive who is new to Agile may not fully understand the value of tools such as Planning Poker, dot-voting, retrospectives, etc. Hence, when attempting to adopt new practices, there is usually a need to educate all key stakeholders as well as team members in order to minimize the misconceptions.
It is easy for “outsiders” to feel that Agile is just a bunch of “cowboy developers” doing whatever they please, and that there is no planning or thinking whatsoever. In reality, Agile encourages persistent and frequent planning through various events that promotes inspection and adaptation; one can argue that all Scrum events, including Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective, provides a forum for the team to plan/re-plan work, and to ensure common alignment and understanding of the work.
- Agile is only for software engineering (software development)
Since the Agile Manifesto was written by a group of software enthusiasts, it is generally assumed that Agile is only intended for software development efforts. Even the early revisions of the Scrum Guide was focused on software system as the primary product. Contrary to popular belief, Agile has evolved into something that is much broader and more applicable across different domains such as manufacturing and hardware-enabled systems; Agile is now utilized as the way to design, produce, and deliver large complex systems by all types of organizations such as John Deere, Lockheed Martin, Cisco, etc. There are many published case studies that are widely available which demonstrates that Agile can and has been a viable solution for non-software initiatives.
- Agile is only for simple (or small) projects/systems
As an extension to Misconception #4 above, there are still many organizations that are reluctant to consider Agile methods because they feel that their problem space is simply “too complex” or “too big”. If organizations such as NASA, FedEx, Saab Aeronautics are able to apply Agile/Scrum techniques successfully, one can make the argument that there is no problem too large for Agile to solve.
- Agile results in lower quality
Those who believe that Agile projects involve no planning or organization typically believe that the end result is a lower quality product, which would make sense if there is actually no planning involved. As stated previously, when you look at the various activities that Agile teams focus their energy on, such as Continuous Integration, Automated Testing, Continuous Delivery, etc., you would see that quality is a big emphasis in Agile due to the iterative, incremental, and upfront quality-centric approach to building a solution.
To conclude this brief article, I would like to emphasize one important opinion – Agile is NOT for all organizations. I encourage any organization that desires to improve how it delivers value and solutions to its customers to explore Agile with an open mind, and start with a clean slate. Talk to experienced experts who have been through the same struggles, learn from them, hear about their successes and failures, then make an informed decision on whether Agile might work for your organization. Better yet…stand up a pilot team (with proper support, of course) and learn by carrying out an organized experiment in your own environment and see what works and what doesn’t work. You might just make a few discoveries of your own!