Top 5 myths about agile teams – BUSTED
The Agile frameworks have taken over multiple industries at a rapid pace. Designed to help deliver more rapid and efficient products and services, there are still confusions and uncertainties about Agile implementation feasibility, especially for organizations that have established cultures of other frameworks such as the Waterfall.
In a 2017 survey by Gatepoint Research, 70% of chief senior decision makers claimed accepted that agile organizations have more capability of responding rapidly and effectively to dynamic business conditions. However, fewer than half said that they use agile methodologies to develop products.
According to the California Department of Technology (CDT) in their Understanding Agile Handbook, along with multiple concepts and approaches, misconceptions and myths are also usually communicated and shared amongst practitioners – new and experienced. This can be misleading while learning about the leveraging an agile approach.
Here, we try to uncover the truth behind some myths through the opinions of real experts and practitioners.
Myth #1 – Agile is new
Allan Kelly is a consultant and the author of the article: “Dear Customer, the truth about IT”. He has also written several books including: “Xanpan – team centric Agile Software Development” and “Business Patterns for Software Developers”.
Allan dismisses the myth that Agile has just recently begun. In fact, The Agile Manifesto got published in 2001 with the Scrum Pattern language presentation in 1995 during the Object-Oriented Programming, Systems, and Languages (OOPSLA) conference. Moreover, the Episodes pattern language (which is the forerunner of Extreme Programming—XP) was described in PLoP 1995.
Myth #2 – Agile means no documentation
In an article co-authored by Eric Bristow, the director of and Azunna Anyanwu, specialist leader in Deloitte Consulting LLP, it has been emphasized that in any project, documentation is important in any project and in most cases, serves as a road map. Documentation helps outline the workflow of a system and the corresponding objectives of the organization, users as well as developers.
The Agile methodology encourages documentation but differently. Instead of massive documentation incorporating project objectives and requirements, the objectives are formed and specified through user stories user stories that can be updated, prioritized as project continues and can be used to provide real-time visibility into the progress of the project.
Myth #3 – Agile involves no planning
Peter Measey is the CEO of Radtac Ltd, an agile specialist consultancy and training organisation. He busts this myth by saying Agile isn’t “just do it” – there is significant amount of planning and re-visiting the plans involved as required during the project development cycle.
He adds that vast majority of agile frameworks require planning frequently. Depending on the customer requirement and involvement, some teams may just need to plan in single iterations/sprints and others may need to plan on different levels.
Kelly also corrects this misconception by explaining that Agile planning is spread throughout the entire development cycle than just a single plan at the beginning. Plus, Agile planning involves everyone in the team instead of relying on a few appointed individuals.
Myth #4 – Agile requires no preliminary design/architecture
As with all projects, Agile projects also require some designed and specification albeit on a simpler scale. Agile emphasizes on the simplifying instead of entirely eliminating upfront designs. Robert C. Martin, one of the founders of the Agile Manifesto says that Big Design Up Front (BDUF) can be “harmful”, however, little upfront design (LUFD) is “absolutely essential”.
Which means BDUF can result in overly complicating a product, which is normally a case with the Waterfall approach. By simplifying upfront designs, teams can focus on the foundation and general structure of the software product.
Myth #5 – Agile is a cure-all for software development
Even though Agile has proven to help in improved stakeholder alignment, faster results with clearer and earlier issue identification, it still is not the answer for every software development problem.
Even though the concept of agile project management is usually associated with software development projects, it offers the same value when managing non-software projects. According to Bristow, Agile may not be the methodology or projects that cannot be restructured into smaller units of work, such as a cycle that can be completed in 1 to 4-week increments.
Some projects that fall under analytics, mobile or social project developments are more suitable for Agile software development approaches. Whereas, ERPs or large-scale systems may be not.
Measey seconds this by stating that Agile is not exactly the silver bullet for all IT problems. Instead, it involves the integration of various frameworks.
The delivery and implementation of Agile frameworks must be according to the real-world environment in which a system is to be implemented as well as utilized. This comes with integrating the best of agile and non-agile frameworks.
Have you or your organization adopted the Agile methodology in projects? Share your ideas with us in the comments below.