Prioritise continuous process improvement with customer work?

Question

I'm reading about Toyota Kata and am impressed with the approach of continuous improvement of the process through constant experimentation toward a target condition.

What I haven't yet found anything about is how to handle this from a scheduling perspective.

The Toyota Kata approach is, of course, useful also for regular customer value creating sprints. But I'm interested in taking a more principled approach also to development process improvement.

It seems like a bad idea to put the same people on both a customer value creating sprint and a process improvement effort (since their attention then will be divided between what's practically two different projects). It seems like a bad idea to allocate particular sprints to process improvement too -- then it's not really continuous.

How do others approach this? I have some more ideas myself but don't want to bias any answers.

Edit to clarify some misunderstandings: I'm not talking about small problems we encounter and fix along the way. Those we're pretty good at. What I'm thinking about here is setting up a target condition towards a challenge and then deliberately and actively taking time to experiment toward that target condition.

Concrete example: wouldn't it be nice if we could do continuous delivery of this legacy product? That's a bigger project and taket a lot of experimentation, and is not just something one gets out of the gay as part of regular fixes of smaller annoyances.

Answer 1

If you are reading about Toyota Kata, then you probably also stumbled upon Kaizen. Kaizen is about "changes for the better", even tiny improvements (but with time add up an start making a big difference). You can also use it as an effective personal development method. One big change might seem scary, the goal intimidating perhaps, but making very small steps in the direction of your goal is not as hard or daunting. So, with Kaizen, you can ask yourself, "what's the smallest step I can take or the smallest thing I can do right now to improve on what I'm doing?".

You ask yourself this every day, or every time you find some problem, or inefficiency, or waste you want to eliminate. You think on something to change, you act, you observe the result. If it's working keep doing it, if it was a mistake, correct it. With time, it adds up. This is in tune with what Agility means:

• Find out where you are
  
• Take a small step towards your goal
  
• Adjust your understanding based on what you learned
  
• Repeat

From your question you seem to consider such a process a large effort that takes up time from customer value creating work. Sure, you can have workshops, meetings, larger goals that you might need to spend some more time on, but it doesn't need to be like that. Small daily reflections and tiny changes don't register much on a sprint duration for example, but with time they can create a lot of positive change. And the total time they add up to the work, you often take back by doing your work more efficiently and being more effective.

In Scrum for example, you have a Sprint retrospective where you reflect on your work and try to introduce improvements. This isn't only about the work itself. This is mostly about the way you perform that work. Scrum prescribes this meeting to tell people that they should pause to reflect on what they are doing, or otherwise people might be focused so much on the work that they might neglect to find ways to improve it. For example, it takes discipline to do Kaizen. To do the work but also think about the work while you are doing it.

Read more into kaizen and how to apply it in your development process. And remember that you need some slack in your process to be able to inspect, reflect, and adapt. If you fill all your time with work, you will do the work in the same way forever, which might be OK if you are lucky, but maybe not.

EDIT after question being changed:

Edit to clarify some misunderstandings: I'm not talking about small problems we encounter and fix along the way. Those we're pretty good at. What I'm thinking about here is setting up a target condition towards a challenge and then deliberately and actively taking time to experiment toward that target condition.

As I mention in my comment, you need to look at your process from a different angle. Right now you don't have room for working on various goals because you are prioritizing the work for customers and are trying to optimize for resource optimization (which is a myth) when you should be trying to optimize for outcomes.

If you want to work towards some target to improve you process, then you need to take the time. Process improvement is important for a whole bunch of reasons, it's not subordinate to work you do for customers. It's then a matter of planning this effort just like you plan all your other work.

Answer 2

I don't think it's the right approach to think about it as "customer value-creating work" and "process improvement work". You do the process improvement work to improve the quality, efficiency, productivity, or some other aspect of the "customer value-creating work".

For anything larger than the "just fix it" types, allocate a percentage of the time to fix that and build it into your iteration planning. For a specific example, consider Scrum, where a chunk of the Development Team's capacity is allocated for Product Backlog Refinement. Allocate some chunk of time, either as a percentage or as a fixed segment of time, for the Development Team to perform process improvements. The team may not need that time but should always consider it when planning.

However, I'd also suggest that not all improvement can be carried out as small, continuous changes or kaizen. Sometimes, you need to make fundamental changes to the process or the system. This is called kaikaku and does need to be planned. However, the same way of thinking applies - by focusing on the improvement, the customer value-creating work will somehow be better in the end and the improvement will, over time, pay for itself.

Looking at your example, if you have a legacy product and want to move to continuous delivery, that could be a kaikaku improvement. But what if you decompose it? What do you need to achieve continuous delivery? First, you need continuous integration. What do you need for continuous integration? Automated repeatable builds. That can be a kaizen. Then, you need automated tests. You can slowly build up automated tests. You probably want a CI server, so stand one up or configure one - that's another kaizen. If you break the work down into pieces that can be done in a day or two by one or two knowledgeable people, you have a series of kaizens.

There is also another opportunity - a kaizen burst or kaizen event. In my experiences, this is a longer session (3-5 days) where the team can identify a series of kaizens that, if implemented and successful, would make the desired change. It may also highlight the need for kaikaku rather than kaizens. However, this is also something that would need to be scheduled in advance.

If you are using Scrum or another framework with short iterations and frequent retrospectives, you may be able to fit something like a kaizen event into your Sprint Retrospective. Each Sprint, you would be able to take on one kaizen and then, at the next retrospective, evaluate its effectiveness and select a new one.

Answer 3

Both of the answers I've gotten so far have been really good, and I wish I could accept both. The Value Stream Mapping book by Karen Martin and Mike Osterling bring up that the plan to get to the desired future condition tends to consist of three types of countermeasures (paraphrasing very freely, now):

• Just-Do-Its, which are simple things that require no coordination and can be done the same day, if time permits.
• Kaizen Events, which are slightly bigger changes that might need some coordination or data gathering first. These are then planned to happen during the next Kaizen Event days.
• Projects, which are the even larger changes, which make sense to plan as any other project well ahead of time.

I was trying to cast all continuous improvement efforts into one mold, which – in hindsight – is ridiculous.

The good news is that our team has room for all three of the above events.

• We do have a little bit of slack to handle Just-Do-Its as part of our regular day.
• We do have improvement weeks planned regularly where we could easily do the slightly bigger tasks.
• We have the capacity to occasionally plan larger improvement projects alongside customer projects too.

I was picturing having to allocate so much slack into our regular work that we could deal with bigger projects in that spare time, which is probably not practical (since it could amount to a lot of time, and divided focus.)

But it's also important that continuous improvement is not constricted to only the improvement weeks or special improvement projects, for obvious reasons.

My question was very confused from the beginning, and I'm very happy you had the patience to answer and guide me along the right track. Thank you, again.