Agile PM Process Grid–6.10 Retrospectives (4)


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.   Now I am focusing on the “Close” process group.   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, although a traditional or waterfall project always ends with the “Close” process group,  the “close” control group in agile also refers to those activities which are done at the close of an iteration and not just of the product itself–such as the process 6.10 Retrospectives which is covered in this blog post.

Today’s post is the last of four that cover 6.10 Retrospectives.   The first post covered the general features of retrospective meetings.    The second post covered the specific sections that are recommended for Retrospective meetings.   The third post covered some suggested exercises for making the Retrospective meeting less of a meeting and more of an event to be experienced by the team.   And this final post covers some general suggestions for the facilitator of a Retrospective meeting.

  1. The facilitator must focus on the process–given the elements of the retrospective as spelled out in the second post of four on the subject, the facilitator may have to cut people off, summarize what they have said, and move on, without it causing hard feelings to the person being interrupted.
  2. If the facilitator has some information that has not been supplied to the team, then the facilitator needs to tell the team that he (or she) is stepping out of the facilitator role, and then after giving the information, to state he (or she) is stepping back into the role.   Why?   A facilitator is one who monitors the conversation but does not participate in it.
  3. Provide a map of the retrospective meeting at the beginning and let people know the purpose of the activities.   This is done without “spoilers” in terms of what outcomes those activities may uncover.
  4. The best way for a facilitator to be able to focus on the activities is to have a script that can be practiced beforehand, but modified after the retrospective if necessary.
  5. Although the team will be engaging in conversation, the facilitator will need to be on tap to coach and guide the activities IF NECESSARY.
  6. Use Emotional Intelligence (EI) to manage emotions of others if they get out of hand during an activity without an atmosphere or judgement, rather one of observation.
  7. Keep the meeting on time–one of the analog methods most favored by the author is a 90-minute sand timer, which serves as a neutral, visual reminder.    Back it up, of course, by a more precise clock or stopwatch for your own use as a facilitator.
  8. Help the group good decisions, which comes from having the appropriate information, giving time for the discussion of alternatives, and letting the team know the guidelines for what a “good” decision will look like.   Give them that, and trust that they will steer themselves in the right direction!
  9. Understand the individual personalities and the group dynamics in order to allow ALL team members to give their opinions.    So, when asking for opinions, ALWAYS ask the introverts first, NEVER the extroverts first!
  10. Don’t underestimate the power of visual aids.   Someone who has information available on flip charts can guide given a single picture what may take dozens or even hundreds of words to explain!

I hope these guidelines are useful.   I have started to use them for my meetings and they are very, very effective.

The following three posts cover the final process out of the 87 processes that John Stenbeck has created in the Agile PM Process Grid:   7.7 Process Tailoring!

 

 

Advertisements

Agile PM Process Grid-6.10 Retrospectives (3)


In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The previous posts have covered the “Initiate”, “Plan”, “Iterate”, and “Control” process group of an agile project.   Now I am focusing on the “Close” process group.   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, although a traditional or waterfall project always ends with the “Close” process group,  the “close” control group in agile also refers to those activities which are done at the close of an iteration and not just of the product itself–such as the process 6.10 Retrospectives which is covered in this blog post.

Today’s post is the third of several that cover 6.10 Retrospectives.   The first post covers the general features of retrospective meetings.    The second post covers the specific sections that are recommended for Retrospective meetings.   This post covers some suggested exercises for making the Retrospective meeting less of a meeting and more of an event to be experienced by the team.

1. Set the stage (5%)

  • ESVP exercise–ask each team member to identify his or her attitude toward the retrospective as an Explorer, Shopper, Vacationer, or Prisoner.

2. Gather data (30-50%)

  • Triple Nickels–give everyone a sheet of paper divided into 3 columns and divide the team into 3-person groups.   For five minutes, have each person individually write down whatever ideas or reflections they have from the iteration in column 1.   Pass the paper to the next person in the group and have each person write in column 2 ideas that are extensions, expansions, or explorations of the ideas already written in column 1.   Repeat for column 3.   The paper is returned to the original writer who uses it to suggest data points to the group.

3. Generate insights (20-30%)

  • Five Whys–have team members listed issues.   Pair up team members who will take roles as Asker or Responder.    Asker will ask “Why?” to Responder with regard to the issue, and keep asking “Why?” for a total of 5 times, while Responder digs deeper and keeps giving responses which drill deeper and deeper into the issues.  Information from Responders becomes input for the next phase of the Retrospective, “Decide what to do”.

