4 Agile myths and how to avoid them

It’s an exciting time to work in federal IT. Despite what you read in the headlines, we are experiencing a renaissance in the creation and delivery of government IT services where technology, and the customers who use it, are leading the charge.

The move to Agile is at the heart of this change. The concept of short release cycles that produce high-quality products (instead of documentation) and small, cross-functional teams (not behemoth PMOs) that self-organize has finally taken root in federal IT shops. This reality is producing both big results and big challenges.

The biggest challenge of all? Doing it right.

Agile is everywhere now - in marketing emails, news articles, and RFPs - but how many agencies are getting it right? Agile works when it is understood and practiced the right way. And it’s not easy to move a large agency with all its systems and dependencies from “waterfall” to an Agile approach overnight.

Bottom line: you can’t just add the word “Agile” to your procurement documents or your project name, and then refuse to make any real changes in how you deliver. That’s not Agile. If this sounds familiar you’re not alone, we see it all the time. Here are a couple of the more popular myths about Agile that can derail your adoption:

Myth #1: Agile is something that you “do.”

If anyone says, “we are going to do Agile here…” it should be a red flag. Agile is a mindset shift to embrace, not a process to deploy. And it makes sense that process-minded program managers look at it this way at first, especially when they want to make big changes.

Myth #2: Scrum = Agile.

Scrum is the most commonly used Agile methodology, but doing Scrum doesn’t mean you’re being Agile. You often see teams holding Daily Scrums, and other Scrum ceremonies, but still requiring long testing cycles, creating comprehensive requirements documents, or executing lengthy deployments. “A la carte” Agile is neither Scrum nor Agile – it’s faking it.

Myth #3: Product Owner is a “part-time” role.

The Product Owner is a critical role on any Agile engagement, yet many in the federal space simply make the most important person in the room the Product Owner no matter how ill-equipped they are to do the job. Since the Product Owner serves as the voice of the customer, and the team needs daily interaction with them to be successful, this is not a role that can be third or fourth on someone’s to-do list. Successful PO’s are fully engaged, informed, and connected to their mission every day – they don’t have time to fake it.

Myth #4: Your tech can lag behind your agility.

Having a successful Agile approach is only half the battle. If your technology platform is a dinosaur and you’re using old tools, your quick-paced team can be slowed down or stopped completely. To ensure that your team can deliver early and often, let your technologists select the tools for their team the same way your let your customers decide what features they want to see you build. Your customers know what’s best for them and so do your technologists. An open source mindset is not a fake, it’s the key to your success.

There’s a reason why taking an Agile approach has driven so many successful innovations in the commercial world – because it works.

And there’s no reason why government IT cannot innovate, deliver, and lead in the same way. It’s happening every day. The rest of us will get there, we just need to stop believing in the myths and commit to getting Agile right.

About the Author

Dave Neumann is a partner and the federal practice lead at Excella Consulting.

Reader Comments

Tue, Jan 24, 2017 BobN

TRUE: Myth #2 -- "Scrum does not equal Agile" ALSO TRUE: "Not Scrum does not equal not Agile" Too many Federal projects adopt Scrum without considering alternative Agile methodologies that might be more appropriate to their mission, size, lifecycle stage, constraints, etc.

Mon, Jan 23, 2017 Tim Hodkinson

I couldn't agree more. So many big enterprises have made and continue to make these mistakes and no one seems to get it. When your business partners want a swift change in direction all the daily stand up meetings, backlogs and planning poker won't do you any good if you don't have a comprehensive set of unit tests, CI/CD and a (small) team of capable, empowered developers

Sun, Jan 22, 2017

Nice article, so far in government projects I have worked on, are combination of waterfall and agile. When it comes to Project plan defining the features and assigning the start and end dates. does it make it an Agile project.

Sat, Jan 21, 2017

This sounds like admirably polished salesmanship. But with no back up or bona fides presented. Perhaps the writer could explain. Some are probably interested. But customers are wary of software miracle men and women, especially if they are "consultants," but beholden to proprietary software. Is Agile usually wrapped in proprietary "clothing." Please explain

Fri, Jan 20, 2017 p n/a

Good piece.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above.


WT Daily

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.