Agile is a value driven software development philosophy that is lightweight, fast and highly iterative. Agile has been around for over 10 years but has recently emerged in the federal space as a result of the governments 25 Point Implementation Plan which highlights modular software develop to control cost and scope. This realization has made Agile more popular than ever in DC. I am currently evaluating several federal agencies attempting to adopt Agile and have seen patterns emerge that require further analysis and reflection. One such item relates to how requirements are captured and managed within an Agile framework, not only at the development level but also across the organization. Traditional requirements definition and management does not fit well into an Agile model, however, this is the norm for how most large-scale software projects operate, especially if organizations have been following a Waterfall methodology for years.
There are two groups within organizations that must cooperate in order for Agile to work properly. The two groups are Business and IT. The business is primarily responsible for building the business case for a proposed software application, funding, organizational goals, and objectives. IT is responsible for building the application within the defined budget, time, and scope. The problem is that there’s a misalignment occurring between IT departments attempting to implement Agile and the business side that defines what needs to be built as well as internal processes that must be adhered to. In government software development, the business side of a federal agency is still responsible for producing the same artifacts they have always produced as well as passing the same Software Lifecycle Management (SLM) tollgates. Organizations cannot successfully adopt Agile at the IT level without changing their mindset of how the business side functions. This paradigm has created a disconnect between organizations looking to adopt Agile within traditional business operations.
If you take a holistic approach to the problem then you will start to see patterns and processes emerge at all levels of the organization. One immediate opportunity occurs at the hand-off between the business and IT. The hand-off is when the business passes over their requirements specification for a software application to the IT team to build. If an agency passes traditional requirements specifications to an Agile team the results are typically negative. Most Agile teams will usually want to start over by creating a list of User Stories that covers the requirements specifications delivered to them. This creates a tremendous amount of rework and churn, which usually leads to frustration by the business because they have to rehash what they’ve already spent a lot of time putting together.
The solution is to come up with a decomposition model during the hand-off period. Decomposition is the process in which the business and IT decompose the requirements specifications together to convert requirements into the proper format for Agile. The goal should be for the business to get the requirements 70% complete, then use the decomposition phase to finish off the requirements together with IT. This does several things to improve the odds of a successful outcome while reducing risk. First, it allows the business to further analyze and synthesis the requirements they’ve defined thus far with technical experts. Second, it gets the developers engaged in the requirements discussion earlier as opposed to doing a single hand-off at the end of the requirements phase. Third, it allows team members to build relationships with one another. Fourth, it allows the team to address usability questions and requirements before development begins.
Agile cannot be rolled out in a silo; it must be woven into the organization at all levels. This won’t happen overnight but as long as we can start to identify and address these challenges, the closer we will get to producing more value for the organization and its user community. Bridging the gap between business and IT has been around for decades, however, the advent of Agile has escalated the issue. Change needs to occur at all levels of the organization in order to accomplish the benefits of adopting Agile.
About the Author : Jason Moccia has over 14 years of experience in the software development field and is a co-founder and managing partner of OneSpring LLC (www.onespring.net), where he oversees the Federal business practice as well as Operations. OneSpring helps companies to work smarter by providing an entirely new approach to software requirement definition.
