Challenges to Agile in the Federal Government

A short blog for today.  I was recently asked about the challenges of implementing Agile in the government.  My quick response was the following:

 -------------------

There are a number of challenges that one encounters in the government sector and these challenges are even further called out when trying to implement Agile in the government space. 

At its core, Agile is built around delivering results while the government focuses on managing risks.  Let us look at the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The Agile world focuses on the left over the right.  However, in today’s world the Federal government largely operates on the right side of these statements.

Thus key issues include:

·         Reporting of value.  The government largely uses EVM methods for reporting of value.  While EVM is not necessarily incompatible with an Agile model, most government organizations use EVM in a waterfall type model, which causes problems when mapped to an Agile program.

·         Governance.  Organizations such as GAO and OMB provide oversight to government projects.  There was an old theory that the more paper you provided to these organizations, the better your program looked.  Although it is getting better, there are still issues with resources at these types of governance organizations understanding the Agile model and being able to translate that into what they traditionally have required from projects.

·         Funding and Procurement.  The funding of government programs can have substantial lead time which creates challenges to programs.  In addition, government contracts are generally not written to support Agile methods.  This combined with limited knowledge of Agile by program contracting officers creates challenges for implementing Agile.

·         Misconceptions.  There are many in the government that have been use to running programs in a traditional way.  Often they believe that if a program fails, it is not because the traditional process is flawed, it was that the process was not implemented correctly.  Thus even more process is placed on the program.  Additionally, Agile is still new to many in the Federal government and misconceptions and misunderstandings on what Agile is have slowed acceptance of Agile.

·         Agendas.  In the Federal government there are multiple vendors, contractors, and organizational groups working on any given program.  Since these groups ultimately do not report to the same leaders and do not share the same vision, this can cause conflicts and political issues that can handicap projects.

As a side note, when I first started on my government program, I came to a project that had a nine person PMO overseeing 3 project managers, 4 business analyst, 1 architect and 1 developer.  The team size was probably ok, but I think the makeup of the team may have been a little off.

Agile Office Space – Isolation versus Distraction

A colleague of mine recently forwarded an article on InfoQ regarding Agile Team Spaces (http://www.infoq.com/news/2010/02/agile-team-spaces). While I agree with the vast majority of the article, there is a point in this article that suggests minimizing distractions.  My concern is the balance between minimizing distraction and isolating the team from everyone else.   While teams in their own distraction free space does promote hyper-productivity, the trade off is that the team loses the connection and understanding to the rest of the company. The team's focus and vision narrows to the work in front of them, which is good for the short term, but becomes less clear on the big picture stuff, which ultimately can hurt in the areas such as product development and innovation. 


Currently, I have a Scrum team located by themselves in the basement of a government building. The team is talented and has a done a great job thus far. They are left alone with few distractions and can produce work quickly. However, this team has some real struggles. The biggest issue is understanding the business vision and the prioritization of various elements of the program. This is proving to be a real challenge for our program and though we are producing work quickly, we often question if we are producing the right work and in the correct sequence (yes, I know that is the job of the Product Owner, who sits down here with us and has the same problems as the whole team). One of the key goals of this team is to physically move closer to the key stakeholders so that we can have day to day interactions with them to help us think more like our key stakeholders.


When I was working with the Motley Fool, I arguably had one of the best (if not the very best) Scrum teams in the company. It wasn't my awesomeness as a Scrum Master that made my team so effective, it was the team's understanding of the business vision and needs that made them strong. The team's ability to quickly understand the business needs and rapidly turn concepts into deliverables was particularly strong. Eventually the team had such a great understanding of the business and a great relationship with their business stakeholders that they became partners in innovation as opposed to just implementers of ideas. The reason that this team was so strong in this area is that their key business representatives sat right with them and were intimately involved in their day to day work. The team also had frequent access and visit from other people throughout the organization which allowed the team to develop a holistic view of the work and understand the true goals of their projects. Though it is true that the team could have worked faster with less distractions, I do not think they would have been working smarter if completely left alone.


While an Agile team with it's own space that is comfortable and pleasing does promote "hyper-productivity", there should be caution to this thought. In many ways, this is a throwback to the days where developers and development teams were the cellar dwellers and left alone to do their techie stuff while the rest of the company does business. This is a major step back and seems un-agile to me.