When you look at the big picture of agile, it’s easy to assume that it’s chaotic and lacking structure. It may appear less effective than Waterfall and other approaches, but in reality, agile’s apparently easygoing methods are an advantage because it is flexible and can change direction when necessary.
Because agile’s focus is on iterations rather than a straight-line approach, often businesses don’t understand its strengths. Agile is better suited to companies with changing needs or those that are comfortable with attempting several solutions to see which is best. Companies that do well with agile tend to better handle ambiguity and risk and acknowledge the ever-changing market for their products and services.
Those who aren’t familiar with agile’s advantages often have misconceptions about how agile works. Some of these myths are debunked below.
Agile is too haphazard and not methodical.
Those who are used to rigid BA approaches don’t like or trust the flexibility of agile because it responds to changes in business needs quickly, and a complete course alteration isn’t a problem. In other approaches, projects are planned well in advance and have little room for error or business needs changes.
Agile has no plan. We need a plan.
With other approaches, planning is heavily emphasized at the beginning of a project, and everyone knows their roles and workload early. With agile, planning occurs throughout and can change direction at a moment’s notice, depending on the iteration and fluctuating requirements of the business or stakeholders.
It’s true that with agile, the BA may not always know in which direction the project is heading, but that ability to alter course is often an advantage in an ever-changing marketplace.
Agile doesn’t give us enough documentation.
Clients love paperwork, planning, and documentation, and they want their BAs to do a lot of it. They often equate documentation with effective business analysis, and they want as much paperwork up front as they can get. (And that paperwork needs to look familiar to them.)
In agile, the proof of effective business analysis is in each iteration, and documentation is done during team meetings and throughout the project. Instead of typical paperwork that clients are used to seeing, the team creates “living” documents that are subject to revision.
We have no idea what we’re going to get when this project is over. Too many changes.
At any time, clients can ask for an update and know what the team is working on and what they can expect in that iteration. Communication is more frequent but less formal than in Waterfall or other traditional approaches. Business or stakeholder needs could change between the current iteration and the next one, which tends to make clients nervous, because they’re used to seeing little change after the project is planned.
In agile, it is expected that needs will change or increase in number. Agile presumes that modifications will occur, and the new requirement or business need is added to the next iteration.
What’s your favorite myth about agile?