Value Stream Management

0:09 Hello. Bonjour. I'm afraid that's the extent of my French. I do apologize. Excusez-moi. Thank you for coming along today. I'm really hoping that you enjoy this talk. This is something I have a passion for and I hope that comes through and I hope that you take that on board for yourselves and take that back to your organizations. So, hi, GitLab. Hopefully you know who we are and what we do, but you'll be able to pick up quite a bit more from this discussion. Now, what you've seen is that this is a talk about value stream management, and it is at its core. But today you're getting a bonus prize because there's something that we've been working on that we're only just starting to talk about now, which is something additional to that called a value stream reference architecture. So although I'm going to be talking about value stream management, you're going to be getting this in the context of then creating a value stream reference architecture, which I'm hoping you will find extremely useful.

1:17 So, first of all, brief introduction into myself. I'm Stephen Walters, Field CTO in EMEA for GitLab. My specialization is around I'm value stream management, but I've been operating in DevOps, DevSecOps now for 20 years, not that it shows. My experience and my background comes from many organizations, many consulting organizations, likes of Accenture and Cognizant and Hewlett Packard and worked in organizations such as Deutsche Bank and so on. So I've been there at the coalface and I like to say that I think I've done every single job there is in IT except for a network engineer. Apologies if you are a network engineer, but you guys speak a completely different language. I've no idea what it is. I'm also an ambassador with the DevOps Institute and I'm an influencer within the Value Stream Management Consortium, which I will briefly mention throughout today.

2:25 So why is a value stream reference architecture needed? In fact, why is value stream management needed? So I'm going to go through some of these reasons before setting this up for you, explaining to you about value stream management. There are three issues which exist within DevOps today, and I'm going to show you the evidence to back that up that comes from other independent reports. And hopefully some of you will say, yeah, you will understand this because you've felt some of these pains yourself. Problem number one. This is called mid-tier stickiness. Now, from the Puppet State of DevOps report 2021, they produced this chart. Hopefully you're seeing the big elephant in the room here, which is that for the last four years, The industry has been stuck in this mid-tier level. So over this four-year period, we've had a lot of organizations which have gone through DevOps transformations and achieved this mid-tier, but they've struggled to get up to the highest levels of maturity.

3:36 And what do those highest levels of maturity mean? It means they're getting all of the value out of DevOps that they want. They're getting everything that they expected to achieve. So what is it that this mid-tier is struggling with? Because even when you take into account the 8% that have gone up into the mid-tier and the lower tiers that have gone up into the high tiers, you've still got over 60% of organizations that for four years I've been stuck in this mid-tier. Well, as it was looked into further, it's because much of the concentration was around automation. And this is where it's going to sound strange to you that I'm saying automation tools is not enough from a tool company, from GitLab. But that's because we recognize that we want you to get the best value out of the tool. And it's because many organizations haven't just implemented this. Who here knows the CARMS framework? Jez Humble, the CARMS framework, that's one hand over there.

4:39 I'll just bring, CARMS, it stands for Culture, Automation, Lean IT, Measurement and Sharing. And what they specify is that for a true DevOps transformation, you need to implement all of those elements in balance. And the problem is many of these organizations have implemented tool chains. done the automation, but they haven't lean their processes. So in other words, they're producing things faster, but that means they're also producing all of their waste faster. They're not measuring to identify where they're improving or how they're delivering or where they're delivering. They haven't changed their culture within the organization, so they're still operating within silos despite having a tool chain that is operating. That's problem number one, which has got so big, they've even broken it down into three levels of mid-tier, which is always worrying. Problem number two.

5:41 Conway's Law. Who here knows Conway's Law? I'm glad to see so many hands go up on that, but for those who don't, Conway's Law basically states what, this was Mel Conway in the 1950s, who said that the architectural design of systems will reflect the communication structure of an organisation. So you think back to the days when we had big IT companies and big projects and what did we produce? We produced great big monolithic structures. We're now at a time where we're broken down into small agile teams and we have these small microservices. We have smaller teams, smaller broken down architecture. But that in itself has its own problems because with DevOps we've said, right, Let's get rid of all the silo walls. Everybody needs to talk to each other. And I've been there in organizations where they've had 40 microservices and all 40 are talking to each other. And what happens?

