Common Myths About Agile
If you have not participated on an Agile team, you may be tempted to believe some common myths about the Agile process. In this section, I attempt to dispel some of these mistaken beliefs.
No Organized Process
Although Agile teams need to be adaptable and change their focus to respond to changes in customer requirements, the Agile methodologies provide a structured approach to delivering products. Each methodology focuses on developing quality products through cross-team collaboration. Development cycles are relatively short, but software still goes through rigorous development and testing.
No Need for Requirements Gathering
The first Agile principle states that:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Based on this principle, it is clear that requirements gathering is an essential part of the Agile process. How can you satisfy customers without understanding their needs?
The answer: You cannot.
You must understand the customer requirement behind each user story and define how to determine when that requirement has been met. What is not needed are long documents that record customer requirements that need to be updated each time a requirement changes.
No Documentation
As a technical writing professional, I find myself face-to-face with this myth on a regular basis. Let me see if I can explain what the Agile Alliance founders meant when they included this in the Agile Manifesto:
Working software over comprehensive documentation
They meant that the focus should be on developing a quality product rather than spending months creating comprehensive requirements, architecture, and software development documents before starting the work.
The founders did not mean that requirements or software design details should not be captured at all. They simply meant that teams should balance the amount of time spent on the documentation. Create only the amount of documentation that is necessary. Stop creating large system-level documents just because they have always been created.
Moreover, “Working software over comprehensive documentation” does not mean that we should stop producing end user documentation and it does not mean that development teams should stop reviewing product documentation in order to remain focused on the software. Product documentation is part of the product and should be reviewed before the product is released. However, just like requirements and software design documents, we should review the types of documents that are delivering to determine whether they are still needed or whether we are just producing them because we always have.
Getting Started with Agile is Easy
Agile has a number of benefits, but getting started is not easy. Agile methodologies require a paradigm shift and support from all levels of the organization. Teams have to learn to work within the Agile methodology and evaluate which Agile framework best meets their needs.
In time, you will learn what processes work for your team and how to work effectively together, but you will likely have had some struggles breaking down tasks to a size that is manageable in defined sprint lengths and/or managing shifting requirements while still maintaining productivity levels.
Benefits of Agile are Instantaneous
Because it takes time for teams to learn to work within an Agile framework, you will not necessarily see the benefits of an Agile approach right away. Teams need to learn what is working and what is not working so that they can make the necessary adjustments. Estimating the time it takes to complete tasks takes practice. The estimation process gets easier once you have completed a fairly substantial number of tasks that you can use as a basis of comparison to new tasks.
To facilitate the transition to Agile, organizations may want to consider investing in training and consulting services from Agile professionals as well as project tracking tools that lend themselves to Agile teams. Even with training, it will take time for teams to apply what they have learned.