The Need to be Needed

January 10, 2014

“A bee is never as busy as it seems; it’s just that it can’t buzz any slower.” – Kin Hubbard

A while back I was coaching a project that was to a large extent staffed by people being experts in narrow fields of expertise that also had other commitments outside of the project preventing them from having any slack time what-so-ever. This constituted quite a big challenge because they all took turns to act as bottlenecks in the process so I decided to run a retrospective focused entirely on how we could free up more of their time in order to improve the flow of work.

The initial reaction I got was almost enough to give up on the idea entirely. Almost everyone started moaning about management and the organization being the problem.
“Tell them to not dump all this work on us.”
“As long as we have to do projects as well as maintenance this will always be a problem.”
“I have to support so many projects that I’ll never be able to set aside any slack time.”

With the support of the project manager though, I decided to run the retrospective despite the chorus of geese shaking off the water. The setup was quite simple; we divided into groups of three and I asked each group to work according to the Iroquois “Rule of Six” to come up with at least six plausible reasons for why key people in the project were constantly overloaded with work. I asked them to specifically look for reasons that were in our reach to act upon. The result was amazing. All groups managed to present at least a handful of reasons showing how we all were responsible of creating this problem.
“I say yes to almost anything.”
“I don’t trust other people to do a good job.”
“I ask other people to help me with stuff without checking if it’s prioritized.”
“I don’t prioritize the work that comes in.”
“I create work that has not been asked for.”

I was overwhelmed with the candidness and maturity in the answers. This was great; we had found so many things that we would be able to act on in order to ease up on our own as well as our peer’s workloads. With this smörgåsbord of possible actions I didn’t want to do a prioritization to select one or two to implement during the upcoming sprint. Instead I asked if we could take as homework to do a daily act of kindness to ourselves and someone else. Could we at least once a day stop to think if we were about to act according to one of the patterns that we had found and instead take another road?

This is where things started to get interesting again. Amidst the nods and yesses I detected some hesitation as well. The hesitation wasn’t spoken out loud in any way but it was in the air so I asked for a fist of five. Could everyone on the count of three please raise a hand showing their commitment to this homework by showing any number of fingers between one and five?

  • Five fingers being “YES! I’m really committed to this, count on me.”
  • One finger might as well be the middle one; “There’s no way in hell that I’m doing this.”

All people raised four or five fingers except the three persons being the most overburdened, they only held up one or two fingers.

When I asked what made them hesitant about doing this daily act of saying no to another task or not handing unprioritized work over to a fellow project member, they all fell back to the initial reaction of pointing outside their own sphere of control: “It’s not possible to say no.”
“If there’s a production problem it has to be done.”
“We have to do this even if it’s not prioritized.”
“Quality will suffer if we don’t do this.”

I’m not entirely sure if the conclusion I came to after this meeting was correct or not but I suspect that these people thrive on being busy. It could be external factors such as explicit or implicit rewards and/or threats that make people act in ways that puts them in the center of everything but having seen the same people end up in these situations time after time in different positions at different companies make me think that the problem often is self constructed. Some internal belief system or internal reward system make some people act in ways that is hazardous to not only their own health but also the productivity of the team that they work with. I don’t have a turnkey solution for this problem but I would ask everyone to consider this possibility before going about redesigning the organization or taking any other measures on the system.

The problem might not be that we force people to work too much, it could very well be that we allow them to work too much.

Forget about Kanban

October 19, 2010

Let’s forget about Kanban. Just for a little while. Kanban is a great tool but once again we’ve (myself included) gotten carried away and started peddling a tool instead of focusing on the problems it is supposed to address. Five minutes after hearing about this great new process [sic], customers start asking for software tools to support it. The Kanban board is up on the wall with cool magnets and custom name tags before any process has been mapped. Consultants as well as customers are eager to sell and buy, afraid to miss the Kanban-train. This is a recipe for disaster.

So can we please forget about Kanban for a while and talk about the problems we want to solve instead?

Let’s talk about what we pay for our inventories in the form of work items residing in queues.
Let’s talk about what we pay for the delayed feedback due to work items not moving through our process.
Let’s talk about how our quality suffers from work items sitting in queues.
Maybe we could talk about how job satisfaction goes down due to developers not being allowed/able to move their jobs to a DONE-state.
We could even talk about team members suffering from stress because work is being pushed to them.
We could also discuss how the organization suffers from the increased costs and risks stemming from the extra overhead and long cycle times that are the results of working with large batches.
We could talk about how the old processes have gone into rigor mortis due to a lack of double loop learning.

There are so many interesting things we could talk about if we could just forget about Kanban for a little while. After we’ve taken a look at all those problems, I promise you that we can start talking about Kanban again. There’s even a slight possibility that Kanban could help us solve some of our problems. But for now, let’s just forget about Kanban.

10 Minute Kanban Pizza

April 14, 2010

It never ceases to amaze me how poorly organized the work is in many restaurants and bars. Many lunch restaurants only get one seating per day because they haven’t planned their work properly. Bars often have a long line of customers waving their money and waiting for service instead of sitting at a table sipping their drinks. Even though I’m a software guy at heart, I’m seriously considering starting a lean consulting business aimed at restaurants (probably more on this in future posts).

However, there is one type of institution that often impresses me; the pizza place. These guys seem to run a Kanban-based manufacturing process, knowingly or not, with very good results. One of the more common process designs I’ve seen is where there’s one person running the cash register and answering the phone. He takes the orders and writes them on a note which he puts at the end of a que. The next person in the value stream is actually making the pizzas. He pulls the next work order from the que, flattens the dough and puts on the toppings according to specification. And finally one person is responsible for putting the pizzas into the oven and then taking them out again and putting them in the boxes. The WIP limits aren’t written anywhere but instead they seem to be self regulating. Whenever there are too many pizzas ready to go and there’s a line of customers, the first guy stops answering the phone and concentrates fully on payments and getting the inventory down. The guy baking pizzas has a table that can only fit two pizzas so his WIP limit is quite obvius. The oven can only hold a certain number of pizzas so once again we have a forced WIP limit.

The result of this design is that these guys can deliver their product with very high precision. Whenever you order a pizza the guy always says that it’ll be ready in ten minutes. And lo and behold, ten minutes later your standing there with a warm pizza box in your hands. Most product owners would probably die for this kind of predictability in their processes. Wouldn’t it be awesome to work with a development team that answered each new request that was prioritized to the top of the backlog with: “It’ll be ready in ten minutes.”?

Homework for tomorrow is to look at how the pizza place follow the 5S’s of Lean workplace organization. Knowingly or not, a lot of them do.

%d bloggers like this: