Product Review for Distributed Retrospectives

On a monthly basis, I see at least one distributed retrospective. Sure, I would prefer to do it onsite with participants, on a wall with sticky notes, but that's not always an option. So, what can we do about it? Not having the retrospective is not an option. Instead, I want to find a tool that has a low level of friction, is purpose built, and reasonably priced.  Sounds like it's time for a product review! Over the last few years, I've used several products for distributed retrospectives. Each of them sucked in their own special way. So, I thought about testing Retrium. My first thoughts are I like it!

Currently, they have Five major techniques (4L's, Mad-Sad-Glad, Start-Stop-Continue, Lean Coffee, and Went Well, Didn't Go Well) customized for the distributed experience. With that, I focused my attention on the  "Start, Stop, Continue" technique.

Steps I used for the product review:

Step One: Choose a retrospective format. I picked Start, Stop, Continue.

Step TwoTo start the retrospective the facilitator should explain how the technique works. He or she should then tell the team the timebox for the retrospective (30-60 minutes, depending on the size of the team).  In Retrium, you can set a timebox time for each step or the overall retrospective.  I like to set a timer for each step.

Step ThreeIdeation. The facilitator should tell participants the timebox for this phase (10-15 minutes should be enough). Participants will then start entering ideas on the board, under the respective heading (Start, Stop, Continue).  As the participants enter ideas, the text will not be visible to other participants (until the grouping phase). I like this features, as keeping ideas private will help ensure participants aren't biased by each other's ideas. When the timebox expires, we move onto the grouping phase.  If people are full of ideas, the facilitator can extend the timebox timer.

Step FourGrouping. The facilitator then chooses to advance to the idea grouping phase. I'd recommend the facilitator inform the participants that once you move on to the Group phase, you will not be able to return to the previous phase.  Since ideas will likely be related (or even identical), participants should group items into logical themes. Participants can label the logical groups on the screen.

Step FiveDot Voting. The facilitator then chooses to advance to the voting phase. Again, I'd recommend the facilitator inform the participants that once you move on to the Voting phase, you will not be able to return to the previous phase.  As noted earlier, each one of these phases can be timeboxed with a timer feature located on the screen. In my retrospective, participants had 5 votes they could cast against the groups.  After voting is complete or the timer expires, the facilitator advances the retrospective to the Discussion phase.

Step Six:Discussion.  This is where I believe you are going to get the most benefits from this product. In the discussion phase, only one idea group at a time will be displayed. Here, you will create action items. When you're ready, choose the next topic (group). Add more action items to your Action Plan.  You can then choose to review the action plan or end the retrospective.  This is by far the step most retrospectives fail at. No action plan is easily maintained and worked.

Retrospective History and Action Plan: Now that the retrospective is over, you can go back and look at previous retrospectives and more importantly, have an ongoing action plan of improvement.

So, is Retrium worth the cost?  At the time of this blog post, 1 team room was $49 a month.

You'll get the following:

  • Access to all retrospective techniques
  • Run an unlimited number of retrospectives
  • Invite an unlimited number of users
  • Create and track action plans
  • View your retrospective history

Is it worth it? I recommend you check out this ROI calculator and dynamically calculate your return on the investment. If you can save your team just 30 minutes a month, through improvements, the product pays for itself.

I would definitely recommend this product!

Full disclosure: I have no financial relationship with Retrium. However, I do know a few of the people there.

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 concensus 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?

PMI Agile CoP Retrospective

When you think of spending a Saturday afternoon among friends and colleagues, do you picture yourself sitting in front of your computer, collaborating for three hours on a web-based tool and discussing what is working and what could work better? Well, that is exactly what a group of us did. It was time for the quarterly PMI Agile Community of Practice (CoP) retrospective. We couldn't all be in the same physical location so some of us from the community jumped online and tried to make the world (or at least our CoP) a better place.  When you look at the graphic above (or click on the link to Cacoo), you may be left scratching your head, if you are neither an Agilist nor a member of the PMI Agile CoP. If you are either, I hope you nod in recognizing the mechanism we used to interact and make our Agile Community of Practice a better place for us all to belong.

Community of Practice

You could describe us as a motley crew of discontents and zealots. You could also describe us as a passionate group of Agilists drawn together, with the hope of helping the PMI community discover the value of Agile practices and approaches.  We all hold a sense of belonging to our community.  We all believe in the altruistic sharing of knowledge, methods, stories, cases, tools, and documents.


Generically speaking, a retrospective meeting is held at the end of a scheduled event or time interval. With the aid of a facilitator (in this case Brian Bozzuto), a team discusses what went well and what could be improved during the next interval or prior to the next scheduled event.  The meeting is time-boxed to help ensure it doesn't just turn into an out-of-control complaining session.  When properly facilitated, you come out of the meeting with an actionable list for improvement. Though I always recommend doing retrospectives in person, actually having the retrospective takes priority. Do it wherever you can however you can.  Successful teams need to take the time to have retrospectives if they have any chance of improving what they do.

PMI Agile CoP Quarterly Retrospective

The leadership of this community recognizes that as our community grows, some things will work and some challenges will need to be overcome (zoom into the graphic to see what we thought).  One thing is for certain: with almost 14,000 members, our PMI community has a lot to offer both members and non-members.  Every minute of that Saturday afternoon was well spent.  I hope this post and the link to the Cacoo graphic provides some transparency into what we've been doing the last three months.

Interested in joining our community or becoming a volunteer?  We'd love to have you!

Source:  This post was originally written and published by me on the PMI Agile Community of Practice blog

PMO Analogy

As my tenure with the PMO comes to an end, I've had an opportunity to reflect on the last two and a half years.  What I realized was how much the PMO was like the U.S. Congress.  If I imagine the organizational structure of the PMO I've been supporting, I can imagine the CIO as the President and the PMO Program Director as the Speaker of the House or the Senate Majority Leader.  Beneath the Program Director are the Division Directors (Committee Chairs) and then members of the PMO (Congress in general).  What I've found interesting is many (not all) have their own agendas and motives.  Gridlock, not collaboration, is the norm.  Now, am I talking about the PMO or Congress?  I'm not trying to paint the PMO or Congress in an unfavorable light.  To the contrary, these people are all SMEs in their respective areas.  But they've seemed to have forgotten the common goal.  They've forgotten who the customer is.  In both cases, it's the American people. From my perspective, when you're trying to deliver value, you need to consider all of the options, regardless of your convictions.  I was the sole Agile evangelist in the PMO.  Think of me as a lobbyist representing the American people.  I did what I could to help the Government understand and to be receptive to new ideas.  But what the PMO failed to grasp was Agile is much more than a way to deliver software products.

I think Michele Sliger put it very well:

Being agile means that teams are working in ways that allow for change in order to better work together and provide a more useful and meaningful product to the customer.

My final days with the PMO will be like a long retrospective.  What went well during this engagement? What could be improved in the next engagement?

HT: Michele Sliger

Intro to Value Stream Mapping

The Critical PathI'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