Content Precedes Design

Past Performance *is* Indicative of Future Results

If your team/organization has taken on and sustained the practice of project retrospectives (see my earlier post), I applaud you. Great initial step, but you're not going to see the true value from this practice without going further. You're now faced with the opportunity not only to reflect and maybe get some clarity on the bigger picture successes and challenges, but also to memorialize those so others can actually do something with that information.

All of those lessons learned around capturing what propelled and confronting what dragged will forever be buried in those notes/outputs unless they are actually shared, understood, and considered next time around by other teams.

I'll repeat: Lessons learned die in PowerPoint decks… unless shared, understood, and considered next time around.

Arguably, there is a responsibility to generally socialize these lessons learned across other teams and beyond within your organization so some things actually start to take hold. These things can span what might need to be integrated into the way everyone approaches a plan, how they kick off a project, or how similar challenges are handled at any point by anyone who encounters them.

This is true Knowledge Management at work, and as with any KM paradigm set up for success, will only be effective by combining the right tools, processes, and people responsible for sustaining this continuous improvement paradigm.

Project Retrospectives

Quite different from the iterative practice of sprint retros (see my earlier post), an overall project review has goals that are a bit different. This is also intended for a broader audience... time to explore how everyone feels about how the project went and what was produced. An important point: sometimes this can be done with a client and sometimes without. Of course, the focus may be substantively different in each of those cases. Just like a sprint retro, the idea is not to make a case for who to blame or ‘for the record’ airings of grievances—we want to capture the things that enabled successful outcomes and confront what encumbered quality and value.

Here are some examples of what could be good to discuss...

Capture what propelled

Try to determine what is repeatable and sustainable.

Confront what dragged

Consider what was detracting from delivering well.

Basically, we want to figure out what to adopt and what to avoid; can’t say it more simply than that.

The who and how is bit different from sprint retros...

Who

Involve everyone who contributed anything at any point—even if the team had a developer or designer a few months ago that is now on a different project, they need to be invited and make time to contribute to a complete picture.

• Project Manager
• Sales
• Product Manager/Product Owner
• Technical Lead(s)
• All team members involved in delivery throughout
  • Not just who was on the project at the end

Keep in mind that it may or may not be appropriate to do an internal and external project retro separately or combined.

How

It is essential to have an agnostic teammate facilitating (someone uninvolved with the project). Having the facilitator be impartial means they will be able to record things in a way that doesn’t assume a lot of the nuances and context that the project team has—because others who weren’t involved need to be able to understand the takeaways.

• Someone from outside the project should facilitate
  • prompt people
  • record +s and –s
  • encourage participation (not pass judgment or validate/invalidate the contributions)
• Artifact (deck, notes, etc.) produced with key summary points that can be approached and consumed by anyone without project context

The key here is assembling that artifact. I'll talk a bit more about what to do with those artifacts in another post soon!

Sprint Retro Guidelines

Continuing on from sharing some perspectives on sprint retros (see my earlier post), here are some simple guidelines to get you started on running better sessions with your team:

Celebrate what's great

Try to determine what is repeatable and sustainable.

Identify what to improve

Consider what (not who) is detracting.

Who

• Only the actual team members should be included in a sprint retro:
  • The tech lead(s)/developers, designers, etc.
  • The product owner and project manager/scrum master
  • If there are client people who are actively working on the project (contributing to the sprint goal and the increment/work product), they can and should be included as well.

How

• Come prepared with talking points
• Someone from this group (a peer) should be able to facilitate
  • prompt people
  • record +s and –s
  • encourage participation (not pass judgment or validate/invalidate the contributions)
• Try and propose a solution when identifying a problem
• Review past retro points and gauge progress

Remember... Team performance that continuously improves is the result of a team feeling accountable to each other!

A Perspective on Sprint Retrospectives

You've probably been in these meetings and on these calls with your team... "Anyone have anything to bring up?" Crickets... but your project manager can say they ran the sprint retro and move on. This isn't the way things should work and your team will never evolve without embracing this opportunity and substantively participating with courage. I’m going to briefly orient you with what the goals of doing this are—it’s not just a sprint ceremony to check a box on so we can say we’re doing Agile.

Your sprint has concluded and the team has held its sprint review. What we care about now is how the team thinks about working on that increment. Give everyone a chance to step away from the day-to-day and anything chaotic—debrief and decompress… amongst themselves. Feedback that we’re gathering here is from the team and for the team. People on the team are accountable to each other—this is not an external management review of the team’s performance or efficiency.

So with those goals understood, let’s review who we need and how to conduct these. Only the actual team members should be included in a sprint retro. This does not include anyone else—no exceptions. Others might review the output of the retro, but they are not invited to participate. In line with the team being accountable to each other, people need to feel comfortable to bring up concerns without anyone in attendance who doesn’t have an equal stake in what is affecting the team.

How to go about this? Come prepared—I can’t tell you how many retros I’ve been on where nobody speaks up. Self-select a facilitator from the group—they’ll record what is brought up and hopefully encourage participation. When you’re contributing a problem, try and propose a solution alongside it. And, have the previous retro summaries available to you can gauge progress from the previous sprints.

Instead of recording black and white feedback—what was good and what was bad, consider 'do less' and 'do more.' We really want to hold up and celebrate what went great! We want to identify those things that really propelled the team forward and maybe formalize some of them—get to a point where we can repeat and sustain. On the other side, we also want to identify what to improve—and important here to not point out who, but the things that held the team back... What is detracting from the team moving forward? What didn’t work so we can stop doing that thing and try a different thing that might be better?

I'll get into some details of how you can run better sprint retros in a follow-on post soon!