DOP 107: Getting Into the Flow With Value Streams

Transcript

Steve: [00:00:00]
I think agile puts people's mindsets in the workshop too much and keeps them in the workshop very often and the factory gets neglected and we can't have too much factory, but we need to balance workshop and factory. You need to have that creation matched with a machine for getting it out, getting feedback, adjusting, and adapting with the idea that this is going to sustain forever.

Darin:
This is DevOps Paradox episode number 107. Getting Into the Flow With Value Streams

Darin:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin: [00:01:25]
Viktor, it's almost spring time. Do you know what spring time and summertime mean?

Viktor: [00:01:29]
It means that it's not summer yet.

Darin: [00:01:31]
It means it's not summer yet and really I'm talking about, I guess the Northern hemisphere, not the Southern hemisphere. Apologies to everybody in Australia right now, because it's starting to get cold there, but I'm thinking summertime and I'm ready to go out to the lake or maybe out to the river and go do some tubing. What about you, assuming that you are not in lockdown anymore?

Viktor: [00:01:50]
I still need two months until it becomes warm enough for me to go out.

Darin: [00:01:55]
Okay, so let's fast forward two months. Let's assume that it's there. Are you ready to get in the river now?

Viktor: [00:02:02]
river?

Darin: [00:02:03]
Yeah, let's get in a stream, get in a river and go ahead and start riding down the, do you do that in Spain? I don't know. It's a thing in the States.

Viktor: [00:02:12]
It's not the thing here. We like swimming pools.

Darin: [00:02:15]
Oh, you like swimming pools. Okay. Why, why am I going down this route? Who

Viktor: [00:02:19]
I, I don't understand. I've I've, I'm trying to figure out where you're going. I'm not getting it yet.

Darin: [00:02:24]
It's usually, that's the thing that I'm, I have no idea where you're going, so at least the shoes on the other foot today. Today we have a guest with us, Steve Pereira. Steve, thanks for joining us today.

Steve: [00:02:35]
Thanks for having me.

Darin: [00:02:36]
And the reason why I was using the stream and the river analogy is Steve has a belief that value streams are important and not only are they important, they're critical for an organization to actually be successful. Is that a correct statement or at least a reasonably correct facsimile of a statement?

Steve: [00:02:56]
Yeah, I would say that that's pretty tame as far as all the views that I hold that might be controversial. I'm happy with that.

Darin: [00:03:03]
okay. We're okay with tame before we get to the controversial, why don't you introduce yourself a little bit better than me just saying, Hey, here's Steve, then I want you to go straight into give us the most controversial statement that you have maybe statement or belief, take your pick doesn't matter about what you think value stream is and is not.

Steve: [00:03:23]
I've been in tech for about 20 years, probably more than 20 years. I started in tech support actually and that's really when the first time that I encountered a value stream without knowing it. No, wait. First time would have been probably delivering papers or making pizza, but in the tech world, I started in tech support, answering phone calls and helping people with printer problems and Windows problems and I moved into desktop support and IT management and then into build and release engineering and then I was consulting for a bit, and then I was a CTO of a startup. Then I started this company that I'm working on right now focused on value streams and it's really the culmination of my entire career's worth of learning and experience and pains and successes. So where I'm coming from, when I talk about value streams is experience in agile environments and agile failures and DevOps from before it was DevOps, back when it was systems engineering and build and release engineering and specific things in software development and software development life cycles and the common thread has always been this concept of flow of work and data and communication towards a customer. In the earlier days of tech and IT, the customer was invisible. The IT department was in the basement or sectioned off, away from anyone that they could harm with their technical jargon and systematic understandings of things. We know that that's held a lot of progress back, but I would say that the most controversial opinion attached to that is the idea that everything that we're working on right now has evolved out of this project origin for IT where we had a start and a finish and there was a big deadline and we were trying to get a lot of work done and we had a budget and we wanted to know everything in advance. We wanted to plan. Agile arose out of a reaction to that. DevOps arose out of a reaction to Agile and the whole time we had lean, sitting in the background, quietly laughing, while we ran around with this bad understanding of how to get work done in technology. I think that there is more that we can borrow and learn from lean and manufacturing than we can ever learn from projects and the origins of Agile and DevOps and we're starting to realize that and we're walking back to the path where we veered off into Agile and DevOps with this project assumption towards the highway, which is this continuous sustainable value flow that is focused on customers and customer outcomes and aligning everybody to value streams.