6:42 You have tight coupling and integration between every single one of those microservices, which means that when you want to change one microservice, you have to get 39 different impact assessments before you can make a change. Net result, three months before a change can be made. I thought Agile was supposed to be quick. We're supposed to be able to do all of this in quick and easy sprints. But the problem that we have is, as you can see in this quote from Courtney Kistler here, when we go into our organization, we tend to define our framework up front. We define our processes up front and we define our architecture up front. So we'll say we're going to have small microservices and they're going to be broken down into these levels. And then we pass them over to an organizational structure which is set up in a certain hierarchy and saying how we're going to communicate, which results in the problems with so many communication pathways, so many tightly coupled integrations. Good DevOps identifies clear responsibilities, high degree of automation, and most importantly, well-defined interaction paradigms and communication channels with other teams.

7:57 I think that's an important takeaway point. For everybody in this room to understand that good DevOps is not just about the technical things that we do, it's how we communicate with each other. And sometimes that can mean not communicating at all. Shock, as he just said, build a silo wall. Yes, sometimes building a silo wall is important. Problem number three. And this is backed up not just with data that we get from our own DevSec, Global DevSec Ops survey that we did last year. This is also backed up with information from the Value Stream Management Consortium, who in September this year produced the second state of value stream management. This is something we call tool chain sprawl. It's a situation where individual teams have their own responsibility for what tools they want to use. So they have many tools that they're using within their pipeline.

9:03 The problem is that you've got some sort of orchestration tool to link those tools, but all you're doing is linking the operation of those tools. not necessarily linking the data and the information that sits in the back end. So how do you find all of the relevant information of what's gone on within your tool chain? Not only that, you're not just one team. You are multiple teams or multiple products or multiple microservices that are supplying to a business service. So if you want to look at that business service and how it's delivering, you've got to look across multiple teams who are all potentially using different tools and all potentially measuring in different ways. So you're getting more and more tools. The result is, as you can see from this report on the Valley Stream Management Consortium, that you are relying principally on aggregation from several sources using a dashboard, or you're relying upon manual collection from several sources using a spreadsheet. How many of you, I can see smiles around the room from people who are actually going through that at this moment.

10:12 And this is why we have that need for something that can interrogate, that can look at the data and the information across an entire value stream. And for that, you have to understand what your value stream is and understand how you're going to measure your value stream. Think back to number one, the M in comms. So, three problems. Well, if we've got all of these problems in DevOps, do we truly understand what DevOps is yet? Well, it's yes, but cultural shift. I mentioned culture, yes. But we've got to stop talking about doing cultural change and actually do it. Actually make a difference. Automation and cloud, yes, but it's not just these things along. They don't make your DevOps highly evolved as you've seen. Security, yes, absolutely. And it can be expensive doing security, but it's even more expensive not doing security. Collaboration.

11:13 I've mentioned that. Collaboration is important, but it can create what I call communication spaghetti, where you see those lines of communication going between all of your various parts of an organization. Lean. Yes. Very important. in your processes, but are you leaning the right things? Are you leaning the things that are important? The number of times I've heard people say, yeah, we've leaned up our build processes and we've automated it, and when it was five hours manual, it's now five minutes automated. Great, how many times are you doing a build a day? One. How many were you doing before? One. So you've just introduced four hours and 55 minutes of waste into your process. You're not actually getting the value from it. And finally, measurement. And it's not just about measurement, it's about measuring the right thing. And understanding what's an important measurement to you is not necessarily an important measurement to somebody else.

12:16 It's a matter of perspective. So, how do we use value stream management? This is from the State of Value Stream Management Report 2022. The first report was in 2021, which had an earlier version of this. It has been tweaked, and I'm glad to say in all of the right places. This is the Value Stream Management Implementation Roadmap. If you go to vsmconsortium.org, you can get hold of a copy of this. You can download this for free. You can get hold of this diagram. And what this basically does is help you to identify how to implement your value streams, how to implement value stream management. And hopefully what you're seeing from this is it doesn't just help you in terms of your alignment of your people and your process and your technology. It's also a way of applying continuous improvement so as to continuously adapt to changes within your organizational structure, within your business structure.

13:21 The steps are to, well, just go. It doesn't matter if you're currently waterfall, if you're agile, if you're DevOps, where you are, just go, just start. It can help you in terms of those transformations. The first step, set the vision. What are your long-term goals in your vision? And the way I like this to be defined, I call it a value statement. Because it's about what the values are you want to deliver. Lesson number one about value stream management, it's about business outcomes. It's about delivering business outcomes. So think about what the value is to your business. I've already had one conversation today where the value to their business is it's about carbon footprint. Which might not sound like something that you would think about in terms of your CICD automation, but it's an important value to your business. And that is ultimately what you're trying to deliver. Your businesses may be in finance, pharmaceuticals, retail.

