Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
Fake Agile article

I'm sharing a link to a recent article on "Fake Agile" in the US Dept of Defense. Hopefully this meets the guidelines for posting.

How Fake Agile At DoD Risks National Security by Steve Denning

I'm sharing because it's another brief summary of the guidance the DoD put out earlier this year, and although the DoD should not be considered an authority on Agility, it's still an interesting read for anyone who hasn't seen it.

More than that, though, this author provides a quick analysis of the challenge of Agility within the DoD in non-software related (i.e. combat) examples. Hopefully your projects don't involve combat, but I know there are many PMs here who don't specifically work in software projects and are sometimes left wondering what all this "Agile" talk has to do with you. About half way down in the article, the author gets into command styles; you might find some interesting comparisons here that you can apply to your workplace, even if you're not an "Agile" organization.
Sort By:

I like Steve's three agile laws. Thanks for sharing, Wade.

The business and nature of war has changed and this was never more evident that Post 9/11. The US DoD and Intelligence community realised they were still using cold war tools and techniques in the twenty first century. The art of fighting your enemy on the battlefield has change and now its urban warfare and cyber warfare that will probably deal the first strike. The vast US military infrastructure needed and still needs to respond to this evolving threat. The fact that projects are being sold as Agile but are incremental or waterfall in methodology demonstrates this fact. One issues that hinders the US military ability to evolve to this threat is how funds are authorised by Congress in the US and the difficulty any President has in getting a budget through Congress. Success favours conservative thinking and its budgets take the shape of more of the same without allowing a complete revamp in how the US military conducts its business. The US military has the resources, people and experience to make the necessary adjustments and ensure it relevancy in todays world.

Although government agencies are legendary for this type of phenomenon, it's common in large bureaucratic organizations.

I've seen the same with Lean. We're all going to Do lean this year (Note: not BE lean). To do lean, we will create lots of templates, processes for organizing our servers, sometimes literally making outlines on our desk of where the stapler goes. Then an auditor comes around and looks at how for one moment in time we have everything neatly organized, so we can declare victory and abandon all that work we did for the sake of fulfilling some director's efficiency goal for the year.

Agility should always be measured based on outcomes and not practices. If we aren't delivering value early & regularly, we aren't improve the quality of what we are delivering, and we aren't making folks awesome, then we can't claim to be agile.

If the current systems, organizational structure or prevailing culture blocks us achieving improvement in one or more of those dimensions, it is a good test of the leadership team's commitment to agility to see what they are willing to do to overcome those...


The problem with this type of articles and mainly with all articles written by Dennng is always the same. they supposse that Agile was born with the Manifesto for Agile Software Development. That was the implementation of Agile in the software domain. In fact, it forgot Agile movement was created by an initiative sponsored by the DoD and the NSF in 1990. But not only DoD sponsored it, DoD applied it beyond the creation of software because the initiative was created without thinking in software. It was created after making a prospective analysis about how the world will be in 2005-2015 and after that they take notice that Lean was not enough to survive, growth and develop in that future world.

Thanks for sharing the Forbes article, Wade. What I witnessed in my years serving as a software implementer in the DoD was a spirited movement toward something akin to what many would call an agile philosophy, yet maybe not agile pragmatism as we practitioners understand is to be. Much of the military still abides by a "command, control, and communication" (C3) management structure which inhibits the open system, self-organizing and flatter organizational pyramid found within most general agile frameworks. In fact, many DoD software methodologies are still taking a page from the RUP, Rapid, and MIL-STD-498 playbook.

Just because a department within the DoD provides its employees a 30min PPT on agile doesn't mean they become instant Adopters. Embracing is a process. Every level within the organizational hierarchy must see the value of such a radical process change if agile is to be a commitment swept broadly across its organizational culture.

Before a particular project management methodology is given a name it first comes into existence in the workplace as a streamlined group of processes or steps in order to successfully complete a group of tasks. These processes of steps follow the particular architecture of that particular organisation. A methodology should be seen as the framework or skeleton that supports the organs within a organisation. As a result the methodology directly mirrors the body of structure that it support. Therefore you can not change one without changing the other. In order for the DoD to fully adopt the agile methodology it must rationalise the DoD departments so that they are agile in their day to day function and structure. Also all the third party suppliers to the DoD would need to implement the Agile methodology with regard to its relationship with the DoD. Only then could the DoD go about truly implementing the agile methodology throughout the DoD.

One of the essential elements for increased agility is trust. You can't eliminate management waste if you refuse to trust your teams.

In the case of government agencies like the DoD, there's an inherent mistrust ingrained in the culture. Managers and Senior Executives are considered responsible for everything their subordinates do (in the case of the DoD, this even applies to off-duty activities). Political influences pitch high-ranking members against one another. And taxpayers demand to know that their dimes aren't being wasted, so documentation becomes more important than operations.

But I'm not just picking on government agencies. I've witnessed first-hand how the lack of trust can slow progress in private organizations, as well. We've gotten pretty good at identifying waste on the manufacturing floor, but we're not as good at applying lean principles to management. So we set our teams off to estimate unknowns, document how they use their time, and we take away opportunities for reflection and self-improvement.

All this to say: it's easy to read articles like this and criticize the DoD from a distance, but how many of the same issues exist in our own organizations?

Very interesting read. Thanks for sharing, Wade!

Really interesting, thanks. It is so easy for developers to describe themselves as agile and then build the system that they want, rather than one that matches the users' requirements.

Please login or join to reply

Content ID:

"Of all the 36 alternatives, running away is best."

- Chinese Proverb