There are some things in life that we’re immediately attracted to, without thinking. There are others that, though we to do but we automatically avoid. The problem with project management is that we need to go towards the things that we automatically avoid.
There are the two value streams of a project, and they interfere with each other. A virtual value stream – the dream stream, which is like flowers. And a virtuous value stream – the cream stream? (ugh) which is like fruit.
In this chapter, I’m going to talk a lot about “value streams”. And also, about “flowers” and “fruit”. Of course, of those terms, “value streams” is probably the less familiar.
Value streams are often talked about with regard to “Lean” approaches to manufacturing. And what are they exactly? In the 1980’s American manufacturing, especially American car manufacturing, started to lose out to the Japanese. Japanese cars were more reliable, cheaper and just generally better than American cars.
Eventually, academics from the business schools in America began to write about why it might be that Japanese manufacturing was better than American. A key concept in explaining the way that the Japanese industry, and especially the Toyota company had beomce so successful was the idea of the “value stream” and together with the idea of a value stream came a very specific notion of waste.
A value stream is a series of actions that culminate in the production of product that’s valuable to its customers. So, as the chassis of a car moves down a production line, value gets added to it. What sorts of things add value? An engine. An engine adds value. Paint, wing mirrors, seats. You get the idea. But note, none of this value gets realised until the car is finally being driven.
American observers also drew attention to the Japanese understanding of what didn’t add value. Activities that are going on in a factory that don’t contribute to the value stream are regarded as waste. An example that’s give in Taiichi Ohno’s book, “The Toyota Production System”, is of a machine that is part of the production line that needs to be change when a different model of car is made. If a machine had to be swapped in an out of the product line, all of the time that it took to swap the machine, is, from the point of view of a value stream, waste. But also, if completed cars, having rolled off the production line are waiting around in a yard, they aren’t delivering any value. That’s also waste.
This is a final crucial aspect of thinking about value streams. The value is only realised when the product that has been through the production line, is actually sold and delivered into the hands of a customer. All of the time that a finished product is waiting in the parking lot, or sitting in a container waiting to be transported, that is also waste.
OK so this investigation and explanation of how the Japanese were building cars produced, at least these three interesting ideas.
To many who read these descriptions of Japanese manufacturing, these ideas offered a suggestion for how any organisation might improve its process and make it more efficient. Although this is quite a leap. Not all organisations, you might have noticed, make cars.
And one main idea came out of these discussions. If it were possible to map the value stream – to see what all the steps in a process are, then it would be possible to see where there are delays and so, where there is “waste”. Then, once we’ve found where the waste is, we can work to reduce it. From this way of thinking, comes a whole new way of organising many industries and the notion of “Just in time” manufacturing.
You might be able to see the appeal of looking at work in this way. If we can map the value stream, and we can reduce waste between processes, especially in the form of waiting times, then we can notionally speed up any production process and make it more efficient.
So, there it is, that’s the idea of a value stream. A series of steps that add value to a product. And people have made good solid efforts to apply these ideas to software development. Some these attempts work and some really don’t. We’ll talk about where these ideas are exceptionally useful in a following chapter [Chapter SOFTWARE].
But right now, I’m going to talk about why this idea of value streams, as it stands, really doesn’t work for the development of new, bespoke, software projects.
Why doesn’t it? Because, when it comes to development of software for a new product, there isn’t just one value stream. There are two value streams rather than the one that’s talked about and imagined when people talk about making cars or other established products. The further complication is that, of these two streams, one of doesn’t exist (yet) and the other is opaque and weird. Oh, and there’s a final problem, what makes this even more difficult is that these two value streams interfere with each other. And when I say “interfere” I mean that they try to kill each other.
So, what are these two value streams? The first of the streams is what I’m going to call the “virtual” value stream. This is a stream that delivers value by looking good, sounding good, or by coming up with a new, attractive, idea. The payoff for this value stream, is in the funding and management support that arrives to make the idea happen and an increase in reputation and standing the people who came up with the idea. Well at least the people who manage to persuade others that it was their idea.
Is this really a value stream? In some sense, it must be. Ideas don’t just instantly appear, fully formed, and projects don’t just instantly get funded so there must be some form of value stream here. But quite how it works in most organisations is opaque, which is why I say that it’s weird. We will talk more about this stream a bit later but for now I want to move on to the other stream in software development projects the one that the start at least doesn’t exist.
The second stream is the one I’m going to call the “virtuous” value stream. This is the stream that delivers value, not by looking good, or sounding like a good idea, but by actually doing good. Doing good means actually something that is valuable to the people who use it.
Because “virtual” and “virtuous” sound a bit alike. I’m also going to borrow an idea from Taoist thinking. And draw a distinction between flowers and fruit. The virtual value stream is like flowers. The virtuous value stream is like fruit.
Don’t get me wrong. It might seem as we go through this chapter that I’m a little bit down on flowers. I’m not down on flowers. Flowers are great. In project management, the part of flowers is played by ideas, dreams. Without ideas there wouldn’t be any projects.
People have ideas, those ideas get money and support and that’s how projects are born. Something that some ideas and most flowers have in common is that people like them straight away. They don’t have to think about it. It doesn’t take any thought to like a rose. Of course, some people might not like roses. But the people who do? They don’t have to take time to work it out.
Something similar seems to happen with ideas. The kind of ideas that get money to turn into projects seem to have a structure that makes people like them without too much thought. Just like flowers, those who are exposed to them tend to like them without doing much or any thinking.
Often ideas are talked about in these terms: easy, fast or cheap. Then other times, the idea’s pitch is that some things won’t change:
“Fully-compatible, with the same functionality.”
Sometimes the ideas pitch difference:
“A fresh look,” or “A radically different take.”
Sometimes all of these things get bundled together.
“A radically different take which does exactly what the old system did, but faster, quicker, more easily and for less money.”
And of course, all of this, almost always, is going to be delivered using the latest technology.
“Does everything that the old system does, but quicker and cheaper and using AI.”
“Deals with all customer enquiries, using chatbots without the need for human involvement.”
“A social network, for dogs, using blockchain”
This “instant appeal” aspect of ideas is a substantial part of why I say that the virtual value stream is weird. Yes, there might be an application process for getting ideas funded, and, as I said, earlier, there must be some steps to the process. But there might just as well not be, this could just be the idea of someone really senior, or someone who has the really senior person’s ear. Some projects get funded on a whim. And even if there is a more involved process, at some point, the central proposal of the project is going to be evaluated – and the mechanism of how an idea appeals to the people who do that evaluation and then decide whether to fund it or not, it is pretty much opaque.
Even though the appeal of ideas might not have any obvious logic to it. From the examples I’ve given, we might see that are some common themes in the ideas that get funded.
Ideas that get funded often have these concepts lurking in them – “all”, “same” but also “new”.
Where ideas come from is a fascinating subject but I’m going to side-step it for now. Because the whole point of this chapter is that, for a project to deliver, it needs to stop being fascinated by the idea and start being fascinated by the reality. We need to stop enjoying the flowers think about how we’re going to grow the fruit.
There’s an important difference between Flowers and fruit. Users eat fruit. They only look at flowers. Nobody ever died from looking at a flower. A sour apple can give you bad indigestion and some fruit is actually poisonous. Some fruit is poisonous until it’s been properly processed.
Similarly, delivered projects need to give value to their users. This involves an interaction with users which is different from buying and selling flowers. Users have to get some good, some value out of using a software product. What ‘good’ that value is, is different for different kinds of products. For example, it’s very different for a social media product than it is for a government form. But like fruit, if it doesn’t taste right, users will spit it out. Also, like fruit if software isn’t put together (grown) properly, it could do them harm.
So, what about fruit? What about this other value stream - the virtuous value stream? The one that actually gives people what they want? In the Toyota product system, this second value stream is the focus of all the attention, in fact, it’s talked about as if it’s the only value stream. In Taiichi Ohno’s, book, he’s always asking himself “How can we improve flow through the system,” and “How can we get parts to the right place in the process just in time.”
There is an aspect of this that seems to be almost always missed when people try to transfer these ideas to the development of software. Most software development projects are developing a new product. The problem that they’re trying to solve isn’t one of trying to make a better car. The problem is that nobody has ever made a car. This is a new product, it’s a one-off, nobody has ever made one exactly like this before.
Am I exaggerating? I’m exaggerating a little bit. It’s more like you and your team are trying to build a new kind of vehicle. If you’re building a video game, well there have been video games before. But you’re still going to need to take aspects of the idea, find out which bits users respond to and connect them together in a game that they want to buy and spend hours playing. If you’re building a form-filling application, well, there have been those too. But you’re still going to need to understand what information you need to gather, what the best way is to ask for the information, and how it’s going to be stored and who’s going to want to look at it. The important thing to understand and admit is that you’re in a prototype process, not a manufacturing process. You’re assembling a value stream, not operating an existing one.
So how do you do this? How do put together the value adding steps that will eventually deliver something that realises value for the customer?
Well, you have to do two things.
In the next chapter [Chapter Swamp] we’ll talk about why, how and with who you should work to discover value. Then in the chapter after that [Chapter SOFTWARE], we’ll talk about how to put these bits of value together and start a value stream.
Simple right? Well, it would be, if it weren’t for a third thing that you have to do. As a result of these two steps.
This the central paradox of project management. Starting to do the project results in the alienation of the people who got the project funded. Why? Because actually doing things results in uncovering problems and making mistakes. By trying to implement the idea, you undermine the idea.
This is especially true of using an Agile approach to software development, particularly a Scrum approach. In Scrum, every day, the team have an opportunity to report any problems that they’re finding in their attempt to realise the dream, the idea that has been funded. Add into this mix user researchers who are talking to the users about their needs - and we absolutely should add them. Then, pretty soon after the project starts, you start to get a picture of what users think of the idea. Maybe they love it, maybe they hate it, maybe they think about it in a way that is totally unreasonable. Maybe they point out a really good reason why it won’t work. Maybe they think about it in way that was totally unanticipated.
However, they think about it, it’s almost guaranteed that they way that they think about it, isn’t exactly the same as the way the people who got the idea funded think about it. And to them – the “keepers” of the idea - unless they have deep and strong experience in product management and development, this is going to appear as a threat. A status-lowering threat.
And this is a sticky, difficult, delicate and business. On the one side we have the dreams, on other side, where we’re headed is a value stream that delivers at all will deliver something that is slightly different from the dream. Something that considers users, their enthusiasms, capabilities and limitations. It also, if it’s got a chance of success, should address the interests and concerns of lots of other stakeholders. Regulators and spectators and possibly investors.
Note that this vision of a project as a difficult balancing act between the dream of the people who funded the idea and the wants and needs of the people, which also incorporates new values that you discover on the journey. This isn’t exactly a “standard” view of project management.
But it is a standard account of something else. An adventure.
In a lot of adventures, the hero has a dream, a vision. They have no real idea how they’re going to realise that vision. But they set off to try any way. On they way, they find things (a sword, a statue, an inscription), people tell them things (an old man in the forest points in a certain direction), and then they start to get a better picture of what their quest might actually be about. In a final scene, they put all of these things together, save the day and win the prize and then go home for whatever the nicest meal possible, in that time period, on that planet, and in that culture.
If you’re trying to deliver a project, you’re on that kind of adventure. You might not be comforted to hear this. And weirdly, the people who had the original idea for the project, and the people who funding the project, they probably won’t be that pleased either, but that’s where you are. The idea is just that start. You have to head out on that journey. You have to find what’s valuable. You have to find the jewel, the chalice and the sword and throw them into the fire in the temple in the right order, then you can save the world and go home for tea.
How does this help? How does seeing a project in these terms make “delivering the impossible” any easier. Remember the quote from Alan Kay? “Point of view is worth 90 IQ points.”
I believe that thinking of a project in terms of value streams, a virtual one, that deals in dreams and a virtuous one that needs to be built through course of the project, does make it easier to understand what’s actually going on in a project. For example, this view of a project explains the team’s reluctance to tackle the pirate ship [Chapter SHIP]. Why don’t the team want to tackle the pirate ship? They don’t want to go on the adventure! And why would they? Adventures are dangerous and uncertain. When they have either heard from the owner of the ship’s own mouth, or they’ve just gained a very good intuition from the way the owner has reacted to even the tiniest thing going wrong or turning out differently than they expected. In order to go an adventure, a team need encouragement and reassurance and someone who knows the kinds of things they should do while they’re away to give them the best chance of success – that’s you!
Understanding this picture of a project, as the construction of a path through a wild and unknown space, also helps you with one of the major causes of feeling bad for any project manager - the principle of commitment and consistency.
When you understand that the thing that gets a project funded is an idea, and the things that get ideas funded isn’t very closely, if at all, connected with their deliverability, but very closely connected with a certain kind of “shiny” simplification, “new”, “fast”, “just like the old system, but better”, “Using AI and blockchain.” You start to realise that all a funded project is, is a gesture in a certain direction. Nobody knows exactly what you’re going to find there. Nobody knows if you’re going to be able to put together what you find there and get it to deliver value. So, what can you possibly promise? What can you possibly commit to? How can you be consistent?
You can commit. You can commit to going on the journey and taking the team with you. You can commit to doing all you can, as a team, to explore the area that the project points to (this is the “swamp” that we’ll talk about in the next chapter) and you can commit to finding what’s useful valuable and attractive there. [Chapter SWAMP]. You can commit to putting together a prototype value stream that connects these values together to deliver that value as soon as you possibly can. That’s what working software is, and we’ll be talking about it in [Chapter SOFTWARE].
Understanding projects in this way, is both good news and bad news. The bad news is that for almost all projects, there is no way of taking the idea, the thing that got funded through the “virtual value stream”, and just implementing it. There is almost never enough detail in the idea, in fact lack of detail is probably part of the idea’s appeal. And there’s even more bad news, once you realise that the only way to realise the idea is to fully explore the area that it points at. Once you understand that then, having discovered those values, you have to connect those things together in a “virtuous value stream” that actually delivers on those values. That’s a lot of work. And it’s work that has to be done whilst somehow not upsetting the people who had the idea.
So, lots of bad news. Is there any good news? Well, the good news is that if you follow this approach, you will have given yourself and the people you work for, the best chance of delivering on even the most impossible-sounding projects. Looking at projects in this way, might just give you the bump of 90 IQ points that Alan Kay talked about. It helps you know what you’re doing. Why are you doing user research? Because that’s how we discover values. Why are you putting together working software and putting it in the hands of users? Because that’s how we take the values that we’ve uncovered and start to put them together into a value stream that can deliver and we can do that, on any project, no matter how crazy the idea sounds.
Finally, there’s one bit of news, that doesn’t come to every project, but when it does, it’s really good news.
The infamous veteran sales copywriter Gary Halbert (he wrote one book – he wrote it from jail where he was serving time connected with something he’d written in a sales letter). Gary Halbert tells a story of a question that he asks people who come along to his copy writing courses. He sets the scene. I’m paraphrasing here: “You’re going to have a hamburger stand, and I’m going to have a hamburger stand. You can have anything you want to make your hamburgers sell and I’m going to have just one thing, and I’m going to beat you every time.”
Of course, his students now play what we’d recognise as the hipster burger game. “Kobe beef”, “Artisanal sour dough bread” and “Ethical meat grown in a lab.” Lots of fancy features on the product.
Then Gary Halbert tells his students the thing that he’s going to have that’s going to mean his burger stand is more successful than theirs – a hungry crowd.
Essentially this applies to software development. If you have a hungry crowd, that’s the best bit of news you can possibly get. If the organisation that is paying you to deliver this project really, really needs this project to be delivered, that is a huge benefit. In my experience, when an organisation is really, really desperate to have a piece of software delivered, they will actually tolerate the kind of approaches that we’ve talked about. Notice I say tolerate, that’s a lot different from “enthusiastically support.”
Pull, discovering pull.