Agile PM Process Grid-2.10 Cumulative Flow Diagrams


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.

Here is an example of the tool used to improve performance on agile project.   The stories in the blue area are in the backlog, and have not yet been started.   The stories in the purple area are started, but not yet completed, and are therefore Works In Progress or WIP.   The stories in the pink area are completed.   (NOTE:  the diagram uses the concept of features rather than stories, but the concept is the same.)

CFD

The WIP at any point in time can be measured by the number of stories between the top of the purple area to the bottom of the purple area.   So, for example, on week 11, the amount of stories that are WIPs is 300 – 100 = 200.   You can imagine that, in between weeks 9 and 11, the agile project manager looked at the CFD diagram and saw that the WIP was getting to be undesirably large.    Then measures were taken to reduce the amount of WIP (see previous post) and then the WIP narrows significantly in the following weeks.   Reducing the WIP, by Little’s Law (see previous post), has a corresponding effect on cycle time.   So a Cumulative Flow Diagram gives a transparent picture on the progress of the project.

The next post will cover the next knowledge area covered repeatedly during iterations, namely, value-driven delivery (i.e., quality).

Agile PM Process Grid-2.9 WIP Limits and Little’s Law


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.

Work-in-Process (WIP) is a concept borrowed, as much of agile methodology is, from Lean thinking to improve the value stream of product development.   The basic idea is that a project is a type of WIP because the business cannot realize value from user stories in process, but ONLY from potentially shippable increments of the solution.

In the first of three posts, I explained how WIP is measured.   In the second of three posts, I listed some ideas John Stenbeck gave on how to reduce WIP.   One tool in measuring the effective of measures to reduce WIP is called Little’s Law, and that is the subject of this post.

Little’s Law was created by John Little of MIT, and it applies to the relationship between

  • cycle time (the time required to deliver a potentially shippable increment of the solution)
  • WIP (the number of stories that are currently being developed, but which are not yet at a point where they are potentially shippable), and
  • throughput (the rate at which stories are being developed in the system)

Let’s take two examples from p. 182 of John Stenbeck’s book.

  1. 200 stories of WIP, where the team produces 10 stories per day:   here Cycle Time = WIP/throughput = 200/10 = 20 days required to deliver a potentially shippable increment of the solution.
  2. 200 stories of WIP, where the team produces 100 stories per day:  here Cycle Time = WIP/throughout = 200/100 = 2 days required to deliver a potentially shippable increment of the solution.

The reason why these two examples were chosen by John Stenbeck is because the WIP is the same.   The variable that changes is the throughput, the number of stories the team can complete in a day.

So if you want to reduce the cycle time there are two ways of going about it:

  • reduce the WIP, ways of doing which are listed in the last post, or
  • INCREASE the throughput, i.e., the number of stories a team can produce in a day.

This can be done obviously by throwing more people onto the team, but there are some processes external to the team which may be influencing how fast the team can come up with solutions, i.e., clarity of the requirements.

The next process in the “Value-Driven Delivery” knowledge edge that is used regularly in iterations is 2.10 Cumulative Flow Diagrams, which is covered in the next post.

