Agile and IV&V Working Together

The Federal government is transitioning more and more projects to Agile development methodologies. Agile’s success with commercial projects has led to greater adoption of Agile in the Federal Government. The move to Agile poses a number of challenges for government agencies. Government agencies need to fit the new Agile development techniques into their current, controlled environment. This includes the need for independent verification and validation for Agile projects. This blog explains how Agile and independent verification and validation (IV&V) can work together and offers a list of best practices for incorporating (IV&V) in Agile projects.

What is Agile Software Development?

It is important to understand what Agile software development is before attempting to understand how to provide IV&V services for Agile projects. My favorite definition for Agile software development comes from Wikipedia:

Agile software development is a group of software development methods based on iterative and incremental development, in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight iterations throughout the development cycle.”

 

This definition does a nice job of identifying the differences between Agile development and the older Waterfall development approach. Some of the key differences that are applicable to IV&V services include:

• Iterative development;
• Evolving requirements and solutions; and
• Flexible response to change.

Many people worry that Agile projects lack control. When do requirements and development end? How do project sponsors control change to ensure that deliverables meet their client’s goals? The fact is a well-run Agile project offers more controls to ensure that customers get what they want. The very differences highlighted above are the reason that it is successful. Iterative development gives the business an opportunity to test early versions of the product to make sure that they are getting what they expect. Evolving requirements and solutions allow business owners to get a better understanding of what they are building before finalizing their list of what they need. Flexible response to change means that the coordinated team can adjust priorities as they learn more about the solution being built.

Agile development is gaining traction because this new approach costs less, delivers solutions sooner, and helps ensure that the business users get what they really want as opposed to what IT understood from a set of written requirements. That is not to say that Agile development occurs in the absence of documentation. To the contrary, Agile development is based on necessary documentation rather than the traditional development process, which often requires a specific set of documentation regardless of its usefulness to the project.

What is IV&V?

Independent verification and validation (IV&V) is easy to define but not easy to understand why it is important.

For IV&V to be independent means that it meets the three parameters of technical, managerial, and financial independence from the project or program. This is achieved when IV&V is conducted by an organization that is separate from the development and program management organizations. The verification and validation processes are used to determine whether the development products of a given activity actually conform to the requirements of that activity and whether the product satisfies its intended use and user needs. IV&V is applied to systems, software, hardware and their interfaces.

Having IV&V helps to ensure requirements are complete, consistent, unambiguous and can be validated; that requirements trace to the design and that the design does not create new requirements; that the code implements all the requirements allocated to the software and that the system meets all the requirements allocated to the system. IV&V then determines whether the system meets the user and the business needs.

IV&V efforts review documents, processes, and procedures against standards and good engineering practices to determine the goodness of each. IV&V will recommend accepting or rejecting a product based on its evaluation of that product. IV&V will recommend continuing to the next phase in the development lifecycle based on its assessment of the products and processes that are required for the proper completion of the current phase. These recommendations are based on objective evidence resulting from assessing products and processes against standards and good engineering practices.

The activities performed by IV&V occur regardless of the development methodology being used. Regardless of whether the methodology is Incremental, Waterfall, or Agile, documents are assessed, processes and procedures are reviewed, and objective evidence is provided to support the decision to accept the product or go to the next phase.

Best Practices for IV&V on Agile Projects

We have developed 5 best practices for IV&V of Agile development practices.

1. Identify the control points. Each agile methodology has its own set of control points. They typically revolve around the development iterations. Scrum, for example, has 5 standard meetings during each iteration (A.K.A. sprint). These include: Sprint Planning, Daily Scrum, Backlog Grooming, Sprint Review, and Sprint Retrospective. The key control points for a scrum are the Sprint Planning and Sprint Review meetings. These are the meetings that talk about business value and what gets included in each sprint. Each control point requires certain objective information be available for informed decision-making. Whether the information is based on concept documentation, use cases, or test results IV&V insures the accuracy, completeness, consistency, and traceability of the documentation to the product.

2. Review the backlog. Agile projects, by definition, have a backlog of user stories or development tasks that need to be accomplished. These backlog items can be considered analogous to requirements in a Waterfall project. The best way to make sure that new items are not out of scope from what the business wants is to regularly review new and changed backlog items. IV&V provides objective evidence about the accuracy, completeness, consistency, and testability of user stories. Objective evidence is required as changes are made. IV&V assesses the desired change for impact on existing tasks and products.

3. Manage the roadmap. Agile projects typically begin with a high level roadmap to guide the project. Each development iteration works against a more granular set of requirements based on the initial roadmap. The IV&V team needs to make sure that the work being done always aligns with the initial roadmap.

4. Question business value. Agile has a concept called minimum viable product (MVP). The goal of any Agile project is to launch the minimum viable project as soon as possible. All too often, development teams build too much into their product. Agile attempts to stop that from happening by launching products when they meet the minimum requirements to launch. This is not always successful. The IV&V team can act as an independent party to validate that each new story or business requirement adds value over and above the cost of delivery to minimize wasted effort.

5. Validate consistent practices. Too often, organizations claim they are doing Agile development to avoid some of the rigidity and structure seen in the Waterfall methodologies. This can be easy to do because very few people understand Agile and Agile does not have a hard and fast methodology. It is important to understand what Agile is (see the description above) and to ensure that there are a set of repeatable practices in place with each development iteration. The IV&V team can play the role of “process cop” to make sure that an Agile structure is in place. The IV&V team also ensures that the processes adapted by the team are adequate and are being followed.

In closing, Agile development is new and gaining traction in nearly every area of IT development. The rules for Agile are quite different from the waterfall development methodology. Agile development is more fluid and allows for a greater level of change throughout a project. This does not, however, mean that Agile development is unstructured or uncontrolled. An IV&V team with Agile experts can identify key control points on a project and make sure that the government gets the same level of independent verification and validation they would get with a waterfall project or from an iterative development project with specified life cycle processes.

If you are beginning an Agile project and looking for IV&V support, Enterprise Knowledge and The IV&V Group® are ready to help.