- Date: April 6, 2017
- By: Rachelle Rood
We love busting myths.
OK, so we're not quite as YouTube-worthy as those Mythbusters. But we still want to bust some myths about Agile. Here's four of 'em busted.
1. We No Longer Have to Plan
In traditional "Waterfall" development, most of the initial work on a project is dedicated to planning.
Business analysts create user requirements, system requirements, and functional requirements. Project managers create project plans and Gantt charts.
Then the developers get to work.
At first glance, Agile looks to skip past all of the planning and put the developers to work right away.
In reality Agile has as much planning as Waterfall, it's just broken up into smaller chunks and performed more often during the development process. Each two-week "sprint" starts by gaining agreement on what features will be developed.
Daily standup meetings check smaller increments of progress against the two week goals.
2. We Can Only Build Small Projects
The Agile process creates small teams that collaborate as the development happens. The teams are designed to be cross-functional.
Small team = small project, right?
Not necessarily so.
Bigger projects can be divided up in different ways. Teams can be assigned to build out different parts of the architecture, or focus on specific features.
Agile largely works because it breaks down complexity into smaller chunks and moves faster to build each chunk. That idea scales no matter the project size.
3. We Can't Have Remote Workers
It is true that Agile encourages involvement from stakeholders and business leaders throughout the development process.
That aspect of Agile can cause people to think that all Agile team members have to be under one roof.
In reality there are many co-located and all-remote Agile teams.
Communication needs to be realtime, yes. Collaboration is crucial, yes.
But technology can step in to help communication and collaboration happen, easing the burden of requiring all team members to be at a single location.
4. We Don't Really Know What We're Building Until It's Done
Waterfall development starts with the end in mind. The end product is highly defined in advance of the work beginning.
The challenge with the Waterfall method is that often times requirements change midstream. Clients redefine things. New features get added. New directions are set.
Projects get delayed. And cost estimates based on the original functionality go out the window.
Agile starts out by admitting that most projects have uncertainty and the potential for change. A high-level plan defines the overall goal, but details are refined as the project is built.
Stakeholders get confirmation of near-term goals with each sprint while the overall direction stays true to the high level plan.
Any other myths you've encountered about the Agile Development process? Contact us. We'll put our flame retardant suits on and fire up the video cameras.