Darin: [00:06:33]
I'm going to probably put words in your mouth. So you're saying that projects are useless and a waste of time and if you're basing all of your software engineering within an organization around projects, because that's what the tools allow you to do, you're just wasting your time and your customers time or did I take it too far? I probably did.

Steve: [00:06:51]
That's definitely an extreme interpretation. There's value from sprints. There's value from spikes. There's value from a very short term effort with a very defined purpose and desired outcomes. Certainly, but I think that's just compensating for a lack of flow. If we had a process that worked for delivering value continuously and continuously learning and adapting, we wouldn't need projects. What would be the purpose of a project that has a defined start and end point? We would continuously be satisfying customer needs and desires and a project would be irrelevant. That would be a smaller goal than the ultimate goal of continuous value delivery. I think that if we shift the paradigm of focus towards continuous value delivery, all the things that we thought we had to get from a project become part of the way that we work and part of the system that we create for creating and delivering value. We can accomplish all the goals that we would with a project with a higher degree of success. Historically we have not done well with projects. I think that's safe to say. I think that's being generous because anywhere between 60 to 90% of IT projects fail and it doesn't fit the 24/7 constant rolling releases, security update in the middle of the night, vulnerabilities that arise out of nowhere, mode of operation that the world is in right now. There's no way to say that when we finish a project that anything is done, unless we don't want to derive any more value from it, or we just want to ring it out and ride it until the wheels fall off. So I think that a more sustainable and scalable and adaptable practice is to build systems of value creation and delivery that are continuous and flow directly to customers.

Viktor: [00:08:54]
I have similar line of thoughts. I'm curious, what is the problem with projects? Is it their duration or the existence themselves? Because if it's duration, then we fix it by having a higher frequency sprints. If the problem is beyond that, then having shorter living projects, like a sprint is not really fixing much, at least that's my line of thinking. If the problem is that I have a project, what do I gain by having a project that is two weeks long instead of four?

Steve: [00:09:29]
It's a few things. Certainly the longer you try to predict out into the future, the more wrong you're going to be. The more you're likely to be surprised unless you're engineering that future, unless you are making that future happen. I think a sprint is a really small project, right? You're just chopping it up into a smaller piece. But you still have this commitment towards a fixed scope and everyone says, no, it's meant to adapt. You're meant to adapt, but eventually people get annoyed when you are constantly changing the scope and you're constantly missing the deadline and you're not making the sprint commitments. They want these commitments to be fixed and they want people to be accountable and they want to be able to measure how well we're able to meet our commitments and there are people who do agile really well and they just follow the manifesto and the manifesto isn't wrong but what happens when you follow this mindset of start and stop and iteration? In my mind is that you neglect the process. You neglect the value of the value creation and delivery process in a way that if everyone in a factory were to be looking two weeks into the future, the assembly line would never be built. You'd never build this highly automated tuned and optimized value creation and delivery mechanism because you would never be focused enough on the process, on the machine that produces all of the value. You spend all of your time in the workshop, coming up with the product and designing and trying to create something of value, but none of the time on the scale, sustainability, delivery aspect of it and I think that we need to strike that balance. I think agile puts people's mindsets in the workshop too much and keeps them in the workshop very often and the factory gets neglected and we can't have too much factory, but we need to balance workshop and factory. You need to have that creation matched with a machine for getting it out, getting feedback, adjusting, and adapting with the idea that this is going to sustain forever. If you're retiring products, you're keeping the system by which you create and deliver products so that you can build the next product. Your entire organization should be optimized towards building whatever kind of product you want to build, but I think we focus on individual products, individual projects, and we don't focus enough time on this. The fact that almost all of these activities are the same and if you get really good at them, it doesn't matter what you're trying to build and deliver. If we look at a company like Amazon, the reason they have like a thousand services is because they build these machines. These teams are able to build and deliver value with a high degree of autonomy and a high degree of velocity and speed because they build according to a value delivery pipeline, a value stream that is highly optimized for value delivery, adaptation, customer feedback, reliability, autonomy. All of these things that make for continuous value delivery. I mean, they're not retiring products very often, but they're constantly releasing new ones.

Darin: [00:12:39]
Well, AWS, I don't believe has ever retired a product, whereas Google, on the other hand, you can't keep up with their retirement schedule.