14:25 They're not actually in the business of producing software. They're producing software to enable them to produce their business. But that software is now a critical part of the supply chain of your business. The next step is to identify your value streams. Now, these two steps, identify and organize, are where the reference architecture comes in because people do find it difficult to understand what is a value stream within our organization and how do we identify is in that value stream. how you're going to set this up within your business. And value stream is something where you go from an idea, a concept, through to the point where value is being realized by your customers. Organize who are the people that are responsible for that flow of delivering that value. Mapping. Value stream mapping is a common exercise that's existed for a while now in DevOps.

15:26 Some of you may have been through it. We at GitLab provide value stream assessments where we can help organizations to map out their existing processes, map out a future state, and identify a progress path that will allow them to get from current state into a future state so they've got a better value stream delivery process. And then connect. Well, you connect with a DevOps tool chain tool. And of course, naturally, you would use the best in the business. But there's a deliberate pattern here, and I'm hoping that you see it, which is to identify the business streams and the people first. And after the people, then it's the process. And after the process, then it's the tools. So it's important to get it in that order correctly. And then with your tools in place, providing you are implementing CALMS, the CALMS framework, you should be able to do measurement, metrics, which allow you to inspect and adapt your value streams.

16:28 And then go through that cycle. cyclic loop of consistently or continuously performing improvements and change to your organization. There's obviously more to it than that. If you want to understand more, come and speak to me. Or speak to or get in touch with the Value Stream Management Consortium. There's a lot of great information on their page. This is also a great source of information and I would add this to a recommended reading list. I've got a copy in that bag down there. This is the book Team Topologies by Matthew Skelton and Manuel Pais. And this talks about how you can organize around value streams. It talks about the most important type of team being a streamlined team whose sole responsibility is the delivery of value. It's going from that idea to that conception. And then you've got very important teams, not as important as a streamlined team to the business, but still important, which are your enabling teams and your platform teams.

17:32 So your enabling teams are teams who are there to assist and ensure that your streamlined teams have everything they need in order to deliver value. What support do you need? What new things are coming along? New technologies? How can they improve the way they're working? For example, running a value stream management mapping workshop, value stream assessment. And then you've got platform teams. And this is where there's a term you've been hearing, platforming. engineering that's where they come in and this is why I scoff when I see headlines like DevOps is dead long live platform engineering well great if you just want to implement platform teams do that it's important but it's not the be-all and end-all it's not everything that you need And then you've got your complicated subsystem teams because, hey, who here hasn't used SAP or TIBCO or something along those lines that needs that occasional support? But it also talks about what the interactions are between those teams that I mentioned earlier on.

18:37 How are your teams actually talking with each other? And it's not just about collaboration, but it's also potentially operating as a service. So in other words, your communication lines between teams are really down to documentation and API. And that is forming a kind of barrier wall in there, but one where you know you are restricting things so that you can have things that are more loosely coupled. And likewise, facilitation, typically used by enabling teams. So the result is that you can use something that's called the inverse Conway maneuver. So the Conway's law now no longer becomes a barrier, it becomes an enabler. What we're going to say is, okay, if our communication structure is going to influence our architecture, Let's set up our communication structure to reflect the architecture that we want. And this then enables you to identify what your teams are going to be and how those teams are going to interact with each other.

19:39 Where you want a dependency and where you don't want a dependency. Where you want things tightly coupled, loosely coupled, or just completely decoupled. So, here's your little bonus slides. What is a value stream management reference architecture? So what we put together is an example. Before I do that, let's talk about this thing called value and what it actually means. I mentioned earlier on about it having different perspectives, different views on what you're measuring. There's two types of typical kinds of value that are measured. The first one is flow. And the best way to characterize that is, it's how you are delivering value. You're measuring how you're delivering value. Dora metrics. Okay? The mean time to recover, your change frequency rate, your lead time, your cycle time.

20:42 These are things that measure your value stream health, how efficiently you are actually delivering value in your organization. And these are probably the things that... You've been measuring, if you have been measuring, these are the things that you have been measuring for some while now. And these are the things that are being heavily put forward. But with value stream management, it's important to remember the other type of value, which is value realization, because these are the things that are important to your business. This is what you are delivering, not how you are delivering. This is what you are delivering. So you could be delivering faster and with less bugs and fixing those bugs quicker. But if they're not resulting in a faster customer journey time, and that's what your business wants, are they actually helping the business? Are you actually enabling the business? So you've got an example of some of those on there, and there's a greater list within the VSM Consortium State of Value Stream Management Report available.

