Agile in the Public Sector

A good 80-85% of my work since 1991 has been on contract for the federal government here in Ottawa. For those not familiar, Ottawa is Canada's capital and seat of government. There are some 200,000 people in the region that are federal government employees, and nearly as many who are secondarily employed as terms, contractors and consultants or support staff for companies that provide those people. In short, the government is a huge part of business in this town, and I've been part of it for a good long time. In terms of the groups with whom I've worked, I've had ups and downs, seeing the good, bad and ugly of organizations and their management.

Since I first learned about Agile in late 2000 (actually it was Extreme Programming then - the term Agile Software Development wasn't coined until a couple of months later), I've been asked more than a few times if it applies to the public sector. After all, I was told, there really isn't that much change in the business of running the federal bureaucracy!


Since I first started doing work for the government in 1991, there have been 6 general elections with 2 changes in the ruling party, and one with a new leader (effectively a change in party!). Each of those changes brought major changes in policy and thus legislation. Even after elections in which the ruling party did not change, new policies that were part of the election platform were enacted. There have also been numerous re-organizations of departments and agencies in that time, each of which changes the focus and direction of the business.

In other words, the business changed, sometimes dramatically.

Additionally, there have been external events that have affected the business of government. A group I was with from 2003-2006 works on an immigration system whose raison d'ĂȘtre was the 9/11 attacks. That system was also affected after the 2004 Indian Ocean tsunami when the Immigration Minister quickly created a program to fast-track requests from that area. The development group was able to quickly respond to the required changes and put them into production so that the program could be supported.

All of this illustrates that even in the public sector business change does occur. It can be rapid and disruptive or move at a glacial or tectonic pace. Regardless, it happens and organizations need to be in a position to deal with it. Of course, being a huge proponent of Agile Software Development, this is where I say, "And Agile can help you deal with that change!"

That's true, of course, but I would suggest that where Agile provides the most value for public sector organizations (and arguably all organizations) is not with these macro-level changes but rather with the much smaller changes that occur as a team, group or organization learns what problem they are really trying to solve with an automated system. This occurs on a daily basis - during visioning and chartering exercises, story creation, release planning, iteration planning, daily standup meetings, ad hoc discussions, iteration demos, retrospectives and even after release when more real-world feedback is obtained.

All of what's learned in those opportunities for collaboration is what sets Agile apart from other processes. The ability to quickly apply the new knowledge and get it into the hands of the people who need it is by far the most important factor. This is what pushes the features most required to the top of the priority list. This is what eliminates features that aren't required, and reduces the priority of those that are less important. This is how knowing the Done State of work allows the whole team and project community to understand how long it will take for features to be released. This is how transparent progress on projects allows the organization to better understand and manage their entire portfolio of IT work. This is how an organization can position itself to be proactively ready for the next macro-level change.

And that is agility in the public sector.


Jason Yip said…
I'm imagining the day when a government passes legislation and the civil service department who has to implement it says: "Sorry, we don't have capacity to do that. You should have checked with us first."
Michael James said…
The stereotype of state government doesn't suggest Agile approaches would work there, but we've had some success in both Washington State and Idaho. For example:

Dave Rooney said…
@Jason - Ilike that and may just have to steal it! :)
Dave Rooney said…
@Michael, yes the stereotype suggests people who are extremely risk averse and have no incentive to change. My experience has been that there are a few people like that, but most want to do a good job.

As for the work you describe in the article, maybe you should give the FAA a call. I think they could use some help replacing NADIN! :)
Anonymous said…
I too have worked in the federal gov't in Ottawa as a contractor for over a decade.

My conclusion: the gov't barely have mastered the waterfall process. They do not have the skills or understanding or the infrastructure to deal with Agile development.
Anonymous said…
The government is always looking for the silver bullet to get more IT productivity . . . but unfortunately there isn't one. Because any methodology requires cultural / organizational behavior change to succeed - you can't just crack open the shrink wrap, install it, keep doing everything you did before, and expect to realize a benefit - and that's the one thing any organization, especially a large one, and especially the government, will find exceedingly hard to do.