Agile PM Process Grid-The “Iterate” Process Group


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’ve covered the first two process groups, “Initiate”, and “Plan,” and will now start to cover the third process group called “Iterate.”   This corresponds to the “Execution” process group in traditional project management.

This post covers some general principles related to execution in agile projects through the iteration process.

Although projects run from the present into the future, planning for them starts at imagining the future state (i.e., the result of the project), and then working back into the present the steps needed to take you from the initial state (i.e., the beginning of the project) to that future state.

At the larger level of the program and portfolio, the scale is different, but the process is the same.    The future strategic objectives are set as the endpoint or future state, and the whole panoply of projects needed to get to that endpoint are mapped out.

In agile project management, the process is the same although the vocabulary is different.   The program and portfolio levels are the release plan and the roadmap, respectively.    So the capabilities and the themes from the roadmap are broken down into release plans, and then iteration plans composed of epics and stories, with the estimate of size coming from Planning Poker or similar technique.

But despite the different vocabulary, the principle that links agile and traditional project management is

Excellence in execution is built upon a foundation of excellence in planning.  

One of the ways to achieve excellence in planning in the agile PM framework is through diligent grooming of the product backlog, which is the subject of the next post.

 

Advertisements

Agile PM Process Grid-7.4 Identify Metrics (3)


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’m in the midst of discussing a block of three processes that are in the continuous improvement knowledge area that are carried out in the planning phase.   The third of these processes is 7.4 Identify Metrics.   In the last two posts, I discussed

  • the dashboard, sometimes known as a stoplight report, and
  • three ways of showing progress on a project, the burn-up chart, the velocity chart, and the earned value management chart.  

In this post, I cover the last of the metrics, the risk register.

How is the risk register in agile different than the risk register used in traditional PM?

First of all, the risk is given a qualitative rating, basic, important, or critical, and the risk is assigned a number based on the group’s analysis of the severity of the risk.

Then the critical risks are listed as being top priority, and the group puts next to each risk in that critical category a mitigation plan.   When the critical risks all have mitigation plans, then the team goes on to the next category, the important risks.   Then and only then are the basic risk addressed.

It is a stripped down version of the risk analysis process used in traditional PM which requires a qualitative AND a quantitative analysis of the risks.    For each risk that is being handled in the iteration, it must go from being critical to being important to being basic in severity.   The reason why the risk register is streamed down is because it gives enough comprehensive information to the stakeholders while avoiding unnecessary expenditure of resources on reports with an unnecessary amount of detail.

This concludes the discussion of all the process in the planning process group.   The next process g.roup, Iteration, will begin to be covered in the next post.

Agile PM Process Grid-7.4 Identify Metrics (2)


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’m in the midst of discussing a block of three processes that are in the continuous improvement knowledge area that are carried out in the planning phase.   The third of these processes is 7.4 Identify Metrics.   In the last post, I discussed the dashboard, sometimes known as a stoplight report.   In this post, I discuss three ways of showing progress on a project, the burn-up chart, the velocity chart, and the earned value management chart.  

A burn-up chart shows the work completed and is most commonly used for release plans.   A line shows progress across multiple iterations in a way that is easy for stakeholders to understand.   It is a cumulative chart, which shows how much work needs to be completed before the end of the release.

A velocity chart shows the work completed across multiple iterations, but unlike the burn-up chart, it is expressed in terms of the number of story points completed during iteration, also known as the velocity of the iteration.

Progress on a project can also be expressed by earned value management.   Like the burn-up chart, it shows cumulatively the number of stories completed during each iteration, but it also includes

  • the Earned Value or EV of the stories completed, meaning how much the stories that were actually completed were supposed to cost, versus
  • the Actual Cost or AC of the stories completed, meaning how much the stories that were completed actually cost.

These two values are plotted against the baseline of

  • the Planned Value of each iteration, meaning how much the stories that were supposed to be completed cost.

In the next post, I will cover the other important set of metrics to be followed, namely, the risk metrics on a project.

 

Agile PM Process Grid–7.4 Identify Metrics (1)


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’m in the midst of discussing a block of three processes that are in the continuous improvement knowledge area that are carried out in the planning phase.   The third of these processes is 7.4 Identify Metrics.

Having accurate and insightful information is vital for effective decision-making.    On the old Star Trek series, if there was something out of the ordinary that the starship Enterprise was encountering on its trek through the galaxy, Captain Kirk would often ask the science officer Mr. Spock whether the sensors were functioning normally.   He had to make sure the information he was getting was accurate before he could decide on an effective course of action.

