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!
Really?
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.
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!
Really?
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.
Comments
http://www.agilealliance.org/show/2180
--mj
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! :)
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.