Steve: [00:12:47]
Yeah, and I think that's good. I think you have to kill off things that aren't working for you and it's good to experiment and make bets, but there is something to be said for Amazon's ability to satisfy customer needs. I don't think that Amazon really goes as far as Google in terms of like moonshots and trying to do things that may or may not work. I think Amazon Web Services is very good at, people have been asking for this for years, we're going to build it. Finally, now we're going to build it and we know it's not going away because the Internet's not going away. They have a pretty solid business model that way. But I think understanding that the internet was not going away, that infrastructure is not going away, that people are always going to be in varying stages of maturity meant that they could build this system for building APIs and services products that was leveraging the best knowledge in the industry and have this high degree of technical capability that ensured that they were building not only the workshop, but the factory behind it to leverage the scale, the sustainability, the margins that you get from building this value creation pipeline, the value stream.

Viktor: [00:13:53]
I have a feeling that Amazon's factory is actually, more than anything else, a huge number of small workshops, that they are very good at recognizing that every team has a product and every product has a user and those users sometimes, or actually more than sometimes are internal users. So there is a relatively small team that makes sure that all other teams are having tools to build stuff. Those teams do work in small workshops. It's just that they're very good at combining those workshops into factory, right?

Steve: [00:14:28]
We're probably talking about the same thing here, but I think that Amazon's focus on creating highly capable and advanced pipelines is an incredible investment that a lot of companies need to leverage, if they want to really change the way that they built and release software. That's the factory I'm talking about. If I want to spin up a new product inside of AWS, I've already got a pipeline, right? Probably in two clicks, I've already got something that's going to get any idea that I have out to the world, probably in a production ready state, just kind of switched off and at some point I can turn it on for internal users. At some point I can turn it on for beta users and then I can turn it on for production, but I don't actually stay in the workshop the entire time until I'm ready to go to the world. I'm simultaneously in the workshop and in the factory, I'm leveraging the factory because the factory is basically my path to production. I think a lot of organizations, especially agile adopters that at a low level of capability, they don't have that path to production or where the path to production is a rocky footpath instead of a highway.

Viktor: [00:15:39]
What I'm experiencing often is that we have those teams that are organized in whichever ways are organized, but very often insufficient number of people in organizations who understand how that hypothetical factory works. Everybody's dedicated to their small piece of the phase of something or the part of that machine. Nobody really knows how it works. We very often get to the situation where each of those phases or products or whatever it is that we are doing are sub-optimal because, Hey, I don't know what after me. I don't know what comes before me.

Steve: [00:16:13]
I think that is the mark of a poor factory, because I don't think it should have to matter. When we get on the highway, we know how to use the highway, but we don't know the regulations that it's adhering to. We don't know the structural specifications. We don't know how to build our own highway and we certainly couldn't fill a pothole on our own. We might have ideas, but we don't have to care because it's taken care of by somebody else. We get to leverage it and we get to do what we need to do by using it and I think that's where we need these value creation pipelines to be at is a full commodity that if I have an idea, I have a channel. I have that path to production that's ready to go and I don't have to think about it at all. I think every organization needs a Heroku or better that they can leverage whether they build it themselves or they hire it out because that path to production is so critical and it's so often neglected. It is the way that you will get the fastest feedback, have the best security compliance. You will have the most developer happiness. You will have the happiest customers because you'll be able to adapt to any failures or any challenges, any missed assumptions you can pivot, you can adapt. I think that path to production is absolutely critical and it's what I like about how much enthusiasm I'm seeing behind team topologies and people talking about platform teams. I think it's about time that we started talking about platform teams and platforms as absolutely necessities in software development and something that really needs care and feeding because if it's the foundation of all of your products, it should get a lot of attention, much more than your products, because one single product should be somewhat autonomous, but your platform is the foundation for all of your products, for everything that you're delivering. Paying less attention to it than your products makes no sense. If you're paying more attention to your side roads than your highways, then no one's going to be able to get anywhere or if you build a fantastic stadium in the city to use another analogy, but you don't have a highway to get into the city, then good luck. People are going to hate that experience and you're not going to be very successful.

Viktor: [00:18:23]
I agree. I think that one of the changes that we're also seeing is different type of externalization of the work. Like in the past, we would have situations where almost every company should have both people who know how to drive that car in a highway and know how to fix the holes in the highway and we're slowly realizing that, Hey actually, I might have external company like AWS that is doing a lot of that work so that I can focus on driving instead of focusing on building the highway.

