Continuous Improvement

Picture this: It’s another exciting day working on a scrum team. You’ve had a productive sprint, but you have some room to grow. You acknowledge the things that are going right and wrong with your team during your Sprint Retrospective. One of the positives is that your team has achieved all of the continuous improvement action items that you outlined during your last Retrospective and Planning meetings. You leave your retrospective refreshed, reinvigorated, and with a few more of these action items that you plan on pulling into your Sprint Backlog.

Flash forward to two weeks later. You’re still just as excited about working in this agile environment, and are headed into another retrospective. Once again, through honest team introspection, you notice that there’s a mix of good and bad things that happened during your last sprint. You’ve made more gains by completing the planned action items for the current sprint. However, someone on the team recalls that two sprints ago, you had identified that your communication with another external team was one of your improvement goals. You achieved this improved communication during the adjacent sprint, but it fell off in the current one. Completing these action items was how you and your team were supposed to be improving (not just for the sprint, but for all of time!). What happened?

When Simple Action Items Aren’t Enough

Ostensibly, we want to improve our execution in general, not just for the next sprint. So why do action items last for only one sprint? I can think of a few solid reasons:

  • Getting an action item “done” looks good, feels good, and fits with our conception of getting work done in sprints.
  • We want to be able to pull in new action items to continue to improve based on our most recent analysis of where we are on our journey to becoming a high functioning team.
  • We don’t want to overload the team by having many action items in progress at once - a recipe for getting nothing done.

These all seem like good reasons to not break the mold of having improvement action items constrained to the sprint container. So how can we get better? How can we make improvements that stick, instead of just crushing whatever is right in front of our face/whatever has been brought up most recently?

Crafting Your Own Habit Based Action Items

The good news is, there are a few simple tricks that we can use to improve our retention of positive outcomes via building effective habits. The bad news is, we have to get in the habit of doing them!


“The four stages of habit are best described as a feedback loop. They form an endless cycle that is running every moment you are alive. This “habit loop” is continually scanning the environment, predicting what will happen next, trying out different responses, and learning from the results.”

-James Clear, Atomic Habits


There are four parts of every habit. Here they are listed in the order they occur in the human brain.

  1. Cue
  2. Craving
  3. Response
  4. Reward

In a weak version of continuous improvement focused only on completing shallow action items, we are still going through this process:

Cue - Action item is identified during a retrospective and pulled into the sprint backlog during our sprint planning.

Craving - We want to get as much as we can done from our Sprint Backlog during the sprint.

Response - We focus on the action items we’ve agreed upon for the sprint.

Reward - We accomplish our goal! Kudos!

At this point, we can see that we have a reward system/habit built around accomplishing action items during our sprint. This is an excellent step towards improvement. If our action items are particularly geared towards building better habits, these improvements will more readily stick around. Can we somehow hijack this proven habit/reward cycle to improve our outcomes? By adding a little bit of preprocessing for our action items, we should be able to make the related improvements last far longer than our current two week iteration.

Let’s consider the example from earlier; we want to improve communication with an external team. Maybe you extrapolate, and your action item becomes: Amy will call Dave on Tuesday in order to discern how we can be proactive in resolving some inter-team dependencies. This seems achievable, and it was. Amy called Dave that Tuesday.

A small step towards building a habit that will stick around would be something like: Amy will call Dave every Tuesday. This sounds like a good action item, and even has implementation intentions listed. A specific person is called out, with a time in mind to accomplish the task. But then what happens when Amy is out Tuesday? Or if Amy forgets?

Habit Stacking


“One of the best ways to build a new habit is to identify a current habit you already do each day and then stack your new behavior on top. This is called habit stacking.”

-James Clear, Habit Stacking


Sticking with our running example, let’s consider how we can attack our communication problem with habit stacking in mind. Perhaps we can schedule a five minute call with this external team every day right after our daily standup. This is an easy, achievable goal that builds off our our current process, as we are already functioning within the Scrum Framework. If this is too frequent, or too short of a window for the update call, we can easily flex to adjust and compensate. The important thing is we are starting to build a habit around this communication. As it becomes a part of our process, we’ll have less miscommunication and lingering dependencies on this external team.

We can leverage this concept for more technical action items as well. As a developer, I frequently commit code to shared repositories with various style restrictions that are unique to the teams I work with. A related improvement item could be - I will ask coworkers to review my code more often. Now, I know that I eat lunch every day around noon, and come back to work at my desk directly after. An improvement item built around habit stacking would sound like - When I sit down at my desk after lunch, I will immediately ask a team member to review the code I’ve written in the last 24 hours.

Gateway Habits

Adopting new habits is no easy task. In order to start something new, you must proactively ignore your currently accepted habit/way of doing things. With this in mind, starting small with a gateway habit can be extremely valuable in our pursuit of continuous improvement.

If asking for a code review everyday sounds like a lot of hassle or might produce more mental friction than you have energy for, never fear! You can begin a new habit by trying something out a few times, and flexing upward. Asking for a code review once during the week is a lot less effort than doing it every day after lunch. If you’re seeing the value in the activity, it should be natural to start doing this more frequently after you have a baseline. If you add a habit that doesn’t have value, you can also easily scale it back. Remember, when we’re working in an agile environment, empiricism is key. We should always be running improvement experiments and reflecting on their usefulness.


  • Look for places where you can build an action item into your work routine instead of just solving a problem once and then tossing the solution aside.
  • Try to find obvious cues in your work to help you build new habits.
  • Don’t be afraid to start small!


Get your project started today

Get in Touch