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.

The previous posts have covered the “Initiate”, “Plan”, “Iterate”, and “Control” process group of an agile project.   Now I am focusing on the “Close” process group.   I first want to define what I mean by that term of “process group”.   Why do I use this instead of the word “phase”?    Phase implies a sequence that goes more or less from one set of processes to another.   In reality, after the initiate and plan process groups, an agile project actually shuttles back and forth between the “iterate” and “control” process groups.   However, although a traditional or waterfall project always ends with the “Close” process group,  the “close” control group in agile also refers to those activities which are done at the close of an iteration and not just of the product itself–such as the process 7.7 Process tailoring.

This process is the last of the 87 processes that John Stenbeck describes in his book.    Having learned all of the agile processes, it is now time to go beyond them–meaning to incorporate processes from waterfall or traditional project management if it is warranted.

The first post out of three discussed hybrid projects in general, i.e., those that incorporate elements of both agile and other  methodologies.    The second post covered process tailoring in order to meet the needs of the organization.   Today’s post, the third and final one in the series, will cover process tailoring in order for the organization to meet external standards.

There are two types of external standards to consider:    regulatory and industry standards.    The biggest difference is that the first type of standard is obligatory, and the second type is more of a recommended best-practice type of standard.

1. Regulatory standards

Let’s take a typical example of the first type;  the health-care industry, which is covered by HIPPA regulations (among others).    Although the Agile Manifesto’s second principle is:

Working software over comprehensive documentation

the reality of the situation is that if you don’t do the documentation that shows your new system is HIPPA compliant, then it not be able to be used by a health-care provider.   Period.   So agile processes have to produce documentation that allows the product to be sold.    I know this well from my days working for Mitsubishi Motors, when I worked in the regulatory compliance division.    All those tests we did to make sure we passed NHTSA and EPA regulations may not have seemed, at first glance, to add value for the customer.   But if didn’t do those tests, either agency would have been able to make sure that the customer never even saw the vehicles in a showroom, let alone buy one.

Regulatory compliance is so important that, when tightening a company’s budget, a project which works on regulatory compliance issues that has, on the surface, little ROI, will be carried out even over a project which has a relatively high ROI but does nothing to advance the product’s regulatory compliance.

Agile is like a reed that bends to the winds of reality.    So if process tailoring meets the external need of regulatory compliance, it will accommodate that reality.

2. Industry standards

A set of quality standards like ISO standards is self-imposed to a certain extent, but it is done as a symbol that the product has value to the customer because it meets certain quality standards.

Here are some guidelines given by John Stenbeck:

• Analyze those organizational standards which are in most need of improvement, i.e., that will deliver a high value if changed
• Have  a strong executive champion to sponsor the change (important)
• Find evidence (case studies or white papers) which validate similar organizational improvements done by other organizations within the industry (the sponsor will need these to convince others in upper management)
• Identify which roles must be tailored to the external standard–it is roles, even more than resources, which people tend to protect more fiercely, and you will need to show how the changes will benefit them, NOT make them obsolete
• Create a framework and detailed procedures that incorporate the new standards

This is the final post on this book, and I must say it was very helpful in studying for the Certified ScrumMaster exam, which I recently passed.

Tomorrow I will start a series of posts on the Global Risk Report 2016 from the World Economic Forum, analyzing its contents and comparing them to previous reports in order to identify significant trends.

Filed under: Uncategorized |