It’s Not Agile’s Fault: 3 Lessons to Ensure Accountability and Collaboration

Today we often hear project and program managers and even technical staff (on occasion) complain about agile, but is it the methodologies fault if it’s not being used as intended? Agile presents a methodology shift that requires continuous collaboration and accountability through a project lifecycle—this is a change from the way things used to work and change is uncomfortable.

Before agile, the Defense Department’s acquisition model was based on waterfall/spiral methods where accountability was hierarchical, and through this method the industry saw over 70% of software engineering projects fail in their first 12 months.  Requirements were rigid and both Industry and Government would be delayed by spending too much time interpreting requirements.

In the waterfall/spiral environment, we had an adversarial environment where a business that provided test services would be in competition with a business that developed software instead of working together. 

Another problematic approach was the “urgent needs” process, where requirements were generated directly by our warfighters. Those “oh crap” moments on the battlefield where you realize your enemy has adapted to your battle plan and you need a real-time solution. These needs would remain urgent; however, they would be pushed through an acquisition process where government civilians and troops in the rear would politicize the needs. Ultimately, diminishing the “urgent” element of the requirement.

Agile Is Rooted in Collaboration and Accountability

The industry pushed agile hard and the very first department to formally adopt acquisition based agile practices was the Department of Homeland Security in 2016. Given that agile was commonly used in commercial industries, many teams were able to easily and quickly train teams and find experts to get up and running. Developers, testers, writers, architects, cybersecurity staff and requirement teams were working together instead of in silos. The result was seeing projects successfully deployed in months versus years and a direct line to return on investment for the first time in government software development.

From my perspective, the single most important aspect of the agile methodology is accountability. Agile teams have multiple competencies relying on each other to get the job done, meetings are held daily and the team members hold each other accountable through creative estimating processes, comradery and competition. The agile approach has also allowed teams to fail fast, as teams can measure success to meet goals more often and more accurately throughout the entire process, as opposed to waiting until the end and losing valuable time.

3 Key Lessons to Using Agile Effectively

In 2020, the government industry has mostly forgotten about waterfall/spiral and where we were.  However, we still see a partial agile implementation on nearly every program as a cosmetic rather than a rigorous practice. Teams with stickies on the wall think they are doing agile. Programs with teams that make up multiple competencies claim they are doing agile. I have even experienced a team claiming to be agile, where the level of accountability was tied to daily attendance and badging processes (instead of EPICs, user stories, features, etc.).  

The three most important lessons we learned from agile are to: 

• Ensure team level accountability (focused on EPICs, user stories and features).
• Iterate in parallel with all competencies of your team. 
• Bridge the gap between users, designers and developers by minimizing the middleman (acquisition) and orienting requirements towards features over “shall/will” statements.  

If you feel like your program is failing and it’s agile’s fault, ask yourself are you truly implementing an agile methodology. Is there accountability from within? Are you working as a team to measure success and effectiveness throughout the process? 

Erick Mann is the vice president and chief engineer for CommIT Enterprises.