4squareviews

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now covering a block of five processes that relate to risk management which are done on a repeating basis during each iteration of the project.   The first four of these processes are 5.6 Problem Solving, 5.7 Continuous Integration, 5.8 Risk-Based Spikes, and 5.9 Risk Burn Down Charts.   This post will cover the last of these process, 5.10 Verification and Validation.

For agile projects being executed in the government sector or healthcare industry, there may be a requirement for independent verification and validation to be done at the end of the project.   Some people get confused about verification and validation.   Here’s a way to get them clear in your mind.    Let’s say you are visiting a client and you have to park your car in an massive, underground garage.     What’s the first thing you would do when you leave the car?   If you are like me, and are somewhat “directionally challenged”, you may write down or VERIFY the parking space before leaving the area.

Now let’s say the appointment with the client is done and you want to go to your car, but you want to avail yourself of the opportunity to get the parking fee waived.   You would go to the front desk of your client and VALIDATE your parking.    In a similar way, your company verifies the product internally against the requirements and the customer validates the product externally against the requirements.

If this process is externally driven by government or industry regulations, then the steam must integrate these requirements into the usual agile procedures and activities.   In other words, as in everything else in agile, the team must … adapt.

This concludes this block of processes, and the next post will cover the next knowledge area of Team Communications during the Iteration Process Group.

Filed under: Uncategorized |