Debunked: 4 Myths about the Agile Methodology

April 20, 2016 Appirio

By Chris Bell and Jiordan Castle

  1. Agile means you don’t have to plan

With agile, you’re not fooling yourself into thinking that a plan that was put together a year before the end of a project will accurately predict the project’s outcome. An agile methodology means starting off with a plan that accounts for capacity, time, and a commitment to team members. You build the plan as you go, which allows for greater insight over the course of the project — not just in its initial phase.

  1. Agile is for projects with undefined requirements

In truth, agile means defining requirements more clearly. You’re not just asking what the system shall do; instead, you’re talking about what you’re trying to accomplish, who you’re accomplishing it for, and why it’s a benefit. When you have a list of “shalls,” you can point to one and ask, “What was the genesis of this?” and not have an answer. That actually makes it much harder to prioritize.

With agile, you get better requirements that you’re more able to prioritize. In fact, sometimes you do start with requirements (with agile), which can cause you to realize that some don’t matter and even that you’ve missed some that do.

  1. You don’t know what you’re going to get with agile

An agile methodology isn’t like getting dressed in the dark, hoping for a match. Agile involves getting everyone’s input — the whole business (IT, management…); the team plans it together when doing a sprint, challenging assumptions and stating clearly what needs to be demonstrated at the end of a sprint in order to get a clean sign-off. Agile gives you the flexibility to reprioritize as you go. This is key because, in reality, business processes aren’t static. And the business process you thought you were following can turn out to have surprising variations when you see your process in an in-progress demonstration. These revelations are often the most critical; this is where we find gaps and see that the business process has actually evolved from where it was when last mapped out.

  1. My project plan gives me visibility into my project

We’re going to have to disagree with you there. Seeing things working at the end of every 2-3 weeks (and during) — that’s what gives everybody visibility. While you may feel you need that project plan, it can’t tell you that the end result is going to be what you’re looking for. Numbers can give you a false sense of security; it’s more the illusion of security, like having a visible security system that’s not hooked up to anything.

What it really takes to make an agile approach successful

All of these positive findings are conceptual if you don’t get firm commitments from all members of the team. People have to be there, involved, every day. The commitment to quickly resolve issues, make decisions, and answer questions needs to be there. Something to remember about agile is this: You won’t be surprised; you’ll see the results multiple times in a sprint, and have all the hard conversations along the way.

In fact, this is why we often call the daily standup a scrum; we liken the team to a rugby scrum, moving down the field together. How could you be surprised by where the scrum ends up? You were there.

Previous Article
Learn How to Create a Great Constituent Experience
Learn How to Create a Great Constituent Experience

Next Video
Worker Experience Fails Pt. 2
Worker Experience Fails Pt. 2

What would work be like without collaborative cloud tools? Join us to learn more about engaging your employ...

We love hearing from our customers, partners, and friends!

Contact Us