Government agility

Government Agility: How to reduce IT cost using Agile

BY Devon Morris

Y

ou have heard the buzz words - Scrum, continuous integration and test driven development. You have also heard the myths: Agile does not work for the Government; Don’t use agile on large projects; Agile teams don’t plan. We could spend time debunking these myths, however, it would not add any value to 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 - GET AGILE.

30

May - June 2013 · MODERN GOVERNMENT

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: 1. Customer satisfaction Delivering valuable software 2. Welcome changing requirements, even late in development 3. Frequent delivery of working software 4. Working software - The principal measure of progress 5. Sustainable development and pace 6. Close, daily cooperation between business people and developers

IT Investment 7. Face-to-face conversation - The best form of communication (co-location) 8. Build projects around motivated people 9. Continuous attention to technical excellence and good design 10. Simplicity—the art of maximizing the amount of work not done 11. Self-organizing teams 12. 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. It offers a set of tools that foster improved productivity, shorten the feedback loop and deliver

based on value. Functionality is released incrementally and accelerates return of value from the government and citizens.

Here are some of the practices that help improve time to market: RELEASE OFTEN – 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 it, which removes waste and clearly creates more value for the customer.

CROSS-FUNCTIONAL TEAM – 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 - One Decision Maker represents the users of the system and has knowledge about the business domain. This person owns the backlog, writes and clarifies requirements, and accepts 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 a 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 hits, the first thing to go is testing of every kind and people begin cutting corners instead of re-evaluating the committed.

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

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

ACCEPTANCE TEST DRIVEN DEVELOPMENT (ATDD) – Acceptance Test Driven Development allows us to build projects that deliver what the customer wants by using acceptance testing to validate requirements. This creates a trustworthy safety net because, as you incrementally meet the needs of the customer, errors are caught early, mis-communication 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 – 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

MODERN GOVERNMENT · May - June 2013

31

the design and reduces defects, while building in a continuous code review process and collective code accountability.

TEST DRIVEN DEVELOPMENT – 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 seem to be infused with a culture of waterfall norms and behaviors that support 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’ve 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

Functionality Usage 7%

45%

13%

16%

19%

always or most often used (See Figure 1). 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.

Here are a few practices that can help you get on the right path of not doing everything: PRIORITIZATION SCHEMES help people prioritize work.

The most common scheme is simple prioritization. Simple Prioritization is a relative prioritization scheme from 1-n where no two items can hold the same prioritization slot. Another scheme is MoSCoW, which is 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 20% of our efforts delivers 80% of the value, common sense would suggest that we build our most valuable and most used features first.

Conclusion 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. These are very simple practices that can help the government reduce cost in IT. [MG]