3 Agile Government Myths, Busted - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Government // Leadership
Commentary
10/3/2013
12:29 PM
Connect Directly
LinkedIn
Twitter
RSS
E-Mail
50%
50%

3 Agile Government Myths, Busted

Agile development principles can help federal IT departments save time and money -- if they can get past the barriers.

The federal government is traditionally hesitant to adopt ideas that challenge deeply entrenched thinking and practices. But when it does, the energy brought to bear is astounding, and the results are mostly for the better.

One of the latest ideas to catch on with federal IT is agile development, which addresses the pressing need to deliver software projects more reliably, with higher quality and at less cost. This concept is big, and so is its potential. It impacts IT staff, the contracting community, program staff, leadership and procurement. If it's more fully adopted, agile development will alter spending for a large share of the $80 billion federal IT budget.

So what's standing in the way? There are three common excuses used for avoiding a move toward agile development -- but these are more myth than reality.

Myth #1: Agile is new and has to prove itself.

The reality is that agile has been around since the dawn of software development -- as iterative or incremental development -- and has repeatedly proven its value. The bedrock idea of agile development is to grow software by delivering working chunks of code to your customers regularly.

[ What can you learn when an IT project crashes and burns? Read Lessons From A Failed Federal IT Project. ]

All agile values, principles and practices flow from this idea. Project Mercury, begun in 1958, practiced half-day iterations and test-first development. Computer scientist Gerald M. Weinberg, recalling Project Mercury, once remarked, "All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid..."

Leading practitioners of software development from every decade since the '50s have argued that agile-like development is the most reliable way to deliver complex software systems.

Myth #2: Agile is just a process.

Agile teams use processes, but it requires much more -- agile is a set of values, principles and practices in the hands of competent professionals. There is a misconception that says, "If only we followed a process, we could control for success regardless of who's on the project."

There is no substitute for skill in software development. Skill is required to know what practices, processes and tools to use, and that has significant impact on outcomes. For example, the productivity of the top 1% of developers has been measured repeatedly at 10 to 100 times the productivity of the median! Even more telling, it's been estimated that about 10% of programmers actually have "negative productivity" -- under-skilled staff undermine projects.

Myth #3: Traditional PMO methods are compatible with agile development.

Planning without doing will fail to expose most of the risks a software project will face. Moreover, the only measure of progress that matters in software development is working software, not documentation. IT must measure progress by what's been finished, based on doing lots of small things. Leaner, well-run project management offices produce more accurate measurement and projects that are more efficient.

In contrast, the project controls demanded by traditional PMOs are dangerous -- and they're incompatible with agile. Demanding detailed project plans prior to doing any development, and measuring progress by resources consumed and "estimates" of percentage complete is misguided. In addition to generating misleading progress reports, these PMOs substantially increase cost and risk.

Start Now, With Agile O&M

There is no need to wait for the next big new development project to consider agile.

With an estimated 80% of the IT budget spent on operations and maintenance (O&M), leaders need to take a fresh look at their entire portfolio. By implementing innovative approaches such as lean methods of work, agile principles and leaner PMO, and by empowering project managers to be high-tech (using dashboards, for instance) and high-touch (collaborating over working software), government can see astoundingly positive results.

Displacing the deeply entrenched waterfall methods from government will not be easy. IT leaders need to retool procurement and rethink how they staff and manage development and O&M teams. Some organizations have applied agile and lean principles to O&M with great success, as I've seen done at the Federal Communications Commission. The result was increasing productivity and customer satisfaction with fewer resources than before agile O&M.

With those kinds of cost savings and gains in productivity and end results, who can afford not to become agile?

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
WKash
50%
50%
WKash,
User Rank: Author
10/3/2013 | 6:24:54 PM
re: 3 Agile Government Myths, Busted
The debate continues, but it's certainly hard to argue that the waterfall approach to development makes any sense anymore.
Slideshows
9 Steps Toward Ethical AI
Cynthia Harvey, Freelance Journalist, InformationWeek,  5/15/2019
Commentary
How to Assess Digital Transformation Efforts
Lisa Morgan, Freelance Writer,  5/14/2019
Commentary
Is AutoML the Answer to the Data Science Skills Shortage?
Guest Commentary, Guest Commentary,  5/10/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
A New World of IT Management in 2019
This IT Trend Report highlights how several years of developments in technology and business strategies have led to a subsequent wave of changes in the role of an IT organization, how CIOs and other IT leaders approach management, in addition to the jobs of many IT professionals up and down the org chart.
Slideshows
Flash Poll