Bringing Procurement into the Agile Product Operating Model
Procurement is often the missing piece in Agile transformations. In this Scrum.org Community Podcast, Dave West is joined by Mirko Kleiner, President, Lean Agile Procurement Alliance and Simon Reindl, Professional Scrum Trainer to explore how procurement’s traditional predictive approach can clash with Agile’s iterative nature—and how to fix it. They share how early involvement, transparency, and cross-functional collaboration between procurement, legal, and product teams can unlock greater agility. Learn how to apply Lean Agile Procurement principles, shift toward goal-oriented contracts, and align third-party relationships to deliver better outcomes faster.
Transcript
Lindsay Velecina 0:00
Announcer, welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.
Dave West 0:20
Hello and welcome to the scrum.org community podcast. I'm your host. Dave West, CEO, here@scrum.org in today's podcast, we're discussing an element of the Agile product operating model that's often ignored, and that's the area of procurement. You know, contracts, legal, all those things. Oh, sounds awful. You know, it might sound strange that in a product approach, that we actually worry about procurement, but actually, if you don't, these third party relationships can ultimately undermine your move to product and to agility. In particular, imagine building a car for a second most complex, mass produced product in the world, 1000s of different suppliers, complex OEMs and hierarchies of supply. Imagine trying to build a car using an agile approach. Ultimately, if do not include procurement in that process, you're going to never get to Agile. You're probably going to never manage to change anything, and it's going to be a complete mess. And you'll you'll get fired. Of course, most organizations, you're not building something as complex as a car. You know, there's the supplier ecosystem is much simpler. But let's look at the scrum.org website for a moment. When we moved to the new platform, we moved to Drupal, we, you know, changed how we worked on the on the website. We worked with suppliers around the development. We had to increase our development capacity to do it. We have a CRM vendor. We use Salesforce, marketing cloud and all that. We also, of course, have Amazon and stuff like that for the for the hosting and and actually, we have a number of third parties around assessments, etc. Now we wanted to move to that in a very agile way, you know, incrementally move our website. It was really hard to work with these third parties. They were like, No, we need to know exactly what you want at the start. So so it wasn't easy. So I'm not sure we did a particularly good job, actually, to be honest, we had some big challenges along the way. So because of that, we are fortunate today to have two experts in the discipline or in the field of Lean agile procurement, and that is Mirko Kleiner, president of the lean agile procurement Alliance, and author of probably the pivotal book in this space, which is lean agile procurement. If you've not read it, I suggest you do. And Simon Randell, a professional scrum trainer on this podcast before author, consultant, coach, is also a lean agile procurement trainer and board member, welcome to the podcast. Mirko and Simon,
Mirko Kleiner 3:05
thanks for having us. Thank you. Dave pleasure to be here.
Dave West 3:10
Yeah, it's great to have you. I know that it's all a bit of a complicated, interrelated, you know, cross disciplinary field here, so I guess that our listeners would want to start at the very beginning, to sort of set the scene. And maybe we start with you Marco, talk a little bit about the state of agile and procurement. They seem like they're not the happiest of bedfellows.
Mirko Kleiner 3:36
Well, actually, yeah, it said sad but true, the demand for agility or more agility in procurement has never been bigger than today. But one of the reasons we are here, we want to spread the word there is an answer, you know, to become more agile, more adaptive, even in procurement and other commercial roles. I think so. We are still at the very beginning of the innovation bell curve. So to say, our movement, little movement, is already nine years old, and we have done fantastic we have fantastic success stories in almost all industries, public private sector, very regulated, far more. For example, industry, banking, sourcing far beyond software and you know, services what we are used to in the Agile community, for example, sourcing new trains for the government. Or now in nowadays, defense is a huge topic, right? The challenge that procurement is facing is similar to where the agile movement has been 20 years ago. So to say, because back then, you know, software came up or was. More and more a thing. And everybody was like treating the software process, software development process in a sense that we know exactly what we want today. We know we don't know. We have to see it right. It's assumptions. It's hypothesis. Now, procurement, to oversimplify, works the same way till today, their main assumption is that they can specify what they're going to buy, and that's already part of the big strategy. You know, if you're just looking for toilet paper for your company, that's still fine. But if you're looking for the next CRM for scrum.org, or or any other service where you have an opinion, but you don't know what are the possibilities, especially in our days with AI and all this, you know, fast evolving products and services you might need to have. You might look for a different approach, a more collaborative approach, similar what we are doing in Agile teams. The second and we might deep dive into that in the later in the podcast is the assumption that somebody buys for us. It's, let's, let's stay with the analogy of software development. 20 years ago, there was a quality assurance department who ensured quality for our software developers, right? And it's as wrong as that somebody else is buying for us, if you think about it. So if you think DevOps as a concept, or your a palm model, fast forward, I think there is the ambition that future agile teams, or product teams, whatever you want to call them, micro enterprises, that they are owning the whole product, including the commercial side of the product, managing, evaluating, managing, laying off their third party. So Simon, did I miss something?
Dave West 7:24
Yeah, Simon, you want to add a little bit of from your perspective, because you're out there in the field doing this, trying to help these organs. Well, you both are, but Simon, you're sort of bringing in professional Scrum and combining it,
Simon Reindl 7:37
yeah, what excited me when Mirko and I met at a conference and is describing the whole procurement process the number of times my teams or my clients had been stymied by a classic predictive contract. So they're trying to work in an agile, iterative, incremental, empirical way, and all of a sudden the contract is written in the classic predictive model based on phase, gates, milestones, all that cool stuff. Now that's great. If we're in the world of the clear or the complicated you're working in Scrum, we know that it's really important that we are clear that we don't know exactly what we're doing all the way through the life cycle of our product, because we want to run experiments and learn and evaluate and iterate. Well, how is my partner going to get paid if we don't have that milestone that all the requirements are signed off, and that's a payment milestone, and in large companies, we could be talking millions, 10s of millions of dollars, pounds, francs, Euro. And so you then end up with this commercial conflict. That's the first one. And the second one I've run into too many times, procurement was focused purely on the lowest cost. And so when the bids were put out, people would bid, but they bury in the contract that a change request was worth a load of money, and so they'd sign off the requirements, and then you'd get into this really quite toxic discussion. Is that a bug? No, that's a change request, because it's the only way that the supplier could recoup the actual cost of the development. And so what we're aiming to do is be open, clear, transparent, and build a trust based Win, win relationship, so that we won't have an us and them approach. We start building an ecosystem of trusted suppliers. It is
Dave West 9:41
interesting, you bring us one of the, one of the sort of case studies that I use a lot when talking about this move to product thinking in particular, is SpaceX versus Boeing with respect to manned spaceflight, one of the reasons why Boeing was in search. Such a mess with, you know, obviously a neighbor of ours got stuck there. She lives in Needham and Sunita, who was one of the astronauts who got stuck in space, because that one of the reasons why they got in such a mess was because the the the the the US government, NASA, changed their procurement process to be basically fixed price based on delivery, you know, sort of like we are going to pay. We believe the value is this of taking a person from the ground, taking them to the International Space Station. Therefore, we'll break it into these 15 segments and fixed price based on very clear goals and incentives. Now, Boeing has never worked in that way before. It's always been time materials and Boeing's entire system wasn't built around that. It was built around a completely different model. And because of that, it was one of the many reasons, but it sort of fell apart. And so the reason why, one of the reasons why procurement is so front and center in in a palm, is one because Simon does go on a bit, and you have to sort of listen to him occasionally. But the second reason is, honestly, because this case study is perfect example of a different philosophy and and the other thing that was interesting about this was the way in which it was goal oriented. It was about outcomes, very clear outcomes that you need to have an engine that can do this stuff, because that's, you know, rocket surprisingly, rocket science isn't actually as complex as we think it is. It's been around for a while, right? So they, they, they broke it down on that. So I think, you know, it's, it's clear that if we don't work in a different way with suppliers, and don't build contracts that allow Win win, then you end up in a bit of, a bit of a mess, but so, so let's Simon talk, tell me a little bit about, you know, the Agile product, operating model and products and and how that sort of fits in. Because I can see, if you go into procurement and say, we're going to change procurement, so you're coming in from that angle, revolutionizing procurement, getting wins a bit like 18 f did with the government in the US and in which has actually been got rid of now, but that's another thing. But I don't how does it fit in with this agile product operating model, which very much comes from Business and Technology, grouping capabilities around outcomes and building teams and teams of teams around products. How does it fit there?
Simon Reindl 12:45
It's rather pivotal in the fact that it sets up the space for the teams to connect and work together. You can even use the lap Canvas for teams to agree connection points. Now, the wonderful thing about Scrum is it's very articulate about a single team. However, when you get to multiple teams, portfolio, enterprise, you're on your own. And this is where the apom model is beautiful because it offers an organizational approach based on principles that each organization can customize to suit their context, their people and their delivery. Now, as we've started saying, that setting ourselves up with our partners, our suppliers, that's procurement, and so if it's straightforward materials, the procurement departments have mastered straightforward procurement, and you've got aI models to boost and help you. So if you're after staplers, computers, you know, kit not a problem. The procurement teams have solved that one. When we're entering the world of complexity, we really need to start applying Agile principles to our procurement approach. So we then bring in a procurement expert, a legal expert, a governance expert, as well as our product team, because our product manager and our delivery teams need to have an understanding about costs, the impact on the financial outcomes, as well as establishing a relationship with our partners from the outset that things are going to change. And there's a fascinating observation in this this year's State of Agile and Lean agile procurement, 40% of all contracts from the respondents were not reviewed after being signed. So if we're working in an agile way, surely we should be adjusting and tweaking our cons contract, checking that they're the right deliverables, and working out how to sustain that Win Win partnership with our long term. Suppliers, because you talking of Boeing McDonnell Douglas went out of business because they were getting hit from all sides and and one of the most successful the Forge fourth generation fighters, if not the most successful fourth generation fighter, was a McDonnell Douglas fighter, and that's the F 18 Hornet, which went through A, B, C, D, E, F, Super Hornet models. It's 40 plus years old now, and Boeing have had to pick up support for it. So thinking about the longevity of our product as good product owners need to do we need to think about not only bringing it to market, but supporting it while it's in market. And that's what we're trying to do in that true agile way, bringing a cross functional team together to help support the product delivery and operation.
Dave West 15:56
And I think what's interesting so, you know, I've been obviously that, hopefully there's gonna be a white paper out soon. Listeners, you know, we're working on it, but I so I've been reading the materials and sort of talking to you about this, Simon. So one of the interesting things is a lot of organizations to avoid getting into those dependencies and to avoid working with procurement, build their build stuff. So a large financial institution that we're not going to mention their name in the Boston area did exactly that, you know, oh, rather than use the CRM, we'll build our own. Rather than, back in the day, rather than have a database management system, we'll build our own. You know that the do that because working with third parties was so difficult in respect to working in a more agile way. If you've got the control and you're doing everything yourself, then it's easy peasy, right? But one of the key tenants of a palm is core versus context. Don't build stuff that you you there isn't a competitor that isn't a differentiator, which isn't going to help you, because it's everything you build, maintain cost. I mean, it's, it's expensive, you know, last resort, almost concentrate on your core. And one thing that so that makes procurement so much more important to be integrated into the into the into the this the a POM model. But tell me, how how do we do you? So you bring in these experts, you know? Because, let's be frank, I've dealt with some of these procurement people and that, I mean, I'm sure they're fabulous that I would never want to be their contractor at home. Put it that way, you know, they're like, Wow, on a
Simon Reindl 17:36
Wednesday, that's what everyone used to say about developers.
Dave West 17:41
Oh, yeah. Well, yeah.
Simon Reindl 17:45
When, when scrum started out, you know, everyone said, Oh, developers don't talk to people. And, you know, every test has got the heart of a developer in a jar on their desk. And the good old joke about asking a developer's partner asks them to go to the shop, and says, go to the shop and get some eggs, and if they've got milk, get two and they come back with two eggs. Well, they had milk, right? It's just like and the way you're thinking about it, and that level of exactitude is needed in contracts, because it's money. We're talking about building this micro enterprise thinking so that everybody understands the balance sheet, the profit and loss, the spend. How are we going to recover it? Being brave enough to say, Do you know what this feature is? Just draining money. We're going to kill it. Google. Do it all the time, so I hear your concern. Ah, I don't like working with discipline x, but that is the antithesis of Agile. What we're trying to build is cross functional teams and zero silos, because we're all people. We all got to eat,
Dave West 18:55
yeah. So Mark Marco, so how does a team so I hear you, Simon, I 100% agree, and I was being facetious. I actually quite like talking to these people. They always create a feeling of dread in me afterwards, because they know how horrible the world can be. And I tend to be a more of an optimistic gentleman. But so how do teams engage with these, these, these people, and how do they bring them on? Is it a full time situation? You know, what does it look like? You've seen it in the in the wild, or in a phrase, how does it what does it look like?
Mirko Kleiner 19:37
Yeah. So it's a great question. You know, it's depends on their maturity, right? I mean, your agile product, operating model, some have just started, let's be frank, right? And so procurement has just started on their journey, maybe, or maybe not. So that's kind of the first advice. That Simon and all of us give, if there is a transitional agile adoption ongoing, think about commercial roles and parts of the organization, because there is a huge, huge leverage they have. We have from studies, we know that in private sector, commercial rules, or an average responsible for up to 80% of revenues, yeah, okay, so if we can get 100% faster in procurement, if we can get, you know, better value for money into the product teams that has a direct impact on the business. So it's not just, oh yeah, once we have time, we're going to transform procurement. No, you should start there actually, together with the strategy and product and so on. So that's, that's one thing. So just generally. So one tip, if you are running a transformation, think about to add people from Supply Chain Management, procurement, if you are on the supplier side, from sales account management and so on. By the way, think about your top three strategic partners. Why don't we include them in our agile transformation? Now the second perspective I'd like to give is, what does a potential should state from a majority look like? Now we have examples out there in the market. Roche is a very good state. Currently, they have, for example, turned their whole procurement organization, excellence organization, into a insights and enablement organization. So what does that mean for a product organization, or in their case, R and D organizations and so forth. Well, from a product perspective, they get all the services, all the insights, all the data is platformized, right? So it's just self service. So there is no more a process. Or Now we need to go through, you know, procurement process, and it's a bottleneck, it will take ages. No, it's just self service. Now, if something is complex, we need to build a new strategic partner, or we need to develop an existing partnership, or we even think about a new supply chain, then these people, these capabilities, like in a DevOps team, we need them as close as possible. Yeah, so it could be that they are embedded in our product organization because it's just strategic. And I want to put the emphasis on Simon mentioned several times cross functional. Well, we are currently lifting cross functional to cross company. So your product organization, you might not be familiar, or it's not maybe not obvious on the first side, you're focusing just on your internal team and team of teams. But think for a second is, are there some strategic partners? And there would be value if you have a joint planning, if we would have joint dailies, a shared impediment backlog, and so on and so on that would, you know, increase our, improve our collaboration and CO innovation capabilities. And last comment, Simon, then you can jump in. And all of that needs to be supported by the legal foundation. So that's also something we have to enable the legal teams, compliance officers and so forth, that they have an understanding about agile, about all the possibilities of agile contracts, so that those contracts are no more separating the organization, and the management of the risk is done by the contract. No the contracts should enable agility cross company, and we need to figure out how to deal with the risk, how to deal with the governance model, cash out, co invest even, you know, sharing of potential failures. And that's what we are doing. So we have, we have created. Create a whole framework of agile contracts. We call it the home of agile contract. And yeah, so think about how strategic are your third party. Then you might need this capability of dealing, evaluating all the commercial stuff you need, this capability in your team or Team of Teams, organization, and at the same time invest in digitalization. That procurement becomes a platform, by the way. HR, same thing, finance, same thing, right? So, if somebody comes up with a new product idea, and that's the vision of a product operating model. Everything is there, and the organization is more like hire. Is operating hire, the Chinese company, which turned into over 5000 micro enterprises, self organized, self managed, even the commercial they have an open strategy that are open to define their own salaries and participation on success and product Everything you wouldn't expect that in a Chinese context, and you can't operate more than 5000 micro enterprises or Team of Teams if you don't have the platforms that support them, not just procurement, as I said, Simon, you wanted To add something.
Simon Reindl 26:38
Yes, thinking about bringing your people from HR, from legal, from compliance, from procurement, together they could support a product, or if your products big enough a portfolio, so that would sit at your Nexus daily, if you're using scrum.org Nexus framework or a portfolio daily event so that risk is managed by resolving it. The traditional model of putting it on the risk log and going, I accept that is naive at best. There's been a number of big, big projects that have come awry of just going, I accept that risk. The F 35 the single largest overspend in defense history within the UK. There's been a, there's been some, a series of clangers, the High Speed Rail HS two, the aircraft carriers, where they ripped out the jet launching system, the caterpillar, which is blue, it would have been cheaper to leave the thing in, and we would be able to work with other air forces, but the NHS IT system, so they're the three that come to mind just in the UK where I'm operating. Having that discussion with those people at a daily basis, means that you have credible, broad, ranged advice to support your product leadership. Who are, ultimately, they're the mini CEOs. That's the model we're promoting, right? That's the APM model, because they're the mini CEO, as mercos saying, looking after their micro enterprise or enterprise if it's a big enough chunk of pie. So they should be talking to their chief of HR, Chief of legal, Chief of compliance, Chief of procurement, and particularly if we're managing money. It's the My dad always taught me, the golden rule of business is whoever's got the gold makes the rules. So we better know how much gold we've gotten, where it's coming from. And who better to advise us than our procurement experts? And we're not. It takes so long to become an expert in a domain. You don't need to be an expert in a domain. You need to have those experts help working together as a collaborative team.
Mirko Kleiner 29:07
And I want to give a very practical tip to some of the, you know, some of the guys in the audience, or maybe team members or Scrum Masters, you know, and yeah, would be awesome if you know these guys are involved in our transformation. So but I What can I do? Well, we often forget the most trivial thing is, you know, if we have something ahead where it's clear, we need to go to the market. Just walk over in the other department, procurement, or whatever is the one, and get them, you know, get in touch with them and say, look, it's not yet urgent, but we want to get you involved as early as possible. By the way, we are operating in a completely different. And way you might have heard of it, let's get the conversation started. How we can include you the best, and how can we deal with uncertainty and so forth. Same thing, by the way, for lawyers, I need to laugh before Dave however, he said, I don't know how you know these guys in procurement well, people are even more afraid of lawyers, but same story with them. You know, they're the last in the chain
Simon Reindl 30:30
and governance and compliance,
Mirko Kleiner 30:32
everything needs to be done yesterday, so in every of the super complex procurements we are involved in on my second day in the engagement, I gonna visit with the legal team, because they need to know something is coming. It will be completely different. They usually have no clue about agile, agile contracts. So we need to prepare, we need to maybe even enable them along with the project. So and they are very welcoming. You know, they are very, very much appreciating that they are getting involved so early
Dave West 31:16
they are. I have the same experience. However, it is very clear very quickly that the goals between a product who's ultimately trying to push, you know, to innovate, to deliver new value, to do things in a very different way, their goals do not align with the goals of set usually centralized, particularly legal departments, and because legal departments is ultimately to reduce risk and to basically say no and any change is a risk. So one thing that I've always you know and I like about the lean, agile procurement approaches with the you know, trendy things like canvases, or whatever you want to call them, but the mechanism that you use to get everybody on the same page about goals, or which is often the case, the disalignment, make it transparent. You know, Simon has taught me professional Scrum. I was using Scrum before I joined scrum.org but over the last 10 years, he has, and a few others have continually hit me with this rational scrum hammer. And one of the most important jobs as a scrum master, and I know this is a different scale often, but is to make things transparent. That's their job. If you make them transparent and then involve the right people, then magic tends to happen. And so one of the most important things we do when engaging legal isn't just going and having a cup of coffee with them, though I do recommend that, particularly if they're buying but the is to actually try to get these goals very transparent, because then the CEO wants Everything. The CEO wants no risk. Wants massive innovation wants, and we live in a world of not you can't have everything. Can't have your cake. You can't eat it. You can't you know if you're going to get drunk tomorrow night, tonight, you're going to have a hangover tomorrow. We live in that world, and you have to make these things, and choices need to be made. Is that okay? Do you think this transparency thing?
Mirko Kleiner 33:23
I think I can start and then Simon, please add, I think that's exactly where we are. You know, that's the core value, beside the value of operating on a win win mindset is creating, you know, a transparent, collaborative approach. Were, for example, in a in a in a in a kickoff, usually, you know, in a standard procurement kickoff, it will be procurement and some stakeholders, that's it. Now we add everybody that has something to say, even lawyers, compliance officer, if it's, you know, data security or whatsoever. And because, at the very beginning of something, it's basically, it could be a new product in your sense, right? Or a new aspect of the product we need. The most important thing is to get an alignment very early, and also to have the transparency about risks gray zones and you know, where people see potential impediments, etc, and we can accept it or not. And the same thing we apply with the vendors, because traditionally, we write documents, send it over the fence, expect proposals, and there is so much misunderstanding right, which leads to a lot of costs, which leads to a lot of friction, delays over budget. It and so forth and so forth. So it's so powerful just to co create a proposal. I know we don't go into a deep into the details today, but just think about it. You know, you get all the information as a vendor, and maybe there are three, four of your competitors in the same room, and they do the same thing in parallel, and you have the opportunity to talk to real users, to talk to real clients, to talk to the head of platform security. You know, I read here something, I don't get it. Please explain and so forth. So what we are doing is we're testing the collaboration. Somebody once said it's like speed dating before, before getting married. And it's really true, right? Because capabilities, expertise, their products and pricing, that all matters. But as important is we like each other. Can we imagine to be on that project for the next 612, whatever months, and then, you know, continued by operations and continuous improvement and further development, you know, in the product sense. So, ah, it's, it's at, it's really, it's at transparency is at the core.
Dave West 36:30
So, Simon,
Simon Reindl 36:32
yeah, I can care, and would like to build on what both of you said. And back in the day when we first started doing Scrum. Well, when I first started doing Scrum in the early 2000s we had a huge pushback from the ops people. They're like, what are you doing? You're releasing again, but you only released two to three weeks ago. What? What? Yeah, we got a little bit more value. Oh, this. And then eventually we got moved to the front of the cab, and this is where the whole DevOps movement came from, because operations learned to trust because those cross functional teams were building a better product. So Andy Spence, a fellow PST, he did this with compliance at a major financial institution, and they worked in a beautifully agile, Scrum based way. And compliance. Love it when you get engaged in because the last thing they need is, oh, we're going live next week. Tell us what's wrong. And so crikey, if you'd come to us, you know, six weeks a month, a year, a year ago, we could have made sure that you're we're completely compliant, so that that early warning is a risk mitigation technique. And when we bring our people together, like particularly in the big room process that we use in lean, agile procurement, so we've got three potential partners, and we're having this discussion in the room. Our feedback loop is so short, and because we're transparent, we're hitting all the compliance, anti corruption, anti bribery, government checklists, because all the suppliers are hearing the same message simultaneously. And depending on how long your procurement process is, let's say it takes you a year to bring in a procurement contract using your traditional procurement process, and we do it in a month, we're saving the better part of 11 months, which is, if we've got a single team, a single scrum team, at 70k at Sprint, that's 2,000,011 months. Yeah,
Dave West 38:37
I think that it's transparency, but it's also regular inspection. It's not just because, you know, you talked about the high speed railing, and I know a little bit about that because my cousin was part of the consulting team there, and he used to over a pint of IPA, which he liked to drink. He'd talk about it, and without breaking any confidentialities. But and one of the issues wasn't actually the initial goals, it was the fact goals over time and nobody wanted to rock the boat. Nobody observed stuff. It was no continuous inspection and adaption and and appreciate, some of these goals were untenable. They were just impossible. That's not saying they're bad goals. It's not saying anything else. It's just the it's, it's transparency, frequency, etc. Micah,
Mirko Kleiner 39:31
you raised a very important thing in inspection and adaption. Now let's put procurement of what means that in the sense of procurement, yeah. So imagine you, you are a startup, or an investor in a startup, and the whole business case is worth it, 100 millions, yeah. Would you ever ever find. Want the startup with 100 millions at once? No, it's obvious, right? But that's what we do with procurement, because in a complex strategic space, it's as uncertain if those assumption you know, if this partner will or this new service we gonna build together with the partner, or whatever it is, will be successful. So what Lean natural procurement does is it looks it prioritizes even procurements and slices it down to the most promising hypothesis first. So we are applying the 2080 rule, right? If we can achieve with 20% of the spend budget, 80% of the value, let's just do it when we want to do it fast. We want to get as fast feedback from the market as possible, and then if we see we are heading in the right direction, we are willing to invest more. So you could also say procurement is more of an investor into the products, and the whole sourcing strategy becomes incremental.
Dave West 41:21
Simon,
Simon Reindl 41:22
yeah, to build on what Mirko is saying, this is where using evidence based management having clear metrics to measure it and feed into that learning loop, so that as our team ships regularly at either single team, product or portfolio level, being able to quickly get to the build versus buy decision as quickly as possible, to have a consistent clarity. So it doesn't mean the approach has to be same, but we have a consistent clarity across our organization or our subset. That means that we can then manage our risk and maximize the effectiveness of our organization.
Dave West 42:06
I mean, yeah, I mean, that almost just sums it up. However, I could talk to you gentlemen for hours, because there's so many, so many topics that you raise that I'd love to lean into in your experiences is incredible, but we have to have to come to a close. So, all right, I'm sitting here, the majority of our audiences working in teams, hopefully product teams, fingers crossed, or at least teams, and they're like, oh, okay, so what can they do? One thing, brief, one thing, what can they do? Okay, do I
Mirko Kleiner 42:42
think increase the awareness. So if they are new to what we just talked about, visit our website. Get yourself, you know, up to speed. What's the value, and then find your role in that. Maybe you don't have a role, then you just hand it over to somebody you think should know that if you're a scrum master, if you're a product owner, you should know that stuff, because what I like about your a palm is procurement is no more optional. It's part of it, right? So I think that that will be my tip, no, Simon,
Simon Reindl 43:28
yes, and it's you need to do that, go and talk like everybody's human businesses are built by human connection. Find out who is in your procurement team. Find out who is in who's supporting you financially. Procurement wise, compliance wise, governance wise, go and have a chat and say, Look, how can we work together to make life easier for all of us? And if you can do it in your organization, treat all your partner organizations in the same way, but start small, start local, just like we did with Scrum 25 years ago.
Dave West 44:07
That's great. Words of wisdom, gentlemen, well, thank you for taking the time today. I really appreciate it. I know you're busy, though it is the summer, so I've actually hopefully pulled you away from the beach or drinking margaritas by the pool, but thank you for spending the time today, and I know our listeners really appreciate it.
Mirko Kleiner 44:27
Thanks for having us. Thank you so
Dave West 44:29
today. Gosh, that was interesting. Listeners. We heard about how procurement is a key part of the Agile product operating model. We learned a little bit about how it needs to be embedded in these particularly large product teams that are embarking on innovation and change, and that it's a key aspect of all of the aspects of product development and needs to be made transparent and inspected and adapted. And apparently you. These, these commercial people, are actually human beings. Simon did say that a few times, and I have evidence that supports that hypothesis. But there's always a great opportunity in your organization to test it. So talk to them, get them involved, make them part of the solution, not the problem. You know, it's on you. If you go to them at the in like day 5000 of a program and say, Hey, I've got this thing, can we release it? And they go, hang on, get them in earlier, make them part of the solution, and then magic can happen. Thank you for listening today. Today, scrum.org, community podcast. Hopefully you liked what you heard. I certainly learned a few things. Please subscribe, share with friends, and, of course, come back and listen to some more. I'm a very lucky man, because I get a variety of guests to talk to about everything in the area, professional Scrum, product thinking. And, of course, agile. Thank you, everybody. Scrummar, you.
Transcribed by https://otter.ai