21:46 But these are important. You okay? Yeah. I thought I'd caused him to fall asleep for a minute. There we go. There we go. Yeah, all good. So some of the values that you will typically hear are profit, loss, revenue streams. But not all values are down to monetary needs. You will see from the State of Value Stream Management report that one of the top three is NPS, Net Promoter Score. You need to understand that your customers are happy. One of my previous businesses, one of the greatest CEOs I ever had, said, forget about the money, concentrate on the NPS, because if I know my customers are happy, I know they're going to renew, and I know they're going to tell other people to come and use our service. The money then takes care of itself. Others that I've mentioned, I've mentioned about carbon footprint is another value which might be important to yourself.

22:53 And there's differences as well because you can get lagging measures and you can get leading measures. Profit and loss are lagging measures. They measure what your performance was, not what your performance is going to be. So for things like what the performance is going to be, it's things like customer journey time. How quickly can my customers get onboarded and using this and getting the greatest value possible from our services? These are important measures for them. How does that lead into a reference architecture? Right. Now, there's a lot of information on there, but let me stress, this is not a Spotify model. In other words, go away, take it, replicate everything on it word for word. Do not do that. This is an example. This is an example of how an architecture can operate and work together. And it is up to you within your organization to go through this process to define this.

23:59 Now, this is done within the team topologies model. So you'll see on the key that we've got our streamlined teams, we've got our enabling teams, our platform teams over on the far right. And we can see how they're built together. Now, from my perspective, there will typically be two types of streamlined team. There will be a DevSecOps service stream or a technology stream or whatever you want to call it. These are your typical two pizza teams, five to nine people. They will be responsible for a product, a microservice, a feature set, whatever it is that you want to define. And there will be multiple ones of those working together within a business service stream. Where your business service stream is this much larger capability, anything from 50 to 150 people. But the responsibility of the business service stream is delivering a complete business service, which is all of those products and microservices working together plus all of your other functions and capabilities.

25:04 Just because you deliver software does not mean the business service is there and is ready and is enabled. Training needs to be in place, marketing materials, sales need to be enabled and ready to go, governance, what are you doing in terms of finance and measuring the finance on that business service stream. And this is where there's an important aspect to value stream management that comes in, and it's a key differentiator. It's a true integrator of technology and business together. It brings the two together to operate within the same model and to be complementary towards each other. These teams, these service stream teams, are solely responsible for the delivery of value. Supporting them is a platform team, which might be your platform engineering team. So these may be responsible for database administration, network setups. These you can think of as shared services.

26:07 But don't think of them as development. Database development will take place within your actual streamlined team because they are delivering that as part of that service. These guys are delivering internally. They do not deliver to an end customer. They deliver to the streamlined teams within your organization. These are typically your platform engineering teams who will be your GitLab administrators or any other tool that might exist. You've also got within there this team here in purple. I'm not going to go into great detail about the complicated subsystem teams. You all know what they are and you all know how they operate. But what's important is how do you interact between those teams, which is typically you should be trying to operate as a service. Because you want to remove as much collaboration dependency that you're creating as possible. You should only really need some kind of deep collaboration where you know that there's going to be a very tight coupling or inter- between capabilities.

27:17 So even in these technology teams within a business service stream, should there be a fracture plane? Is there something we should be doing to put a barrier between these teams to prevent them creating a dependency that we do not want? Recently done a value stream assessment with an organization where their quality engineering team is operating as a platform team, but they are operating directly within the pipeline of these teams here, which means there's a dependency. So the moment the quality team is stretched or stressed, it doesn't just impact that team that they're part of the pipeline, it impacts every team that they're part of the pipeline on. So that's the platform team. And then in purple, you have here the enabling team. So these are the teams that come in and they will do facilitation. They will have more direct collaboration immediately, but only for a very short period of time because you don't want to be creating dependency between them and what you're delivering.

28:25 Their purpose should solely be to be looking at what these teams are actually doing and the shared services that they're receiving something from and identify where they can make an improvement, apply that improvement and then step back. They should be no longer involved. But what they should be able to do is to act as a shopping cart service for these improvements, to share these improvements with the rest of the organisation. So improvements that have been identified within one streamlined team can be shared with other streamlined teams as well. The S in comms. There's a few other interesting things that you'll see on here. I've identified some little pink fuzzy bits, and these are areas that value stream management at the moment is still trying to identify how it can incorporate it. So, value stream management as a discipline has been around for a hundred years.