4. Decide what to do (15-20%)

  • Voting with Dots–have team generate a list of possible alternatives for what to do based on the information gathered in phase 2 and insights generated in phase 3.    A limited amount of dots are given to each person and each person has a chance to give a certain amount of dots based on their preference.   Alternatives are narrowed down to a short list, and these are discussed in order to make a final decision on what to do.

5.  Close the retrospective (10%)

  • EQ–It is important to use ritual as a way of creating an emotional closure to the retrospective.   John Stenbeck recommends that each scrum master planning on running a retrospective study Emotional Intelligence in order to learn how to influence the emotions of others without being seen as someone who is trying to control the emotions of others.

6.  Shuffle time (10-15%)

  • Hourglass–Use a visual reminder such as an hourglass (real or virtual) to represent the flow of time–this will help remind people that time is a precious resource not to wasted, since each minute of a retrospective that is wasted is multiplied by the number of people in the team whose lives are all one minute shorter with no value added!

The next and final post on Retrospectives will be about general tips for those leading the Retrospective.

 

Agile PM Process Grid–6.10 Retrospectives (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.

The previous posts have covered the “Initiate”, “Plan”, “Iterate”, and “Control” process group of an agile project.   Now I am focusing on the “Close” process group.   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, but the “close” control group also refers to those activities which are done at the close of an iteration and not just of the product itself–such as the process 6.10 Retrospectives which is covered in this blog post.

Today’s post is the second of several that cover 6.10 Retrospectives.   The last post covers the general features of retrospective meetings.    This post covers the best practices that are recommended for Retrospective meetings:

Here’s how the time should be used in a retrospective meeting, with the amount of time in percentage put in parentheses, followed by some best practices.

1. Set the stage (5%)

  • Describe the goal of the retrospective
  • Ask every team member to speak and be an active contributor
  • Outline the process that will be used
  • Establish an environment of personal safety so difficult topics and challenging conversations can occur
  • Post and view and team working agreements, then suggest any adjustments needed during the retrospective

2. Gather data (30-50%)

  • Create a shared picture of what happened during the iteration
  • Give data about the features and stories developed during the duration, and add metrics
  • Review decisions that were made during the iteration
  • Encourage the team to refer to calendars and artifacts
  • Create a visual depiction where patterns and connections can be recognized
  • All of the above refer to the quantitative–add the qualitative, feeling part of the story
  • Create a structured, comfortable way for the team to talk about feelings and topics that carry an emotional charge

3. Generate insights (20-30%)

  • Have the team examine what conditions and interactions helped and which of them inhibited the success of the iteration
  • Identify breakdowns, constraints, missing information, risks and unexpected outcomes
  • Dig deeper to find possible causes and effects
  • Analyze what changes could help the work flow more effectively

4. Decide what to do (15-20%)

  • Based on the insights generated in the last portion of the meeting, create a list of potential changes the team can make and then pick one or two that the team can implement during the next iteration
  • Make a plan with enough structure to guide the team’s actions–choose to test changes proposed in the last step to see if they produce a positive effect at the end of the next iteration
  • Create stories and put them in the backlog to make it easier to integrate the changes suggested above into the work of the next iteration

5.  Close the retrospective (10%)

  • Since the above steps 3 and 4 are intellectually and perhaps emotionally exhausting, it is important to close the retrospective on a positive and decisive note.
  • Make sure the team makes the new practices developed in step 4 visible with posters or on a wiki page, including any tracking data showing progress against the metrics.
  • Encourage, acknowledge and applaud the effort and risk taking of the team–not the results!

6.  Shuffle time (10-15%)

  • This is the time is takes to shift between activities or topics during retrospective meetings–don’t overlook accounting for this in the schedule

These are general descriptions for the flow of a retrospective meeting.   There are specific exercises that have been tried by agile teams, and I will discuss these in the following posts.  For more complete information and tips on how to run a retrospective, I suggest you check out John Stenbeck’s book, “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”!

 

Agile PM Process Grid–6.10 Retrospectives (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.

The previous posts have covered the “Initiate”, “Plan”, “Iterate”, and “Control” process group of an agile project.   Now I am focusing on the “Close” process group.   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, but the “close” control group also refers to those activities which are done at the close of an iteration and not just of the product itself–such as the process 6.10 Retrospectives which is covered in this blog post.

Today’s post is the first of several that cover 6.10 Retrospectives.   This post covers the general features of retrospective meetings.   As opposed to the processes 1.10 Deliverables Acceptance and 2.14 Product Release which are product-centric, retrospectives are process-centric meetings where the team identifies how it can improve its development process.

In traditional waterfall project management, there is an exercise that is done at the end of each project called Lessons Learned, which is an analogous process for those type of projects.    What is interesting is that the fact that agile does a Retrospective at the end of each iteration has started to effect the world of waterfall projects.   At a Project Management Institute Chicagoland chapter dinner meeting last year, there was a presentation on Lessons Learned and the person who was discussing the topic said that the “hot trend” in project management was start compiling “Lessons Learned” periodically on a project and not to wait until the end of the project.   Afterwards, I asked the speaker where this movement was coming from, and he said simply, “it’s based on a sprint retrospective in agile”.

One major principle of a retrospective meeting in agile that may be different than a “Lessons Learned” exercise in traditional PM is that the facilitator should be someone who is external to the team (but most likely internal to the organization).    This is often done by getting a scrum master from another team to lead the retrospective.

In the next post, I will go into the specifics of what elements go into making an effective and efficient agile retrospective meeting.

 

Agile PM Process Grid–4.13 Self-Assessment


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’s post on 4.13 Self-Assessment, which is the fifth of the 7 processes in the Close process group, and is part of the Team Performance knowledge area.

Although agile terms are self-organizing and self-directing, it is advantageous, according to John Stenbeck, to have effective assessments of team performance.    In the spirit of agile, you have the team conduct a self-examination along two dimensions:  delivery performance and behavior.

  1. Delivery performance–how efficiently and effectively did the team deliver the features and stories that were defined as the iteration goal?    There should be objective external measures such as how many story points were planned versus how many were actually devivered.
  2. Behavior–how well did the team apply best practices from the chosen agile framework .    This is a measurement of team cooperation, cohesion, and commitment.

The form used to chart the self-assessment can be as simple as having columns or rows for “above expectations”, “met expectations”, and “below expectations”.    This is to be done at the end of each iteration so that trends can be observed, and then finally at the end of the project, when the product is released.

The next three posts cover 6.10 Retrospectives, which is part of the Communications knowledge area.

 

Agile PM Process Grid–4.12 Performance Incentives


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’s post on 4.12 Performance Incentives,  which is the fourth of the 7 processes in the Close process group, and is part of the Team Performance knowledge area.

Although agile terms are self-organizing and self-directing, it is advantageous, according to John Stenbeck, to have effective assessments of team performance.    In the spirit of agile, you have the team conduct a self-examination along two dimensions:  delivery performance and behavior.

  1. Delivery performance–how efficiently and effectively did the team deliver the features and stories that were defined as the iteration goal?    There should be objective external measures such as how many story points were planned versus how many were actually devivered.
  2. Behavior–how well did the team apply best practices from the chosen agile framework .    This is a measurement of team cooperation, cohesion, and commitment.

The form used to chart the self-assessment can be as simple as having columns or rows for “above expectations”, “met expectations”, and “below expectations”.    This is to be done at the end of each iteration so that trends can be observed, and then finally at the end of the project, when the product is released.

Rewards can be given to the team for those iterations where they have met expectations, and even larger rewards can be given to the team if they have exceeded expectations.

HOWEVER, it should be noted that exceeding customer expectations is a tricky concept, because if you add features that the customer didn’t ask for, this is not exceeding expectations, but GOLD-PLATING, and is frowned upon by the Project Management Institute because it is ripe for abuse.

One final note about performance incentives:   note that they are not given to individuals, because it is important to promote cooperation rather than rivalry within the team.

The next post covers 4.13 Self-Assessment.

 

 

 

 

 

Agile PM Process Grid–4.11 Team Evaluations


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 4.11 Team Evaluations, which is the third of the 7 processes in the Close process group, and is part of the Team Performance knowledge area.

Although agile terms are self-organizing and self-directing, it is advantageous, according to John Stenbeck, to have effective assessments of team performance.    In the spirit of agile, you have the team conduct a self-examination along two dimensions:  delivery performance and behavior.

  1. Delivery performance–how efficiently and effectively did the team deliver the features and stories that were defined as the iteration goal?    There should be objective external measures such as how many story points were planned versus how many were actually devivered.
  2. Behavior–how well did the team apply best practices from the chosen agile framework .    This is a measurement of team cooperation, cohesion, and commitment.

The form used to chart the self-assessment can be as simple as having columns or rows for “above expectations”, “met expectations”, and “below expectations”.    This is to be done at the end of each iteration so that trends can be observed, and then finally at the end of the project, when the product is released.

The next post covers 4.12 Performance Incentives.