While researching for whats new on Agile in Federal space, I found a really interested take on Agile practices by Feds.
Here are the excerpts:
There are a lot of teams out there saying they practice agile software development, when in reality they’ve just broken up their waterfall roadmap into two-week sprints (often called agilefall). This can lead to executives in government thinking “well, we tried agile and it didn’t help at all.” What they really tried is the exact same waterfall approach they’ve always been using with a slightly different vernacular surrounding it. This means really changing your team into an agile operation can be an uphill battle, because you have to overcome some of these initial biases (just listen to Tim Gribben, the CFO of the Small Business Administration, talk about how he’s not a fan of agile, but he acknowledges agile development was central to the success of the DATA Act implementation).
If you think you’re likely to face resistance from your leadership about trying an agile development approach, you can start out by asking your leadership questions like:
- How confident are we that we’ve captured all of the requirements up front?
- Do we anticipate any of the requirements may change after our initial planning phase? If so, how will we accommodate that with our team and/or contract?
- Are there some areas with lots of variables and moving parts (like legacy technology systems) where we can’t accurately judge the risk up front?
- Is it risky to pin all of our hopes and dependencies for this large project on one vendor?
- Should we schedule regular demos of the software with the vendor (instead of taking their word for it in status meetings) so that if things aren’t on track, we’ll know sooner?