pmStudent

A project manager was struggling deeply with his project.

He was doing everything he had been taught to manage projects effectively, and yet it seemed as if more time was being spent on rework and just getting things done.

A fellow colleague was doing well. Her projects were not only going well, but she and her team seemed much less stressed.

"I'm in trouble here, I need to know your secret. Can we chat?" he asked.

"Of course," she replied.

The struggling project manager laid out his problems, one after the other.

"I'm working my tail off, and so is my team. Yet every day is like putting out one fire after another. We are always re-working something because it wasn't what the customer really wanted. And all of our tasks seem to take so long, especially when I compare my team to yours. Heck, even updating a document seems to be a monumental effort. My team is very skilled, just as good as yours. What am I doing wrong?"

"You want to know what I think?" she asked.

"Yes! Tell me!" he replied with exasperation.

"You are focused on getting work done."

"Aaaaand? Isn't that what I am supposed to do, get things done?"

"No. That shouldn't be your goal. You should be adding value." she replied.

"Oh come on! What's the difference?" he whined.

"Work which does not add value is wasted, and non-valuable work usually ends up causing even more waste work. Stop looking at what your team is doing as a collection of tasks. Start questioning what is adding value from the customer's perspective. If it doesn't add value, why are you doing it?

Also, start seeking out waste and eliminating it. Time lags between steps on an individual feature or item is a form of waste. It takes your team longer to update documentation because they have to go back and remember what they did with their code in order to make the updates. The longer it takes for anything to go from initial design to being delivered to the customer, the more waste you incur and the less value your customer gets."

"I never thought of it that way" he said.

"Think about it. Observe your processes in action and you'll start to see what I mean. Well, I've got to run, but it's been nice talking with you." she said with a wave as she walked away.

He thought about her words for a moment. Immediately, his mind was inundated with examples from what his team had been doing just in the last week which fit her definition of waste perfectly.

"Oh crap" he thought. "We have got to do something about this. Now!"

I've realized something lately.

Or rather, been reminded of it.

Sub-Optimization Sucks

The only way to acheive a truely lean organization or even a lean project is for the entire value stream to be bought into lean thinking.

Because of this fact, senior leadership in any organization must be fully supportive and invested in moving an organization to lean and agile thinking and process.

My teams are gaining clear benefits from the methods we've implemented with Kanban. However, because we are the only teams running this way, the benefits are also very limited.

Blocked

For example, in some cases my team members need external validation from other teams before we can move a particular feature forward in the value stream.

When those external parties are not bought into lean thinking (single-piece flow, limited WIP, continous deployment) they can very quickly become a block, causing a bottleneck in the value stream.

Pushing For Change

So, I am trying to develop interest from the other teams we interface with. Who knows, maybe I'll be successful in 'converting' them. Perhaps not.

Even better, I'm formulating plans for a method of convincing senior leadership that for our next program, a lean/agile approach is superior to our waterfall SDLC.

We'll see.  Wish me luck.

Tweet

One of the videos I've enjoyed recently over at Kanban School is this one with Pawel Brodzinski.

Pawel makes the point that Kanban does not replace software development methodology or project management methodology. I agree.

In the video he said it's more of a change management process (I think that's what he said) and I don't think he meant it quite like that.

To me, Kanban is a method of execution. On my teams, it's about the day-to-day execution and all the benefits that come with the Kanban process for that execution. The visualization really makes continuous improvement possible, almost inevitable. 

So what do you think about all this? If you are new to Kanban, check out Kanban School.

Tweet

When I teach people about Kanban for the first time one of several key concepts must be fully understood before I proceed into the details of executing with a Kanban-enabled process.

Every Team Has A Value Stream

Whether you know it or not, your team has a value stream. Some teams have several value streams depending on the varied type of work they do.

It is the process by which your team takes input and turns out the product at the end. That process is a value stream.

It's nothing fancy or complicated.

Each Step Adds Value

Well, every step should add value anyway. If it doesn't, why is it a part of your process?

You will also find after using Kanban for awhile that the more time between steps, the lower value you acheive and the more waste is introduced into your system.

This is why cycle time is so important in any system; the longer product in the system lay dormant, the more waste you introduce.

People start forgetting what happened to the product in the last step, and so they have to spend some time reviewing it again before they can try to add more value to it. This process introduces the potential for human error, and in software it means more bugs.

Start Where You Are At

The benefit comes from visualizing your true value stream and facing it.  Look it square in the eyes.

You have to fully understand and accept where you are starting from before you can move forward.

This is why visualization with something like Kanban is so astoundingly beneficial. It acts as the mirror you can look at to reflect reality.

Only once you know thyself can you truly improve.

Kaizen (Continuous Improvement)

After you start using Kanban for awhile, you will soon start noticing problems with your value stream. Or rather, opportunities for improvement.

There are no steps I can give you to make this happen.  It just will. I never have had to have any retrospectives or set times to consider lessons learned. Every second we use Kanban we are in a retrospective process, evaluating our performance and process in a continuous manner.

You can't help it.

Questions about Kanban?  Leave a comment below or check out http://KanbanSchool.com.

My teams and I do Kanban within a waterfall program.

This means that we have release cycles that start out with some investigation and detailed planning, move into true development, and then we have an Integration & Test process at the end of each release to go through.

A struggle we've had is that our value stream changes each time we transition from one phase of the waterfall cycle to another.

Furthermore, when in the Integration & Test phase, there is a specific tool we a required to use to work off what we call Test Descrepancy Reports (TDRs) which are basically bugs we find in testing.

At first, we would use a separate kanban board for the I&T phase, which maps the value stream of that process. However, due to the requirement of using a specific tool, it became a wasteful process to try and use both.  We had to keep both updated.

So in those cases, we dropped the kanban board - everything else was the same, but the visualization and mapping of a value stream went away for that portion of our work.

Has anyone else ran into a similar experience, with Kanban or something else, where a tool made a difference in terms of how you could work as a team?