Americans often complain about their broken government’s inability to get anything done. Partisan politics separates us into us-versus-them camps, and people dig in their heels. Yet when we finally get action, as with the recent Supreme Court decisions and resumed talks with Cuba and Iran, it serves only to divide us further. It’s an ironic cycle:
Our divisions prevent political progress. Yet political progress furthers our divisions.
A Glimmer of Hope
Yet one hopeful idealist hopes to change all that with a technique borrowed from the business world. Luke Hohmann is the founder of consulting company Conteneo, and also the inventor of Innovation Games. If you know me, then you’ve probably heard me talk about Innovation Games. But as a quick summary, these “games” are structured facilitation agendas designed to gather insights as to what is truly important to people. Unlike those bland and dry customer surveys, these activities are intended to engage users, consumers, and customers directly. From quietly observing how people use actually products (The Apprentice Game) to brainstorming a categorized set of desired features and benefits (Prune the Product Tree), product managers get deeper information than ever before. Both Luke and his company have had impressive success, installing this approach at Fortune 500 innovators from HP to Adobe.
However, in 2011 Luke had a unique idea: what if the most important product we build, is our government? He formed a non-profit to explore that idea, the Every Voice Engaged Foundation.[tweetthis url=”http://wp.me/pv0z1-rb”]What if the most important product we build, is our government? Here’s the story of business #collaboration applied to politics [/tweetthis]
Here’s what happened.
San Jose and Missoula are on board
In August of 2011, his Foundation teamed up with the city of San Jose to host the first ever “Budget Games”. The event featured citizens seated in table groups, discussing some hard choices around the tight city budget. To help that conversation, they were handed equal amounts of monopoly money, and each proposed line item was given a sticker price….oh, and the amount allocated was about half the amount needed, which now forced some serious conversation about tradeoffs. This is very close cousin of the same “Buy A Feature” activity Luke has popularized for the prioritization of product features that product managers debate vigorously.
Here’s the fascinating part: it worked. When the event was over, everyone had agreed to some specific cuts (run the city’s fire trucks with one less fireman) and increases (half the groups were willing to accept a sales tax boost of 0.25 percentage points). They were highlighted in Bloomberg and Financial Times and when they repeated the event in 2012, and have continued the tradition since.
Lest you think this is only for west coast hippies, let’s talk about cowboy country in Missoula, Montana. In 2014, a City Councilwoman asked Luke to host the same buy-a-feature game at a town hall meeting, as a way to gain ideas for tackling the municipal budget crunch. One idea that popped up: offering urban deer bow-hunting permits, a practice already allowed in other districts. These city-dwelling Montanans were definitely curious, but not quite sold..yet.
Now for Going Big
I’m pleased to announce that I will be sponsoring the Every Voice Engaged Foundation’s presence at Agile2015.
Last night, I attended the Washington DC Scrum User Group’s monthly meeting, where a group of 25 technology professionals talked about the Healthcare.gov crisis. There’s been a lot of debate in traditional media as to why the website project incurred so many issues.
The group discovered four common themes…
No One in Charge: The congressional hearings revealed the classic accountability problem: Everyone was in charge of their part, but no one was in charge of the whole thing. If there were ever a conflict over which agency or contractor needed to own an issue, there was enough ambiguity to deflect any blame. Also, even if CMS took accountability for stitching together all the pieces, they would have needed the appropriate expertise in house, which by all accounts, was not the case.
Quality: By now, we’ve all heard the story that overall system testing began way too late in the game. Each agency or contractor reportedly delivered their components just fine, but cross-system testing happened too little, too late. The group discussed the value of continuous integration, applied not just to the individual components, but to the entire program.
Big Bang Delivery: The opposite of continuous integration is last-minute, all at once integration, which we saw with Healthcare.gov. The group wondered out lout what problems would have been avoided if the program release support for only 1 state at a time. Releasing one small piece of the capability at a time allows for progressive learning and elaboration of the technical solution.
Volatile Requirements: Several fascinating points were made regarding the scope of the project getting delayed and changed in a way that would put any technology project in jeopardy:
- Scope Unrealistic: One person made the point that the ACA law refers to “the website” 118 times. This means the website project was launched with over a hundred system requirements, which ostensibly, had not been reviewed by technical experts.
- Scope Delayed: Much like any large scale project, the 2012 election created very real political forces on the project. Out of a sense of prudence and self-preservation, the administration held off on several policy decisions that were feared to have a potential impact on the election. As a result, key questions (like the difference between a gold and silver plan) were delayed until after the president and the democratic Senate were safely secured.
- Scope Changed: When the Supreme Court ruled on NFIB v Sebelius in June of 2012, all of the Medicaid expansions were invalidated. Needless to say, that would require any previous work on that piece of the system would have to be reworked.
- Scope Expanded: The website was originally envisioned to be a pass-through portal to the state-run exchanges. However, when Republican governors overwhelmingly decided not to create state exchanges, the federal website would now have to support those states as well. Expanding from 8 exchanges to 34 could not have been a trivial change.
This week marked the latest annual Agile in Defense conference, in the outskirts of Washington DC. There were about 100 attendees, and strong support form the agile community. As with any conference, the real value was the conversations that happen between the talks, but the talks themselves are also worth mentioning…
Warnings From the Past
I showed up a little, but just in time for Dr. Robert Charette’s talk. He gave a hard warning about the pitfalls of NASA’s Faster, Better, Cheaper program in the 1990’s might be repeated once more in the Defense community. Specifically, the program met with some initial triumphs such as the Mars Pathfinder project. But the continued pressure for “cheaper” began to create a culture of compromise, which some say led to the Challenger disaster. The response was to swing the pendulum all the way back to the extreme opposite end: never ending budgets. He warned us that mentality could bankrupt the military.
Agile EVM for Defense
Scrum expert Brent Barton then gave a tutorial on how to calculate Earned Value Management (EVM) in an Agile environment. Easily the most practical talk of the day, it was based on his original white paper, which you can download here.
The Agile Virus Spreads
Ronald Pontius, the Director of C2 Policy for the DOD CIO, gave an update on specific agile initiatives in the DOD. First, the Section 804 of NDAA 2010 and Section of 933 of NDAA 2011 are formally closed. The Office of the Secretary of Defense (OSD) completed its report for developing a strategy for rapid acquisition. That report included a proposed a modification of the DOD 5000 acquisition standard to be more iterative. But that was just the beginning. Not only did he cite 9 active programs seeking to be more agile (e.g. streamlining for “integrated test” initiative at Department of Test and Evaluation, but he gave a few pointed assertions:
- “The latest acquisition guidelines are encouraging concept of “time certain” delivery” (aka “timebox” in Agile speak)
- You can’t execute in smaller chunks if the requirements guys aren’t on board”
- “The CIO of DOD, Ms. Takai, is absoletly embracing agile”
- “Agile is consistent with Under Secretary Ashton Carter’s “Better Buying Power” defense memo“
- “All the C4SI senior project officers “get it”. The problem is at the middle management level.”
It was an encouraging list of the seeds of positive cultural reform.
Agile By the Numbers
The most enthusiastic talk of the day came from Dr. David Rico’s talk featuring some shocking statistics.
- Large systems are risky. When systems approach 400 millions lines of code, bad things happen
- The average productivity for a DOD system is under 1 line of code per hour
- Of the world’s $1.7 trillion in IT expenditure, $858 billion is lost
- Today 60-70% of DOD projects are using #Agile methods, including the F-35 and F-22 (My guess is all those projects may have at least one agile teams, but very few full program-wide implementations of Agile/Lean methods)
In its September meeting, the DC chapter of Agile Project Leadership Network hosted a presentation called “IT Acquisition Centered on Agile Processes”. It’s a rather boring name for what was a really exhilerating talk about Agile momentum in the most waterfall of worlds: defense procurement.
The presenter was Don Johnson, who works for the office CIO of the U.S. Department of Defense. In his presentation, he cited a number of points that reveal a growing consensus within the military that old ways of procurement are becoming less effective. He started by noting the key regulatory standard for procurement, DODD 5000.1, was originally developed in 1977 and has remained mostly unchanged since then.
But that was just the beginning:
- In a speech last year, Defense Secretary Robert Gates called procurement processes “baroque”.
- Army CIO LTG Jeff Sorenson has said, “how we can make it better…Policy. Acquiring IT not like tanks.”
- In 1970, IT accounted for approx 20% of weapon system functionality, by 2000 it accounted for as much as 80%, and today it is reported IT can deliver 90% or more of functionality.
- IT Systems are growing in complexity. The FA-18 runs on 10 million lines of code, but the more recent Joint Strike Fighter has 20 million. Also consider the handheld grenade launcher uses smart projectiles guided by 2,000 lines of code.
- Even the Government’s oversight agency (GAO) has itself said, “As you know, the way in which DOD has historically acquired information technology (IT) systems has been cited as a root cause of these systems failing to deliver promised capabilities and benefits on time and within budgetâ€¦”
Don explained that today’s procurement involves “long cycle-time driven by processes developed to counter a cold war adversary in an industrial age society”. Defense departments utilize a “big bang approach equally applied to it and major hardware acquisitions”. This becomes especially complicated when you consider that software is increasingly at the heart of the largest hard weapon systems.
Well, eventually the momentum became so great in 2008, Congress responded to these concerns by mandating a Defense Science Board (DSB) to study current policies and procedures. At the end of their analysis, they recommended a new IT iterative, incremental approach to project acquisition and execution. The DRB’s recommendations have been so compelling, they were invited this past May/June to testify to Congress about their strategy. Congress has responded and drafted an unprecedented nod. Next year’s Defense appropriations bill will authorize Gates to “designate up to 10 IT programs annually to be included in a demonstration of an alternate acquisition process for rapidly acquiring IT capabilities” (2010 NDAA, Section 804). In normal English, that means the United States is working on a law to reform procurement from the cold-war big-bang approach to an iterative incremental approach.
It’s one thing to pass a law, but it’s quite another to have it mean something. How often have we heard about the laws that have no effect? To that end, the DRB has crafted an implementation strategy that consists of policy documents describing how to do it, and picking the right pilot projects to start with. Furthermore, the DSB has a relationship with the council of Federal CIOs, allowing the new procurement approach to be socialized among officials from all parts of the entire United States government.
By the end of the evening, the room was full of energy. Several of the chapter’s previous Agile Government presenters were on hand to lend their support for Don’s work. Stay tuned. There is certainly more to come.
This past Thursday, the Washington DC chapter of the Agile Project Leadership Network conducted its monthly meeting. The chapter hosted a roundtable on Agile in the Government, and featured the following panelists:
- Dr. David Rico, PMP of Boeing
- Nathan Carpenter of Pyxis Engineering
- Richard Cheng, PMP CSP of Excella Consulting
- Thad Scheer of Sphere of Influence
With such a talented panel addressing a topic that resonates strongly with Agile practitioners in DC, it was a format certain to deliver good nuggets. The moderator, Bearing Point’s Matt Vandegrift opened the evening with some discussion around current momentum and opportunity. For example, the CIA’s CIO has issued an agency wide mandate to use Agile Project Management. However, some expressed skepticism over the long-term impact of an appointee who would likely be off to another assignment before real culture change can happen. Mr. Carpenter suggested the most Agile-friendly agencies are those with an existing entrepreneurial culture of value delivery, such as IARPA or DARPA. However, most of us know those kinds of government cultures are far and few between.
Eventually, the age old debate surfaced of bottom-up grassroots adoption versus a top-down Agile mandate. Interestingly, a consensus emerged that this was the wrong debate. Both the panelists and the attendees called out mid-level government bureaucracy as the key barrier to effective Agile adoption.
Even if a senior sponsor wants to alter project scope to reflect emerging information, the project’s contract officers will resist it. A mid-level career staffer serving as the Contract Technical Representative (COTR) will be graded on performance-to-plan. Indeed, many situations carry more than just career consequences for adjusting scope, they may face criminal charges. Current procurement policies and statutes are designed with a plan-driven philosophy. If your project takes 2 years to get funded, it’s not the COTR’s fault the scope is no longer relevant to the mission, but he still gets stuck with it.
Mr. Carpenter further broke down the this dynamic into functional roles. In his mind, the real opportunity for breaking through this impediment is not the technical route (easier), not through the Prime/Sub teaming partnerships (harder), but from government PMOs.
Claire Moore, also from Sphere of Influence, challenged the group for some value metrics to facilitate such a cultural transition. What are some examples of programs that measure “value to mission”, rather than “performance to plan”? Several examples were cited (decreased costs, customer satisfaction, or Dr. Rico’s book ROI of Software Process Improvement), but all agreed getting contracting officers to implement them was the hard part.
Dr. Rico emphasized this point several times by issuing the charge that Agilists take influential positions in these policy organizations such as the Defense Acquisition University (DAU) or Institute for Defense Acquisition(IDA). One attendee raised the possibility of launching an Agile lobby, as a means to influence contracts. Yet another suggested outreaching to MBAs, to overcome the buzzword status Agile has in the minds of the few executives who have heard of it.
Other observations included:
- Mr. Cheng: To improve government adoption, find an upwardly mobile G-man & pitch Agile as his niche contribution to the agency.
- Mr. Carpenter: Be pragmatic evangelists. Tailor your dogma to the native language of your government constituents.
- Mr. Sheer: Agile is a means, not an end. If government RFPs and PMOs require Agile, they will do little to transform organizations to deliver against the mission
- Dr. Rico: We are the software century. Government functions have evolved from paper and hardware systems (analog) to software-centric systems (blended) to all-software systems (digital). As such, Agilists are uniquely positioned to influence the deliver of those functions.
- Mr. Carpenter: Get security scans early. If you provide Certification & Accreditation officers materials they need as early in the project as possible, you’ll get the flexibility needed to deliver incrementally.
- Gradually decrease cycle. Move from 3 month releases to 2 months to 1 month. Measure improvements in quality and value as a way to justify tighter timeboxes.
- Focus first on wining the Hearts & Minds of the PMO and sponsor. Use that leverage to formalize new policies around “delivering mission value” over “performance to plan”. Finally, use mission-driven policies as a foundation for instituting value-driven metrics.
- Fear of failure motivates the government more than anything. Find ways to communicate how Agile reduces risk of failure, as defined by your stakeholders.
In all, the evening was a successful discussion. I left with a better sense of how I would tip-toe through a government environment as an Agile Project Manager.