29:28 Okay? In fact, some believe there's a theory it goes back to the monks writing books 500 years ago. But the first modern recorded use of it was Henry Ford as he was producing the Ford manufacturing lines. Then that went on to be perfected by Toyota with the Toyota production system that so many of you in here already know. And over the years, you know, we've had Taiichi Ono produce the Toyota production laws that have been in place. And we've had books around value stream mapping. But many of these have still been based around the world of the supply chain in manufacturing or in retail. IT has only started to look at the implementation of value stream management since 2018, when Forrester first produced their wave report. Since then, Gartner have produced a report and the Value Stream Management Consortium was created in January to March last year, which I was immediately part of that group when that was created.

30:36 So it's very, very new within the technology and within the IT industry. So there are still elements that we're still trying to come to terms with. Things like the fuzzy front end. This is something which has actually existed in business for a long time. But at the moment, the way we technology measure value stream is from the point of development team or the point a team has been created to create a solution that will deliver value. But there's things that go on before then. There's business plans. There's looking at the validity of that business as to how it can operate, what that service can actually do. And that can be as much as 90% of the timeline of delivery. The final 10% is the time it takes you to actually create that system and deliver it to the customer. The fuzzy back end, well think about it, when you deliver your technology, when you deliver your IT system, is the customer using it from day one? There's potentially delays in them getting value from it in the time it takes to train them, in the time it takes to train you,

31:42 in the time it takes your salespeople to be trained up in order to sell that product, to make people aware of it through marketing. Through the materials that go out. So the moment it's delivered is not the day the customer is getting value. The customer could be getting value one week, two weeks, four weeks down the line. And the job that we need to be doing is to be bringing that down to zero as much as possible so that they can get value near instantaneously from your service. And then of course we've got KPIs, OKRs, value and vision statements. They're being defined now, but how are we defining them as part of a value stream? And then this is where something new comes in, some key VSM roles. These are new roles that you will start to see appearing in the marketplace. Somebody mentioned before that they're having discussions with their CFO. I'm not going to ask them to put their name up. In 2021 State of Value Stream Management Report, they put forward a new role called a Chief Value Officer, which they said would be replacing Chief Financial Officers.

32:50 In the 2022 report, 4% of those organisations had replaced the CFO with a CVO. The difference being a CVO is a is not just responsible for profit and loss and balancing the books and understanding where the money is being spent, but all of the other values that the business is dependent upon delivering and ensuring that the rest of the business is targeted against those values, defining the value statement and therefore defining the OKRs and the KPRs that the organisation is going to be delivering. Other roles, value stream lead, somebody who is responsible for the value stream, because I'm hoping something you've seen from this is that, you know, in the past we were organized around projects and we moved to being organized around products. Well, you're still sort of being asked to be organized around a product, but where that product is considered a value stream. But there are other things which are value streams which are not a product. So we're now asking you to also organize around them. And what's more, a value stream potentially exists within your organization longer than a product does because products can be replaced, but the business service persists.

34:03 So value streams live longer even than products. And so you've got value stream leads who are responsible for that value stream, even within the platform teams. You've got value stream engineers who, by the way, are not developers, not people in operations, not people who've got a job description with 2,000 different roles that we expect them to fulfill of everything on there. You can see I've got a bugbear over the term DevOps engineer. But a value stream engineer is there principally to ensure that the value stream within your organization is operating efficiently. You've also got a value stream architect who is responsible for your reference architecture diagram, understanding where changes need to occur, matching the vision, identifying value streams and helping them to organize. And then finally, a value stream facilitator who is Principal responsibility is for ensuring that these teams are enabled with their value stream capabilities as quickly as possible.

35:06 So, I think we're just about on time. Rush through that. I'm out of breath. I need a drink. But. Final summary, how does this resolve our issues? Mid-tier stickiness. This is about aligning automation now to culture, to lean IT, to metrics and to sharing centered around business outcomes. Conway's Law. Conway's Law is now no longer a barrier. We can implement the inverse Conway's maneuver in order for it to be an enabler, to get us to where we want to be. And thirdly, the proliferation of tools and data sets. It's about having a holistic approach to a single value stream delivery and management platform. Platform engineering using GitLab. Merci beaucoup.