Improvement goal

Recently, i attended a training on Kanban. To drive continuous improvement, Kanban has its main or even sole focus on shortening the lead time. I was impressed by results from a couple of case studies shared in the training. This triggered me to think further on how improvement is achieved in Scrum.

Before getting to improvement topic, let's first understand Scrum foundation a bit more. Scrum framework is based on empirical process control, which consists of transparency, inspection and adaptation. Transparency is necessary for your inspection and adaptation, moreover, goals make inspection and adaptation effective.

There are three explicit points for inspection and adaptation built in Scrum flow. They are daily scrum, sprint review and sprint retrospective. In CSM course, we relate empirical process control to Scrum flow. We start with the purpose of those meetings - they are all for inspection and adaptation. Then, we dive deep around the below questions - what goals guide inspection and adaptation? how frequent does inspection and adaptation happen? who's leading it? how do we create transparency? what information is inspected?

Let's elaborate on what goals guide inspection and adaptation.

• For Daily Scrum, it is sprint goal that guides inspection and adaptation. We inspect what happened in the last day and where we are towards sprint goal, then we make adaptation for the coming day.
• For Sprint review, it is product goal that guides inspection and adaptation. We inspect product increment from last sprint and where we are towards product goal, then we make adaptation about what to deliver in next sprint. The product goal is dependent on the context. In the context that you release in multiple sprints, it would be your release goals. In the context that you release every sprint or even continuously deliver your product increments, it would be your product vision and roadmap.

For Sprint retrospective, it should be process goal that guides inspection and adaptation. We inspect what worked well and what to do differently in the last sprint, then, we adapt by experimenting different ways of working in the next sprint. However, the inspection against goal is usually implicit and weak. I call process goal as improvement goal, since retrospective enables continuous improvement. What's the improvement goal? What does the perfection look like? Unfortunately, it's neither defined by Scrum, nor defined by most Scrum teams. The lack of improvement goals makes the inspection and adaptation in sprint retrospective often less effective than it could be.

In practice, the lack of improvement goals leads to lots of shotgun retrospectives. Teams randomly pick up problems to solve and areas to improve. We shall benefit from setting clear improvement goals. I'll share some ideas about what improvement goals could be.

First idea is to learn from Kanban. Lead time is probably the most leveraging point. We set the only improvement goal to shorten lead time. Less is more. We shall start to measure the current lead time and monitor its trend, then analyze and act on it for improvement. Kanban also provides specific tools for that, such as limiting WIP, CFD, control chart, etc. It seems a bit absolute and single-minded to only focusing on lead time, but it indeed has profound impact and will eventually cause improvement in many areas, such as collaboration, infrastructure, engineering practices, etc.

One challenge in using lead time as improvement goal in Scrum is that Scrum uses timebox. In theory, team may work on all items in parallel and get them all done by the end of Sprint, thus, the lead time for all items is the same as sprint length. In reality, this approach involves high risk and is discouraged. Once team tends to work on small items in sequence within the sprint, it could still be useful to look at lead time even if we do timebox.

Besides lead time, there are a few alternatives as improvement goals.

• When your definition of Done is still subset of what's required to be potentially shippable, expanding Done is an effective improvement goal. However, some companies are doing continuous delivery, which is already beyond Done at the end of sprint. For them, this is already reality, rather than improvement goal.
• Team visioning to come up with improvement goals for longer period of time, which guides sprint retrospective. Team radar exercise is a way to monitor its improvement progress.
• Velocity, which should be used with much caution. In a way, it's the equivalent of lead time in timebox. Through improving the flow, lead time will be shortened, while throughput will increase. However, since there's "easier" way to get improvement on velocity - by inflating the work size in story points, it is less effective than lead time itself in teams of creating real improvement focus.

In summary, establishing improvement goals is essential for the effective inspection and adaptation in sprint retrospective. It is worth looking at how Kanban drives improvement by relentlessly focusing on lead time.