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.   Tomorrow I start on the “Control” process group, but 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, a project always ends with the “Close” process group.

Today’s post on 1.10 Deliverables Acceptance is the first of 7 processes in the Close process group.

Deliverables Acceptance

This process is the whole summit of the project, where the customer or sponsor formally accepts the deliverables.    Even in agile, with its de-emphasis of formalization, requires that the deliverables be accepted formally by the stakeholders because it is crucial to prevent misunderstandings.

Here are the parts of the process.

1. Stakeholders commit to a formal acceptance
2. Administrative closure:   milestone payments, go/no-go decisions about the next phase
3. Necessary documentation:  end-of-project administrative reports, financial reports, continuous improvement notes
4. Celebration!

Celebration is a way of paying back the hard work of the team members, but it also allows a sense of purpose for team members whose sole purpose in the past few weeks or months has been to get to this point.    Beside project closure therefore, it is there for emotional closure as well.

The next process is 2.14 Product Release under the Value-Driven Delivery knowledge area.

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.

The previous posts have covered the “Initiate”, “Plan”, “Iterate”, and “Control” process group of an agile project.   Tomorrow I start on the “Control” process group, but 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, a project always ends with the “Close” process group.

Here are the processes in the “Close” process group:

1.10  Deliverables Acceptance

2.14  Product Release

4.14 Team Evaluations

4.15 Performance Incentives

4.16 Self assessment

6.10 Retrospectives

7.7  Process Tailoring

Out of the 87 processes in agile project management, the Close process group contains the above 7, making it the process group with the fewest amount of processes.   It is nonetheless as vital a process group as the others, and I will start with the first process in the group, 1.10 Deliverables Acceptance, 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 am now covering processes that are performed during the Control process group of an agile project.   Remember, after the Planning process group, an agile project does not go in a linear fashion from Iterate to Control to Close; rather, it cycles from Iteration to Iteration with periodic checkpoints (many times at the end of an iteration cycle) where you Control or make changes to a project to make sure it gets back on track.   Or sometimes, you even change the track itself if there is a change in the requirements.

In the past set of posts, I have covered those processes done in the Control process group that relate to the sixth knowledge area of Communication.   Today I start covering the process related to Continuous Improvement:  7.6 Process Analysis.

Process analysis describes a process by showing the inputs into the process, the operations of the process, and the outputs from the process.   Process improvement can only come after understanding of how the process works.

Then there is a process flow diagram created which shows how one process flows into another.   Processes done sequentially are drawn in series; processes done simultaneously are drawn in parallel.   This helps identify any bottlenecks that reduce process capacity, and quantify the impact of these bottlenecks.

Here are some common opportunities for process improvement based on analysis of the process flow diagram mentioned above:

• Reducing work-in-process inventory
• Increasing the capacity of a bottleneck
• Minimizing non-value added activities

These improvements can be made at a minimal cost, whereas optimizing the capacity of a single process can require a significant investment.    So choose “lean” over “mean” when trying to improve processes!

This concludes the review of the Control process group.   The next post will start the last process group, when the team will Close the 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 am now covering processes that are performed during the Control process group of an agile project.   Remember, after the Planning process group, an agile project does not go in a linear fashion from Iterate to Control to Close; rather, it cycles from Iteration to Iteration with periodic checkpoints (many times at the end of an iteration cycle) where you Control or make changes to a project to make sure it gets back on track.   Or sometimes, you even change the track itself if there is a change in the requirements.

In the past set of posts, I have covered those processes done in the Control process group that relate to the fifth knowledge area of Risk Management.   Today I start covering the process related to Communication:  3.9 Knowledge Sharing

1. Skill-related Knowledge Sharing

One of the best long-term investments in a company is not a senior person with highly developed skills, but a senior person with high developed skills who is willing to transmit these skills to junior members.    This allows the junior members to fill additional roles when the team is stretching to reach an iteration goal.

2. Project-related Knowledge Sharing

When a technical challenge is presented that requires the team to explore a possible solution (sometimes referred to as an exploratory spike), it is good to have someone who is experienced about things that work as well as things that don’t work.   This can help the team in an open space meeting when possible solutions are being evaluated.

3. Process-related Knowledge Sharing

This means sharing knowledge related to agile practices and agile frameworks.   This not only is useful within teams, but within teams as well.   Such an exchange of knowledge is beneficial for delivering on process improvement activities.

The next process covers the last knowledge area of Continuous Improvement, namely, 7.6 Process Analysis.

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 am now covering processes that are performed during the Control process group of an agile project.   Remember, after the Planning process group, an agile project does not go in a linear fashion from Iterate to Control to Close; rather, it cycles from Iteration to Iteration with periodic checkpoints (many times at the end of an iteration cycle) where you Control or make changes to a project to make sure it gets back on track.   Or sometimes, you even change the track itself if there is a change in the requirements.

