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