pmStudent

Waste.

There is almost nothing I despise more.

Muda is a Japanese word meaning waste; activity that does not add value.

Why would you do such a thing?

Why?

“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.” ? Peter F. Drucker

Shoveling Muda

For a long time now corporate offices have been intent on efficiency, on productivity. We have been shoveling value littered with muda, in some cases mostly muda.

We have been focused on getting better at shoveling. More efficient shoveling is the only way to get more done, right?

In our current mindset, yes. If you aren’t able to change the content of what you are shoveling, you are doomed to go on shoveling a mix of what’s valuable and a great deal of what’s not. We bring in machines to automate the shoveling to make it go faster. Sometimes this means even more muda seeps into the mix, but we’re moving more tons per hour so it must be good.

And then we use our fancy tractor shovel to dump the mixture of half value, half muda on to our customers.

Self-Induced Muda

Now what if I tell you the muda involved in the above scenario is mostly self-induced? We’re actually creating the muda ourselves in many different ways.

We start with a pile of diamonds, but bring along some mud ourselves which we throw onto the pile of value. We tell ourselves the mud is necessary to keep the diamonds from moving around so much, or perhaps our supervisors require us to use mud. We see no useful purpose of the mud in this process, but we go along like good employees and do it the way it’s always been done.
Many times the mud had a purpose once, but now we are mining something entirely different than when the mud was introduced originally. However the old timers have always used mud, so we keep using it too.

Eliminating Muda

What if there was a way to go about delivering what the customers wanted, without the mud? Or at least without bringing along our own mud to the project?

Well, there is. It’s called Lean Thinking.

You can start by asking Why. And then ask Why again, and again. I’m not talking about the 5-Whys technique, that’s a different topic.

I mean every time you or your teams partake in an activity of any kind, ask these questions:

• Why are we doing this?
• What’s the value of doing this?
• Who gets value from doing this?

By the way, an answer like “upper management gets value because hey, they asked for it” is not good enough. Doing something just because somebody wants it isn’t good enough. Why do they want it? Are you sure they want it?

I’ve seen people produce reports by hand for years, and email it out to executives every day and then find out that no one ever, ever opened them. The reports were started at some time because a director asked for them. She probably used them for a week and got the information she needed, and then they became irrelevant.

But no one asked why. They just added it to the daily reporting deck, assuming it was valuable.

Well, it wasn’t. And as a result, some people’s entire jobs are almost entirely spent producing waste, when they could be producing value instead.

Think about the project(s) you are currently managing. What is their value to muda ratio?

Projects At Work just released a new report called “Distributed Agile Teams”.

The whole report is interesting but I want to focus on a particular question.

21. What is the greatest challenge of working with a distributed agile team?

“Poor Communication” was the biggest challenge by far. Go figure!

Now I’ll be the first to admit that co-located teams is an optimal situation if you can get it. There is nothing like face-to-face interaction between team members. At the same time, there are some strategies for dealing with distributed teams that I believe many teams are not taking advantage of.

There are two root causes cited in the study I want to discuss: cultural/language issues and tools issues.

Cross-Cultural Teams

I have experienced first-hand the frustration of assuming communication has been smooth with someone who does not have the same language as you for their first language, only to find out it wasn’t.

This is where I think several options are available to ensure understanding across the entire team. This isn’t really limited to cultural differences within a team, miscommunications and different interpretations happen all the time regardless.

Make It Objective

It’s important to make sure you are using some kind of documentation that makes it clear what is being delivered. Good software requirements work, user stories, use cases, behavior-driven development, etc.

Regardless of the project, I’ve seen requirements that can be interpreted 57 different ways, and those are not good requirements. If you had to have been there when they were written and be told what the intent was, they are not good requirements.
Something I’ve started looking into heavily for my domain is behavior-driven development. It’s sort of like what I’ve known as test-driven development in the past, but much more user-focused. I like it. Aside from being very focused on the end user, it also makes it pretty darn clear what the functionality of the system is supposed to be. There is very little room for interpretation.

Make It Visual

The best way to communicate a concept clearly is through visuals, in my opinion.

