Overview

Grio has adapted the Agile methodology to our consulting business; and one of our most valued “ceremonies” is the retrospective. We keep these meetings open to all, and the notes from these meetings are in a shared folder for everyone at Grio to read.

Despite having access, I found them “gathering dust” so to speak, and decided to dig through the entire folder to track Grio’s ability to implement the changes proposed and avoid the pitfalls of previous projects. We’re genuinely asking ourselves, “Are we serious about learning from mistakes?”

I’ve explored the overall process of my research here, and have presented the findings in depth to our entire team. There’s some good news, and some work to do; but we’re happy to see that our efforts have created tangible benefits to our team, our clients, and our bottom line.

We’re asking ourselves:

“Are we serious about learning from mistakes?”

Evolving

Underlying the entire retrospective process is a desire to improve upon outcomes, job satisfaction, and client retention. Grio has evolved the retrospective process dramatically over the time, and even in my relatively brief tenure at Grio. At first, we would hold these meetings only at the end of a project or major deliverable. These broad-scope conversations were helpful at surfacing thematic issues in the project, but were not as effective when projects ran over a couple months.

It was suggested, very likely in a retrospective meeting, that we increase the frequency of these conversations. Each project and client has different needs and teams, so we experimented with a few options. One option was to have a retrospective upon feature release; this increased the frequency, and enabled us to apply lessons immediately to the next phase of work. With this tighter feedback loop we found ourselves improving projects measurably.

Around this time, our PM group all attended a CSM course as a refresher, and as a way to spark some conversations around how we have applied Agile methodology to our business model. One of the notable outcomes was a serious conversation within Grio around how to move closer to the Agile process of holding retrospectives for each sprint. We typically run weekly sprints to keep clients frequently updated on project progress; we discussed the merits of longer sprints, and more frequent retrospectives.

Exploring tradeoffs of each option, we decided to stay firm on weekly sprints, as they are central to our collaborative relationship with our clients. In particular, small projects can drift off course in days, and a longer sprint would increase risk on all sides. With that in mind, we decided to increase our retrospectives from feature-release to bi-weekly. Now we’re running lighter, let painful retrospective meetings, and we’re learning at an even faster pace. At the same time, we haven’t introduced too much “process” (read: meeting time) into our workweek.

The Template

We use the same template for all retrospectives, which made the overall analysis extremely easy. We introduce this concept to new team members in the course of their first project, and it quickly becomes second nature to everyone.

We keep careful meeting notes (the PM is in charge of this) and typically we’ll tag each line of feedback with the initials of whomever is speaking. This enables us to look back at old feedback and get into the right mindset, and have context for the feedback, or the ability to identify communication patterns.  

WWW – What Went Well

This may seem obvious, but it is a critical step. One of Grio’s values is that we have fun in our work, and a retro is not just a time for us to “eat our veggies” and learn from mistakes. When an individual or team does something above and beyond the tickets in the backlog, this is the time to make note. Small victories that make the client happy, or small improvements that make our work easier should be highlighted so that they can easily be repeated.

This has the knock-on benefit of starting off the conversation on a positive note, reminding us that we’re all on the same team. Even when things are going sour, try to extract something that did go right, but don’t force it. “We all came to work this week” is not WWW.

WWP – What Went Poorly

It is critical to be open and honest about what isn’t working on a project. Frank discussions about the failures themselves (not the people) are the essence of a retrospective. Everyone’s opinion must be treated equally, there is no room for hierarchy in this forum. When people disagree on WWP, there’s something to be discussed and learned. It is also essential to remember that this is not a forum for personal attack; the goal is to assess the project’s health and the process, not management/HR issues.

The best feedback for WWP is feedback that is specific and can lead to actionable notes in the all-important next section. It’s fair to say “I don’t like the project” if that is how you feel, but it would be far more valuable to comment on the actual source of the feeling. Was the project inherited with problems? Was communication a challenge?

WTDD – What To Do Differently

This is where it all comes together. Sometimes a WWW note becomes codified in our process, to be carried into other projects. As an example, one of our team’s development environments assembled for (what turned out to be) a smooth running project has become a part of our on-boarding process and kickoff checklist.

Make sure that the focus of the retro is in the WTDD section. Whether you’re teasing out victories or deconstructing failures, the whole activity is only valuable if the conversation expands outside of the room and permeates the rest of the company.

How It’s Done

The primary advantage of the biweekly retrospectives is the stickiness factor; with the added benefit of a much lighter meeting structure. With longer intervals, feedback quickly devolves into generalizations and broad strokes; this feedback has a tendency to be more personal, as opposed to work/process/outcome based.

As before, we keep all of these notes in shared documents that are accessible to all Grio staff. Each week, after standup, the team will pull up the shared file and our PM’s will first walk through the “What To Do Differently” notes from the previous weeks. We hold ourselves accountable on a regular basis, and avoid lessons from falling through the cracks. If a suggestion has been applied, we can mark it off the list, if it has not, it stays. We’re always striving to keep the list of WTDD short and manageable.

The reason these lessons stick is that they feel more real; for example: pain felt in a call on Tuesday is discussed in a retro on Friday, and a concerted effort to address the issue is in place by the following Monday. With little time for that pain point to fester, the team and the client perceive the change as a nudge, as opposed to a “corrective action.”

The most important part of our culture at Grio is the constant pursuit of learning and self-improvement. We strive to raise concerns early, and address them quickly; this is facilitated by a number of processes that we’ve developed since the first project nearly 10 years ago. Whether we’re learning new languages, adopting new tools, or asking new questions, we’re always focused on ways to make our clients, and our team happier and more efficient.

So, are we serious about learning from mistakes?

We think so…