How to strengthen your agile heartbeat with powerful retrospectives

323 readers like this.
Two different business organization charts

Opensource.com

If you work in an open organization for any length of time, you're likely to hear someone mention "sprints" or "heartbeats" at some point. Understanding these terms is simple: Take a big goal, then break it into small pieces that help you get there.

The practice derives from agile development and its various (funnily-named) flavors like "Scrum" and "Kanban", but the underlying logic is simple: Break big jobs into small time-bound sprints, then design a process and ritual for unpacking:

  • what you accomplished in the last sprint
  • what you learned from it
  • what you're going to tackle in the next one

From "sprints" to "heartbeats," finding a healthy cadence

Many of us have found that replacing the word "sprint" with "heartbeat" is helpful for explaining the value to new colleagues. It implies a steady, healthy cadence or rhythm—as opposed to endless "sprinting" or panting against a series of arbitrary deadlines.

Heartbeats can create a great sense of purpose, and ebb and flow in your team. They can be set to any length—a week, two weeks, a month. It's really just about bringing people together in a regular, predictable cycle, with a ritual and set of dance steps to ensure everyone's on the same page, headed in the right direction, and learning and accomplishing important things together. (As opposed to the "make it up as you go along" / gazillion emails and meetings / Bataan Death March of Multi-Tasking that gobbles up most projects by default.)

"Too busy to think"

A big reason people love working in heartbeats is that it makes work more mindful. It invites or even forces regular moments to step back, reflect, adjust your goals, and share real insights with colleagues that don't typically fit in the hurly burly of email and status updates. That process is generally called a "retrospective"—and lately I'm finding it to be the single most valuable parts of the process. Done right, it can help you work smarter instead of harder.

BUT: retrospectives are also often the most neglected or easy part of the process to skip over—especially for time-starved teams already suffering from Too Many Meetings Syndrome. Here's why great retrospectives are one meeting you don't want to skip.

A regular ritual for reflection

A retrospective at the end of each heartbeat helps you unpack what you've accomplished and learned together, and where you might want to improve together in the next cycle. They can be dead simple; at the end of your heartbeat, just ask each team member to share:

  1. What went well in the last heartbeat?
  2. What could have gone better?
  3. What do we want to improve in the next heartbeat?

Good retrospectives generate surprises

I find that when I'm part of a great retrospective, I leave the meeting feeling surprised. I leave knowing something I didn't know going in. I've had my perspective shifted in some way—particularly around what our priorities should be in the next heartbeat, or a key learning someone shares that helps me spot a new opportunity.

In particular, retrospectives can help to:

  • Re-prioritize stuff that seemed urgent a week or month ago but doesn't anymore. That's great! Let's consciously de-prioritize or set it aside. By the same token: Little things that didn't seem important suddenly reveal themselves as highly leveraged in the week or month ahead, little keys or springboards that emerge out of the haystack.
  • Punt! What can we push out to the next heartbeat, so that we can narrow our focus in this one? Retrospectives make you more conscious of time and the value of phasing. Not everything needs to be done all at once; it's liberating to push stuff out. If it's not on this train, it'll go on the next one.
  • Do less work! Yes, I said it: Great retrospectives should help you do less work. Less work means faster, better work. Eliminate the clutter and distractions that grow like weeds around your team's feet; it's amazing how good that feels—and your teammates will love you for it.
  • Unpack learning. You're learning great stuff as you go that you didn't know when you started the project. Retrospectives are a chance to share and write this stuff down. Without a regular ritual or invitation to do so, this usually slides to the bottom of everyone's to do list. But these are valuable diamonds and nuggets you don't want to slip away.
  • Pull up. Good retrospectives invite altitude adjustment. Go back to your original strategy / roadmap and remind yourself what you said was important. The stuff that actually matters, as opposed to just being "busy." How are we doing? How has our thinking changed? How do we re-connect our big picture goals to day-to-day tasks?
  • Re-energize. Feel proud. Most of us walk around feeling guilty and stressed about how "behind" we are. Retrospectives remind the team that, no matter how imperfectly, you really are accomplishing and learning a lot together. You're not just hamsters on a treadmill.
  • Continuously improve. Get better at getting better. Small improvements add up to powerful change over time, like compound interest. You don't have to move mountains; just feel the trust and momentum that builds after your team makes an agreement and actually sticks to it.

Bland retrospectives become boring status updates

On the flip side, bad retrospectives or heartbeat meetings start to feel like a waste of time. They become rote, and more like status updates, as opposed to really stepping back and doing some fresh thinking together. This becomes a vicious cycle; there's less and less value, so people start to question their purpose. Eventually someone says: "Should we just cancel these? We have too many meetings already."

Some common pitfalls:

  • Not enough time. Everyone hates meetings, so it's easy to make heartbeat meetings too short to do real retrospectives. Or to just skip the retrospective piece altogether. But, this should be the one hour every week or month you invest to save dozens or hundreds of mis-spent hours going forward!
  • Not enough trust. People are afraid to say what they really think in front of colleagues or leaders. Or it becomes a defensive exercise to prove that everyone is "busy." Busy is the new bored.
  • Bad or no strategy. When the strategy is bad or the goals are unclear, retrospectives can just end up exposing that fact over and over again. In a healthy project, that's good! It surfaces something you can fix. In an unhealthy one, it just repeatedly pokes the elephant in the room.
  • Agile without agile. Every organization says it wants to be "agile" nowadays, but most don't mean it. You can't "do agile" without retrospectives, or some ritual for re-prioritizing. It's like doing archery without the arrows.
  • Hopeless over-capacity. Many organizations have no shared view of the work they've committed to doing. Consequently, they're hopelessly over-committed. They're drowning in work they'll never really get done, and have no meaningful way to prioritize. Working in heartbeats and doing real retrospectives can help; but only if they start to whittle down workloads. Otherwise, they just remind everyone how screwed you all are—and that's not fun.

What's working for you?

I'd love to hear about your own experiences with heartbeats, sprints and retrospectives. What's working? What secret tweaks or process improvements have you made? How do you tell the story to colleagues who are new to agile? How do you keep the process fresh? Let me know at @OpenMatt or using the #openorg hashtag.

This article is part of The Open Organization Guide to IT culture change.

User profile image.
Matt Thompson (@OpenMatt) is the Director of Program Management at the Mozilla Foundation. He's currently working on an interview series and open book in progress called Working Open, gathering strategies, hacks and case studies about inspired teamwork and collaboration.

2 Comments

Have you read the Retrospectives book by Larsen & Derby? Great suggestions on how to keep retros fresh, and to plan a retro specific to various issues. E.g. Timeline retrospectives if you're reviewing a whole release, or working with a team recovering from a waterfall death march.

Be careful about focusing too much on sprint plans or release plans (backlogs). This isn't a sprint review, backlog grooming, or planning session.

I describe it like this: each team has two products, or systems to improve: "The Product," and "The way we build the product."

Retrospectives are mostly about the latter.

No not yet! Just ordered it -- sounds like something I should read. Thanks for the recommendation!

I like that emphasis on both the "what" (the product) and the "how" (the way we build it.) A colleague also recently turned me on to the importance of "why," which I'm finding to be an effective way to start -- always begin with a shared sense of why we're doing the work in the first place.

https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action

In reply to by Rob Myers (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Download the Open Organization Guide to IT Culture Change

Open principles and practices for delivering unparalleled business value.