This is why I love the kanban board. The whole team can see what’s going on at any given time. There are many online options available for distributed teams.

A picture is worth a thousand words, and it’s true. A diagram can convey a level of understanding that you just can’t get from words alone. Even when speaking to one another about parts and pieces of a system, our hands wave about wildly to illustrate specific points. At some point one of us usually says “Let’s go find a whiteboard, this is going to be much better if we can draw it.”

Well you can do the same with virtual teams too. Screen sharing and whiteboard tools are everywhere, free and paid. For my team members who are offsite, I love to use the desktop screen sharing application while on the phone with them. Either of us can convey understanding and have in-depth discussions this way as if we were in the same room.

Sometimes, the desktop sharing actually makes it seem better than being in the same room. You don’t have to lean over someone else’s shoulder or stare at a projector screen. You have the other person’s desktop right there in front of you.

Independent Validation

Having someone else on the team independently validate the work of other team members after development is finished is critical.

Why?

Not only for quality. No, this really helps teams gel in my experience. They get to know how their team members work better. They share tips and advice. They encourage each other. You know you’ve reached a good spot with independent validation as a part of your teams’ culture when people start actively seeking review from each other. That means they truly value each other’s opinions and communication is going to be enhanced as a result. It needs to be really easy to pick up the phone and just talk!

Tools For Distributed Teams

I think there is a lot of reliance on the wrong kind of tools out there for distributed teams.  Task assignments shouldn’t be done through a software tool. In fact with something like kanban or some implementations of agile, it’s not even necessary. Self-organizing teams pull their own work out of the backlog.

Direct communication where possible is best, and so I really don’t believe in many of the tools out there today that get all whiz-bang about task assignments and capturing estimates in the tools, etc.

I’d rather have a simple kanban board, screen sharing software, a phone, and instant messaging. You can do time-boxed Agile just fine with a kanban board.

How do you think communication can be improved among distributed Agile teams?

You may or may not be familiar with Shigeo Shingo’s identification of types of waste. Waste is essentially any activity which does not add value to the products being produced.

Even if you are not strictly working in a Lean methodology on your projects, these are applicable to all projects and environments, and can be avoided or mitigated if they are acknowledged.

I’ll provide my perspective from managing project teams doing software development for image data processing for a remote sensing satellite mission. If you are doing software development much of this will sound familiar, and even if you manage other types of projects I’d bet you’ll start getting ideas for your own domain.

I think you’ll be surprised at what you find when you start looking for these on your own projects, and using 5 Whys and other techniques you’ll be able to attack many of them and make your project teams more productive.
 

Defects

When the product doesn’t do what it needs to do, this is obviously a form of waste. There is one type of defect we call ‘bugs’ in software development. This is when there is an internal defect in the way the system works, or even just that it doesn’t meet a requirement.

There is another kind of defect though, and it’s probably the biggest form of waste in my book. It’s when you’ve produced something the customer doesn’t want. When I was a developer, I participated in creating several products that met our requirements, but when we launched them no one used them. Why?

Primarily, this was due to either a ‘pet project’ by some director in the organization who dreamed up this great system without checking to see if it would actually add value to anyone’s life. Additionally, the waterfall method without proper iteration means that by the time a product is delivered, it’s no longer what the customer wants or the interpretation of the requirements was drastically different. That’s why I love lean/agile methodologies where continuous customer feedback is critical, iteration and change is expected and encouraged.
 

Over-production

With physical goods this one is easy to see. Picture a warehouse full of materials because they were ‘cheaper to produce in bulk’. Producing something before it’s needed or producing too much of it is waste.

With something like software development it’s a bit different. Overproduction can take the form of producing elaborate systems to handle potential issues that are very unlikely, and could be handled manually by operators rather than trying to build the perfect system to automatically handle every little eventuality you can think of. There is maintenance of code to consider, and the time spent designing, developing, and testing code weighed against the time it will likely take for operators of the software to manually identify and fix these issues.
 

Transportation

In Lean manufacturing, transporting goods from an overseas supplier is often seen as waste when a local supplier can provide them, even if it costs more. The local supplier can be more responsive with shorter lead times, so you have less need to predict future demand and store input materials or finished goods taking up warehouse space.