Steve: [00:18:53]
Yeah and I think that a lot of companies are starting to realize that this is more important and more critical and more valuable than something that we should just toss to our engineers and say figure it out and have them say, well, you know, my resume could use some Kubernetes, so let's try that or I've never tried this technology, but it looks really promising. Let's use that. You would never create an experimental highway, if it was really critical, the main artery into your city, then you're not going to try and create a grass highway based on someone's idea that that might be a good idea. Maybe this is overextending the highway analogy a little bit, but I think that companies really need to have this strategic perspective on all of this and I think that's starting to happen. I think what has challenged organizations and thinking about technology was, again, back to this project and IT origins, it was so divorced from business, it was so separate from what people learned. The leadership in the organization, if they have an MBA, they understand lean. They don't understand IT projects, but they probably have a lot of understanding of lean and traditional manufacturing and traditional value delivery. You can leverage all of that understanding if you have this common dialogue around value creation and delivery. It gets really challenging when you have the business talking about value streams, because businesses are all about value streams. If you talk in the terms of the business, you'll have a much more productive conversation, but if you start having a conversation of we're gonna lay this out as an 18 month project and we have to have QA for three months and we have to do all these things, it doesn't make sense to a business person. I think they really struggle to wrap their heads around it and why is this so complicated? I think you get much better results when you follow something like a lean approach, a lean startup approach as well, where you're trying to deliver value continuously and think about building the highway. Think about investing in the pipeline.

Viktor: [00:20:51]
The problem might be that it might be difficult for companies to establish that balance, right? Because you do need some longer-term vision kind of, Hey, we are going towards Mexico, right? But not necessarily that the trip should be in one go. It takes three months to get there or whatever it is. So I do believe that we should be delivering value all the time, but then I've seen also other extremes where there is a value in each individual piece without leading really to some bigger value coherent story, right?

Steve: [00:21:21]
Yeah, I think that for way too long, we've had IT and tech and software separated from customers where the business still own the customer, the business was still responsible to satisfy the customer and software was just a means to an end. It was just give it to us, make sure it's where it needs to be and we'll take care of it. We'll make sure that it's doing its job and same with IT projects like infrastructure. It's just get me these requirements, make sure it does this, this and this and we'll be fine and then you can move on to the next thing. Once you connect these things to the customer and you connect them all the way back up to the values of the company and the company goals and objectives and you start looking at that value flowing from here's where we want to go to satisfying a customer need and desire, and ideally anticipating those effectively using hypotheses to experiment in new ways. Then all of a sudden, you're going to get better outcomes because you have this connection to the ultimate goal and you're getting feedback from the right place instead of having this game of telephone. We had this separation where it was the customers tell the business people, the business people tell the tech people and they're all speaking different languages and the more that we can connect the value stream all the way across the business, through the technology, out to the customer, then that feedback starts speaking the language that everybody understands and I think that the model of the value stream really puts it into a perspective that people inherently understand. It's easy to wrap your head around something like a value stream. It's very simplified representation of value delivery, where you don't have a big Gantt chart. You don't have a bunch of requirements. You don't have a bunch of speculation either about here's what we need before we know what we're even doing. The value stream mindset says build the highway, focus on the highway and then anything that you want to do, whether it's something that you've wanted to do forever, or just comes up tomorrow, or it's something that your customer tells you about in three weeks, you can respond to that because you have the highway. You have the path to production that's highly optimized.

Darin: [00:23:27]
What happens and this is a very strange parallel because I had this conversation with my mom last week. She's 85 and doesn't like driving on the highway anymore. Fair enough. But I've gone into companies and talking to teams it's like, well, yeah, we know that highway exists, but we don't want to do that. We want to go blaze our own new highway. What's your answer to that?

Steve: [00:23:47]
Oh, I'd love to know why. I think that there could be a few reasons for that. It could be that the highway, isn't actually a very good highway. If it's full of traffic stops, if it's full of potholes, then sure. You're gonna want to say I don't want to deal with that and I think I have a better way, but I think that in an organization that's actually investing in value streams, that's not likely to be a viable option and you could compare the current highway to the proposed alternative and measure them both on their qualities and merits. It could be that some team has invented some leapfrogs process for delivering value. Maybe they want to use a different platform. Maybe they want to use something off the shelf that could be a better highway. Maybe it's a Hyperloop and maybe that's a viable option. I think in a lot of organizations you could have a highway and a Hyperloop. You're probably going to still want a highway, but a Hyperloop might be a viable option for, okay, well, we have this tier of products. We have this type of customer demand that needs to be satisfied a different way, or it needs to be faster than the highway. So given specific criteria, if A, B and C are true, we use the Hyperloop and for everything else, we use the highway and I think that's a viable option. It just means that you're splitting your efforts and now all the things that the Hyperloop people learn might not apply to the highway and vice versa and so you're likely diluting your ability to innovate and improve by dividing your attention and investing in two places. But that's a strategic decision. I think that's a viable, strategic decision.