In the past set of posts, I have covered those processes done in the Control process group that relate to the fourth knowledge area of Team Performance.   Today I start covering  processes related to Risk Management:

• 5.11  Obstacle Removal
• 5.12  Variance and Trend Analysis
• 5.13  Escaped Defects

The first of these is 5.11 Obstacle removal, which I covered in the previous post; I cover 5.12 Variance and Trend Analysis.

Do you remember the Christmas Story by Charles Dickens, where Ebenezer Scrooge was visited by the ghosts of three spirits:   the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future?

In a project, a project manager or scrum master is also haunted by three ghosts, but in this case they are called the Ghost of Defects Past, the Ghost of Defects Present, and the Ghost of Defects Future.

The Ghost of Defects Present is detected through variance analysis, and the measures taken to exorcise this ghost are called corrective actions.   The Ghost of Defects Future is detected through trend analysis, and the measures taken to exorcise this ghost are called preventive actions.   This process of 5.12 Variance and Trend Analysis is covered in the previous post.   The Ghost of Defects Past is covered in this process, 5.13 Escaped Defects.

The first activity to be done if escaped defects are found by users is to repair them, which requires finding out when they were created, and what the root cause of the problem is.

The cost of this process of repairing Escaped Defects needs to be measured because it is part of the costs of poor quality.    Often when asked to justify quality measures, it is useful to have the cost of poor quality available to show that the cost of implementing measures to improve is less than the cost of poor quality.

Finally, there must be an improvement process put in place to eliminate similar kinds of defects from escaping in the future.    This reduces the risk of having future costs that are related to poor quality.

The next process I will cover is the one that is related to the sixth knowledge area of communication that is done during the Control process group, namely, 6.9 Knowledge Sharing.

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 am now covering processes that are performed during the Control process group of an agile project.   Remember, after the Planning process group, an agile project does not go in a linear fashion from Iterate to Control to Close; rather, it cycles from Iteration to Iteration with periodic checkpoints (many times at the end of an iteration cycle) where you Control or make changes to a project to make sure it gets back on track.   Or sometimes, you even change the track itself if there is a change in the requirements.

In the past set of posts, I have covered those processes done in the Control process group that relate to the fourth knowledge area of Team Performance.   Today I start covering  processes related to Risk Management:

• 5.11  Obstacle Removal
• 5.12  Variance and Trend Analysis
• 5.13  Escaped Defects

The first of these is 5.11 Obstacle removal, which I covered in the previous post; I cover 5.12 Variance and Trend Analysis.

Variance analysis calculates the difference between actual and estimated levels of performance and analyzes the cause or causes of the differences in order to be able to correct them.

Trend analysis collects data points, including those concerning the level of performance, and analyzes them to detect patterns that may predict the future trajectory of these data points.

Do you remember the Christmas Story by Charles Dickens, where Ebenezer Scrooge was visited by the ghosts of three spirits:   the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future?

In a project, a project manager or scrum master is also haunted by three ghosts, but in this case they are called the Ghost of Defects Past, the Ghost of Defects Present, and the Ghost of Defects Future.

The Ghost of Defects Past is covered in the next process 5.13 Escaped Defects.   This post deals with the other two Ghosts:   the Ghost of Defects Present, and the Ghost of Defects Future.

The Ghost of Defects Present is detected through variance analysis, and the measures taken to exorcise this ghost are called corrective actions.

The Ghost of Defects Future is detected through trend analysis, and the measures taken to exorcise this ghost are called preventive actions.

The best tool to use for variance and trend analysis in agile projects would probably be the burn-down chart.   The burn-down chart shows both the team’s planned and actual work, so it is easy to compare the actual work delivered against estimated work planned.

We will discuss the process 5.14 in the next post on Escaped Defects.

The next process 5.12 Variance and Trend Analysis will be 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 am now covering processes that are performed during the Control process group of an agile project.   Remember, after the Planning process group, an agile project does not go in a linear fashion from Iterate to Control to Close; rather, it cycles from Iteration to Iteration with periodic checkpoints (many times at the end of an iteration cycle) where you Control or make changes to a project to make sure it gets back on track.   Or sometimes, you even change the track itself if there is a change in the requirements.

In the past set of posts, I have covered those processes done in the Control process group that relate to the fourth knowledge area of Team Performance.   Today I start covering  processes related to Risk Management:

• 5.11  Obstacle Removal
• 5.12  Variance and Trend Analysis
• 5.13  Escaped Defects

The first of these is 5.11 Obstacle removal, which I cover today.

Obstacle Removal

