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

Filed under: Uncategorized |