Being Agile in a Federal Fiscal Year
Written by: Carl Pritchard
Agile On Time
There seems to be a significant disconnect between running Agile projects and meeting deadlines. Nothing could be further from the truth! Despite the seemingly laissez-faire approaches in Agile management, deadlines and deliverables abound. You just have to look for them.
In many organizations, Agile is considered non-viable because it doesn’t have the concrete end date of a waterfall or predictive project. Those kinds of opinions often flow from individuals who don’t understand that flexibility (like that afforded by Agile management) does not equate to a lack of deadlines or deliverables. The structure of the deadlines is obviously different. The nature of the deliveries? Also different. And it’s in those differences that opportunity resides.
Agile Deadlines
With the latest (of quite a few) federal fiscal year deadlines looming, it’s difficult to imagine shifting to a practice that says “We don’t know when we’ll achieve final delivery.” It’s that last adjective (final) that throws most outside the Agile community. Agile Scrum is classically broken out into sprints or iterations. Such iterations last one to four weeks and produce something of value at their conclusion. If the organization chooses three-week sprints, for example, that’s 17 delivery events in a single year.
Theoretically, even if a project is shut down at the end of the fiscal year, that’s 17 moments when project teams could proudly say, “We got stuff done.” And they did it per the schedule. The only variable is the nature of precisely what work was accomplished. But with a steady flow of 17 deliveries, there should be multiple moments at which Minimum Viable Products (deliverables that work) and Minimum Business Increments (deliverables that create value) were achieved.
The key to weaving Scrum practice into a federal climate is making the practice part of the original business case on the project. If the project is sold as a two-year upgrade to existing platforms, Agile will sound less favorable. If the same project is sold as 34 micro-upgrades to the existing platform, with incremental deliverables across the time period, it’s just been promoted as Agile.
Agile Delivery
The other half of the promotion of Agile in a federal setting is the framing of Agile deliverables. The class side of project management contends that there’s no end to an Agile project. The problem with that contention is that it is potentially true. A software firm in the DC Metro area originally proposed an 18-month improvement plan for a federal system, conducted using Agile (in 2-week sprints). In theory, after 36 sprints, the project would be done.
At last count, that project was on Sprint 51, with no firm end in sight. When asked if the agency was satisfied with the vendor’s performance, the reply was a resounding “yes!” The agency said that they had accomplished about 80% of what they originally wanted by the 18-month mark, but saw so many new possibilities, they opted to leverage their contract options and continue to move forward toward an enhanced version of their original goal.
What did the government customer like the most? Flexibility. Above all, they felt like they were seeing real progress without having multiple procurement cycles and other impediments along the way. They also prided themselves in seeing the value of the adaptive approach early enough to take full advantage of it. They contend that many agencies trapped in a predictive, waterfall approach never have the joy of being responsive to the needs of their customers in real time.
Adaptive Agile approaches can make sense in the confines of federal projects, but they need to be framed as such openly and honestly from the project outset in order to succeed.
