Let’s talk about Waste


This is a follow up on a previous post where I talked a bit about how the way our work works is inspired by Lean principles. In this post we shall look into the concept of “Muda” i.e “Waste” and how we address this in our shop.

Ten sources of waste:

1. Extra features

What is it, and why is this a problem?

This particular kind of waste can be defined as a lack of rigor in the value definition process. This is when features are added to a release, which results in a bloated scope, increased complexity, increased maintenance and a delay in the delivery of value to the customer. This is particularly troubling if there’s no real indication that anyone out there actually want’s to use that feature that is allowed to slow us down. The old YAGNI (You ‘Aint Gonna Need It) acronym comes to mind.

How do we address it?

The battle against this start early, in the idea stage of our process. The light weight opportunity assessment that everyone who want’s anything done is required to fill out, has a question regarding how the champion of the value imagines that the proposed value can be separated into smaller releases, and to give some thought to what might constitute a Minimum Viable Product (MVP). As work moves along, we do our very best to question absolutely every item of value that is proposed to be part of a particular release. If it’s not necessary, it’s out.

2. Partially done work

What is it, and why is this a problem?

When a team spend time doing awesome stuff, and then stops doing awesome stuff to do some other stuff, and puts the awesome stuff on the shelf for some inexplicable reason, no value has been delivered to the customer at all. Zero. As the value lies there on the shelf, it rots. The window of opportunity shrinks by the hour.

How do we address it?

Our WIP-limits, together with definitions of done in each work state and acceptance criteria, is meant to take care of this problem for us. I’d be lying if I said it’s fool proof. Sometimes external dependancies (reality) breaks our system (theory). This is usually just life happening, I’m afraid.

3. Relearning

What is it, and why is this a problem?

When team players have to jump through hoops in order to get their head in the game regarding work, we’re in trouble. When partially done work, as mentioned above, is allowed to lie dormant, there’s a lot of relearning going on when the player picks it up again after while. There’s also the trouble that specialists can emerge, who suddenly find themselves rather alone in their specific area of competence. When this happen, you can almost hear to sound of risk building up.

How do we address it?

This is a problem for us. We try to rotate people, but as we are operating close to capacity, we have not been able to share knowledge to the extend that I would have wanted. This particular aspect of waste collides with our ambition to let people follow their passions as much as possible, and of course this sometimes creates specialists. I think we have to let that happen. Even so, we are putting in counter measures to balance the situation a bit better. And I trust we can get our act together on this soon.

4. Handoffs

What is it, and why is this a problem?

Each time a person does some work, and then hands it off to someone else along the value stream, information is lost. It’s like the game “Chinese Whispers”. This will cause a delay as it will lead to relearning.

How do we address it?

I’ve found that the hand off between “person who want’s something done” to “person explaining to someone else what the other person want’s to get done” is the worst kind of hand off. This is the stakeholder – product owner – product developer mess. That’s why, in our line work, it’s the responsibility of the person who want’s something done to write their ticket following a few simple rules, and sign their name on it. When our product developers are ready to pull that particular ticket, the developer has a conversation directly with the person who made the request. And those involved work together to make it happen. The same thinking is guiding our cross functional team who do what we call “theme work”. The team in question is responsible for the entirety of the value delivery, all across the finish line.

5. Task switching

What is it, and why is this a problem?

When people working with advanced problem solving find themselves in the zone, any disruption will force them to retrace their steps and rekindle their line of thought. This causes problems.

How do we address it?

The obvious answer is our adherence to WIP-limits, and we try really hard to keep task switching to a minimum. It still happens more than I would like, though.

6. Delays

What is it, and why is this a problem?

Delays that can be avoided are a problem. Avoidable delays include waiting for decisions, or waiting for another department to finish their part of the value delivery process.

How do we address it?

Working across functional silos in cross functional team takes care of the “waiting for another departement” problem rather well. We also work hard to push as many decisions as possible to the front line. To the skilled people in our Product Development Team. Delays still exist, though. There’s more to be done to improve this.

7. Defects

What is it, and why is this a problem?

Defects kills trust internally and externally, and it creates a lot of re-work.

How do we address it?

We have chosen to do the hard, but right thing, and attack the largest source of defects that we have, at a root cause level. Capacity have been allocated to extensive platform work. We also have a “code review” step in our process, which means that code must pass the eyes of at least two developers. This practice continuously catch potential defects before they are out in production.

8. Frustration

What is it, and why is this a problem?

Frustration is energy directed towards problems, not solutions. These negative emotions risk spreading in the group, and they can kill initiative, enthusiasm and general happiness.

How do we address it?

We try to address any frustrations during our retrospectives and turn the frustrations around towards the desired end state. The questions “Well, how would you like it to be?” or “How would you like that to work?” are often heard during these workshops. The outcome is potential solutions that we monitor using our change board.

9. Extra efforts

What is it, and why is this a problem?

Extra efforts is anything we do that does not bring value to our customers, internally or externally.

How do we address it?

We try to keep administration to a minimum, and we work to keep meetings short, productive and sweet.

10. Unused employee creativity

What is it, and why is this a problem?

This is basically the coder – developer – product developer evolution. Not making the most out of the many ideas, insights and creativity that we have in our team would be utter madness.

How do we address it?

People who believe that it’s their job to write code will not feel at home in our shop. There are no “code monkeys” in our team, there is no such thing as “just a developer”. The mindset we try to cultivate is rather one where everyone is a Product Developer. These efforts begin in the recruitment process, where we hope to see this mindset in our recruits. The whole team is included in discussions regarding product strategy, how to organize and how the work works. Trust is high, and the fact that we allocate 25 percent of our time to our product developers own initiatives proves that we put our money where our mouth is.

So, this is how we work with the concept of “Muda”. Mind you, I almost never call it “Muda”. I  don’t even call it Waste. And I don’t talk about what we do as “Lean” or “Agile”, if I can help it.  I just call it work.

 

 

Leave a comment

Your email address will not be published. Required fields are marked *