Get the Government On Board with an Agile Mindset... Before the Project Starts

***The views contained within this article are my personal views, and not necessarily the views of my current employer, L3Harris.***

My Agile practitioner career has been spent exclusively on government contracts. Typically, I come on board, and we're all working within an Agile framework, usually Scrum, and there are product owners, Scrum masters, teams that are largely cross-functional, standups, demos, and retrospectives.

But we've also got an integrated master schedule, a project manager (and sometimes a full-time scheduler), a host of milestones we need to ensure we meet, and a Burj Khalifa of documents that go out with each release. The releases don't always happen at the end of each sprint. And you know what else? A lot of sprints fail.

How is that Agile? How can teams focus 100% on shipping iterative, frequent, user value when we've got so much other stuff we're told we need to worry about?

My suspicion: at the procurement level - before we get to sprinting or Kanban-ing or whatever Agile awesomeness we are practicing - there isn't enough evangelizing Agile as a framework for user value delivery. We need to ensure that before anyone signs or approves anything, both the contractor and the government agency are on the same page about what Agile provides, and what it doesn't provide.

At the same time, spending tax dollars requires accountability, and there are ways Agile frameworks can provide that insight - and ways contractors should staff and organize their teams - without jeopardizing the value stream.

Permit Me a War Story

A previous employer brought me on to help deliver some changes for a web application. As I and the other "Agile guy" acclimated ourselves those first few days, we quickly realized we had walked into a minefield. The government had a list of user stories (if you could even call them user stories) that were massive. Previous contractors hadn't been able to deliver them. Some of these individual user stories were each estimated to take 300 hours to complete. We were also not allowed to change the text of these user stories because they had been written and approved by a committee. I remember a single acceptance criterion which was over 500 words in length. These weren't stories, or even epics. These were zeppelins.

Here's the best part. Before either of us came on board, a detailed project schedule had been handed to the customer, promising around 12 of these "user stories" to be delivered in each two-week sprint, scheduled out at least a year. This spreadsheet was referred to as the "product roadmap." That roadmap, and that contract, had never circulated among anyone who would be doing the work, or among anyone who had done similar work in the past.

We told senior leadership this wasn't going to work. The stories were too big. We didn't have enough people to make it happen. But since we'd agreed to everything beforehand, we were on the hook to deliver. In addition to the user stories, there were stacks of documents we had to provide at the beginning of the sprint and at the end of the sprint. Developers, testers, and business analysts all swarmed these documents. None of these were user training materials, they were all project documents, each of them repeating what the other document said. Oh, and we also agreed to provide a bunch more documents, too, which weren't even part of the contract.

Needless to say, the sprints failed. Every single one. We were able to break down the stories some and demonstrate some delivered value at demos, but in the end, it wasn't enough. The government agency's own, rather fantastic Agile coach tried to intervene, but the government was rightfully holding us to the terms of the contract to which we'd agreed, and we couldn't deliver.

I'm grateful for that experience: for learning from failures, and learning where I should have stood my ground far more firmly. I don't want another PO, SM, or team member to share that experience.

Where, and When, are We Talking about Agile?