One of the ways of displaying metrics is a dashboard, so that more information can be compressed into a smaller space if it is visual rather than text-based.   You could read through a report that has a negative conclusion that would take all of five minutes to absorb, or look at an indicator that is colored red and get the same conclusion in five seconds.

Speaking of red lights, some dashboards are called stoplight reports for the reason that they utilize the familiar color convention used for stoplights where

  • green means work is progressing as planned (no special action needed)
  • yellow means work is progressing there is a risk or work issue that must be addressed, and either corrective or preventive action must be taken
  • red means progress has stopped, and either correction action or defect repair must be undertaken in order for progress to resume.

The next dashboard, or way of displaying metrics on the project, is called a burn-up chart.   This is the subject of the next post.

 

Agile PM Process Grid–7.3 Cross-Functional Team Formation


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’m now about to discuss a block of three processes that are in the continuous improvement knowledge area that are carried out in the planning phase.   The second of these processes is 7.3 Cross-Functional Team Formation.

Teams are self-organizing, which means that each individual team member needed to bring something to the table in terms of skills and subject-matter expertise.   But in order to make sure the table (to continue the metaphor) is a stable working environment, the members have to bring a flexible attitude towards how it will self-organize.

If you need to work outside your area of expertise or “comfort zone”, this should be embraced by other members of the team when it helps ensure meeting the iteration goal.

This creates challenges in some ways, because certain organizations use their human resource departments to create more definitive boundaries between roles such as business analyst, developer, tester, etc., whereas the cross-functional team in agile often blurs those boundaries in practice.    The blurring of the lines between roles helps the agile team, but can come in conflict with the organization’s wish to create more clearly definable hiring and compensation guidelines.

So the creation of cross-functional team in agile is a worthwhile goal, but it is important for the scrum master to know that it can come into conflict with an organization culture that prefers to put the various roles in silos.

The last of the three processes in the Continuous Improvement knowledge area is 7.3 Identify Metrics, which is discussed in the next post.

 

Agile PM Process Grid–7.2 Value-Stream Mapping


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’m now about to discuss a block of three processes that are in the continuous improvement knowledge area that are carried out in the planning phase.   The first of these processes is 7.2 Value-Stream Mapping.

There’s an apocryphal story that goes like this:   Michelangelo was once asked how he would sculpt an elephant.  He replied “I would take a large piece of stone and take away everything that was not an elephant.”   Since of the principles of agile is that you want to maximize the value of the product to the customer, there are two ways of doing this in value-stream mapping.    You take your current process that use to produce the product for the customer and break it into smaller pieces.   Then you analyze each piece and you keep or maximize those pieces that add to the product’s value, and throw out or minimize those processes that do NOT add value to the product.

Here’s a more detailed description:

  1. Identity the target of the value stream analysis, whether it’s a product or a service.
  2. Define the current stream by breaking down the steps required to deliver product of service.
  3. Identity opportunities to eliminate waste, i.e., those steps that do not add value to the product or service and are not operationally necessary, i.e., needed to lead to a step that DOES add value.
  4. Depict the desired future state of the product or service that has the non-value-added steps removed.

Value stream mapping is a part of lean manufacturing techniques and is a methodology used in Six Sigma projects.   Now it is part of the tools and techniques used in agile project management, because of its emphasis on maximizing value to the customer.

The next process is 7.3 Cross-Functional Team Formation, and is described in the next post.

 

Agile PM Process Grid–Continuous Improvement Knowledge Area


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’m now about to discuss a block of three processes that are in the continuous improvement knowledge area that are carried out in the planning phase.   But before I do that, I should spend some time on the relationship between continuous improvement and agile.

What is continuous improvement?   The ongoing practice of advancement through incremental or disruptive changes to the design of the delivery process.   As such, it has affinity to quality assurance in traditional PM, as opposed to the value-driven delivery knowledge area, which has affinity to quality control in traditional PM.

Agile frameworks tend to focus on delivering the right product for the current need, rather than improving on the process of delivery itself.   However, agile project management recognizes that improving the process does improve the product, both the current product and future products, so this continuous improvement is the last knowledge area, although by no means the least important of the seven.

Kanban has affinity with agile in spirit because it focuses on

  • value-driven delivery
  • self-organizing teams
  • adaptability

However, it does not have fixed iteration lengths, so some do not include it as a form of agile.   Well, in my opinion it may not be in the same immediate family as agile, but it is definitely a cousin.

The next post will cover the first of the three continuous improvement processes done in the planning phase, 7.2 Value Stream Mapping.