I've started work in a very different organization, in a very different
culture and see the same problems. For those that don't know yet, I have
moved to Indonesia and works for the Bala
Keselamatan, better known internationally as
the Salvation
Army. My tasks here is around helping the organization that
organizes the Salvation Army hospitals (yes, 6 of them) and clinics (17
I think), to become more effective and get more done with less. "Doing
the most good" in other words
When I went here I was hoping (or betting maybe is a better word ^^)
that my interests and knowledge in Lean and Agile would be helpful to
them. And I've at least seen similar problems here as I did with clients
at home. In this blog post I thought I would talk about one of these
problems: long lead times in important projects.
Yes, I wrote "important" projects. It really stumped me at first. But
then I realized that I've been in many important, urgent projects with
long lead times. In another industry and another world. I have two
examples from my current situation in very different scales, both when
it comes to people. They are both concrete and you can probably make
your analogy over to your context and situation quite easy.
### The projects
###
- The first
project is about clearing out the final details on how two
organizations should be separated from each other. There's a lot of
discussions, decisions and meetings to be had. A lot of people (4
teams of 6-8 people each) are involved.
- The other
project is much smaller: we (4 - 5 of us) need to clear out some
misunderstandings around a project run at one of our hospitals for
the mother organization of the Salvation Army, so that they know
where and why we spend our funds this way.
For
both of these projects a number of common factors are the
same:
- These projects are very important (the
word "paramount" has been used a couple of times)
- They are urgent, but on different
timescales (month-months in the first case, day-days in the
second)
- They are staffed with people that have
a lot of other things to do.
All
in all... the perfect setup for success. Don't you
agree? And after you don't. Stop
and think for awhile.
You been in these
projects.
Right?
Right?
Right, sure you have.
Me
to.
So
how does project like these look then?
How we work
### What ends up happening is not very hard to figure out
### Person A start to work and then hand stuff over to the next person. Person B in turn doesn't have time right now... so after a day or two (or hour or two, take your pick), picks the task up and ... realize that he didn't really understand where A left off, so an email is sent (urgent email) to clarify the situation
### Sadly the A is involved in other things and after a day can explain what he meant and send a more comprehensive answer to B. Now B understands but ... has an important conference the rest of the week. But on Monday B can give answers and now can send it on to C
### C has been wondering what's taken so long. As C reads the proposed actions, he realizes that A and B is focusing on the wrong things. Why wasn't C involved earlier, C thinks angrily. And sends a quite angry email to both A and B: "we should meet and discuss this! My next week is pretty busy but after that..." C sends the email and then storm past A and B's desks on his way for a coffee
Actually, just writing that made me
angry. It's just stupid, don't you agree? But still this is how many
discussions and decision making processes are run. Both in Swedish and
Indonesian companies I've worked for.
### Lead time
###
In
processes like the one described above the work is not being worked on much more than it is
actually being worked. This, of course, has a dramatic and damaging
effect on the lead time to complete the work. Try this very simple
exercise, if you dare, on a whiteboard next to you:
- Draw a line across the entire board.
For extra measures mark it with dates (or weeks even)
- Write "Working" above it and "Waiting"
below it, to the left.
- Now plot where the task has been by
doing a staple diagram of sorts. You'll end up with
something like this:
Now,
for the fun part.
- Measure the
length of the line as it's in "Working" area. It doesn't have to be
exact but enough to prove a point
- Draw a new
similar diagram below and plot only the "Working"-time on the
diagram.
- You'll end up
with something like this (I've even added a little waiting time in
the beginning, I'll get back to that later in the post):
In
true Switch-spirit we now have visualized information and
hence "found the feeling" or felt the pain that's needed to improve.
We've also "posted a postcard from the future" to show how fast it could
go? Now, the only question is, how?
Oh,
this exercise is a very simple form of
Value Stream Mapping. You can do much more advance
versions of this, but seldom do to get the point across.
How to get to better
### Ok, here it comes. My solution to this age old problem. I'm planning on releasing this as book later this year, but you can read it now. Please don't spread it since I want to trademark it. It's really big news
- Find a time when everyone can work in the same room together
- Work on it until it's done
- Done!
It's also known as "Go in a room and get it done" or
"Sit together - work together".
Sorry, I was being ironic there for awhile. But one could ask oneself,
as one (being me) has done from time to time: so **everyone** knows that
this is a bad, so **why** does this still happen?
### Why is this
### By now, most of you probably has left me since I'm just ranting. So for you there back in the corner that still is reading this... this is a bit of a puzzle, right. Because everyone know this. Manning an urgent and important project with already busy people will lead to really hard scheduling and that in turn will hurt the lead time. Badly
Still, this is the common way of doing
things. "I want you to engage in this project also", "We're pulling
people from other project to create a task force to make sure that ..."
You've heard things like these.
#### Effective versus efficient
| |
|:------------------------------------------------------------------------------------------------:|
| 
|
| "Nothing to do is super boring" |
I
think that it's because we're all too often focusing on keeping people
busy and efficient. Don't miss
Dan North in this
excellent talk on
effectiveness vs efficiency.
This,
by the way, goes both for organizations but also for individuals: we
want to be busy, right?
It's
super boring to have nothing to do. And I don't look
important either.
And
we want our people to be busy, right?
They
cannot just sit around do nothing, now can they? It's better that they
do something than nothing. It's simply not efficient if they are not
busy.
That statement is perfectly true. Consider the case of writing code. As
it turns out, the hard part is not typing. It's understanding each
other. A software company is not selling "keystrokes / minute". They are
selling finished (features in their) software that people are using.
> href="http://zuill.us/WoodyZuill/2012/09/16/the-8-agile-maxims-of-woody-zuill/"
> target="_blank">“Working Software” is software that users are actually
> using. Until it’s in use it is truly useless.
When I first introduced a colleague to Mob Programming (quite simply: a whole team, one
room, one computer, one keyboard, one screen - working on one thing at
the time) his response was correctly:
> "but that's just not efficient!".
If I could think faster I would have responded:
> "No, but it's very effective"
#### Priority
Another thing that doesn't help the poor
people in processes like these is often the lack of clear priorities.
I've heard about a big bank in Sweden that had 15 projects that was top
prioritized. That's 15 project that we should work on first. I'm not
sure that's even English? Surely only one project (person, thing or
whatever) can be the first?
I've
also worked at a Swedish insurance companies that, in one project, had
so many PRIO 1 items in the backlog so that they (wait for it)
introduced PRIO 0. Yes, PRIO 0 is even more prioritized than PRIO 1.
Surely this will redeem the situation? It's did not and pretty soon they
had about 20 PRIO 0 in the backlog too.
With
a lot of things that is highest priority for teams and people we're
making it very hard to for them to know what to do? In a lot of
situations it really doesn't matter: they are making someone
disappointed anyway.
Google defined "prioritize' as:
> designate or treat (something) as more important than other things.
Doesn't say a thing about giving priorities 1, 2, 3 and first do all the
1 and then all the 2. No it says: "treat something as more important
than other things". Yes. Somethings will have to wait before we start to
work on them. But, the then that we **actually** work on is more
important and hence it will be a better use of the time we put in.
Corey Ladas introduced
me to a tool called
priority filters. With this we visualize our
priorities from less important all the way up to "so important that
we're actually working on it now". I like that definition much better
than PRIO 1.
### What I will do now
I think it's better, and much more effective (as well as efficient in
fact) to wait until the time is right to do this project. When we reach
that point we can explain, for everyone involved, why this is now the
most important thing we can do right now.
That's why the second version of my simplified value stream map had a
waiting time in the beginning. In order to be efficient when we do get
together it might be worth waiting awhile first.
Then we go into a room and get it done. We bring the people that we need
to make the decisions we need to make and we get the work done. Or at
least as far as we can given the constraints we're given.
Going into the room without important decision makers, in other words:
without the authority to make decision, is a waste of time. The work
will not be done. It will only be started. We want to finish stuff. Not
start stuff.
> > It’s not “the more you start, the more you finish,” it’s “the more
> > you finish, the more you finish.”
>
> > —David P.
> > Joyce
|
| "Nothing to do is super boring" |
I
think that it's because we're all too often focusing on keeping people
busy and efficient. Don't miss
Dan North in this
excellent talk on
effectiveness vs efficiency.
This,
by the way, goes both for organizations but also for individuals: we
want to be busy, right?
It's
super boring to have nothing to do. And I don't look
important either.
And
we want our people to be busy, right?
They
cannot just sit around do nothing, now can they? It's better that they
do something than nothing. It's simply not efficient if they are not
busy.
That statement is perfectly true. Consider the case of writing code. As
it turns out, the hard part is not typing. It's understanding each
other. A software company is not selling "keystrokes / minute". They are
selling finished (features in their) software that people are using.
> href="http://zuill.us/WoodyZuill/2012/09/16/the-8-agile-maxims-of-woody-zuill/"
> target="_blank">“Working Software” is software that users are actually
> using. Until it’s in use it is truly useless.
When I first introduced a colleague to Mob Programming (quite simply: a whole team, one
room, one computer, one keyboard, one screen - working on one thing at
the time) his response was correctly:
> "but that's just not efficient!".
If I could think faster I would have responded:
> "No, but it's very effective"
#### Priority
Another thing that doesn't help the poor
people in processes like these is often the lack of clear priorities.
I've heard about a big bank in Sweden that had 15 projects that was top
prioritized. That's 15 project that we should work on first. I'm not
sure that's even English? Surely only one project (person, thing or
whatever) can be the first?
I've
also worked at a Swedish insurance companies that, in one project, had
so many PRIO 1 items in the backlog so that they (wait for it)
introduced PRIO 0. Yes, PRIO 0 is even more prioritized than PRIO 1.
Surely this will redeem the situation? It's did not and pretty soon they
had about 20 PRIO 0 in the backlog too.
With
a lot of things that is highest priority for teams and people we're
making it very hard to for them to know what to do? In a lot of
situations it really doesn't matter: they are making someone
disappointed anyway.
Google defined "prioritize' as:
> designate or treat (something) as more important than other things.
Doesn't say a thing about giving priorities 1, 2, 3 and first do all the
1 and then all the 2. No it says: "treat something as more important
than other things". Yes. Somethings will have to wait before we start to
work on them. But, the then that we **actually** work on is more
important and hence it will be a better use of the time we put in.
Corey Ladas introduced
me to a tool called
priority filters. With this we visualize our
priorities from less important all the way up to "so important that
we're actually working on it now". I like that definition much better
than PRIO 1.
### What I will do now
I think it's better, and much more effective (as well as efficient in
fact) to wait until the time is right to do this project. When we reach
that point we can explain, for everyone involved, why this is now the
most important thing we can do right now.
That's why the second version of my simplified value stream map had a
waiting time in the beginning. In order to be efficient when we do get
together it might be worth waiting awhile first.
Then we go into a room and get it done. We bring the people that we need
to make the decisions we need to make and we get the work done. Or at
least as far as we can given the constraints we're given.
Going into the room without important decision makers, in other words:
without the authority to make decision, is a waste of time. The work
will not be done. It will only be started. We want to finish stuff. Not
start stuff.
> > It’s not “the more you start, the more you finish,” it’s “the more
> > you finish, the more you finish.”
>
> > —David P.
> > Joyce