Balancing the budget. Saving the middle class. Lowering taxes. Making government agencies adopt the agile methodology. One of those claims was not made in last night’s presidential debate. Can you guess which one? If you said agile, then give yourself a pat on the back.

The reason it wasn’t discussed – besides the fact that it would have put the electorate to sleep – is that making government agencies adopt the agile methodology has proven to be an unrealistic claim, and hence will not likely be part of anyone’s platform come November.

Here’s a good article on the difficulty of agencies trying to make this transition, with a few important points to consider:

Agencies continue to struggle with agile IT development, two years after former federal chief information officer Vivek Kundra made it a central piece of the administration’s 25-point IT reform plan. The agile approach, which is relatively new to the federal government, aims to make IT development more efficient and cost-effective. It focuses on more frequent incremental progress, letting agencies refine requirements as they go along and as technology changes. But the concept presents many challenges.

For one, agencies face difficulties holding contractors accountable, said Mark Schwartz, chief information officer at the Homeland Security Department’s Citizen and Immigration Services.

“And in an agile model, it’s not impossible to do that, but you certainly have to think about it very differently,” he said, because the process brings in many input groups and the requirements change frequently. Some points of accountability shift away from contractors.

…agencies must figure out how to get around roadblocks that threaten success under agile. CIOs have listed federal budgeting issues and cultural difficulties as major hurdles to adoption. And even if they find solutions, agile development will not lend itself well to certain IT categories, such as hardware.

The lesson here: The switch to Agile cannot be forced or mandated. It must be organic, with buy-in from all of the key players. Without this, the approach is destined to fail – but don’t take my word for it. Here’s a great quote from an interview we did with Scott Barber awhile back:

Honestly, I think the buzz around the “Agile movement” has, in many cases, taken the industry in an unfortunate direction. I meet far too many people and companies who are completely unfamiliar with the Agile Manifesto and think of Agile as a collection of practices, processes, and tools. The reality is that Agile is a far more a mindset and a culture than it is a collection of practices, processes and tools. Agile isn’t the best fit for every situation, or for every person.

I believe that the trend to “go Agile” is misguided. If a company is developing good software, the people involved in developing that software are happy working there, the software development is sustainable, and the business is being adequately served by that software, there’s really no need for them to try to be more or less Agile. Agile has challenges like any other culture, but the single biggest challenge I find is companies trying to solve development, process, management, and/or schedule problems by “going Agile.” Teams who have grown up in a culture that is fundamentally different than Agile simply will not find it easy to “go Agile.”

Think of it this way. Telling a team to “go Agile” between projects is like telling a professional baseball player to switch from being a right-handed hitter to being a left-handed hitter between seasons – and expecting that to break their hitting slump. You simply don’t see that. What you do see is batters working with coaches to re-evaluate their swing, work on their timing, spend more time in the weight room, etc.

Personally, I am happiest when I’m working in an Agile culture, but that is a personal preference, nothing more. What I do think would serve individuals and teams well, would be to read the Agile Manifesto and really think about whether or not those principles are a good fit for themselves, their team, and/or their organization. If so, I recommend embracing them.  If not, I recommend finding or developing an equivalent set of principles to build a culture around.

Have you or someone you know been “forced” to switch to the Agile methodology? Share your experience in the comments section.