What are the categories of obstacles that can threaten a team’s ability to deliver the iteration goal at the end of the iteration?

• Technical challenges–usually the first category of obstacles the team will consider when discussing risk management
• Stakeholders–the customer or senior management may want to change the iteration goal
• Functional manager–may reassign members of an agile team
• Communications–may lead to both process and product impediments
• Competitor product release
• Changing customer preferences
• Regulatory changes

Organic risk management is done in conjunction with the daily stand-up meetings–“organic” in this case means “done as a part of agile project management processes.”   Overt risk management is done using traditional project management techniques (risk register, etc.).

The next process 5.12 Variance and Trend Analysis will be 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 am now covering processes that are performed during the Control process group of an agile project.   Remember, after the Planning process group, an agile project does not go in a linear fashion from Iterate to Control to Close; rather, it cycles from Iteration to Iteration with periodic checkpoints (many times at the end of an iteration cycle) where you Control or make changes to a project to make sure it gets back on track.   Or sometimes, you even change the track itself if there is a change in the requirements.

In any case, I have covered those processes in the Control process group that relate to the first three knowledge areas of External Stakeholders Engagement, Value-Driven Delivery, and Adaptive Planning.   Now I am covering the two processes that relate to the fourth knowledge area of Team Performance.   In the last post, I covered 4.9 Task Board/Burn Down Chart Updates, and in this post I cover 4.10 Velocity.

Velocity is defined as the number of story points completed by the team during the iteration.

During the planning phase, an estimate of team velocity is used which is called forecast velocity.    In order to create this estimate, some assumptions must be made in order to make basic calculations, such as:

• how many members will be on the development team
• how many weeks there will be in the iteration

• 5.11  Obstacle Removal
• 5.12  Variance and Trend Analysis
• 5.13  Escaped Defects

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 am now covering processes that are performed during the Control process group of an agile project.   Remember, after the Planning process group, an agile project does not go in a linear fashion from Iterate to Control to Close; rather, it cycles from Iteration to Iteration with periodic checkpoints (many times at the end of an iteration cycle) where you Control or make changes to a project to make sure it gets back on track.   Or sometimes, you even change the track itself if there is a change in the requirements.

In any case, I have covered those processes in the Control process group that relate to the first three knowledge areas of External Stakeholders Engagement, Value-Driven Delivery, and Adaptive Planning.   Now I am covering the two processes that relate to the fourth knowledge area of Team Performance, namely 4.9 Task Board/Burn Down Chart Updates, and 4.10 Velocity.

Task Board or alternatively Kanban Boards were set up in process 3.16 Task/Kanban Boards and Burn Down Charts were set up in process 3.15 Burn Down Charts.   This process is where you periodically monitor and, if necessary, take action based on the information in those charts.

What is the primary duty of the task board or burn-down chart?    According to John Stenbeck, it is to enable team synchronization.   It must have the following characteristics:

• visible–the information must be able to be understood in sixty seconds or less
• flexible–the information must be able to be used by ALL team members
• accurate–the information must reflect as closely as possible the current state of the project

The visible characteristic is important because it is more visual than verbal–more information can be processed this way.   This is especially important for teams which have international members and for whom English is not their first language.   The “sixty second” rule is not John Stenbeck’s, but one I learned from a previous boss.   However, I have followed it through my career and it has served me in good stead.

Every team member needs to be able to gain something from the task board or kanban chart; that’s where the flexible part comes in.   And finally, accurate information in the sense of reflecting the current state of the project, is important so any action that is taken in response to that information will be effective.

As opposed to some control processes that are done at the END of an iteration cycle, this process is one that should occur on a DAILY basis, no matter the length of the cycle.   It should answer two basic questions:

1. where are we NOW?
2. where are we going in the near future?

There are other charts, such as burn-up charts, which can tell where the team is going in the medium and long term; the burn-down chart is for what’s happening NOW.

The next control process that affects Team Performance is 4.10 Velocity, and that is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

This post covers the process that monitors during the Control process group the information radiators set up in process 6.4 Information Radiator in the Planning process group.

Those things which are monitored through information radiators during the Control process group include:

• critical issues
• status of each backlog item
• status of testing

How useful is the information in the information radiators?   Obviously in order to be useful it might be accurate and timely.  The team should observe how often stakeholders are viewing the information and whether the information prompts insightful dialogue, even asking the stakeholders which pieces of information in the information radiators they end up following most closely.

By prompting dialogue with the stakeholders, information radiators can deliver both control AND flexibility on the project level.

The next post covers 4.9 Task Board/Burn Down Charts Updates, a process done during the Control process group based on the processes 3.15 Burtn Down Charts and 3.16 Task/Kanban Boards set up in the Iterate process group.

Filed under: Uncategorized | Leave a comment »