We talk a lot about Agile within the walls of a software delivery shop. PI planning, sprint planning (if you're Scrumming), grooming, demos, standups, all that great stuff. Those conversations are crucial and we've got to keep having them in the industry, and within the feedback loops at the team level.

What about before the project gets to the team?

Does the division VP know what Agile is? Dare I ask if the CEO knows what Agile is? The business development manager?

What's in the RFP response? Are Agile frameworks mentioned during capture efforts? By that, I mean something other than tossing out the word "agile," which is sexy, but could also mean anything. Agile isn't Waterfall reallyreallyreally fast.

If you're a solution architect, how much do you know about Agile frameworks your company uses? Do proposal writers and volume leads understand it?

And what of the proposals themselves? What are those proposals promising the government? Has a team of seasoned Agile developers, testers, and other practitioners reviewed the RFP response to ensure their employer isn't merely promising the stars to get the contract? Can the Scrum or Kanban teams deliver this? Has anyone seen the list of deliverables? This just in: if the project team can't - and doesn't - deliver what you say they will, plan on losing that client.

A lot of government agencies put together training for their contracting officer representatives (CORs). A lot of those CORs will be working on IT projects. Is Agile part of that training? How do we know when government agencies put together their panels to decide which vendor will get the work, that they go into those sessions understanding Agile doesn't simply mean squeezing all the usual stuff into two- or three-week chunks? I've met government folks who didn't know what a sprint was and expected formal meeting notes from all standups. If the government isn't reliably training its people on what Agile frameworks really are, we need to do that from the first handshake. It's in our best, business interests to do so, and in the best interest of delivering value for citizens, which also includes us.

Why Should We ALL Talk about Agile?

We are all on the same team. Agile aims to provide unparalleled transparency and communication, but more than anything else, value for customers. Everyone owns a piece of that, from the first bit of schmoozing and discussing the client's needs, to deploying the first few builds. How can you do your job as best as possible if you don't understand the guts of the framework that delivers what your customers actually want? The means is just as important as the end, because when you are confident in your means, you can be even more confident about the end, i.e., the value for which your customers are paying you.

Do you think the government doesn't care how you're going to do all this stuff they want? If so, you must be on your first government contract, or have never worked one at all. You're asking to spend tax dollars. Not only does the government want to know your methodologies in that RFP response, they want to know, once kicked off, how everything is going, and why it's happening the way it is. Some CORs are going to be more curious than others. You may be making sausage, but she may want to watch you throw every single scrap into the grinder. That isn't always the case, but shouldn't you be prepared for it? And wouldn't it be less painful for everyone if your government customer knew what to expect?

Give Uncle Sam the Warm and Fuzzies

So, in addition to user value, the government wants to feel confident in its contractors during the execution phase - and is more likely to continue a business relationship with them when they have those warm and fuzzies.

Give them that confidence by building trust, and providing transparency. Here are a few things contractors should consider before a project starts:

• Train everyone in the portfolio on Agile. Everyone needs to know what they're doing. They don't need to all come out of there as certified Scrum masters or product owners, but they should have an understanding that Agile isn't shoehorning PDR, CDR, TRR, and all that into two- or three-week blocks (again, talking about Scrum, as that's what most government contractors will work within). Agile is all about taking requirements from the customer and turning those requirements into pieces of user value that can be shipped out and used by the customer, with a lot of feedback. There's no months and months of analysis and 500-page design documents before you see a wireframe. You start building right away and deploying to the government a big piece of what it needs really fast.
• About that training... make sure your business development people are part of it. They need to be able to speak authoritatively on how value is delivered, so potential customers have insight going into the procurement process.
• Ensure your RFP responses go over the above as well. Ensure your past performance speaks to the value you've delivered on previous contracts, and how you did it. Agile can't be just be a buzzword. Agile is a mindset: a customer value delivery mindset.
• Propose project documentation that's tight, concise, and not repetitive. Frame it as reducing waste and focusing more time on building customer value. The government will get the insight it needs, while you've got a team that will happily truck along as it sprints, or as it plucks from its backlog. A helpful tidbit: Agile lifecycle management tools like MS Team Foundation Server and Atlassian Jira can auto-generate a lot of reports, and custom queries can be built to provide other stuff.
• Bid a dedicated, technical writing and training development team. If developers and testers do this work, it takes their attention away from value delivery, and as I learned very painfully, people constantly working on documentation and code will deliver neither. Nothing erodes the government's confidence more than not delivering.
• Pricing is the elephant in the room. Scrum fits much better within a time-and-materials model, particularly when the requirements are not fine-grain, and the customer knows only what it wants, and is just eager to see something and then provide feedback on it. It takes time to get there, and firm-fixed-price doesn't support that mindset. But if you have to bid FFP, similar, previous projects can provide insight. As another perspective, Deloitte released two years ago a fascinating white paper on story points-based pricing for procurement.

At the project execution level:

• Build trust through regular demos. Ensure presenters are speaking to the value that's delivered. Don't talk about code.
• Provide a project roadmap that doesn't lock you into fine-grain things delivered on certain dates, but gives the government an idea of what features they can expect, and when. An incredibly detailed, MS Project file with tons of line items and dates is NOT a project roadmap.
• The government may be interested in your retros. Don't provide a word-for-word transcript, but give them highlights of what teams did really well, and the changes you're excited to make in the next sprint.
• Invite your government counterparts to the Scrum of Scrums meeting. A daily standup invite won't provide as much value as hearing the highlights from each team, and being available to provide insight on how to move through blockers. This provides transparency the government is paying for. Alternatively, they may want to attend only the demos, so ensure product owners are at the meetings to relay anything the customer needs to know.
• Use project managers not as supervisors and clockwatchers, but as resources. They won't be Scrum/Kanban masters, but what they can do is work some of those project documents, they can handle procurement, they can produce burndown charts, all that stuff to feed the beast, and tackle external blockers. This will put the government's mind at ease when they are thinking about all the things that *could* pop up.
• Remember those writers and training developers? They will be best served if they attend grooming and planning to understand what's new and what's coming, so they can build cool stuff like context-sensitive online help and computer-based training presentations, so you can show off all the value you've provided your clients. One or two other writers could also help with project documentation. Remember also that it may not always make sense to stick writers and training developers on sprint teams, as their process might not always jive with sprinting. Make sure they get time with the right people to ask the right questions. Again, the government has to be far more accountable for its funds than a private sector customer, but you won't deliver anything if you make team members "multitask".

I'd love to continue this conversation. If you've got other tips on how to get the government on board with an Agile mindset, and keep them there, share them!