Subscribe
Share
Share
Embed
Steve Pereira describes the concept of value stream mapping, and how it, and related techniques, can be used to improve the flow of practically any process from product ideation to delivery and customer experience. Steve is the founder of Visible, and is obsessed with making tech human, and leveraging it to deliver continuous value.
Solving big problems with small teams
Jonathan Hall: Ladies and gentlemen, the Tiny DevOps guy.
[music]
Jonathan: Hello, everybody, welcome to another episode of Tiny DevOps, where we talk about DevOps for small teams. Today, I'm joined by guest Steve Pereira, who is-- Well, Steve, why don't you just introduce yourself here in a second, but Steve works with value-stream mapping, which I'm curious to learn all about. I hope you are too. Steve, would you tell me about yourself and value-stream mapping? What is it?
Steve Pereira: First of all, thanks for having me here. It's always wonderful to have these conversations and with a focus on small companies, I think that's a very unique perspective that I'm pretty familiar with. The reason being my last gig was CTO of a startup. We went from, I was employee number one, and we went to about 60 people when I left over three and a half years. Then I started Visible after that, which is a very tiny company of 1.5. I'm very passionate and familiar with the small business and startup world and the challenges there.
How value-stream mapping fits into this is, value-stream mapping was something that I discovered as I was looking for visibility and measurement across organizations. Trying to figure out how are things going? What does everything look like? What are we doing right now? Where should we be focusing? Value-stream mapping is really a practice of drawing out processes, but with a very specific focus on value creation and delivery. Not just a flow chart, not just a process diagram, the magic in value-stream mapping is that you layout the process, but you measure the performance of each of those activities.
We can dig into how that's done specifically, because there's a number of different ways that that happens. The magic really is in that combination of visibility and measurement that come together and help you narrow your focus from we could be looking at anything and we could have problems anywhere to these are the top three prioritized items that are going to drive the specific results that we want.
Jonathan: Fascinating. Let's take a brief step back here. Before we talk too much about a value-stream map, can you define a value stream so that we know why we might want to map it and improve it?
Steve: Yes, it's a great starting point. A value stream is the sequence of activities that go from the very initiation of a value creation process, all the way to the end result, so something that will be delivered to a customer. We want to cover the entire picture because hidden inside that flow of activities is a constraint, is something that is holding us back, and it is the one thing that if we were to address it would increase the performance of the entire system.
That's the whole founding belief behind value streams, is that you have a flow of work that is held back by one thing and that one thing, whether it's upstream or downstream, wherever it happens in the stream, is holding back the flow of the entire system, just like the bottleneck in a bottle or a clog in a pipe. Until you address that, everything that you do will likely make things worse, because you'll have work accumulating, you will have a disconnection between the work that you're putting in and the results that you're getting out.
Value-stream mapping is really a practice of identifying where that constraint and other constraints are in the flow, so that you can improve the performance. The scope of it matters because that constraint can be hidden anywhere in the entire process. In the context of DevOps, a lot of folks are looking beyond dev and ops because constraints can be upstream of that in program management, in product planning, in backlog creation, in scrum rituals, all the way downstream to things like marketing and success where we've already built something, but it's sitting around because no one can turn it on until we have a press release.
Looking at the entire start to finish big picture is going to highlight where the biggest opportunity is across the organization, not just within the boundaries of dev and ops.
Jonathan: Is it fair to say that a value stream, maybe an aspect is the life cycle of a bug or a feature request from ideation to release to production, and all the steps that happen in the middle, but you're going much farther than that, to not only is it in production but how are we now marketing it to end-users? Even before that, probably what led the user to request that feature in the first place, is that fair?
Steve: Yes, you really get the most benefit out of a value stream when it encompasses every single thing that can go into value creation and delivery, because just like we saw with agile, the success of agile led to DevOps because all of a sudden you had people optimizing the flow of development and we got pretty good at that. We could crank out features like crazy, and then they would hit the wall of ops and just pile up. It's because we weren't looking beyond development.
Now, we're looking beyond DevOps because we have either things piling up in other places, or we just have not enough like insufficient flow feeding an effective and efficient system of dev and ops. You don't want not enough work flowing through the system, you also don't want too much, and so you need that end-to-end flow to make sure that you can turn the dial on the tab, increase the flow and actually get more out on the other end.
Jonathan: That sounds really great. If you are in the position of say CEO or a high-level manager, then you have a purview over all of these things, but if you're limited to say the platform team or you're a developer, and you only have control over a small portion of that, is this still valuable, or are you limited in how valuable it can be?
Steve: This is a great clarification. You are, of course, limited anytime that you are looking at anything less than the entire end-to-end flow. You're limited to whatever your sphere of influence and visibility is. That's not to say that this is irrelevant to even individual contributors, because value streams are present at multiple different zoom levels. We can zoom out to the release, everything that it takes to put something in front of customers that they're actually going to use.
You can zoom in a little bit further to individual features or bugs or improvements. You can zoom even further than that if you wanted to use value-stream mapping techniques on your CI/CD pipeline. You could certainly do worse. You're going to get great results from all of those efforts. You're going to see the sequential flow of activities. You can see things that are running in parallel as well, it's pretty easy to represent those things. You can see things like tools that are being used across the value stream.
You can see different roles that are interacting with the value stream. You can layer on all kinds of different dimensions on top of it, and really understand it at whatever level of detail you like, and also the level of detail that's available to you. As an individual, what I could do is say, "I don't really understand what goes into delivering value to our customers, but let me take a stab at it. Let me take a stab at building out a value stream from my perspective."
That could mean that I have a bunch of question marks, a bunch of cloudy areas where I don't really know what happens here and here and here. As an individual, I could go shop that around the organization and say, "Here's the best I could do with my perspective. I'm trying to understand the end-to-end flow here, can you help me fill in the gaps?" This is the most ad hoc meandering path to mapping a value stream. Ideally, what we do is we get all these people in the same session and map collectively so that you get everyone's perspective at the same time.
You can go about this in several different ways. You could also run it as surveys, right? You could send out a survey to a bunch of people and say, "What is the sequence of events involved in this? Where do you think the constraints are? What are the things that you're responsible for in this flow and where do you think you're constrained by other dependencies?" There's all different approaches to building out that picture. You don't always have to be really high in the organization.
It helps to have somebody high up in the organization involved, because they can say yes to change. They can support efforts. Once we have the picture, that's half the battle, you really want to make change. You've probably have to have some support behind that. If it's beyond your sphere of influence. That's a long way of saying that, yes you can do this anywhere. If you want to really get the biggest bang for your buck, you probably want to involve people who have a high level of influence and visibility in the organization.
Jonathan: A value stream will really help, as you said, it helps to make visible bottlenecks and blockers to efficiency. How does the value stream map look? This is a podcast it's hard to show a picture, but what is it? Can you describe, what does it look like? Is it post-it notes? Is it a drawing? What is it?
Steve: I don't think it's too challenging to describe for a podcast luckily. If you go to Wikipedia and you look up value stream mapping, you are going to get something that's impossible to describe on a podcast if we only have an hour, but the way that I do value stream mapping is a very simplified version of a classical format and the classical format of value stream mapping is sequential activities and measurements.
Those are the two ingredients, you've got activities, you've got measurements. There's a number of different measurements that we care of that we care about. The most important ones are timing, because time is somewhat inelastic to us, and so it's a good thing to hang the value stream off of. We're looking at what are the sequences or what is the sequence of events? What are the activities that we're performing?
For example, if we're drawing this out or for using post-its, we will have a post-it for let's say sprint planning. Let's look at a sprint because a lot of people are probably familiar with the structural for sprint. We have a sprint planning, we're trying to figure out what to do, that's probably a meeting, it's probably an hour or two, so the way that I would structure it is I'd have a post-it for sprint planning. I would probably write on that post-it above sprint planning two hours.
I would probably put that on a separate post-it note because we also, so we have two timings that we really care about, but in value stream mapping, one is the step time, the activity time, the, how long it takes to do each activity. The second one we care about is delay time. How much time is passing between step one and step two? We have, let's say sprint planning, then we have backlog creation or let's say after sprint planning, we have backlog refinement, because let's say we captured a bunch of notes in sprint planning.
People have clarification's and so the product owner goes away and like updates a bunch of the cards in sprint planning, or in the backlog sorry. Let's say that that takes another two hours. We have timing for step one, step two in between, let's say they're finishing up reporting on the last sprint, or they have some other thing that like distracts them. They usually don't get to the next step for four hours. We would have two hour sprint planning, four hours delay, which I put underneath just for base reasons.
People can see examples of this on my website. There's lots of visual examples of this, but it's very simple. It's just activities, timing and you lay each of those steps out sequentially to build out this horizontal representation of the sequence of events, and the timing of each.
Jonathan: Okay. That does sound easy to visualize. I took your or I went through your, I guess I don't want to call it a course, the flow engineering course, and you talked about many other types of maps in there as well, an outcome map, a dependency map, and I think some others, how do these relate to a typical value stream map or are they like subsets or are they independent? What's the relationship between those things?
Steve: Yes, the other mapping techniques I basically added on because there are some things that you need to do before you start to map a value stream and then there are some things that once you discover a constraint in your value stream, you want to dig deeper into. We start earlier than mapping the value stream by breaking down a target outcome, because if you're mapping a value stream without a specific goal, it's challenging to know what detail you need to capture.
What level of detail you should be aiming for, who to involve in the mapping process, the scope of the value stream that you should be illustrating, there's all questions that hinge on an understanding of what we're trying to do first. That brought me to outcome mapping and outcome mapping is basically saying, "Here's what we want. We want to go--" The classic example I use all the time is we want to go twice as fast. We want to deliver features in half the time.
Starting from that outcome, what we actually do with that is, first of all, before we even decide on that, let's say we don't, somebody might hand us the outcome, "You need to go twice as fast," in which case let's figure that out. Oftentimes with or with teams, they're not quite sure what the best target to aim for is. They're not even necessarily clear that they have a target, and so we can do some early brainstorming to find out what is a good outcome that we should be targeting?
How should we phrase it? How should we clarify it to make sure that it's we all understand it, and we can all act in accordance to moving in that direction. We'll take an target outcome from the team if they're able to define their own target outcome, which is rare because teams are usually not that autonomous, but let's say in a smaller organization, let's say they're empowered to do that, or they're empowered to clarify an outcome that's been handed to them from, from somebody else.
They get form their own understanding of that outcome in their context. An outcome map allows you to break that down by looking at first of all, why is that valuable to us? Why is it valuable to the organization? Why is it valuable to our customers, which anchors it in meaning, so that it's becomes a little bit more powerful, and we feel a little bit more attached to that outcome, which helps fuel our efforts. Then we look at obstacles, what are the things that are going to trip us up?
What's going to slow us down? What are we going to need to design around or design solutions for in order to reach the outcome? Then we look at investigations. What can we do to learn more about getting to the outcome, avoiding obstacles, how we work together if we're aiming to tackle this outcome in a different way than we're used to, there's all kinds of things you can investigate. Then that brings us to measurements. How are we going to know how we're making progress or that we're not headed in the wrong direction?
You can define very early on. Here's how we expect to see progress. That then informs the value stream map, because now what we understand is, we know what scope we're looking at. We know what measurements are going to be important to us. If we're aiming to improve quality, sure we care about the timing of the value stream, but we also care about what percentage of the work is complete and accurate at each stage. That would be another dimension that we start to measure on the value stream.
Then we have two final maps of the core four that I recommend folks go through. These maps run in sequence so doing them out of order, doesn't make sense. What you are doing when you map in the sequences, starting from the outcome, you're learning more about, first of all, what is going to contribute to that outcome with the value stream. Then, with dependencies, we're seeing what is contributing to the blockers and the constraints in the value stream, what's holding the value stream back?
Then, with capabilities, we're saying, what capabilities would we need in order to break the dependencies that are holding back the value stream that is contributing to the outcome? Flow engineering flows through the sequence of maps that iteratively give you more detail, more understanding on how you are going to reach your outcome from, "We don't even know what our outcome is," to, "If we do these things, the outcome is almost guaranteed."
Jonathan: Nice. What metrics do you generally look at when you're starting, and then that you're aiming to improve when you map these processes?
Steve: This is a great thing to dig into a bit. The primary metric, the most important metric in a value stream and in any workflow is lead time. Lead time, meaning the time from when we start to when we finished the entire sequence of events. The reason for that is that is the time from idea to value delivery, the time that it takes to get someone what they want. It's also the time that it takes us to learn about what to do next.
Until you ship something to a customer, and they tell you, "This is great. I'd like more of this," or, "This is not quite what I was expecting. I would like more of something else," that is the most important activity in an organization. It's this value reconciliation because you're going from, "We expect this to be valuable," to, "Yes, it is valuable, and let's build the next valuable thing." Lead time is number one. Cycle time is another term that folks will see.
Cycle time is really the time it takes to do a subset of a value stream. It could be one specific activity, but it's probably used to reference the time it takes in your CI/CD pipeline, for instance, from a code commit to all your tests passing and triggering the next sequence. That's a good representation of cycle time. A lot of folks, right now, in the DevOps space, that's the only time they're looking at, which means that they get really good at that, but you hit diminishing returns with that pretty quickly.
Once you dip below something like 10 minutes, it's no longer a bottleneck. It probably never was your bottleneck. Oftentimes, the folks working in that system feel that it's an important bottleneck to address, because it keeps them from getting feedback. All of this is in service of feedback and delivering value. A few others, so there's an entire suite of flow metrics. We call them flow metrics. Folks can look up flow metrics, and there's a few different representations.
Dr. Mik Kersten created the initial set of what he called flow metrics for his book Project to Product where he starts to talk about flow in value streams. Then, I believe it was Gartner, the analyst group expanded it to a much larger series of measurements that look at things like they talk more about value, they talk more about work profile, which is what is the work actually look like as it's flowing through the system.
Mik Kersten, I think, pioneered the term flow distribution to talk about what percentage of the work fits into different buckets. The four buckets that he picked was technical debt, bugs, features, and the fourth is probably going to escape me. There's a number of different ways of inspecting the value stream with metrics and finding out where are things flowing well, and where are things being held up.
Another one that's pretty common is work in progress, because that's highly correlated to flow. If you have too much work in progress, people do too much context switching. There's a lot of inventory in the system, in the flow, which is costly. What you want to do is approach very low work in progress, fire out work, get feedback, pivot, iterate, improve and keep the flow as efficient as possible to maximize that delivery and feedback.
Jonathan: That sounds like it's closer to related than to the concept of batch size-
Steve: Exactly.
Jonathan: -from the manufacturing industry, of course. Of course, we have the same concept in software development in terms of resizing or splitting a story into multiple stories. Do you want to talk a little bit about that? I don't think it's a completely foreign concept, but it is a little bit counterintuitive that we would exercise the process more frequently with smaller amounts of work, and that that somehow makes it better. Do you want to talk about that a little bit?
Steve: I think what we've learned from Waterfall and even Agile is that the longer your process takes the less visible the issues are, the less pronounced the bumps are because, by the time you move to your next iteration, you've probably forgotten about all of the things that were challenging. You're probably not measuring because you're probably not iterating fast enough to be feeling the pain of repeated constraints.
When you try to accelerate things, and you try to iterate much more often, which means you have to work on less work in order to do that, to get faster because we don't want to be overloading people and just asking them to work more. We just have to be more effective, which includes efficiency. When we have longer cycles, let's say, we have a two-week sprint versus a one-week sprint. We're trying to push twice the amount of work, at least, through that system.
Which means that we probably have multiple items that each individual is responsible for. Probably, many of those could be dependent on each other, because what we're going to do is say, "We have two weeks, we can tie all these things tightly together, because we'll be able to collaborate on them, and we'll be working on them at the same time." What you do is, by having that large batch process, you're actually creating large batch change as well, which means you have higher risk deliverables.
You might have more things to test that are probably tightly coupled together, because you've tried to cram a lot into these two weeks. You have folks who are responsible for multiple stories, which they have to balance themselves. They have to say, "I'm going to work on this thing until I get blocked. Then, I'll shift to this thing, and then I'm going to come back," or, "I'm going to just work on this one until I'm bored. Then, I'm going to switch over to this one," so because of that context, switching, because of the fact that these people are trying to hold all these things in their heads, simultaneously, what you'll get is coupling.
You will have people designing architectures and solutions and code that is interacting with all the other things that are in their head, that they're trying to shift at the same time, "Oh, I can feed two birds with one scone if I just create this common library, which links these stories together, and because I have to wait two weeks before I can shift gears to this other thing, I'm going to cram this into here," or, "I didn't finish the last thing from the last sprint, I'm going to go back and do that. Now that I've learned about this, I'm going to actually go back and update it this way because of the things that I'm doing now."
All that is alleviated if you work on one thing all the way through that's as tiny and self encapsulated as possible, composable, and with minimal dependency, then you get that minimal coupling, ideally, no coupling. You have low cognitive load, people don't have to be keeping track of all these things. They're not bugged by other people who have multiple stories too, who all want to link things together so they can do something super elegant and clever.
You get rid of all of that, because you say, "I have one tiny piece to ship, I'm going to ship it in a way that it's completely isolated as much as possible, and I'm going to move on to the next thing that will also be completely isolated, unless I cannot avoid it at any cost." That is how you get scalable, simple, truly elegant delivery. Without all these tempting, let's connect everything together, and create the perfect solution, and also catch up on the last, the sprint, because we had a big batch, we couldn't estimate properly and we're still working on in this sprint.
Then we have the thing from four weeks ago because I introduced a bunch of technical debt by doing the same thing. All of this just piles and piles, and unless you move towards that simplicity of ideally single piece flow through the system, you will see these things accumulate. It has just been proven over and over again.
Jonathan: We've talked about a lot of things. We've mentioned a few books. We'll try to put links in the show notes of course. I don't want our listeners to be overwhelmed. They don't need to go read three books to do this. Could we go through a value stream map verbally just quickly and demonstrate how the process works?
Steve: Yes, absolutely.
Jonathan: Well, what's a good process to go through, or do you have a handy one?
Steve: Yes, my go to is making a cup of tea. Everyone knows how to make a cup of tea, so we could do that.
Jonathan: Okay.
Steve: If everybody wants to follow along, I'm going to try and do this strictly in my head, see if we can really do this simply. Let's say that the first step in making a cup of tea is filling a kettle. We fill a kettle with water. We set the thing to boil. Then we might walk away because we've got three minutes before the thing boils. Then we realize that the kettle's gone off and we come back, we grab a teacup, we grab a teabag, pour the water, let the tea steep, and then we drink the tea. That's our sequence of events.
Let's assign like arbitrary timings to this for simplicity. Let's say that each of those things, aside from boiling, the water takes about 20 seconds. We've got 20 seconds pour the water, three minutes to boil the water. Then all of this has no delay, except for when we boil the water, we set it to boil. It finishes. We come back to it two minutes later, because we were off scrolling Twitter or something. We got a little bit distracted, so we have one delay of two minutes here.
Then we've got 20 seconds for grabbing our teacup, 20 seconds for the tea bag, pouring tea, waiting for it to steep and then drink our tea. Out of that, maybe we're starting to see a constraint here. Obviously if we look at the timing of everything that's happening, boiling the water takes the longest amount of time. Good luck boiling water faster. We could get maybe a better kettle. Maybe we start with hot water, which is probably not people's favorite idea.
Maybe we could just say, we are going to commit to sitting right beside the kettle the whole time, so that we get it at the moment that it's finished. These are all things that people could think of when we're thinking of a value stream, even in software development, just like, "How do we address this thing that's taking up most of the time in the value stream?" That's the right approach. We don't want to attack something that's taking 20 seconds when we have five minutes in the middle of the value stream for boiling water and getting to it.
What are the things we could do? Well, first of all, what we could do once we see this sequence is that we realize, "Okay, well, while the tea is boiling, we can't be pouring the water into the teacup. To steep the tea, obviously you have to wait, you have a sequence, an enforced sequence, but we can paralyze a couple of other things. We can take getting the teabag, getting the teacup while the water's boiling, and then we save 40 seconds.
Maybe there's a way that we avoid walking away, maybe we commit to, we're going to check our email while we're standing beside the kettle. That's, it's a good chance for us to take a break. We check our email, we do something productive. We don't feel like wandering off. Now, we've eliminated two minutes, 40 seconds. Out of the entire sequence, we've probably saved about 30% by now. It's pretty common with everyone that I've talked to, and in my experience to look at a current state, like what we just described, and find 20% of the value stream that we can just quickly eliminate by doing simple things like that.
Let's run a couple things in parallel. Let's eliminate delays that don't need to happen, and that's then we start on our way, but let's say we want to keep going and get the most out of this. Let's say making tea is one of the most important things to us. We make it five times a day, make sense to kind of drive that lead time down, so we get our tea quicker. What we could look at is, let's buy a hot water boiler. We always have hot water. Maybe we fill it once a day at the beginning of the day, but we don't have to incur that step, so we're saving 20 seconds there.
We save three minutes of boiling time. We're saving our 40 seconds as well. We're up to saving six minutes now out of the entire value stream, which I think was probably seven minutes in total, maybe six-and-a-half minutes. That water boiler, the hot water, whatever it's called. I forget what it's called, but your source of hot water for tea represents a platform. This is exactly the thing that we aim for with DevOps, creating something like self-service CI/CD, self-service infrastructure, access to everything that it takes for you to do your job, whatever your job is like as an engineer.
The things that will make your job easier. that is exactly what we're aiming for when we're talking about going from a current state value stream to a future state value stream, is where can you be pulling things out of the flow, making them available as self-service so that they don't have to be addressed on demand in the flow, and where can we paralyze things, automate things, eliminate delays and handoffs and decouple dependencies?
Jonathan: I worked at an office that had a hot water faucet in the regular sink. It wasn't on every floor. It was one sink only that had that, but if you happen to work by, or you walked by there, you had your tea in 20 seconds, everybody else was waiting for that kettle.
Steve: There you go. I ran that a ton in my last job when I was going in the office, which has been a while, luckily, but you'd have people set the kettle and get distracted, and then you come back, you got to rerun the kettle again. Your cup of tea takes 10 minutes.
Jonathan: Suppose our listeners they're excited about this. It sounds useful. What should they do? How should they approach this in terms of introducing it to their team? Should they just start mapping things and hope the team catches on and say, "What are you doing? Show me that trick," or is there a more productive approach to introduce this concept?
Steve: I think mapping themselves could be productive. It really depends on the politics of the environment. I think in a lot of spaces, somebody introducing something new could be seen as posturing, have some kind of an angle, ulterior motives in the worst environments. In the best environments, you might run into challenges around, why do something new? What is this meant to accomplish? You have to put in some thought into sales.
How are you going to introduce this if it is valuable? How do you think about its value to you because you're going to have to translate that into value for others? Taking a step back and saying, "Okay, well here's why I think this is worth pursuing." Then you're going to have to basically run that through a Rosetta stone here's like, "Here's how this is going to be valuable to every other member of my team," and the organization because if it is something important then it probably needs to resonate with those folks as well.
I would probably suggest either checking out my eBook, which is a total start to finish. It's a free tour of the process with some examples of where this fits, and what outcomes you can expect. There's a video tour as well on the same page that takes you through the process from a high level-- I've got a few of those actually. That's something that you could share with your team and say-- Throwing people in eBook and saying, "Read this and it's going to be good for you." It's telling people to eat their vegetables it's not a great tactic.
A video is a little bit easier. You could say, "I thought this was really interesting. What do you guys think? Do you think this is worth trying?" It might be something that you just sit on until you have a challenging problem that you need to solve. Somebody comes to you and says, "You guys have to speed up, or the backlog is just growing out of control." That is probably the best time when you have an urgent challenge to address, and what got you here isn't going to get you to fixing that challenge.
When you need something new this practice of flow engineering and value stream mapping is there as an option that will include all the members of your team, that will allow you to understand, "What is this problem that we're dealing with? What are we trying to achieve?" All the way to, "Okay, we now know all the deliverables that need to be put in place to create this outcome. We know what measurements we're going to be using to measure our progress. We also know what methods we're going to use to impact the measurements to deliver the milestones that are going to deliver the outcome."
Jonathan: Good. We'll have links to those videos and the book, of course, in the show notes. Check that out. What else would you like to tell us Steve about flow engineering, value stream mapping before we get into specific resources to recommend?
Steve: One other thing I would point folks to is we recently published a course under the value stream mapping consortium, sorry, value stream management consortium. We've been talking about mapping all day, but value stream management. To introduce that to folks before I throw you a link that isn't going to be directly in context. Value stream management is about the entire domain of improving value stream performance.
It's a higher level practice than value stream mapping, and value stream mapping is a part of it. We created a value stream management foundations course, which has just been published. It's really cheap for folks. I think it's a $100 for an entire year of access to the materials, the community, all the resources, and continued updates. That is available to folks and I highly recommend that. Not only because I built half of it, but it's really like it's huge.
It's very comprehensive. It takes folks through origins and evolution of the practice all away from the 1400s to today. Not in crazy detail, but that's the scope we're looking at. The other thing that I would put folks onto is a newsletter which is chronicling the creation of a book on flow engineering. IT Revolution the folks who have put out The Unicorn Project, The DevOps Handbook, and a bunch of other excellent books have picked up a book on flow engineering that myself and my co-author Andrew Davis are putting together.
We are delivering the manuscript to that book very soon, and it will be refined over the next year, and coming out this time next year. If folks want to follow that process, get a bunch of early access to materials. Keep in touch with us as we evolve that material and deliver it in different ways. We'll have a link to the newsletter which will have all that content available.
Jonathan: Wonderful. Of course your website-- I guess you have more than one, but visible.is, that's your company, right?
Steve: That's right.
Jonathan: How else can we get a hold of you if people are interested in reaching out for questions or learning more about this?
Steve: Folks can reach me on LinkedIn. I'm on LinkedIn all the time. There's a lot of great discussions about value streams on LinkedIn. I recommend it if you're interested, there's great discussions. There's a lot of people to follow in that space. My personal email is steve@visible.is so please do reach out to me with questions, comments. I would love to talk to anyone who's interested in this.
Jonathan: Wonderful. We'll have a lot of links it sounds like in this in these show notes. If somebody wants just one link, where's the single best place to go if they don't have time for the others?
Steve: The ultimate link is vzbl.io/links. That is the link to all the links.
Jonathan: [laughs] All right.
Steve: I run into this problem all the time.
Jonathan: Yes. Sounds like you're prepared. Wonderful. Great. Thank you so much, Steve, for coming on. I'll be following you on LinkedIn along with hopefully all of our listeners, and we can improve our value streams.
Steve: I hope so. I'm very confident that we all can. Thanks again for the chat.
Jonathan: This episode is Copyright 2021 by Jonathon Hall, All Rights Reserved. Find me online @jhall.io. Theme music is performed by Riley Day.