With software projects this is largely mitigated in terms of moving product around, but can apply to moving people around. Traveling more than needed to meetings in other cities or even just the meetings we all have on a daily basis is a form of wasted potential productivity.
 

Waiting

Any people, parts, or other items waiting for the next step in being complete are being engaged in a form of waste.

With software development this can be the time between when coding is complete, peer reviews of the code take place, documentation is updated, and testing is performed. The more time between these steps, the longer it is going to take for the team to get re-oriented. I’ve seen peer reviews or or documentation take 10 times longer than it needed to, because the developer had to go back to the code they had written months ago and familiarize themselves with it again.

All of the queue times between steps from ‘begin’ to ‘complete’ are waste.
 

Inventory

With physical goods this is clearly warehouse space getting used up by goods just sitting there doing nothing.

With software, this is the list of features you’ve finished but not yet deployed to a customer. There is potential value being wasted because it has not been deployed. It also means it will take longer for you to find problems because you are delaying the crucial feedback mechanism from your customers.
 

Motion

This is pretty much what I said under the transportation heading. I’ll add to what I said there to mention that a huge source of waste on projects are meetings. If you or anyone on your team ever attend a meeting you can’t either 1) contribute to or 2) benefit from then it’s a form of waste. That is lost productivity that will never be regained.
 

Over-processing

This is essentially gold-plating. Anything you do beyond what adds value to the customer is wate. Even if you think it’s a whiz-bang cool feature, if it doesn’t get used it doesn’t add value and therefore is a form of waste.

So look around. What forms of waste can you start avoiding?

If you've done any work in systems or software development, you've probably use Lines of Code (LOC) before.

Either as an estimation tool with something like COCOMO, or as a retrospective gauge of the work your team did on a particular release of software with added/modified lines of code.

It's All Bull

Lines of Code as a measure of productivity or as an estimation tool is nearly meaningless. But it's something quantifyable and so people (especially managers) grab hold of it like a life raft.

I feel very similarly about Function Points, and I think both of these try to simplify something that is too complex for a one-size-fits-all method.

Here's the problem with equating LOC with productivity, effort, or estimates:

• An engineer may spend several hours on a block of code less than 20 lines, and the next day spend the same amount of time on writing 1000 lines of new code. Both are completely valid, and reality. It's all a matter of context.
• A system with 50k LOC that does the same thing as another system with 100k LOC is twice as good as the 100k LOC system, I'd argue. The lower LOC system is refactored better, less complexity for the same functionality, and easier to maintain.
• I re-wrote about 40 lines of code a few weeks ago (this is rare, I usually don't do much programming any more) because of a performance issue. The end result was half the code, and a roughly 450x improvement in performance (returning records in 400ms from a database instead of the ~3 minutes it was taking). I spent an hour reducing LOC to improve the system.

Now tell me how LOC can possibly be a global proxy for value or productivity?

User Stories or Features

I think the best proxy we have is user stories or features completed, provided and assuming they are valid. It's really just as valid a measure as any other arena like construction...you have assumptions that requirements were elicited properly and you are actually building what the customer wants.

What do you think? How do you measure or estimate productivity/effort on your software projects?

Taking small risks and failing fast is the best risk management strategy around.

Let me explain..

Vallidated Learning Through Small Risks

I identify strongly with the Lean Startup concept of validated learning, and I think every project is just like a startup. Especially in the beginning, validated learning is much more important than just cranking out a product for the sake of it.

If you think your customer will love something and you have the capability of demonstrating it in a visual way very quickly, do it!

The learning you gain from the experience, even if the customer hates it, is worth it.

Avoid Creating Your Own Big Risks

Too many project managers create their own large risk of producing a product no one will use.

That's the biggest risk of all.

Trying to avoid the small risks.  Being afraid to make mistakes. Being afraid to be wrong.

These are the attributes that result in big risks. And the project manager induces these herself.

What ways can you take small risks proactively to learn more quickly and avoid the big risks?

photo by Explore The Bruce