By Christian Bisson, PMP
Agile approaches allow for iterative and flexible avenues to develop software. (It can be used in other fields, of course; I work in the software world.) When used properly, it can be an efficient way to adapt to changes in requirements and scope, and provide stakeholders with an up-to-date and ongoing list of deliverables to review.
Unfortunately, it’s a misunderstood approach that leaves many of us wondering if they’re really working in agile ways. Here are a few misconceptions I’ve encountered throughout the years.
Things just change names
My favorite misconception of agile is that terms suddenly need new names.
Meetings become “scrums” or “daily scrums”—even though the team is just having a regular meeting. A “week” becomes a “sprint”—even though there is no deliverable/release at the end.
Going faster is agile
Project managers sometimes “crash” a schedule to speed up project deliveries, knowing that it uses more budget in order to meet a deadline. Sometimes “crashing” is confused with “agile,” which is thought to deliver projects sooner and cheaper by having everyone start their work sooner than they would have in a traditional waterfall approach.
Having people start sooner and risk rework is still crashing even if the practice is called “agile.”
Stakeholders don’t have to be involved
Stakeholder involvement is a critical part of the agile approach. It requires them to be available and in constant discussion with the team. This prevents surprises and allows constant feedback.
The misconception I see sometimes is that a team can work “full agile,” with stakeholders only involved when they receive assets and go through their typical review cycles.
We’ll just “try” agile
Agile is not about trying out a new software. It’s a culture, and it involves everyone from stakeholders to the team. Some believe that a few people can “try agile” on a project and see how it goes, even though none of them worked in an agile environment before.
Scope and cost can be fixed
Although agile could work with a fixed cost, it is quite the trap. Agile assumes that what will be delivered is the work that the team was able to deliver in a set amount of sprints, and each sprint will cost a certain amount based on the team’s size (among other things).
This means that if a feature took twice the amount of time estimated because it was decided to create something a bit more complex, then another feature might be removed or budget will be added to compensate. However, if you keep the budget the same but still expect to deliver everything planned on day one, then this more complex feature is simply scope creep.
These are just a few examples of agile misconceptions. My bottom line: When I’m told stakeholders want to use “the agile approach,” I make sure to ask for a definition of agile.
Have you encountered other agile misconceptions? Share them below!