Well, thanks. Yourself?
Todd: Not too bad.
Excellent.
Todd: We’re here at the Lean - UX conference and to get started, why don’t you tell us a little bit about yourself.
I’m Adam Yuret, I’m an independent principal consultant at Context Driven Agility, we do Agile, Lean, consulting, lately I’ve specialized in large enterprise retailers at the portfolio program team and executive level, really depending on the context of the day and trying to help people arrange their whole systems to optimize for value delivery. It sounds really buzz-wordy, but it’s really good stuff.
Todd: It’s appropriate that you are here at this conference and doing a workshop on value stream mapping.
Yes, Jabe Bloom and I worked together at creating a value stream mapping exercise; value mapping comes from the original Lean, there’s a book called Learning to See that’s very good by John Shook and Mike Rother that talks about value stream mapping in the manufacturing context and while linear manufacturing metaphors are not perfectly adaptable to knowledge work, there is still value in being able to see the whole picture of work as it goes from demand to delivery to customers and a lot of Agile methods are very focused on team level delivery optimization and the bit that’s missing is the lead time, the what happens before it goes into a backlog and a team starts to process it and do it. In a nutshell, our value stream mapping exercise consists of having people map their journey to the conference, they create sticky notes and put them up on a wall, starting from the moment of value realization which is you’re here at the conference today to what happened just before that and then what happened before that and people write activities; in the real world, we would tack some cycle time numbers in there so we start to get an understanding and aggregate how much time went into working on these things, then people map it all the way back to the day that they realized they wanted to go to the conference, so that’s the moment of demand.
In software or in organizations of most any kind we would start with when the customer received value and then go to what happened right before we gave them that value, what happened before that and doing that we start to identify the wait time, the queues, how many hand offs there were, did we have to wait for this to sit in queue for three months, in the product, or did it take two months to do ethnography, to figure out how to make this thing work so that users would want it. And when we do that we start to see that the vast minority of the work the time between we have an idea and we give it to a customer is people touching it and doing things. So, in Lean there are these concepts of resource efficiency and flow efficiency, there is a really great book called This Is Lean that’s a best seller in Sweden I think, you can’t get it on eBook, but you can order it. It’s a really concise, fantastic book that talks about the difference between a resource efficiency and a flow efficiency model. So, in a nutshell, the resource efficiency model optimizes for effort and busyness on the resource side of things and the thing that gets left behind is the customer.
The examples given in that book are two women discover a lump in their breasts, respectively, and one of them goes to a traditional American medical system where they go to a primary care doctor, the primary care doctor does a manual test, says “yes, there is something there, we need to send you in to get a sonogram”, two weeks later she gets a sonogram, they see what’s in there, they say “yes, this should be biopsied by a cytologist”, an appointment is made, two weeks later she sees a cytologist and then she gets a biopsy made and then two weeks later her results come back. Over the course of that six weeks, the total lead time between she discovered she had a problem and she got a diagnosis was six weeks. The alternative is a flow efficiency model, the same demand occurs, she finds a lump, she goes to an all-inclusive breast cancer clinic where everything she needs is in one building, she goes and checks in and they say “yes, we’ll send you in to see the primary care physician”, the primary care physician manual checks, ok, in the next room over there is a sonogram, take the sonogram, in the next room over there is cytologist, take the sample and in the next room over there is a laboratory, tests the sample and her total lead time is two hours.
So the resource efficient model was 600x less efficient for the customer than the flow efficient model and the flow efficiency model though, if you were to look at it from the perspective of the people delivering the value instead of the customer you would see they had a primary care physician who was available, he wasn’t super busy, he had slack, and you had a sonogram that was available, you had a cytologist that was available and a lab that was available. If all four of those things had, even in the same building, been kept resource efficient so they are constantly processing a massive backlog of things, then the customer’s value, time gets longer. So, it’s a really great book, Håkan Forss did a talk in Central Europe, it’s on YouTube, called The Red Brick Cancer, it’s essentially about that, and I feel like one of the ways to start solving for that problem is to make the entire value stream in an organization visible and once we see the majority of the cause of our delay is queues and wait times, will start to address those problems and fix the system instead of trying to make people work harder and go faster.
A lot of effort goes into cycle time and cycle time, essentially, is the moment where work begins on a work item to when it’s delivered. If we discover we need something, we for whatever reason identify demand for a product or service, we then begin thinking about processing that demand, that’s the moment at which the lead time clock starts ticking. Now, while we’re figuring out what needs to happen in order to implement it, that lead time clock is ticking. Once somebody starts making it, then we start the cycle time clock. When it’s delivered both clocks stop. So, the cycle time clock, individual actors at the tactical level have more influence over it than they do at the lead time level, so software engineering can't go tell marketing they would like them to go more quickly.
3. What may a traditional value stream map in software company look like?
What we’ve done with large retail organizations is people write down activities and we’ll put a bunch of butcher paper, or usually we’ll have easel paper up on the wall and we'll choose a given project that they worked on. Ideally, to make the point, we’ll choose a project that had a lot of interactions with other areas of the business and we like to have people represent all of those areas there. Those people will put down activities that they engaged in and they might also add times when new information was discovered and add different visual indicators that we worked on this thing and then we got this piece of information and realized we had to change things, if they then handed off to another team they might switch to a different color, so engineering people will have yellow stickies for engineering task, when they handed off to operations it went to green stickies. So, the end result, the artifact, ends up being a wall covered with sticky notes that has little light bulb at one end and a little happy dude at the other end and then we’ve got a chain of interconnected stickies and at the end of that session or towards the end of that session we’ll have everybody go up with color dots, of which there aren’t any on this table, but the color dots represent three different types of value, essentially.
So, there’s the green ones which represent value add and that means from the perspective of the customers this activity delivered and generated value; the red one is non- value add, which essentially is waste, if we didn’t do this, the customer would not know that we didn’t do this and we didn’t get any benefit from it, it would be a thing we’d be better off not doing in the future, and then a third color yellow, let’s say, would be essential non-value add. So, an example we’ve used of essential non-value add would be HIPPA paperwork, you go to the doctor, they make you sign this thing, you’d probably rather not have to do that, but there are laws and regulatory compliances that require that you do that, so you don’t get to skip it, but it adds no value at all to your experience, you don’t get better service because you signed that document. So, regulatory issues. So, what happens is people go and stick those on the tasks as from their perspective and we pull in the wisdom of the crowd in that process and we identify areas of severe misalignment, when you’ve got a bunch of green dots and one red dot, we’d like to know why somebody thinks this is a complete waste while everybody else clearly thinks it’s very high value.
So, in the Eisenhower sense of planning is essential, but the plan is meaningless, so even if we burn the value stream map itself, the fact that we’ve gotten people together to have a dialogue, with executives, with directors, with people from marketing, sales, engineering, operations or test, all of those people were able to share their perspective of whether or not work was valuable or essential, and having those discussions with the decision makers in the room, and with the people actually doing them, we get to start to unpack where those disconnects are and from that we can either identify things that can stop happening all together right on the spot, the low hanging fruit as it were. Or we can identify areas to investigate further, we can say this is tough, we’re not going to get this sorted out today, but let’s have a Lean Coffee session about it with the people it’s going to impact and we'll hash it out and come up with some problem statements, hypothesis, and we can start to work on improving our process. And it doesn’t become a static thing that we have to own forever, we want to revisit it periodically because the system is going to change and evolve and ours is much more, I think, emergent and it doesn’t turn into a concrete improvement plan, there is some traditional value stream maps where the end result is a very elaborate artifact that then gets turned into a five year improvement plan, it goes into a Gantt chart and then the organization has to spend ostensibly the next five years executing on a huge plan while their process and systems are emerging and changing. The end part is much more emergent and less heavy weight than one might think when they think of manufacturing value stream map.
It probably comes from manufacturing where we can see how hard somebody is working and how many units came out of the other end, it’s a very deterministic and simple domain kind of work, so in knowledge work that stuff is invisible, it’s more intuitive to talk about limiting work in progress than manage flow if what’s happening is you bring a carburetor to a guy who can only work on one carburetor at a time and he has 50 carburetors in a bin next to him, you understand that you’re not adding value by making another 50 carburetors for him, you’re just piling up a bottleneck. So, those things are visible and they make sense, but in software everything is invisible, our repositories can hold more software than any of us could build in our entire lifetime.
So, we start to fill it up with software and people start to use proxy metrics like velocity to measure how busy people are and then it becomes this lever to turn, we just need programmers to make more velocities and get them out the door because there is no visible reason why that is a bad idea. So, when you tell people you need to go slower in order to optimize for flow, it doesn’t make any sense. They think productivity means you produce stuff very fast and lots of it, when our customers don’t necessarily want stuff, I know very few people who speak quantitatively about software that are not in the software production business. I don’t know about any consumers who say “what I really need is a lot more software”, so I think the thinking is the easier thing to solve is we give requirements to engineers and they do things we don’t understand and then software comes out the other end, if we can make them do things we don’t understand more quickly, then we would be more successful. So, that’s my thinking around what leads to that paradigm.
It’s challenging to get that to even happen in the first place, that’s more of an end-state goal, when you first go in everybody has unlimited work in progress, everybody is overloaded. What I try to express is that we need three different types of slack in order to enable flow, and the three different types of slack that I talk about are slack for variability buffer which I won’t go into too much detail but you essentially need space between two cars in order for both of them to go fast, the freeway metaphor is what I use often, you need slack for innovation, for creating new things we don’t even know if the market wants, design and doing those things, and we also need slack for learning, because we are not in a production business, we are not making widgets, we’re thinking and designing and so we need space to learn how to do that differently and new things.
6. What comes next for you when you get out of here? What’s exciting for you?
I’m looking forward to going to a few more conferences this year and working with clients. I spend a lot of time doing Seattle Lean Coffee every Wednesday morning in South-Lake Union and for me there is a lot of great opportunities for collaboration in the community and I love working with clients, seeing these systems change and grow and improve while people are less beleaguered and have happier lives is really what I’m in it for, so I’m looking forward to what this year has to offer and this Lean UX conference that we visited was really exceptional and set a high bar.