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.