The term agile is being used for just about everything: parenting, business operations, personnel management, content marketing. What’s next – wine tasting?
What concerns me is that agile is everyone’s darling, everyone’s savior, the new hope. Help me, Obi Wan! Unfortunately, agile is also easily misunderstood.
Let’s start at the beginning.
Agile was created by a group of developers in the early 2000s. If you want the quick and dirty on what it’s all about, read their Agile Manifesto to understand the basic underpinnings of this development methodology. It’s not tricky – the developers who wrote the manifesto were tired of delivering systems that didn’t provide value to stakeholders. So, they came up with radical ideas about developing and delivering software that were different than the classic waterfall methodology.
Here’s a quick refresher on the key differences between waterfall and agile development:
- In classic waterfall methodology, we stick to a sequence: plan, determine every system requirement, develop, test, deliver, and move into maintenance. Once we’ve completed each project phase, we move on – without looking back. Requirements are fixed once agreed upon; resources and timeline often are modified, but – by design – requirements cannot be.
- Agile methodology follows a sequence, too, but it’s cyclical, allowing for more iterative development. It’s okay to look back – to tweak and retry something– before plowing ahead. The timeline is fixed, but requirements may be modified based on learnings as the project implementation proceeds.
- If you want to dive a little deeper into the difference, revisit this old post of mine: agile vs. waterfall 101.
Let’s clear up some misconceptions about agile.
Agile isn’t unstructured.
Agile implementations have structure that requires everyone to know their roles, authority, and accountability in the process. Agile is not a free-for-all development methodology.
SCRUM is agile, but agile isn’t SCRUM.
Over the years, different flavors of agile have emerged, each with their own twist on the basic framework laid out by agile’s creators. These include SCRUM, Visualization, RAD, Crystal Clear, and so on.
I frequently hear SCRUM being used as a catch-all phrase for agile. In reality, it’s the other way around: agile is the whole ice cream shop, SCRUM is just one flavor. But it is by no means the only or even the best flavor. However, I will say that SCRUM seems to be the most popular form of agile.
Agile methodologies have specific language.
Each flavor has its own language. For example, a few terms specific to SCRUM are: SCRUM Master (sort of like a project manager), daily SCRUMS (15-minute stand-up meetings), user stories (how functional requirements are expressed), and a product backlog (the full list of user stories).
One of the goals of SCRUM is to keep things moving, so it’s extremely clever to refer to the initial requirements set as a product backlog. It could have just as easily been called product features set or product user story collection. But by using the term backlog, it automatically invokes a feeling of, “We better get going; we already have a backlog!”
Agile does not mean requirements are wishy washy.
This is the greatest misunderstanding that I would like to clarify. I hear some vendors tell prospects that they use an agile methodology, and then go on to explain one of the benefits is that it allows them to see prototypes and change requirements as the system implementation progresses – that way the client gets exactly what they want. While one flavor of agile does develop this way, most don’t. To make this claim about SCRUM, for example, would be a misstatement. In most flavors of agile, the exact details of the implementation may change, but the user stories (the basis for requirements) give the development team plenty of detail – and those stories don’t change.
Agile requires training for everyone involved.
Please, please, please – ensure your implementation team AND your organization’s subject matter experts, project managers, leadership team, and everyone else involved with the project have training on how the selected agile methodology will be rolled out. It is a disaster to implement agile without training if your organization typically uses classic waterfall.
Believe it or not, agile doesn’t guarantee success.
Nor does it guarantee a better quality solution. It’s that simple. Without adequate leadership, stewardship, and resources, any project can blow up into a big mess – no matter what development methodology is used. Agile alone is not necessarily the answer.
Yes, agile allows more iterative development, but that does not automatically mean you will run over budget.
If managed properly, agile can deliver on budget and on time.
Agile isn’t for everyone, and that’s ok.
After teaching a graduate-level requirements analysis class at Georgetown University for 15 semesters, I have heard plenty of students tell tales of agile failures in their organizations. Your organization must determine for itself whether agile is right for your culture, your skills, and the specific project at hand.
How do you decide if agile is right for you?
Agile is great when:
- Decisions can be made quickly and confidently.
- Subject matter experts are available throughout the project.
- The entire team is comfortable not knowing every last detail about the solution before it is in the hands of the development or configuration team.
Don’t make any assumptions about agile with respect to whether it is right or wrong for your team or for a particular project. Agile works, but it isn’t foolproof by any means, so go into it fully armed with a clear and thorough understanding. Oh, and don’t get me started on the developers who say they have a “hybrid” approach – I’ll have to save that for another post.
Flickr photo by Vincent Noel