TwinTechs

It is an understatement to say that it can be difficult to sell the idea of an Agile project methodology within the Federal space.  When you begin talking about iterations, sprints, chickens and pigs and stand-ups with a decision maker (or even a seasoned government programmer) it can be a tough pill for them to swallow.

Most Agile developers or PMs present the methodology using accepted terms, all of which are unfamiliar to Stakeholders unless they have worked previously on Agile projects.  What it really comes down to though, is that an Agile methodology aligns with Government projects quite nicely, and many of the principles are already applied at Agencies, just under different nomenclature.

Firstly, Remove the Language Barrier

Thinking back to when I was first learning what Agile was, I can recall needing an AgileSpeak to GeekSpeak dictionary.  Remembering that one of the key tenets of Agile methodologies is to engage the customer throughout the process in ways that they can understand (think user stories) you have to wonder, how can this occur if they don’t understand the high level process? It actually will not matter, as they may be reluctant to continue when you approach the idea of involving an Agile process asking if they want to be the chicken or the pig.  Some key words to replace in your vocabulary during initial discussions:

Product Owner: Stakeholder, Customer
Iteration, Sprint: Milestone, Phase
Work Product: Proof of Concept
TDD: Test Cases, Constantly Tested Code
Bluesky, Observation: Requirements Gathering
User Stories: Use Cases, Requirements
Standup, Daily Scrum: Status Meeting
Assumptions, Impediments: Risk Assessment
Burndownchart: Project Plan, Requirements
Work Period: 8 man hours
Velocity: Workload
Backlog: Task List
Product Backlog, Release Backlog: Phase 2
Pair Programming: Mentoring, Knowledge Distribution
eXtreme  Programming, Barely Good Enough: Just remove these from your vocabulary altogether during initial discussions!

When presenting an Agile project methodology to the Customer, be sure to present the benefits of the processes in clear terms.  Government projects are filled with meetings, documentation and testing.  Each of these items is addressed, and all are actually benefits of an Agile process.

Documentation

On some projects I’ve led, the documentation was equally as important as a working application!  When an outside entity is brought in to build a module or an entire project, one fear I have seen is ‘Will the existing (Agency) team be able to support the finished application?’  Stressing that time is built into each iteration for documentation, and that this methodology helps enforce that proper documentation is completed before each work effort is delivered is a great way to pave the way to understanding Agile.  Your Stakeholder will certainly appreciate that the Agile process forces planning time for documentation right into your plan!

Meetings

Generally speaking, even Federal employees can laugh at the fact that much of their career is spent in meetings.  Presenting an Agile methodology as a way to improve meetings, while still keeping them frequent, is a great introduction to the process.  Many times attendees at a meeting do not have a voice.  Agile processes enforce a level playing field, as well as requiring, even demanding, that meetings are always productive.  Due to the frequency of meetings, even teams that telecommute always have a full understanding of the project status, as well as any impediments that have cropped up during the development process.

Testing

One would think that this speaks for itself, but testing is by far one of the most important stages of development.  It is also one of the first things to be sacrificed during a project, and in every Government project I have come into the middle of, has been put off to the end. ROI can be quickly diminished and budget can balloon out of control during testing, often resulting in a product losing key features that Stakeholders have requested.  Explaining to your Client that an Agile process supports modules that are tested during every phase of development to match the exact requirements that they have laid out is an exciting opportunity. Further explaining that the deliverables are moved into the shared development or testing environments already having passed a significant amount of testing (with tests being written before the module when applying Test Driven Development (TDD)) ensures that the resources that they have lined up for acceptance testing  (usually months in advance) will receive a great product both on time and on budget.

Additional Benefits

A key benefit of Agile projects within Government space becomes clear when you consider the blackout theory, frequently referred to as ‘the black box in which software is developed by private sector contractors’.  Seeing a list of requirements followed by infrequent status emails and hacked together demonstrations while actual development is occurring in a secret environment almost seems to be the norm on contracted Federal projects (the black box).  Even in Government (especially in government), Stakeholders need to see that the budget allocation was money well spent.  They answer to their superiors frequently and having a working product to take with them to demonstrate progress goes a lot further than completed requirements and a Gantt chart.  Explaining that an Agile methodology allows easy task prioritization and frequent milestones that function and are demonstrable helps them justify the project work effort more easily by providing tangibles.

An Agile project, by the definition of the word, is able to stop on a dime, regroup and move in a new direction as Customer requirements change.  Since the product is delivered at the end of each iteration, the Agile team expects that the requirements will change, or at the very least be refined.  This is one reason I feel that Agile development is a must for Federal projects.  In many cases the end user is another group within the Agency, or even another Agency in a completely different sector.  The initial pass at requirements in a typical project is handled before the RFI ever hits the street and the team is first assembled, and many times the remote group or Agency, who is not always funding the project, is not brought back into the loop until User Acceptance Testing (UAT).  Understanding that the stories an Agile process will produce will bring all assumptions to the forefront, it may allow the original requirements to be refined immediately by fleshing out any details that may have been overlooked, thus improving the Client/Customer relationship and the project as a whole.

Final Thought

One last thing to keep in mind is that change or process improvement, even for the better, is not always a driving force within a Government project.  Many Federal employees are great at mitigating risk and may therefore be hesitant to introduce any major process changes.  Be sure not to sell Agile as ‘the way things are done now’.  Instead note that many of their existing processes are Agile processes masked (and sometimes buried) in other terminology.  Applying an Agile process methodology to their current efforts only streamlines their project.  Not only do they get more out of their effort, but also many of the current processes that they do not enjoy simply fade into the background during an Agile project.

To learn more about how Twin Technologies has helped other organizations with Agile methodologies, please feel free to contact me at nic.tunney@twintechs.com.