Not "Go And See": Come And Listen!

In the world of lean thinking there is a dose of healthy skepticism about numbers and reports. Taiichi Ohno, the most prominent of the creators of the Toyota Production System, was known to put the papers away and instead say: "Let's go and see for ourselves!"

Going down to the shop floor, the gemba, the place where value is created (and sometimes wasted), is to actually grasp the current situation and understand what is going on. Down there, anchored in reality, Ohno-san could tell the people what to do based on what he actually saw happening.

Now, where is the gemba in a knowledge factory, for instance a group who is developing changes in a digital service?

I have seen offices where "lean experts" from the factory floor has tried to apply the tools of the factory on what they believed was the knowledge factory gemba: the desks, the meeting rooms, the copier machines and office supplies.

That is of course ridiculous (and the result more so) since knowledge work isn't about shuffling papers around on a desk or having meetings. Knowledge work happen in and between people's brains. The gemba is the conversations between the people participating in the work of gaining mutual understanding of needs and how to meet them using digital tools.

We sometimes try to adopt the lean principle of visual management when we do service development. Scrum and other agile practices has borrowed the idea of the kan ban, visualizing the workflow maybe on a board so that we can see where we get stuck.

Sometimes managers, in the spirit of Toyota, wants to go and see what is happening on the "factory floor". If there is a kanban-board available, there is where they naturally will go. And sometimes ask: "What does the board tell us?" "Why can't people create visualizations of their so called 'work' so that we understand?" "We need to tell them what to visualize!"

The thing is that the kanban board, or any other visualization tool such as Jira or Trello, is not the gemba!. It is not the place where work happen!

The work happens in people's brains when they have a productive exchange of thoughts. In the conversations. The visual aids we might use are just aids for better conversations and collaborations.

So, if you are a manager assigned to help people doing knowledge work, please understand this:

It is NOT about "go and see"!

It is all about come and listen!

And share. And participate.

Scrum Hack: Rolling Wave Instead of Sprint

As those of you who have attended my workshop in agile planning know, you can talk about planning in two dimensions:

1. The percentage of your capacity you want to allocate to planned work.
2. The planning horizon: how far ahead in time you want to allocate that capacity.

The Scrum Guide implies that a team of developers will allocate 100 percent of its capacity to planned work, divided between implementation of backlog items that the team thinks are ready for development, and refinement activities where the team makes sure that the upcoming backlog items will be ready for development in the future. The planning horizon is a sprint: a regular period of at most one month.

However: the nemesis of all planning is that pesky little thing called reality. During a four week sprint, there are many things that can (and will) happen, so many teams feel that they have to shorten that time. Sprints that are two weeks long have therefore become popular even if it is hard for many to actually deliver value in such short time.

But since reality happens even during two weeks, you might feel the need to replan in the middle of the sprint. And this is where the rolling wave can start to happen if you let it.

When mid-sprint replanning becomes a regular necessity due to circumstances beyond people's control you may ask yourself what planning horizon you should have. Of course you need to replan the rest of the sprint (the last week), but can we say something about the future? The coming sprint?

(The replanning is by the way often conducted directly after daily stand-up monday morning in the second week of a two week sprint.)

The last week we learned that it wasn't wise to allocate 100 percent of our capacity to planned work. Maybe 80 percent is more realistic, so let us do that for this week too. And what do we know about the coming sprint? Maybe we can see the need for like 50 percent? At least for the first week, we know actually very little about the second week of next sprint. Maybe we for the second week of the next sprint can think of work worth about 20 percent of our capacity.

The week passes and it is time for sprint planning for the next sprint. We have already planned for 50 percent of the first week of the next sprint, and 20 percent of the second week. Let's just add some more insights to that plan so that the first week of the sprint becomes planned to 80 percent and the second is filled to 50 percent. (And maybe also look ahead for the coming two weeks after that but not more than like 20 percent of the first week and 10 percent of the second.)

Shouldn't we aim for filling both weeks of the sprint to 80 percent at sprint planning? No, we can't predict the future anyway. Let's keep it planned to 50 percent. We know that we will have a replanning event in a week anyway.

TADAA! The rolling wave is formed. Sprint planning becomes basically an adjustment of the rolling four week forecast that we polish continuously. We can still have our reviews and retrospectives every second, third or fourth week if we want to, but we have a more flexible planning practice in place that in many cases can accommodate the natural variation of development better.

Scrum Hacks: Scrum Buts or Scrum Ands?

There is a tension between the need for adapting a known and proven collaboration framework, and the need for said framework to be allowed to do its job.

I have during my ten years of agile, the last five years as a full time mentor and coach, seen countless of "Scrum" implementations where they had removed everything they found difficult and hard, and therefore didn't achieve what they wanted to achieve.

On the other hand: I have also seen numerous agile collaborations where they applied just the tools they needed at the time, tools that also can be found in different frameworks such as Scrum, but together with other tools and ways of working. And it has been working just fine.

I have during these same years only seen Scrum being run by the book (The Scrum Guide) once. Most of my clients work in environments where the implicit preconditions of Scrum doesn't really apply. So they have to adapt in order to get work done.

Adaptions of Scrum are sometimes called "Scrum Buts" since they are described with the words "We work with Scrum, but...". I think that's appropriate for cases where the organization takes away the things that drive good change and thus never achieves what they have set out to achieve.

I suggest the term "Scrum Ands" for the cases where your situation calls for a slightly different set of tools than what is provided in the Scrum Guide. For when you inspect and adapt the framework, in a way that gives you better outcome than the alternative.

The result of your toolset hacking will not be Scrum, of course. Scrum is defined in the Scrum Guide. Any deviations might be useful, but it will not be Scrum.

However, since Scrum contains most of the elements you need in order to make your collaborations more agile (organizational capability to prioritize, collaborate on value creation in self organizing teams, daily synchronization between people, clarity on what is ready for implementation and what is done, continuous improvement etc.), and since the framework is pretty well known, it can be a good idea to present your ways of working as your own twists to Scrum.

I call them Scrum Hacks. Distinct ways of collaborating that replace or complements existing ways of working in the framework. Like the idea of having retrospectives either more frequent or less frequent than each sprint. Or the idea to plan only one week at a time. Or having an ongoing Scrum meeting in digital channels instead of the daily fifteen minutes standing in front of the sprint backlog.

As soon as you start experimenting with Scrum Hacks, the result isn't Scrum. It can make your outcome worse. But it can also make it better. Reflect on why, and share your favorite hacks with your friends in the community. Let's build a catalog of proven Scrum Hacks that explains under what circumstances they have improved our lives.

What do you think?