While agile continues to steer software development teams towards success, there are many teams out there who are staying away from agile or are running into challenges in adopting agile because of myths they or their leadership or their customers have formed on agile.
Here are 12 agile myths that we will bust in this blog
- Agile does not support documentation – I have run into customers who do not want to hear the word agile because they think agile does not support documentation and in their world of business, they cannot sustain without proper documentation. One of the agile values talks about working software over comprehensive documentation – this simply means that agile values working software more than documentation, it does not mean that agile does not value documentation at all. Agile practices very much supports documentation for clients that require them for their success.
- Agile is about developing code fast – yes, agile is about going to market faster or failing/succeeding/improving faster but it does not, in any way, mean that a work that would take 40 hours, will get done in much less than 40 in agile. Agile practices make you focus on highest value items and only the items that are just enough needed to go to market. These aspects enable products developed in agile to go to market quickly, however this does not mean that agile is about developing code faster.
- Agile is an IT thing only – agile usually starts within IT for obvious reasons however the whole rationale of agile software development is to achieve business agility. Agile without gain in business agility is of hardly any value. But because agile starts with IT teams, a lot of times, people pushing for agile fail to connect with business and help them see business value of agile.
- Sprinting is agile – it is amusing sometimes to find teams say that they are doing agile because they run sprints but when asked how often they release production ready code, their answer seems to point to the waterfall world. Just mere sprinting is hardly agile, if you are not producing working software that can be released to production.
- Teams will do whatever they want to do in agile – a myth, I have found some managers worried about. Yes, agile teams require empowerment for them to succeed however they work on shared business goals which are defined in collaboration with business. The empowerment helps teams to take the ownership and drive their work towards meeting the goals. This myth usually is driven by the traditional management mindset, where managers used to decide on who does what and delegate tasks to members. Letting go of the control, only improves team ownership and increases likelihood of achieving business goals.
- Management wants agile, so they can track the employees more closely – agile makes effectiveness of almost all practices visible very quickly – tech and non-tech. Sometimes I hear developers tell me that management is pushing agile because they want to track us closely. I can understand that there is fear of getting your weakness visible however agile practices does not intend to punish failures instead it only works if we can learn from failures. The environment of fear is usually due to the traditional management practices however it has nothing to do with agile. Moreover, management does not want to push agile because they want to track their employees but because they want better customer satisfaction and business agility.
- Agile encourages micromanagement – Practicing agile does mean everyday collaboration with your business and everyday collaboration within the team as well in order to deliver value to business in shorter increments. This would mean that issues will surface quickly however this does not mean that agile encourages managers to start micromanaging teams. In fact, agile leadership would require leaders to empower teams towards self-organisation for the team to succeed. For members to take team ownership on the business goal, it is necessary that they are empowered, supported and trusted in the work they do.
- No planning in agile – This is another misconception in managers and customers that agile does not support planning. This is not true. Agile supports iterative planning, which means every iteration or sprint, you do your sprint planning and also product planning. In agile planning is an ongoing task as opposed to traditional waterfall, where planning used to be one detailed upfront planning. In agile, iterative planning allows you to learn at regular intervals and improvise your plan, so you can respond to market needs better and improve your quality of delivery.
- Agile does not support proper architecture and design – People who have worked long time in traditional waterfall model find it extremely difficult in coming to terms that architecture and design are also emergent in nature and it can be delivered with better quality when approached iteratively, as opposed to doing it one big bang approach up front. Just like planning, most of the design work in agile happens iteratively. If a team needs to work on building things like framework or defining architecture, agile principles ask you to also deliver business value out of those framework or architectural work. This ensures that customers get functional software/features and it also helps validate the framework and the architecture. This approach ensures efficiency and effectiveness of the design and architecture effort.
- Agile cannot scale – this myth probably has become popular due to the popularity of frameworks like Scrum. Scrum Framework focuses on a small team which is referred to as Scrum Team. The essence of agility lies in simplicity, which means building a minimum viable product or having a minimum viable team and roles. The agile manifesto does not prescribe any specific number of team or team size however keeping it minimum reduces overhead and helps your organisation stay agile. This does not mean that you cannot add multiple teams and roles, if need be, however adding teams or roles should be exercised consciously, with an awareness that while there is value in having additional capacity, it does bring an overhead of communication, dependency and integration challenges.
- Agile is about using tools like JIRA – Sometimes I run into leaders who refer to practicing agile as using agile templates in tools like jira. Agile isn’t about tools. Tools are there only to support your process and methods of working. True agility lies in how often your customer gets working software or how often your team reflects and improves or how self-organized is your team or how quickly your team responds to change etc.
- Agile has no governance – This is another myth probably formed because agile teams deliver working software in shorter increments and may be because agile teams are supposed to be self-organized teams. While the goal of the team is to deliver working software at the end of each iteration, this should not mean compromising on any of the quality goals. Agile emphasizes on governance within agile teams, so as to ensure quality goals are not compromised. Scrum teams achieve governance by having a “definition of done” as a common definition across teams. Definition of Done must have specific governance requirements that every item must comply with, in order for it to be called “done”.
