Future improvement starts today

I’ve been a rower for many years. I don’t actively engage in the sport anymore, but I do regularly step on a rowing machine when I visit the gym. During one of my outings, I remembered one principle I used to live by: you can’t expect to improve a single step of the rowing motion and have a perfect stroke at once.

Rowing is a cyclic movement, where you repeat a single motion. Catch, drive, finish, recover, and over again to the catch. You can only make the next stroke count if you execute the current one correctly. If you don’t, you’re likely to have a disbalance in the boat and you’ll discover that the starting position of the next stroke is suboptimal, giving a poorer result. However, if you improve the recovery now, the next catch will be better. For a great catch, make sure you get your finish and recovery right.

Agile development is also characterized by cycles. In Scrum, we have the two-to-four-week iteration that starts with a sprint planning and ends with the retrospective. Many organizations have built large cycles on top – for example, quarterly planning cycles like the program increment events described by SAFe. When improving these, the rowing principle applies as well. Since the cycles follow each other, the improvement you want to make in the next iteration starts in the current one. Today’s improvement will not only help you finish the next iteration with better results but also sets the stage for further improvements in the iteration thereafter.

At one of my clients, we’re trying to improve the quarterly forecasting process. In a scaled environment with multiple teams, this is quite a challenge, and it doesn’t work to try and set up a perfect process at once. Small steps need to be taken.

First, we organized a planning event where the teams predicted what items they would work on (catch). Next, we let them work on it (drive) and demo what was ready (finish). At the end of the first cycle (the recovery), we counted the completed items. As expected, this resulted in some debate on how to count and measure them, but it helped us start the next iteration with a better understanding. This in turn enabled the organization to finish the second iteration with more accurate results and better trust in the measured velocity.

The outcome of the second iteration laid the foundation for the next cycle, where, building on the experience of the previous cycles, two great things happened. The velocity was used to better explain to the stakeholders what they could expect from the development teams. This yielded a better understanding and approval of the targets set for the coming iteration. What’s more, teams started to use the measured velocity. During the feature refinement, they could now better predict what items to focus on. This set the stage for better discussions about solutions and dependencies, which helped to finish more of the committed items.

The story isn’t finished yet and further improvements need to be made. Still, it serves as a nice example of how small improvements made in one cycle enable further improvements in the next. Often it’s not possible to implement a full solution in one go. You need to work toward it, cycle by cycle, stroke by stroke.