Government // Leadership
Commentary
8/26/2013
11:32 AM
Roger Baker
Roger Baker
Commentary
Connect Directly
LinkedIn
RSS
E-Mail
50%
50%

What I Didn't Say About Agile

Former VA CIO Roger Baker responds to readers who haven't seen the upside of Agile development.

In my recent InformationWeek column, Why Feds Are Embracing Agile, I said "the case for Agile is straightforward." From a CIO perspective, it is all about saving money, building better solutions and, most importantly, avoiding project failures.

Based on some of the feedback that I've gotten, I didn't make one point clear enough -- Bad Agile (like bad Waterfall) can and will fail. Specifically, several noted that in their experience Agile programs have lower product quality, or that Agile is only suitable for small, inconsequential programs.

My direct experience is different, and I think I understand why. Effective systems development, Agile or Waterfall, must be a disciplined process, a point that was made most effectively by the creation of the Capability and Maturity Model (CMM) by Carnegie Mellon back in the late 1980s. Lack of a disciplined process will cause a systems development program of any type to have problems. I think that both sets of observations, good and bad, reinforce that effective, decisive management is probably the most important determinant in program success.

[ Want more expert advice from government gurus? See Government IT Contract Wins: An Insider's Perspective. ]

To be fair to those who disagreed with me, Agile is still emerging in some organizations, and may be immature and guilty as charged. However, we shouldn't use these examples as our benchmark, as we have significant evidence to the contrary.

In the case of Agile -- mature, enterprise-level Agile -- code standardization, build automation and integrated testing are key components of our software development processes. If these practices are being executed right, it is impossible not to deliver higher quality. And that's been our experience in engagement after engagement.

Also, government projects face unique challenges at both the front and back end. Specifically, the initial funding and authorization hurdles take longer to clear, as do executing the certification & accreditation processes needed to secure authority to operate. As a result, the core argument for Agile -- keeping big, long-term projects on track by breaking them into easier to manage components -- is even more relevant in the federal sector, as the overall process is longer.

Let me be clear that it is impossible for Agile to be a panacea as it's not even a single methodology. However, it does provide the tools and frameworks needed to be successful. The challenge is having the discipline required to use these approaches effectively and consistently.

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Alex Kane Rudansky
50%
50%
Alex Kane Rudansky,
User Rank: Author
8/27/2013 | 7:06:41 PM
re: What I Didn't Say About Agile
I agree that integrated testing is key. I'm curious how this works at the government level because of privacy issues -- who is the product tested on? Are there restrictions as to who can have access to the unfinished product for testing?
WKash
50%
50%
WKash,
User Rank: Author
8/27/2013 | 8:25:06 PM
re: What I Didn't Say About Agile
One wonders whether Agile had a better chance of working at VA, where former CIO Baker had an overarching IT authority that most other agency CIOs don't enjoy. That said, it's hard to imagine, given the pace of technology change, for committing to any IT project that doesn't incorporate an Agile approach.
cbabcock
50%
50%
cbabcock,
User Rank: Strategist
8/28/2013 | 1:20:35 AM
re: What I Didn't Say About Agile
Agile can't possibly work in every case. Waterfall before it didn't. But it brings not just a framework and a discipline to development but a system that builds in necessary feedback from the application's target users. The DevOps approach doesn't always work either, but if you start building the right approaches and disciplines into the respective staffs, it works much better than predecessor approaches. I don't think you can get to DevOps without building up an Agile state of mind.
moarsauce123
50%
50%
moarsauce123,
User Rank: Ninja
8/30/2013 | 12:33:11 AM
re: What I Didn't Say About Agile
Agile is just another fad so that consultants can make money. I've been on plenty agile projects and no matter how they are run and with methodology they use they all suffered from the "we can change anything at any time" think. Today we want this and tomorrow we want the opposite and that is perfectly fine, even when in two weeks we change our minds again. Agile is the cop out for utter indecision, lack of leadership, and hiding behind "the team".
liverdonor
50%
50%
liverdonor,
User Rank: Apprentice
9/3/2013 | 7:50:41 PM
re: What I Didn't Say About Agile
Um, no - Agile is the response of engineering teams fed up with being forced to spend months documenting a system, only to be made to change horses in mid-stream, then being beaten up by corporate management when (surprise, surprise) they missed their dates.
Agile works fine as long as a few things are understood:
a) just because you're agile, it doesn't mean you can arbitrarily change the fundamental nature of your project on a whim.
b) even though you don't need a copy of the Bible or War and Peace before you start building your system, you still have to have traceability from requirement through to tested and proven feature
c) you can't pretend that any methodology will magically fix everything.
d) if you don't have a solid, well-organized team structure, it doesn't matter what methodology you use - you'll end up with a herd of backstabbing cats at the end.
Keep these things in mind, don't go crazy down the rabbit-hole, reward entire teams for solid work as well as individual contributors, and try to have at least a few former engineers in management. Seen it work more than a dozen times with different companies over my career (which spans almost 4 decades).
liverdonor
50%
50%
liverdonor,
User Rank: Apprentice
9/3/2013 | 7:54:55 PM
re: What I Didn't Say About Agile
No one methodology is a panacea.
DevOps is, as far as it goes, a great approach and I've seen it work well, too.
Caveat - you have to have a flexible management structure to match. If your management isn't 100% onboard, it won't matter how good the coordination between your IT and Development teams are - you won't be able to release on time.
liverdonor
50%
50%
liverdonor,
User Rank: Apprentice
9/3/2013 | 8:08:34 PM
re: What I Didn't Say About Agile
At our company, we've discovered that a hybrid approach (Agile, especially XP, internals with a level-4 CMM framework surrounding it) works really well.
Of course, we enforce it all the way up and down the company. This means, everyone from the CxOs down to the part-time plant-watering lady is in on the game.
CTO is discouraged from forcing mid-stream program changes because his reward per year depends on the success/failure of the teams under him. Directly. If something he does adversely affects the ability to meet dates, and he pushes a change on the product teams, that goes in his record and if that means we don't meet our dates, his bonus gets cut accordingly instead of the team below being punished.
Our CEO is very progressive in this regard. She's a former 'Softie with a LONG industry track record. So far, we've only missed product dates once since we formed 6 years ago, and we iterate major releases every year.
Implemented correctly, agile methods can work. You just have to be sane about it. Fanaticism and lack of adaptability generally leads to failure (maybe not right away, but eventually and catastrophically).
StevenJ13
50%
50%
StevenJ13,
User Rank: Strategist
9/7/2013 | 5:12:18 AM
re: What I Didn't Say About Agile
GǣAgile is just another fad so that consultants can make money.Gǥ G Wrong. Just like in the other post you are completely misinformed. Consultants hate agile. Consultants make money on GǣscopeGǥ changes and contract modifications. That is the bread and butter, pure profit. Agile done right shouldnGt involve contract modifications.

Gǣthey all suffered from the "we can change anything at any time" thinkGǥ G That is bad management.

LetGs get into your last post:

GǣAgile is fine for apps that are very small in function and scope, that are intended to be thrown away within a yearGǥ G You mean how enterprise software should be built? Like how Amazon is built/ran? Or Office 365?

GǣSo for the dinky mobile apps that all are one trick ponies agile might work outGǥ G Oh like the dinky mobile apps with millions of enterprise users like Salesforce and Box?

GǣFor anything that amounts to a real application that is intended to be in use for years agile just brings more baggage and disadvantagesGǥ - Like everything at Microsoft, Facebook, Twitter, Google, LinkedIn and the 1,000 other successful engineering firms?

The jury is out. Agile done right works, results in a better product and is used by those actually delivering software and at a rapid pace.
2014 US Salary Survey: 10 Stats
2014 US Salary Survey: 10 Stats
InformationWeek surveyed 11,662 IT pros across 30 industries about their pay, benefits, job satisfaction, outsourcing, and more. Some of the results will surprise you.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek - September 2, 2014
Avoiding audits and vendor fines isn't enough. Take control of licensing to exact deeper software discounts and match purchasing to actual employee needs.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
In in-depth look at InformationWeek's top stories for the preceding week.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.