If you’re involved in software development at a federal agency, you’ve noticed that government as whole is pushing more and more teams to use Agile development methodologies. Let’s face it. Agile is trending. #Agile
Personally, I think it’s a great trend! Who doesn’t want to see their product more often and have input throughout the building process? Sounds like a major win for the Product Owners, even if it does provide some headaches to the development teams (like pushing them to become public speakers and prepare presentations for stakeholders every 2, 3 or 4 weeks). As a former software tester, it was always exciting to get a new build to test! It was like Christmas morning when you suddenly have all these new toys to play with! Sure, in a day or two, all the new toys would feel just like the old toys; but at least for that morning, everything was new.
Agile development allows other stakeholders to take part in the joy of the process! Every new sprint brings new features to see and enjoy. I’ve noticed that there is a certain level of excitement on demo day when the Product Owner and stakeholders gather to see the unveiling of the features they requested. However, in industries where traditional waterfall development is still the most common methodologies in use, there is one major factor that can put a damper of the excitement and joy of Agile – project management.
Yes, I said it. As a Project Management Professional, I will admit that one of the major hurdles the federal government has to overcome in moving towards agile development is how to revise their project management process to align with agile principles like valuing “individuals and interactions over processes and tools… Working software over comprehensive documentation…. Customer collaboration over contract negotiation…Responding to change over following a plan.” If you take the Agile Manifesto into a Project Management classroom, be ready for a fight!
Prescriptive management plans, detailed requirements documentation, clearly defined development contracts – these are all things federal government contracts have placed high value on for decades. I believe the federal government is at a pivotal crossroad of creating a new hybrid way of managing agile development contracts. Project Management at its core is not the issue. All projects need to be planned, managed, and controlled. The problem is not the “what”, it’s the “how.” If the only way we know how to manage the scope of a project is to have all of our system requirements at the start of the project, then we’re not allowing for the collaboration and transformation that happens over time as a product is designed. Our perception of project scope must align to something other than an inflexible, unchanging document, or true agile development will not be possible.
Many academic institutions and business enthusiasts have created agile management model in attempt to tell government entities how they need to change their processes to fit the agile culture. I’m not here to do that. I believe that overtime as pioneering agile projects are successful in each government agency, the cumulative lessons learned will develop a new way of managing agile projects. All we need is a little time and a lot of mutual trust.
Leah Onuoha joined Gunnison in 2008 and has held several different positions from Software Tester to Business Analyst, Scrum Master, and Project Manager. She spends the majority of the day working with development teams to remove impediments and improve their processes.
 “Manifesto for Agile Software Development”, http://agilemanifesto.org/