Government Agility: How to reduce IT cost using Agile

Original printed in Modern Government.

You have heard the buzz words – Scrum, continuous integration and test driven development. You have been told about the myths. Agile does not work for the Government. Don’t use agile on large projects. Agile teams don’t plan. 

Well we could spend time debunking these myths, which would not add any value for this article. With a little research, you can find the truth. Take a journey with me to discover ways that Agile can help the government with Information Technology (IT).  

According to the Office of Management and Budget, federal IT spending is estimated to be 74 billion this year, which does not include the local government, legislative or judicial branches. Roughly one third (or 25 billion) is mismanaged including cost overruns and duplications. By any standard, these numbers are staggering. What can the government do to be more efficient with the dollars that are entrusted to it? How can they reduce the cost of IT or at least better manage the 25 billion? Simple answer – GET AGILE.

What is Agile anyway?

Agile is a different way of doing software development. The term ‘Agile’ is derived from the Manifesto of Agile Software Development known to most as the ‘Agile Manifesto,’ which was created in 2001 by a small group of people that were using lightweight frameworks for software development. The Agile Manifesto consists of 4 values that we have come to live by: 

  • Individuals and iteration over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Although there is value on the right, we value the things on the left more. All agile frameworks and methods align with these values. There are 12 principles that support the Agile Manifesto, which are:

  • Customer satisfaction by delivering valuable software
  • Welcome changing requirements, even late in development
  • Frequent delivery of working software
  • Working software is the principal measure of progress
  • Sustainable development and pace
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (co-location)
  • Build projects around motivated people
  • Continuous attention to technical excellence and good design
  • Simplicity—the art of maximizing the amount of work not done—is essential
  • Self-organizing teams
  • Regular adaptation to changing circumstances

Think practices not frameworks

Maybe you have used Scrum or XP. Maybe you heard of Feature Driven Development or the Crystal Orange. Each agile framework is a collection of practices that have been proven to work well together and drive better results. These agile practices empower teams with tools that can exponentially increase productivity. These same practices are building the blocks for demonstrating value each Sprint while gaining trust with customers, stakeholders, teammates and most of all, oneself. Although we talk about frameworks, it is the common agile practices that help us continually improve, so  let’s talk about the common practices that can help

Quicker Time to Market

Agile encourages early and continuous delivery of software to satisfy the customer. Agile offers a set of tools that foster improved productivity, shortens the feedback loop and deliver based on value. Functionality is released incrementally accelerates return of value from the government and citizens.

Here are some of the practices that help improve time to market:

 Release Often – is the practice of getting the software out to the end customer as often as possible without inconveniencing them. This will test your deployment process and help streamline the process, which removes waste and clearly create more value for the customer.

 Cross-Functional Team  as a practice is very important. It refers to having the necessary expertise on the team to take a requirement from concept to deployed for the user or customer. This allows the teams to eliminate waste and bottlenecks. It enables team to be iterative and incremental, which support the team ability to release early and often.

 One Decision Maker that represents the users of the system and has knowledge about the business domain. This person owns the backlog, writes and clarifies requirements,  accept or rejects the results. This provides the team with a go to person for feedback, confirmation of requirements and demonstration of results. This person prioritizes the backlog to get the highest value targets done first. All these things help to improve time to market.

 Fewer Bugs

 Most software development environments are breeding grounds for few ‘friendly’ guests. These guests arrive for a variety of reasons including human error, communication failure, poor design logic and unrealistic timeframes. When a time crunch hit, the first thing to go is testing of every kind and people begin cutting corners instead of reevaluating the committed. 

 Here are a few practices that help foster fewer bugs being created:

 Acceptance Test Driven Development (ATDD) allows us to build projects that deliver what the customer wants by using acceptance tests to validate requirements. This creates a trustworthy safety net because as you incrementally met the needs of the customer, errors are caught early, miscommunication is discovered sooner and ambiguities are cleared up faster. This results in a code base that is continually tested and reduces re-work, which leads to fewer bugs.

Pair Programming is the practice of two developers working together on the same computer to build functionality. One developer works on building the code with hands on the keyboard, while the other developer is looking forward at the design and reviewing the code that has been completed. Two people working on the same problem improves the design and reduces defects, while building in a continuous code review process and collective code accountability.

Test Driven Development is the practice of writing clean code by writing tests prior to writing to just enough code to pass the tests and refactoring. At the core, this practice is ensuring the software’s technical quality with tests that are written and maintained by developers to enable change of design and reduction of the cost of finding and fixing bugs. This practice takes time and requires discipline otherwise the tests become stale.

Stop Building Everything

Many government projects seems to be infused with a culture of waterfall norms and behaviors, which supports people building everything perfectly. Imagine a world that was imperfect and projects are only given 20% of the budget and are held accountable for the results in order to get more money. You heard of the Pareto principle (aka the 80/20 rule), which is the law of distribution and states that 80 % of your results come from 20% of your efforts.

If 20% of our efforts delivers 80% of the value, common sense would suggest that we build our most valuable and most used features first. The research from the Standish Group supports that 20% of requested features are always or often used. Think about the software that you use. Now ask yourself what percentage of the feature do you use most of the time… Pause… Good reason for us to stop building everything. 

Figure 1 – Functionality Usage


Here are a few practices that can help you get on the right path of not doing everything:

Prioritization schemes help to people prioritize work. The most common is simple prioritization, which is a relative prioritization from 1-n where no two items can hold the same prioritization slot. Another scheme is MoSCoW, which divided into 4 categories – Must Have (mandatory), Should Have (desirable), Could Have (nice to have) and Would Have, But Can Wait. There are many prioritization schemes that are being used by teams.

Participatory decision models are when a team needs to make a decision. One example is a Fist of Five, where each team member raises one hand to vote with their five fingers. When the hand is raised, each person must pick one of the six votes – a closed fist suggests strong disagreement, 1 finger suggests slight disagreement, 2 fingers suggests slight warm disagreement, 3 fingers suggests Luke warm agreement, 4 fingers suggests agreement and 5 fingers suggests strong agreement.

Open Space technology is a simple way to run productive meetings, for five to 2000+ people, and a powerful way to lead any kind of organization, in everyday practice and extraordinary change. It is known for beginning without a formal agenda and harnessing the power of self-organization. This is simply one you have to see for yourself.


If you are already using an Agile Framework, consider using some of these additional practices. Maybe you are doing waterfall. If so just start with one agile practice to experiment with how it works. Gather the results to find areas of improve and implement the improvement. When you get comfortable, try another practice. Keep growing with practices and soon enough you will get to the point where you are ready to pilot an Agile Framework to implement this new found knowledge.





This site uses Akismet to reduce spam. Learn how your comment data is processed.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.