Agile PM Process Grid–2.9 WIP Limits (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.

Work-in-Process (WIP) is a concept borrowed, as much of agile methodology is, from Lean thinking to improve the value stream of product development.   The basic idea is that a project is a type of WIP because the business cannot realize value from user stories in process, but ONLY from potentially shippable increments of the solution.

It reminds me of a cartoon from a physics textbook I had in high school.    On the left was a circus clown who had a chair in front of him that was nailed to the floor.    He was grunting and straining at his task, apparent by the sweat that was pouring copiously from his brow.    On the right was another circus clown who took a feather and lifted it up off the floor.   The question in the caption was “which clown did more work?”

The answer the uninitiated might give is the clown on the left, because he’s breaking a sweat and the clown on the right isn’t.   But if you take the technical definition of work as a weight moved a certain distance, the answer is clear:   the circus clown on the right did more “work” in the physics sense, because he moved the feather, admittedly a very light-weight object, a certain distance (let’s say six feet, from the floor to the height of the clown’s head).    But the clown on the left did ZERO work because the much heavier object was moved a distance of exactly ZERO meters, and anything multiplied by zero equals zero.

How did this relate to WIP?   Work in progress is the attempt to get something accomplished; the actual accomplishment is the ONLY thing that counts towards value towards the customer.   In the case of the two clowns, the one thing that kept the clown on the left from being effective was the impediment of the chair being nailed to the floor, which, if he had noticed it, and remedied the situation, would have allowed him to do more work than the clown on the right.

In the post, I talked about MEASURING Work-In-Progress or WIP.   Once you have a measure of WIP, how do you reduce it?   Here are some suggestions given by John Stenbeck:

  1. Reduce the iteration backlog to match the team’s capacity.
  2. Improve the actual work process with what is considered a “best practice” process.
  3. Remove the most common impediments to the process.
  4. Synchronize team members to avoid duplication of efforts, and to avoid any wasted time during the handoff of work from one team member to another.
  5. Manage workflow by means of a storyboard.
  6. Obtain additional resources if limited resources are what is causing a WIP not to achieve a result.

One other way to get a handle on WIP is to use Little’s Law, a relationship between cycle time, WIP, and throughput in a production system in a steady state.   That is the subject of the following post.

Agile PM Process Grid-2.9 Work-in-Process Limits (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.

Work-in-Process (WIP) is a concept borrowed, as much of agile methodology is, from Lean thinking to improve the value stream of product development.   The basic idea is that a project is a type of WIP because the business cannot realize value from user stories in process, but ONLY from potentially shippable increments of the solution.

In the previous post discussing cycle time, it was noted that the business can derive value sooner if the cycle time is shortened, particularly through process improvements external to the time.

The use of WIP limits improves the team’s workflow by controlling the amount of WIP at each step in the process.   This helps the team overcome perceived impediments to completely finishing each story.   The helpful analogy that John Stenbeck gives is the same way stop lights on freeway on-ramps prevent rush hour gridlock by limiting the number of cars entering the system depending on how many cars are already in the system.

In agile terms, WIP limits limit the number of stories being actively worked on by the team at any single point in time.    This actually courses more stories to be completed.

How do you measure WIP?   It would seem to be complicated because it is a moving variable, like the traffic moving on the freeway in the analogy given above.   The best way to measure and manage WIP is to

  1. check the story board a few times per day and count how many stories are in the queue:  this will be the current WIP level.
  2. Take the average of the measurements after a few days and give some sort of buffer for comfort.
  3. Estimate the maximum and set it as the initial limit or starting Maximum Allowable WIP.
  4. Make periodic reductions in the limit and measure the impact on productivity.
  5. The most desirable WIP limit will emerge rather quickly.

This shows you reference point for WIP measurement.

How do you reduce WIP once you’ve measured it?   That will be the subject of the next post.

Agile PM Process Grid-2.8 Cycle Time Measurement


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.

Cycle time in general is the amount of time required to delivered capabilities.   In any framework, whether it be agile or traditional PM, the concept is to measure cycle time so that it can be reduced by removing those activities that don’t create value and thus waste time.

In an agile framework, the definition of cycle time is narrower:   it is the start-to-finish time required to complete a potentially shippable increment of the solution.   One thing to understand is that cycle time is a process measure, not a person measure.   In other words, the cycle time may be four weeks given a certain set of resources working on the solution.   However, with other resources that are more effective, that same solution may take only three weeks.

To improve cycle time, John Stenbeck gives four guideslines.

  1.  Build the roadmap as a swarm–bring together all of the people involved on the project, in order to gain everyone’s insights on how to decrease the overall time required to complete the product.
  2. Define acceptance metrics for releases and iterations–this is focused on the customer/proxy (aka the Product Owner) to produce specific metrics that will validate the potentially shippable increments; this will reduce the time between releases as the acceptance (i.e., validation) process will be minimized.
  3. Select an iteration length that is sustainable–although an iteration length is referred to as a “sprint”, the entire project must be run as a marathon, which must be run at a steady pace over the long haul, one that is conducive to the repeated completion of potentially shippable increments.
  4. Recalibrate and institutionalize learning–this improves the team dynamic within the iteration by creating a learning exchange between members, and scaling up the learning achieved individually to the institutional level that ends up creating organization standards that increase the company’s ability to more accurately estimate cycle times for roadmaps and release plans.

The next post will cover process 2.9 Work-in-Process (WIP) limits.

Agile PM Process Grid-1.8 Product Backlog Grooming


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.

In this post, we will cover the process done during the “Iteration” process group that relates to the “External Stakeholders Engagement” knowledge area:   Process 1.8 Product Backlog Grooming.

I like John Stenbeck’s description of the product backlog grooming as the “steering wheel”, which allows for course corrections to make sure the project is going in the right direction.   What is the right direction?    This must be determined by the Product Owner or customer/proxy.   He or she needs to

  • refine the business value assessment of the product
  • set backlog priorities accordingly.

The latter responsibility, that of setting priorities, is what drives the process of product backlog grooming.    The setting of priority involves discerning the timing of the development of minimally marketable features (MMF) to create both incremental and long-term value.

Since it evolves on an iterative basis, the product backlog is not “written in stone” and is a living document which evolves as the requirements are elaborated.   Just because the customer wants a feature at Sprint #1 doesn’t mean that the customer will want that feature at Sprint #10.   The conversation between the customer and the development team may cause the customer to change his or her mind regarding the product vision and how that is to be expressed in the product under development.

The product backlog grooming process, aka product backlog management, prioritizes each item on the product backlog, moving items from the outer edge of the time horizon to the mid-term to the current time horizon.

It is known that product backlog grooming reduces waste, which has a positive effect on the company’s bottom line.    How does it accomplish this?    By delivering those items that creates business value within the capacity of the team to deliver that value.    Reducing waste is a Lean Manufacturing principle that is imbedded in the intellectual DNA of agile frameworks.

The next post covers processes that are done in the “iteration” process group that are related to the next knowledge area, value-driven delivery.

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.

 

Follow

Get every new post delivered to your Inbox.

Join 685 other followers