Viktor: [00:25:26]
How do people building highways know that they're serving the needs of the people traveling on the highways? Over time, I'm just following the same analogy, over time and I think that I experienced similar thing in States whenever I travel there, that there are so many highways that actually everybody's more concerned about maintaining highways than actually building better ones, new ones. How do you strike a balance between maintaining a highway and building a Hyperloop? How do you know that actually anybody might need a Hyperloop if the only option is highway anyway?

Steve: [00:25:58]
Mm, that's a great question and I'm glad the analogy is serving us this long. I think I I have bad habit of jumping into analogies that I really haven't thought through that extensively prior but I like to ride things until they stop serving the purpose. In technology we have a lot of advantages. We can add telemetry to anything. We can measure usage. We can measure adoption rates. We can measure engagement. We can measure success in a number of different ways. We're in a much better position, although in a lot of highways it's very easy for them to track traffic and usage. Once your highway starts getting bogged down and people start taking the side roads, Google Maps knows when people are doing that. It knows when the highway has become a problem and when it's over capacity or there's some other issues with it. It's constantly under construction, so it's always down to two lanes. There's a number of things that you can gather that will tell you Okay well this is a matter of just improving the highway, widening the highway or because of all this developments that's happening in these specific areas, it makes sense to invest in a new highway and we can make the same judgment calls around pipelines for software. We can look at okay well all of our new products and all the products that we foresee for the next 12 months to three years are highly data and machine learning centric products. So investing in a pipeline that facilitates that would make sense. Creating a highway to serve that new neighborhood or planned development makes sense because we know that we're going to need capacity to satisfy that. That's going to be a competitive advantage. I think that in the case where we're trying to decide where to build a highway and to what extent, we have a lot of data around how many people are using the highway currently. How many people go and they spin up a project using something else and then at some point when it becomes too painful they roll it into the company process. Everyone goes and they create something on the Amazon free tier because it's too hard to get things provisioned under the company account and then they roll it in eventually when somebody finds out about it and calls it out or we have two processes. We have Amazon and then everyone else or probably more common we have Azure which is our primary cloud. We have this big deal with Microsoft but everyone spins up projects under Amazon because it's easier and they have more capabilities. Then we have this big problem when we have to bring things into production. We have to migrate them from Azure to Amazon. These are things that we can see inside of organizations. It's shadow IT for a reason cause it happens not very visibly but I think that these are things that we can measure and we can measure the friction and usage patterns that are around the pipelines and then accommodate what we see. So building a better highway based on the usage of the highway and the usage of the side roads and other modes of transportation.

Viktor: [00:28:53]
I was about to ask you a question and you already started answering that. The question is how do you see because we have situations in which highways are a monopoly and all the highways are built by one entity. Let's say my company builds all the highways that I'm going to use. That's a sort of monopoly in sense that I can not choose a different highway. What would be the level of freedom that I should have as a driver and I'm still using the same analogy to just go for some other pay that I might need to pay a fee for toll and just go to different highway, just kind of skip your company highway and go to Amazon myself, which is basically leading maybe to what you said about shadow IT. How much shadow IT should be a shadow IT?

