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.

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »