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 Two: To 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 Three: Ideation. 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 Four: Grouping. 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 Five: Dot 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.

https://cdn2.hubspot.net/hubfs/1892587/Retrium_feb2017/images/tour.mp4?t=1518454818997

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?

PMI Agile CoP Retrospective

Agile CoP Retro

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

Retrospective

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.

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

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

Week Retrospective 110130

Posts this week

I was a guest of AgileScout Live.  I really enjoyed myself.  Check out my video interview and retrospective.

I wrote about how I’m always looking for ways to communicate with team members, vendors, and customers.  When trying to understand the range of communications, I recently reassessed what I thought the opposite of communications was.  I no longer believe it is silence.  See some of my examples on why the opposite of communications is manipulation.

I loved this 10 minute video by Mike Cottmeyer, I had to write a post for it.  Though I frequent the LeadingAgile website, I had to do a little more than just retweet a link in support of this post.  For those who are new to Agile, Scrum, or Kanban, you need to carve out 10 minutes and watch this video on blending Scrum and Kanban.

After we published our first Scrum Posters, I was asked if we were going to create Non-Scrum Posters.  The answer is YES!  This week, we completed our (first) one-of-a-kind Pictofigo Project Management poster.  The Project Management Process Groups poster is now available!

Like so many this year, I got snowed in.  Unable to go into the office, I instead blogged about how our HOA handled the situation compared to the great snow storms of last year.

I recently read a pre-published copy of the Scrum Pocket Guide: A Quick Start Guide To Practical Agile Software Developmentby Peter Saddington of AgileScout.  I'm giving away one free PDF copy of the book.  Find out how to get registered to win.

Want to use the blog image for free? Find this drawing at Pictofigo

Just One Agile Thing

I met with the Agile Influencers of DC, on Friday night.  The focus of the conversations for the evening was Agile Adoption.  One of the questions asked (I'm paraphrasing here) was

If you were on a project, and you could leverage just ONE "Agile" THING, what would it be and why would you choose it?

This is a little like the first episode of Surviver but it is a good exercise to make you think about what you find valuable in Agile. Would you choose the use of information radiators? Perhaps you favor retrospective meetings?  Or perhaps, you love the use of cross-functional co-located teams?

When I was asked, I chose empowered teams.  Look back at the Agile Manifesto and one of its principles.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I believe if you build a team of professional and empowered people, you increase the probability of project success.  Give your people some general rules to follow and have the faith they will make the right decisions.  It beats the hell out of trying to control them!  Empowering them also gives you more time to help them when they really need you, rather than making trivial decisions.

So, what would be the one thing you would choose?  Why?

Like the image? Find it 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