Steve: [00:29:34]
I think it's helpful to have people poking at the system and experimenting outside of the highway. Obviously you don't want to duplicate efforts. You don't want to waste efforts. I think that having people who challenge the fact that this highway that we all have to use. Is it the best highway? Is it the best highway that it could be and is it the best highway compared to all the alternatives for transportation. I think that's healthy. I think the only way to have the best outcomes is to provide the best solution. Mandating that everyone does something is a recipe for disaster. You're going to especially depending on how you handle that. If you say that complaining about the status quo or complaining about the system is met with you're not a team player and focus on your job and not on this. Stop trying to rock the boat. That I think is a very dangerous pattern that happens in a lot of enterprises that try and go all in on a solution that doesn't necessarily satisfy the main users of the system. It's like creating a highway without considering the people who are going to drive on it every single day. You have to really optimize for the people who are going to be using this system and if you don't then they're going to go elsewhere. We've all seen these pictures of nicely paved sidewalks that edge around a park and then people cutting across the corner and you've got all the grass worn away. You have to accommodate reality. You have to accommodate what people natively want which is flow. People want an absence of friction. They want a sense of progress. They want a sense of ease, especially when they think that that should be available. There's a lot of places where we don't know that there's a lot better to be had. We don't know that things could be a lot better especially when we're in the work, we don't really get out of the work and look at the big picture very often which is something that I try to get teams to do by doing things like value stream mapping, but when people know that things aren't great and they're trying to cut corners just to get their work done, squashing that is a recipe for disaster. You're going to lose talent. You're not going to get the best outcomes and you're not really going to understand why things aren't going well because you will be missing feedback. You will be missing signals and data in the system.

Viktor: [00:31:49]
That might be one of the issues. At least in my experience the bigger, the company is, the less are people aware inside of that company what is happening outside. If you don't know what's happening outside then you don't have a point of reference, then your tiny little road is as good as it can get or maybe it is. Maybe it's the best can get, but maybe it's worse. Bigger companies tend to be locked simply because there are 10,000 employees here. We don't need really employees looking into what Netflix is doing, because there are 9,999 other employees that can help you and then you lose that. Then we end up still working on mainframe because that's the thing.

Steve: [00:32:25]
I think that there needs to be a balance. You certainly can't copy Netflix. I think a lot of companies try to copy what works for other players in the marketplace and even copying your closest competitor, who has an identical business model is a terrible idea. We know that that has applied to business for a very long time. I think we're starting to realize that applies to technology equally. You really can only do what you do as well as you can do it and you need to invest in your ability to do the things that you do. It's very important for these teams to look inwards, but from an outside perspective. I think that taking ideas and challenging the status quo, wondering if the principle behind another organization's success could lead to an insight or an opportunity inside their business. I think what people fail to do when they look at a company like Netflix or AWS, or a technical success story or a business model success story is to throw away everything but the principles. You really have to go back to what are the assumptions that this is based on. What are the things that are true universally that we might be able to consider. in our context and I think everything else has to go away. But, you know, if you look at a mainframe, what would have to be true for us to take advantage of another technology? What pieces would we have to move around on the chess board to create a different strategy to get ourselves out of the position that we're in on the board right now? You cannot copy someone else's chess board. You can't copy someone else's chess move. Your strategy depends on the game that you're playing right now with the pieces that you have in the places where they are at this very moment.

Viktor: [00:34:06]
I would challenge that just a little bit. Generally I agree with you, but now if I switch to chess pieces analogy instead of highways, that's kind of true after you get to a certain level. So I should definitely not copy the strategies of Kasparov or whomever was a good chess player. I'm not into chess so I'm guessing, but maybe that's not such a bad idea at the very beginning, if I'm very, very far behind and I'm actually more trying to catch up than to really be better than that somebody, right? I'm not going to other extreme saying that we should copy what Netflix is doing. I'm not trying to say that, but also see too often that we are going to other extreme. We can do better than Netflix, then I usually start ok do you know where you are compared to Netflix?

Steve: [00:34:49]
right, right, right. Or, or that there's nothing that you can learn from Netflix because you're in a different situation. I think that's also very problematic. I think that the mid point here is that every organization is not in the opening of a chess game. Their pieces are already scattered around the board. The game is already being played, so strategies around the best opening move or how to castle don't apply because you're already in the game. You've got to play with what you have and so moves won't really help you, but knowing where you can move and knowing general strategies, I think is very valuable and so it's kind of bringing it back to those principles, bringing it back to strategy rather than tactics, which a lot of companies try to copy is really where they should be investing.

Darin: [00:35:34]
So if someone wants to get on the highway and play a game of chess with you, how's the best way for people to contact you?

Steve: [00:35:40]
That's a great segue for me to introduce my website, which has a lot more information. It is visible dot is which is an Icelandic domain TLD. The last one left by the time I started the company. So visible dot is has a contact form. It has a lot more information about this and I would love for people to check it out and find out more about what I'm talking about when I'm talking about value streams and flow and flow engineering.

Darin:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.

DOP 107: Getting Into the Flow With Value Streams

Show Notes

Guests

Steve Pereira

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript