Retrospective Shades of Gray

The Retrospective

I love retrospectives.  It doesn't matter if it's an informal process that occurs naturally as team members interact or it is a formal process that occurs at the end of a meeting, an iteration, or a release.  It's an opportunity for the team and organization to make things better.  It most certainly is on the minds of others today.  I've read about the goals of a retrospective on George Dinwiddie's blog and also retrospectives - wronger and righter on Bob Marshall's blog.

I honestly believe we should be constantly looking for things to start doing, stop doing, do less of, do more of, or keep doing to improve the things we do.  I have been a part of projects where a Lessons Learned meeting was part of the Project Closeout activities.  What good is it then!?  We should constantly be learning and constantly trying to make things better.

Shades of Gray

Depending on the team, I may use the four-quadrant grid, starfish retrospective diagram (or both) to capture ideas. I love the format of the four-quadrant grid, in that the team can communicate what is working, what isn't going so well, any ah-ha moments they've recently had, or appreciations they would like to note for their teammates. Unfortunately, just as some organizations or teams think of writing documentation as an afterthought, I see them doing the same with retrospectives.  Retrospectives are a critical component of any process.  Without them taking place, you are pretty much guaranteed to make the same mistakes twice, a third time, ad nauseam.

retrospective starfish

When to do it

Don't wait until the end of your current iteration, release, or project to document and improve.  On a team board or flip chart, draw a circle.  Segment the circle into five quadrants: Stop Doing, Do Less, Keep Doing, Do More, Start Doing.  Please note that these are merely recommendations.  The content and order are not retrospective commandments.  Have a stack of Post-It notes and a Sharpie nearby. Encourage the team to add notes to the board when the mood or event strikes them.  Don't wait!

If you struggle to get cards on a regular basis, perhaps a facilitated retrospective is in order.  The act of collecting ideas is not just to make people feel better.  Notes captured on this board are all candidates for conversion to action items.  If you have the fortunate problem of having too many ideas on the board, use a consensus strategy like fist of five or dot voting to identify the most valuable action items.

Keep Doing (=): Capture good things that are happening. As a facilitator, ask the team what they would miss if something was taken away from them.

Do Less (<): Anything that might need a bit more refining or that is simply waste.  Is there something that adds value but not as much as something else could?

Do More (>): Are there value-add activities the team may want to try more of but are not necessarily taking full advantage of?

Stop Doing (-): What are some things that are not very helpful or not adding much value?  My prime target is long formal meetings.

Start Doing (+): Suggest new things!  You read or heard about something that helped others like you.  What do you have to lose?

Intro to Value Stream Mapping

I'm in the process of doing a Current State Value Stream Mapping (VSM) for the PMO. The big questions are, based on the current state, are there areas we can improve? Can we eliminate any waste (or increase efficiencies) from our current processes? The answer to both questions is YES.  Everyone should be reviewing there processes on a regular basis, giving themselves opportunities to become more profitable.  Though I'm advising a Federal Government project, the American people still deserve the most bangs for their bucks. Today is the last day for one of my projects.  It is done.  Now is the time to see what worked and what did not.  We now need to do a retrospective and see if we learned any lessons from the last go-around. I will give the vendor credit on this particular project. This small cross-functional team did a better job than others, in part, because we had a daily 15 minute status meeting. (otNay allowedway otay entionmay Agileway). One of the other program teams wastes so much time because they only communicate once a week in a 3 hour meeting.  I hope my VSM will change that.

For those new to Value Stream Mapping, I included a 5 minute video that does a pretty good job of explaining its value.  See how a process that took 140+ days to complete was shortened down to just 30 days.

If you don't have your current process documented, you need to do it!  As the saying goes, "What cannot be measured cannot be improved".  Don't be complacent and accept the waste.  Times are tough and we need to think lean!

Like the drawing? Get it free at Pictofigo

Project Management Theater

tsa

After hearing public outcry over all of the "junk" grabbing going on at Transportation Security Agency (TSA) checkpoints, I heard the resurfacing of the term "Security Theater".  I'm not certain if TSA "gets it".  If you are going to take true action to help fix issues, you need to treat the cause and not a symptom.  Have a shoe bomber?  Make everyone take off their shoes.  Have someone wearing baggy clothes wear a bomb onto a plane, spend millions of dollars to see beyond the baggy clothes.  Without telling you what I did, I bypassed both the new full-body scanners and the TSA pat down in two major airports within the last few weeks.  Certainly, I didn't want to deal with either so I was happy.  The problem I have, as a stakeholder, is a lot of money has been spent and the issue still exists.

Imagine if that happened on your project?

I see Lessons Learned meetings or a Retrospectives as opportunities to help you refine your processes.  You see what works and doesn't work.  You find out the root causes and then you make changes.  You refine.

Today I witnessed what I call Project Management Theater.  The vendor loves to use Gantt charts.    On a program level, both the customer and vendor follow a more traditional waterfall process.  At last count (5 minutes ago) the "integrated" schedule had 5,954 lines.  (Internally, I use a backlog and Kanban) Within seconds of reviewing this monster schedule, I could point out improper work decomposition, improper work package mapping, description inconsistencies, improper use of preprocessors or successors and the list goes on.  If your customer prefers the use of Gantt charts over Burndown charts, I'm not going to argue with them.  Whatever the culture will demand, you have to work with it.  But, the problem here is these are just charts.  They are only as good as the data driving them.  When the customer asked me today what I thought of the split view the vendor provided (WBS/Gantt chart), I was blunt.  I hate it.I added, everything that needed to be reviewed at the meeting could have been presented either as a milestone report or backlog.  Instead, we spent most of our time trying to locate activities and get statuses on each.  On top of that, the schedule provided had not been updated in two weeks.  Therefore, we had to ask over and over again if certain activities had been completed.

If you're going to commit time and money for a support activity, please make sure the resulting "thing" has some value.  At the next meeting, I expect the Gantt chart to go the way of the dinosaur.  I'm advising the customer to request a milestone report from the vendor (instead of the WBS/Gantt Chart).  In the end, I want to ensure the vendor is reaching agreed upon milestones.  Currently, the customer is so distracted by all of the inaccurate details of the schedule, they forget to ask the hard questions about the milestones.

Eliminating the Gantt chart is not going to solve the problem.  Next week, I'm going to show the executive team a Kanban of the milestones.  Let's see if they find more value in that.

Like the image? Find it at Pictofigo

We didn't learn our lesson

As the project I support enters a new period of performance, I reviewed the lessons learned documented a year ago and compared them to the documented lessons learned from a few weeks ago. To be identified at any point of a project lifecycle (PMBOK page 437), all project managers should collect and document lessons learned.  In reality, everyone on the project should be collecting and documenting lessons learned.  But, as many will attest, you need to be able to implement approved process improvement activities (PMBOK page 83) or you will just continue to revisit history at the end of each cycle or project.  If that is the case, you really didn't learn your lessons.

Do you learn from your mistakes?  You should be able to at least be aware of them.  Document your mistakes and revisit them at the beginning of the next project or cycle.  Group them into three categories: Correct Actions, Preventive Actions, and Defect Repair.

Corrective Action: Document your direction for executing future project work. Bring expected performance of the project work in line with the project management plan.

Preventive Action: Document your direction to reduce the probability of negative outcomes associated with project risks.

Defect Repair: Document a defect in a project component with the recommendation to either repair it or completely replace the component.

Though the process of documenting, reviewing, and implementing lessons learned may differ between Waterfall and Agile projects, the process still needs to happen.

Again, don't just document lessons learned.  Act on them!

Graphic: Flickr: sopheava

Did you learn your lesson?

I'm going to be facilitating a second lessons learned session later today. As part of the project closing processes, all project managers should collect and document lessons learned.  But, as many will attest, you need to be able to implement approved process improvement activities or you will just continue to revisit history at the end of each cycle or project.

Do you learn from your mistakes?  You should be able to at least be aware of them if you document them at the end of each cycle or project. Revisit them at the beginning of the next project or cycle.

Corrective Action:  Document your direction for executing future project work. Bring expected performance of the project work in line with the project management plan.

Preventive Action:  Document your direction to reduce the probability of negative outcomes associated with project risks.

Defect Repair:  Document a defect in a project component with the recommendation to either repair it or completely replace the component.

Responsibility Assignment Matrix

As a graphical depiction of a more detailed perspective of responsibilities, the responsibility assignment matrix should reflect assigned responsibility by functional role for key project deliverables.  An example of roles detailed below could include (1) Project Manager, (2) Project Sponsor, (3) Implementation Manager, (N) Team Lead

Project Deliverables	Role 1	Role 2	Role 3	Role N
WBS 1.15.10.1300 - Project Charter	E	A	C	I
WBS 1.15.10.1301 - Project Schedule	E	A,C	A	I
WBS 1.15.10.1302 - Project Budget	E	A,C	E	I
WBS 1.15.10.1303 - Status Reports	C	C	A	E
Legend E = responsible for execution (may be shared) A = final approval for authority C = must be consulted I = must be informed

I use this matrix in a few of my project artifacts, to include the Lessons Learned. You can download a free copy here

Free Lessons Learned Template

It is not important that you call it a Lessons Learned or a Postmortem. What is important is you learn from your mistakes. At the end of every iteration or project, you should identify everything that went wrong or could have gone better. Articulate them in a document. At the beginning of each new iteration or project, review the document and see not only what was learned but what has been implemented. Feel free to download my free Lessons Learned [Template]