Staying Agile in a World that Isn't

I will start with the disclaimer that I am a true Agile Evangelist and have been part of many Agile teams of all shapes and sizes, both successful and unsuccessful. One of the things that seems to be universal in Government Agile projects is that eventually, no matter how Agile you are, your efforts crash into a wall in the organization that is not. It's never the fault of any person in particular, but somewhere in the process from idea to release there will be stakeholders that can only engage in a limited fashion. It can be easy to blame your own lack of agility on the culture around you and the limitations of the organization you're in. I've learned that there are ways to work within a non-Agile system and still achieve the results you're hoping for when you select Agile as your organizing framework.

Agile Isn't Your End Goal

It's tempting to measure how successful Agile adoption is by measuring how much you've adopted Agile. Did we hold sprint planning ceremonies on the right days? Did we have great attendance at our daily Scrums? Capital "A" Agilists will tell you that each of these ceremonies, steps, rules, and framework elements are vital pieces to Agile's success. When you have a mature, well trained, willing and able Agile team, each of the Agile elements do indeed play a role in shaping the team's behaviors and actions.  More important than the Agile framework are the behaviors the framework is there to enable: we want our team members to commit to completing their tasks, and we want our work to be transparent and accessible to our users, stakeholders, and business partners.

It's the behaviors and outcomes that add value, not the framework itself. Ditch the daily standup if your team has another way to hold each other accountable. Record your sprint demos and distribute them to interested parties that can review them for situational awareness when it works for them, instead of declaring Agile a failure because not everyone will engage at the cadence you want.

Bring Your Agile Process To Them

Your organization is a living thing that has organized itself in some form or fashion based on various historical or current factors. Work is getting done, governance is occurring, and smart people are making decisions throughout the structures that are in place. While you can't force all of those decision makers to officially participate in your Agile ceremonies, there are ways to educate them and leverage their influence to further what your team is trying to accomplish.

In an ideal world, the architects, business leaders, and stakeholders would be able to attend your sprint demos and your system demos (at the end of a major release). But they won’t, so it can be helpful to make existing organizational meetings a part of your sprint. There might already be a monthly Enterprise Architecture change control board meeting, so queue up a few features and make that meeting a planned activity during the appropriate sprint (and part of your definition of done for closing stories). Occasionally, invite a major stakeholder to your backlog grooming session to help them understand how upcoming work is prioritized and to provide their input on how to best roll out new functionality. This helps challenge the perception that Agile is "a lot of work" or requires a huge time commitment and allows stakeholders to be a part of the process. Try to find ways to go outside of the regular Agile ceremonies and cadences can help bridge the gap to those that are intimidated or don't understand how they can participate in Agile.

Practice the Principals

There are times when Agile is not an option. You might be in an organization where Agile has failed, and "Agile" has become a four-letter word. Maybe Agile is in its infancy and your management says they're not ready. I've found that the principles that Agile is meant to embody (and the behaviors that result) are universally applicable and can often be "snuck" into projects without using the official Agile language. Scrums become daily status meetings and GANTT charts look an awful lot like Agile Release Roadmaps. Your team can break down work into smaller chunks and have a strong definition of done.

While your organization might not support frequent Production releases, consider delivering functional chunks to a staging or acceptance environment while still participating in your organization's security and release processes. You can still use the Agile tools that allow you to document and track outcomes with the same rigor and discipline you would use on an Agile project, but you can choose how transparently you want to treat those boards. Often, a weekly status report is nothing more than a sprint report of what stories were closed or what blockers were encountered, and you can easily share that very information without calling them "stories" or "blockers".

Once you've had experience in a highly Agile environment, it's easy to reject organizations that can't match that same level of agility as "too rigid" for Agile. What makes a good Agile practitioner is not their ability to stick to the prescribed Agile process to the letter, but rather the ways that they tailor Agile frameworks to embody the spirit of Agile. In larger organizations, the gravity of their most unwieldy and inflexible components tends to pull programs and teams into their orbit. Agile allows us to still adapt, innovate, and experiment within those orbits and create high velocity teams while surrounded by slow moving partners and stakeholders. You just need to focus on the outcome, not the process, which sure sounds like one of the core pillars of Agile.

-----

I am the VP of Solution Engineering for MetaPhase Consulting. At MetaPhase, we focus solely on the Federal Government’s toughest mission, data, and technology challenges - applying Agile, DevOps, AI/ML and other modern approaches to solve problems at scale.