Agile Facts and Misconceptions
Agile Facts and Misconceptions
In this article, an Agile consultant takes on some of the misconceptions that those outside of the Agile world still hold about the methodology and its frameworks.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
As an Agile consultant, I would like to put the many misconceptions about Agile to bed, so that as Agilists, we can better promote an understanding of what is, and what is not, Agile. I find so many times that a person’s perception is their reality. When that perception is based upon misguided interpretations, the result can lead to devastating consequences. I created the following list to perhaps help people in sales, marketing, delivery, or even any Agilist better understand what is a Myth and what is a Fact. As with everything Agile, the results of these lessons are not set in stone and are based upon your individual circumstances.
- Agile can’t support large projects – Agile is based upon small, cross-functional teams that collaborate throughout the software lifecycle and is equally effective on small and larger multi-faceted systems. The trend of Agile teams to decompose work into smaller pieces is especially advantageous on sizeable projects.
- Agile allows for fixed capacity projects –Certain frameworks in Agile require fixed capacity projects and others do not. When starting to help a Waterfall client grow in their Agile journey, we may recommend Iterative Waterfall or ScrumFall to start with rather than a direct transformation to Scrum. Iterative Waterfall and ScrumFall work well with fixed capacity projects. If the client desires to take full advantage of everything Agile can offer and eventually get to Scrum, or a scaled implementation, they must move to a variable capacity model and assign a full-time product owner to each team.
- Agile is a silver bullet that can fix all software challenges - Agile may not be the preeminent tactic where projects cannot be broken down into small units of work and completed in one to four-week increments. Agile should also not be used if an active client/stakeholder cannot be involved or has no willingness to adopt an incremental delivery strategy.
- Agile is another word for Scrum – Agile is just a word that describes approaches and frameworks. Scrum is an Agile framework used in projects that can be especially complicated. Other approaches in Agile are Lean programming, extreme programming, and hybrid methodologies, just to name a few.
- Agile is faster than Waterfall - Agile is less about delivering software faster, and more about delivering value faster. Which is worse, spending several iterations refining a feature with a customer to finally deliver what they really want or to deliver something faster, only to see it sit unused because we didn’t obtain feedback, and it didn’t match their expectations or didn’t adapt to a changing business landscape? Agile seems faster because there is less waste.
- Agile projects are undisciplined and unstructured - Most Agile projects are more process-driven and synchronized than traditional Waterfall projects. Agile necessitates more discipline because the scope is continuously reviewed and modified from planning to production. Key stakeholders examine the advancement at set times and continuously provide feedback.
- Business Analysts are needed in Agile - Like project managers, business analysts can take on a new title, such as Story Author. The Story Authors work very closely with the product owner to ensure user stories (requirements) are written in a way that most any developer can understand, and begin work on it without additional interaction.
- Everyone must be collocated in Agile to be effective - Agile stresses substantial stakeholder participation during a project. Ideally, the Scrum Team (development team, Scrum Master, and Product Owner) would all be collocated. With virtual technologies, this lessens the need for the Product Owner to physically sit with the team. Teleconferencing systems can facilitate daily meetings among team members, not in the same physical location.
- Planning is required in Agile - Detailed planning is as essential to the effectiveness of Agile as it is to Waterfall. The difference between the two approaches lies in the timing. Planning is ongoing in Agile versus taking place primarily at the outset of a project in Waterfall.
- Project Managers are not needed in Agile – The traditional Waterfall project managers are normally retooled to be Scrum Masters in Agile. The Scrum Masters are servant leaders that are principally charged with facilitating and removing impediments for a multi-disciplined Scrum team made up of five to nine members.
- The resulting product is not known in Agile until the project is complete - With Waterfall development, the resulting product is fully defined through written requirements before development starts. Any design ambiguity or unforeseen changes can result in delays and cost overruns. Agile handles indecision and ambiguity by employing a wide-ranging, all-encompassing plan during the first few iterations. The details are developed over time. This method affords stakeholders an improved understanding of what is being developed and delivered with every iteration.
- Documentation is required in Agile - Agile Story Authors do produce documentation, different from Waterfall. Waterfall creates a singular lengthy listing of all project requirements. In Agile, Product Owners can compile a collection of user stories that can be continuously updated, reprioritized with each iteration, and is used to deliver real-time visibility into the ongoing software development lifecycle.
- We’re a self-organizing Agile team, so we can do anything we want - The team always works on user stories that the product owner, in collaboration with other stakeholders, has determined are of the highest value to deliver. Developers and testers can influence the product owner in determining how to prioritize business and technical user stories, but ultimately the Product Owner determines what will be worked on next.
Opinions expressed by DZone contributors are their own.