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’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 »

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.

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.   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.

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.

Now I am starting on a block of four processes that are part of the sixth knowledge area of Communication that are done during the Planning phase of the project.   The first three of these four processes are 6.3 Communication Protocols, 6.4 Information Radiators, 6.5 Team Space, covered in previous posts.   This post continues discussing 6.6 Agile Tooling.   The first of the agile tools is a product vision box, which often includes a vision statement, sometimes often referred to as an elevator statement.    The second of the agile tools is a flexibility matrix, which was covered in the previous post.    The third of the agile tools is a product data sheet. 

Product Data Sheet

This is a one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision.    According to author Jim Highsmith in his book Agile Project Management, Creating Innovative Products, the product data sheet provides the project information that the team and all the stakeholders need in an appealing, condensed format which constantly refocuses them on the strategic aspects of the project.

Here are the typical elements of the Product Data Sheet:

• Project Start Date
• Project Finish Date
• Agile Leader (the project leader who guides the process)
• Customer/Proxy (the project leader who guides the product)
• Elevator Statement (see previous blog post on this agile tool)
• Customer Segment(s)
• Customer Benefits
• Flexibility Matrix
• Milestone Table

Using the example I’ve used for the previously presented agile tools in the series, let me take the example of an app that is already in existence called Duolingo, which I use every day to study foreign languages.    The following is an example of a product data sheet which uses my own made-up content to give an example of everyone of the elements listed above.

You can see how the customer will be focusing on the elevator statement, the customer segment(s) and the customer benefits, whereas the team will be focusing on the flexibility matrix and the milestone table.    It is more left-brained and logical in its presentation as opposed to the more right-brained product vision box which is more visually-oriented and geared more strictly for the customer than for the team.

This agile tool actually combines the other two, the vision statement (aka elevator statement) and the flexibility matrix.   The whole purpose is to give all the information that would be of value to the customer.

The next post will start covering the next block of processes that deal with the next knowledge area, Continuous Improvement.

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.

Now I am starting on a block of four processes that are part of the sixth knowledge area of Communication that are done during the Planning phase of the project.   The first three of these four processes are 6.3 Communication Protocols, 6.4 Information Radiators, 6.5 Team Space, covered in previous posts.   This post continues discussing 6.6 Agile Tooling.   The first of the agile tools is a product vision box, which often includes a vision statement, sometimes often referred to as an elevator statement.   This was discussed in the last post.   In this post, I discuss the second of the agile tools, a flexibility matrix.

A flexibility matrix is a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed).

The Flexibility Matrix

As discussed in a previous post, in traditional PM, the scope is fixed as much as possible in the beginning of the project, and the other two of the triple constraints of time and cost are estimated in relationship to this more-or-less fixed variable.

In agile PM, it is one of the two triples constraints of time or cost, usually time, which is the fixed variable, and the scope is the one constraint that is flexible.    Okay, in theory that it is understandable, but when push comes to shove, and some of the scope has to be thrown out of the project, how do you make that decision?    That’s where the flexibility matrix comes in.   As mentioned above, it shows how to handle trade-offs and prioritize features by showing the relative importance of constraints such as scope, schedule, cost and quality (although other constraints may be added to the matrix).

NOTE:   When using the flexibility matrix, only one constraint may be considered fixed, all of the others have to be defined as firm or flexible in relationship to this fixed constraint.    In the example below, the flexibility matrix is given where the schedule is fixed, the scope and quality are firm, and the cost is flexible by comparison.

Usually the flexibility matrix is incorporated into another tool called the Product Data Sheet, 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.

Today I start on a block of four processes that are part of the sixth knowledge area of Communication that are done during the Planning phase of the project.   The first three of these four processes are 6.3 Communication Protocols, 6.4 Information Radiators, 6.5 Team Space.   This post is 6.6 Agile Tooling.   The first of the agile tools is a product vision box, which often includes a vision statement, sometimes often referred to as an elevator statement.  

Product Vision Box

The product vision box is a tangible expression of a solution to that includes graphic images as well as narrative content to express the customer’s product vision.    This is meant to be presented to the customer so technical jargon is to avoided as much as possible.

One way to create the product vision box is to start with the vision statement, sometimes called the elevator statement, as discussed in the last post.    Let’s review the elements of the vision statement, as set forth by Geoffrey Moore in his book Crossing the Chasm.

Vision Statement

For:  [name a customer type]

Who Want:  [state a specific need or desire]

The:  [name your product]

Is a:  [name the product category]

That:  [name a compelling reason to buy or use the product or service]

Unlike:  [name the leading competitive products]

Our Product:  [specify the differentiating features or functions]

Here’s an example I created with an app that I use every day to study foreign languages called Duolingo.

For all those who want to learn a foreign language, the Duolingo app is an free app that can take you from having no knowledge of a foreign language to fluency by using it just 10 minutes a day, unlike other foreign language programs like Rosetta Stone that can cost up to hundreds of dollars and require a much larger time commitment.  Our product teaches the user the basic and intermediate levels of any one of a dozen or more European languages.

Vision Statement –> Product Vision Box

Here’s a sample of a “Product Vision Box” for the Duolingo app that I created using the vision statement.

DUOLINGO!

THE EASY, FUN WAY TO LEARN A FOREIGN LANGUAGE

For any one who wants to learn a foreign language

App can be downloaded to your iPhone or Android Device

Be fluent in months if you practice just 10 minutes a day

App is free to use

Learn any one of a dozen foreign languages, with more being added

GO FROM LANGUAGE ZERO TO LANGUAGE HERO!

As you can see, there is the product title, followed by a slogan which gives the basic function of the product.   Then you can include a graphic element which shows either how the product will work, or in this case, the logo that plans to be connected with the product, the owl named Duo.

Then the elements of the vision statement can be stripped out and given underneath.    I have followed the list with a catchy slogan “Go From Language Zero to Language Hero” which is aimed at the potential end user, who may have tried to learn a foreign language in the past and had little success.    This is obviously just an example, but it shows the approach being used.

Just remember that there are four communication preferences, those that focus on

• Ideas (relates to what people think)
• Process (relates to what steps people will take)
• People (relates to what people feel)
• Action (relates to what goal people aim for)

One of the perpetual communication problems project managers have is that they are usually have a primary strength in the process communication preference, but may not be able to communicate effectively in the people communication preference, which requires you to tell stories so that people can not just see the steps you are going to take to get to the solution (which is what the process communication preference emphasizes), but what the solution will feel like, look like.    The last statement in the product vision box was “Go from Language Zero to Language Hero.”   This is an emotional appeal to a user, not a practical one.    If you just want to learn a foreign language, then you should try this product.   But if you have been frustrated in the past trying to learn a foreign language, then you should REALLY try this product.    See the difference?    If you have graphic designers or someone with a visual bent, then that is the person you should be using to help create your product vision box.

For those who want to use an approach that is more along the lines of those with a preference for process-focused communication, then you should try the next agile tool, the Project Data Sheet.   That is the subject of the next post.

Filed under: Uncategorized | Leave a comment »