 Okay, lovely. All right, so while we're working out the technology, I'm just gonna get started because the slides just are an enabler to the communication. So what we're gonna be talking about for the next 45 minutes or thereabouts is about agile contracts. Now, who here works in finance or procurement? Oh, one person, that was not expecting that. Okay, this is going to be a talk not from a finance perspective, not from a legal perspective. I'm not going to give you boilerplate templates. I'm going to talk about when you're actually building an agile contract, when you're engaging with a new client, how do you work with them to actually build a contract that supports an agile approach, especially when we have a situation where your client or customer may ask for fixed price. So we're gonna look at a couple of different topics. Some we're gonna look at trust. We're also gonna be looking at the different types of fixing that can occur, as well as other types of contracts. So before we really kick off, does anyone have any particular burning issues that they'd like to make sure that I cover? No? All right, well I'll just talk. And if I'm off topic or you want me to expand on anything, just raise your hand, interrupt, and happy to take this conversation where you want to go. Ultimately, you need to get something out of this. Yes? Absolutely, I will definitely be talking about that, looking at how you actually have those fixed price contracts where the scope is not clear, all right? Go by the velocity points. Because you want some quantifying value. Yeah, okay, let me just make a note of that, velocity. Velocity is an interesting one, and there's some issues, and we'll talk about what the issues with building contracts around velocity are. It can be quite valuable, and it can be a good measure, but only in certain circumstances, and we'll talk about some of that. All right, so to kick off, yep, so yep. So schedule, cost, and the scope, everything is fixed. Where is that agenda? I'll be talking about the different types of fixing, absolutely. All right, so to kick off, for those of you who don't know, my name is Evan Laborn. I'm based out of Singapore, and I've been working in a business context with Agile for the last seven or eight years, taking Agile outside of IT, and applying it to the wider business community. So let's actually look at one of the key principles that you need to understand in order to actually be Agile and have an Agile contract, and that's trust, okay? Trust between yourself and your customer. I use this metaphor, note it's a metaphor, it's a simplification of reality, it may or may not be real, oh, I have slides. I'll use this for the time being just to finish this point, okay? If we look at trust, if we look at four different layers of trust, all right? Can I get someone from the audience to come up for a second? Just as, come on, let me get, Evan, Pavan, do you trust me? Good answer, absolutely. Why doesn't he trust me? Because we're down here, okay? We're down here, we have what we call a level of reference trust, okay? So you do trust me a little bit, you trust me enough because you came to this talk, okay? You came to this talk because something is an interface between us, okay? Now, in a commercial context, it will often be a reference from Yelp or a reference from another client or just because their website sounded really good. So we start a relationship at this level of reference-based trust. Then we go up over time as we build that relationship, okay? So what do you think the next level of trust is gonna be? Sharing information, how do two business partners share information? Testimonials, sort of, but it actually, from a business perspective, it actually comes down to contract. So the second level is you have contract-based trust. I trust you because I have a piece of paper that says this, this is what we're going to deliver, and there are penalty clauses and all sorts of wonderful things that if you don't deliver. Now, we've been working together now for a couple of years. We've gone through, there have been some successes, a couple of little failures because failure always occurs, but overall, you're satisfied with my service sufficiently to bring me back in again and again and again, all right? What, do we have more trust? Do we still have a contract? Yes, absolutely. The contract continues because our entire business model is built around contractual agreements, okay? But what we call this is now identification level trust. I don't trust you or you don't trust me because of the contract. The contract becomes an enabler, but we trust each other because of experience, shared experience, does that make sense? And at the very top, this never happens or very rarely happens, maybe 10% of your clients. This is what we call a partnership. How would you, if you were to trust me at the level of partnership, what does that mean to you? Did everyone hear that? Yep, you expect that you would share the problem together and that we would work together for the outcome. I couldn't have said it better myself. You're absolutely right. A partnership level trust, think of this as a strategic partnership. We will succeed or fail together. Make sense? Can everyone give a round of applause? Thank you. So I want you to keep this trust level in mind as we go through the rest of this presentation because this trust model is exactly what your contracts are gonna be predicated upon, all right? Now I'm not gonna talk about, I'm not a lawyer, don't. I'm not gonna give you legal advice about contract law. Lawyers have a very special understanding of how contracts work. What do people think a lawyer's primary obligation is to? Protect, protect who? Protect the company's interest, absolutely. Do they care whether your project is on time? No, do they care if you actually get the outcomes that you want, not outputs, the outcomes that you wanted? No, a lawyer is there to reduce risk. A lawyer, no, let's take a step backwards. What do you think a, from your perspective, a successful contract would entail? Mutual agreement by both parties, abide by the law? Yeah, absolutely, that sort of thing. But I would actually say a successful contract from a technical perspective is the outcomes. Like, as two parties we work together and we achieved an outcome, and that outcome was successful. A lawyer is gonna look at that and say, that contract is successful if nobody gets sued, okay? Not whether it was the outcome's successful, but about that. So, always, when we're talking contracts, remember what, that we do have a level of, what's the word I'm looking for? A level of distinction between the two. Oh, that's just a quote. Now, there are three questions that you're gonna, oh, your customer's gonna ask you before any project begins, okay? Can anyone guess what those three questions are? Well, the first one is a title of this talk. How much is this gonna cost? All right, can anyone guess what the second one is? How long is it gonna take? And the third, actually, that's a good question. Will it solve my problem? They should be asking that. It normally is, well, what am I gonna get? All right, all right. Now, there's an agile answer to all three of those questions and we'll look at that at the very end. So, I just wanna keep those in the back of your head. All right, let me just go through. Now, agile manifesto. We all know the agile manifesto. Customer collaboration of a contract negotiation, all right? Do we understand what that means? If we have a contract, are we going to have a contract with our partner? Yes. There is still value in that contract but we want to be able to have that customer collaboration in place. All right, so we're gonna talk about different ways that that can be achieved. So, first of all, understand your workflow. Understand the flow of activities, the flow of information and the flow of requirements that go through from a contractual perspective. When you have a team, okay? A team has a fixed cadence more or less. I'm talking here software and I'm talking here services for money, okay? So, where there are capital components, this is not the right metaphor for capital. This is more for operational. But, when you have something that's fixed and a change occurs, then you've got really only three options. This pipe is your team, your team capacity, your team cadence. If a requirement comes in, you got three options. Increase cost, increase capacity, all right? Add more staff. What's the problem with adding more staff? You will actually increase your short-term lead and cycle time as staff are being trained. So, whilst you may increase cost, there may be flow on effects, downstream effects. So, those will have to be calculated and mitigated. Second option, increase duration, all right? If I have a 10-week project and I add a week's worth of work, okay? Then, yes, I could add more staff to do it in the same time or I could do it longer. Or, drop a requirement. Now, I like to, everyone here knows what a change request is. In an agile perspective, especially where you have a fixed contract, start to think of it as an exchange request, okay? Because that's one of the key points. Where you do have fixed scope or fixed time and you're unable to negotiate, you need to start to have this exchange request. I will take something out in replacement for what you're putting in, okay? And you can build those concepts into your contracts. That was this model, so we've already spoken about that. So, what are the ideal contract models? Okay, time and materials. Everyone knows what time and material, does anyone not know what time and materials is? Okay, I won't bother wasting your time explaining that. Why is this ideal for agile? Because nothing is fixed, apart from an hourly rate or a daily rate. I can, as a customer, work with you as a product owner or embed myself within the team and I can do the backlog grooming and change. And as long as there is value. And one of the, I use this as an example of, sorry, I had a pen in my hand the whole time. All right. If we think of cost as a linear expression, okay? Every iteration, we're gonna spend 10,000 to 100,000 rupees, whatever it is, that we need to deliver work. We have a fixed team size. That is our linear cost progression. Then we're gonna see business value do this. At the beginning of any piece of work, our, the business value that we're producing is probably not gonna be greater than our cost. Why? Because we're doing backend stuff, infrastructure, downstream stuff, which is important. It's dependent on what we're, or what we're about to do is dependent on it. But it doesn't have high business value. At a certain point, we'll cross this threshold. The earlier we do it, the better, obviously. But when we cross this threshold, we start adding a net positive value in terms of what we're trying to deliver to the customer. There is a natural point where as the high value, low effort capabilities, functions, outcomes, outputs are created. All right, we're gonna cross that threshold again and suddenly the project's not quite worth doing. That is the natural, not the only, but the natural point for a time materials-based contract to end, okay? Because the work that you're doing is no longer more valuable than the cost of doing it. Make sense? All right, so bear that in mind because we're gonna talk a little bit about that later. But there's another type of contract. The disadvantage of our time materials is it's a linear growth. So from a vendor, here's a question. Who's here is from a vendor organization? Surprisingly, very few of you, okay? In a vendor organization, one of the problems with time materials is it's I'm putting my people in and I'm having a fixed percentage profit on top of that. If I'm more efficient, then I'm actually gonna get less money. So there's no incentive from a vendor perspective to actually increase efficiency, except of course from a trust perspective. So as a vendor, if you wanna improve that trust, yes, you're gonna start to work on this and there are your identify efficiencies and so forth. But at these bottom levels, especially at that level of contract-based trust, there is no benefit to innovation. So what we do is we go to outcome-based contracts. Now these are sometimes known as performance-based contracts and the standards, it all came out about Boeing's power by the hour contract model. Who here is using an outcome-based contract at the moment, if you know of it? One of you, two, three, a couple of you. So an outcome-based contract is valuable when you can actually identify a business value to an outcome. So your work does something. Whatever that something is has a net outcome. Now I say power by the hour, the way Boeing started to change their financial models was you pay us for each hour this engine is in the air. Because if the plane's on the ground, you don't pay us a cent. Now this is sort of a win-win situation because Boeing of course is gonna get more money and the incentive is to keep the planes in the air and the engines efficient and going, whereas the airlines of course, it's beneficial for them because if they're grounded for some reason because there's an issue with the plane, they're not still paying for that engine. Who can think of an example in software, in IT, where this is an appropriate business model or contract model? Software as a service? Yeah, that's an outcome-based contract. Yeah, subscription-based models, absolutely. What about if outside a subscription-based model or a software as a service? And think of other examples? Maintenance. Maintenance, yep, maintenance contracts. Yes, maintenance contracts tend to be better in terms of a combination of these two where there is a sort of capped T&M fixed scope or fixed time capability contract with an outcome-based incentive on top. Defects, here's a question. If I, as a business, not as a vendor, but as a business, you're producing a piece of software for me. Does the number of defects in that product actually impact my outcome, not output outcome? Sometimes, yes, absolutely, if they're critical defects, but from a substantive, how many of us use software that crashes every now and then because there's a bug? Defects are a part of a production environment. So having an outcome-based contract based on defects. Yeah, that's a fair point. So where quality is a critical measure, if I was in, say, the biomedical space, then absolutely, or the aeronautic in producing biomedical devices, software, and so forth. And yes, these sort of, these outcomes are more important to me than anything else. So an outcome-based approach will be valuable there. All right, so any other questions on this? Otherwise, I'll move on to some of the others as a couple of topics to cover first. Makes sense? Lovely. Now we look at fixed time, cost, and scope. Now, I want you to be aware, when someone says fixed price, the implication is fixed time, cost, and scope, but it is not necessary. It is possible to have one of these axes fixed and the others flexible. And when we're talking about an agile contract, we actually want to try and keep some level of flexibility. So when we have a fixed cost-based model, and this is where time and scope are flexible, an example of this is providing maintenance support. It's gonna be a 10,000 rupees a week forever. But how long it will be, we can cut the contract short or whenever, and the work that you do in that contract will decide that on a day-by-day basis. So that's an example of a fixed price model, but a flexible time, flexible scope model. Makes sense? Now in these context, when we're talking about a project with fixed price, but flexible time and scope, then we want to make sure that we do have a level of emphasis placed in iteration zero to plan, because we need to have an assessment of minimum viable product, minimum marketable feature. Because if we say it's gonna be X, but scope is flexible, fine, but the customer's gonna have a minimum scope in mind. So we need to say X as a quote has to be greater than that minimum viable feature. We're not doing a full formal quote of all the features of all the story points, just what is more than minimum, okay? We deliver this as we would any other agile project, but be aware that if you are using a fixed price, you should be using the shorter iteration cycles. Longer iteration cycles have a tendency for greater overruns and poorer estimation, right? Where you have the shorter iterations one to two weeks, you're much better able to control those costs, all right? So let's look at fixed time then. Now this is usually when a project or a capability needs to be delivered by, in most organizations, the end of the financial year, okay? But for example, you may have some marketing material that needs to be ready for a product launch. The product launch is fixed, right? Because all the media will be associated with it. So the work that you need to do, the website or whatever, has to be ready by that date. So this is a fixed time, flexible cost, flexible scope, right? In these instance, we can use historical velocity data. Now, this is where it gets dangerous, okay? What is velocity? That was not rhetorical. Someone tell me what velocity is. Number of X required to, so it's story points per iteration simplistically. It doesn't have to be story points, there can be other measures, but in most cases it's story points per iteration, okay? Who estimates a story point, team? What is one story point worth? How many hours is one story point? Yeah, so when we have historical velocity, if we have a consistent team, the same team, they've been together, we have historical velocity data for that team. We can actually draw a progressive trend as to, okay, your velocity measures are more or less stable. There's always some level of deviation, all right? So we can use that as a baseline. If it's a new team, or the team is fundamentally changed, you pull out three members and put another three in, okay? You do not have historical velocity data. At that point, you just take a guess, because you got nothing else to go on, all right? Where it is fixed time, make sure you strictly enforce time boxes, don't let any sprint overrun. This is agile 101, but the more things that are fixed, the more agile you need to be. The more you deviate from good agile practices, the harder it will be to actually maintain some of this stuff. All right, I won't bother going into that for now. Fixed scope, okay? We know what they want, but cost and time are flexible. This doesn't happen that often. Normally they'll fix scope and another access, all right? But this could be somewhere where, for example, there are a series of financial reports that need to be produced for regulatory requirements. How long it takes, how much it'll cost, can be varied. In this, once again, we have a major iteration zero. This is why I call this heavy agile. This is agile where you're not doing agile. This is agile where you're doing waterfall because you have a plan up front, all right? But sometimes, this is what a client wants. You can still use agile technical practices. You can still iterate, and there's some level of flexibility and time and cost, but your scope is going to be locked down. This is when I talk about exchange requests, where you have a fixed scope contract, and they do want to change the scope because customers always change their mind midway through. You want to exchange because your scope is fixed. So on and so forth, fairly standard stuff in terms of delivery. You're delivered as you would any other agile project. Now let's look at the combinations. Fixed cost, fixed scope. This is terrible. This is where you might have some flexibility in due date, but it's going to cost you a million rupees, and this is our list of specifications. Does that sound agile to you? No, it's possible. It absolutely is possible to plan it, but you need to increase your contingency. So if you were in my talk yesterday, I spoke about contingency from a financial perspective, same thing applies here. My contingency, either as a percentage or a fixed amount, gives me a buffer. Now, most projects, most organizations will run about a 30% contingency. The level of contingency that you run will depend on the, what's the word I'm looking for? Will depend on the overarching cost. So where, sorry, not cost, risk. So where the risk is high, then you're going to increase your contingency. Once again, you're delivering this like you would a normal agile project. We're not really making much changes there. What about fixed time and scope? This one's not too bad. Who can think of why this one's okay? Because we can add new resources, okay? Because we know what the outcome is going to be, and if this is a simplistic, repeatable project, then we probably do know what the outcome is going to be. If it's something that's simplistic and repeatable, we can probably estimate the duration of it relatively easily. But where things are unexpected. Here's the problem with fixing. Fixing doesn't allow you to manage the unexpected. How do we manage the unexpected? With money. So here, we do have flexibility in increasing our staff to do that. This type of contract is usually only used internally, not between external partners, unless they have some sort of strategic partnership. But of course, my favorite, fixed time, fixed cost. This is actually what you want to go for. If your client organization is very heavily focused, emphasizing they have to have something fixed either because they don't trust you because you're a new client, okay? So you've got to have a contract that protects both parties. Or because they're lawyers, the relationship that you have, maybe with one party in that organization, but their procurement department has all these processes that are expected. Then in that case, you're going to have to start fixing. This is, if we're going to be fixing stuff, the best type of fixing that you can do. Why? Fixed time must be done by a certain date, okay? Straightforward, absolutely. Fixed cost, it's going to be a million rupees to deliver. That is our cap. This is sometimes known as cap T and M, okay? Because our scope can change. The customer has a level of surety, a level of risk control that it's only going to cost us this much money and no more, great. But what does the customer want? The customer doesn't know what they want straight away. Of course they don't. That's why we use agile. Business is a chaotic environment that's buying its nature. So because it's chaotic, things occur outside of predictability, okay? Finance and procurements like predictability, all right? But predictability is the enemy of good, is the enemy of adaptability, the enemy of agile, all right? We want a level of predictability to make people comfortable, but people have to start learning to be comfortable with unpredictability. People have to start learning to be comfortable with a little bit of chaos in their lives because that is ultimately the nature of the work that we're doing. Software is a creative art, not a science. Do you agree on that? All right, so who here actually uses these kind of fixed time, fixed cost model? Yeah, some of you, yep. Who here, oh, sorry, some examples and so forth. Who here then uses fully fixed? All right, what do you think my recommendation is? Cancel the project. Now, that may seem like a joke, but it's actually very serious. How, and forget agile for a moment, even think waterfall, all right? Do you have that level of surety and predictability in the delivery of your project that you can guarantee delivery by a fixed date with a fixed cost, with a fixed scope? Is that possible? And here's the greatest lie ever told by project managers. Yes it is, okay? No, every project manager will say, yeah, we want to fix this down, we're going to run through the plan, we're going to have our gantt chast. And sure, if I'm running an engineering project that might even seem reasonable, but I can tell you having worked with engineering firms, both in the biomedical and construction spaces, even engineering projects run over all three of those constraints. So you might have a contract that says, I'm going to deliver this physical building by this time and this cost, but let's face it, they're going to run over it. Greatest example, people here know in Singapore, the Marina Bay Sands, that building that has a boat on top of it. Yep, have you all seen that? Yep, that ran billions of dollars over budget and was about three years late. All right, it was a waterfall project. And actually, sorry, on that side note, would you consider that to be a failure? It was billions of dollars over budget and it was several years late. Is that a project failure? Simple answer, yes or no? Hands up if you think yes, hands up if you think no. So at a project management level, it is considered a failure. Because the project plan was X and we were so far over the tolerances in this project, it was unable to be delivered. So, but from a business perspective, initially, yes, it was a failure. But that building paid off its costs, even the cost overruns within six months of opening. To be fair, they have a casino at the bottom, so that kind of helps. But failure is actually a very interesting, and I'm off topic here, I'm sorry, but failure is one of those interesting things where no matter what is fixed, whatever is delivered, sometimes the outcome is still achieved. So, always remember that sometimes failure isn't quite as black and white as we might think it is. No, does the developer not talk to the business? This is true, so. My question is how are we gonna control the marketing people? So, I actually gave a talk exactly on that on Thursday. There's a way of actually interfacing and communicating with marketing in their language, to try and get them to understand the flow of work within an IT project. One of the things that we've done is actually to start embedding marketing and sales into delivery teams as cross-functional teams. So, once they're truly cross-functional, and you actually start to have that sense of team and that sense of co-ownership of the outcome, then we actually start to control those marketing people. But yes, absolutely. If they go out and sell the Taj Mahal, and you go, we can't do the Taj Mahal for a thousand ringgits, then we're gonna have, there's always that breakdown in communication. But it's actually your responsibility as a developer, as someone in IT, to actually work with sales and go, you need to stop doing this because of this reason here. You're keeping us down here. We can't deliver, we can't keep doing this. We're gonna burn staff, we're gonna get rid of commissions. Absolutely. I've done this for five or six organizations so far. A, there is no evidence, sorry, there is evidence to show that beyond a certain base level of remuneration, commissions add no greater output or outcome from the person receiving the commission or the bonus. Secondly, commissions add a level of jealousy or us versus them. Once you actually embed sales into your development team, if you have them earning a million dollars every time they make a sale and the development team earning like 100K just for turning up, then we're always gonna have that dichotomy. So you actually need to start bringing the relationship to an even footing. So removing the commissions is one of the best things you can do for a sales team. And let's face it, if a sales person doesn't do their job, then you fire them, same as if a developer doesn't do their job. So all the points of commissions aren't actually true. I'm completely off topic and I'm gonna bring this back in but if you wanna have a conversation after this, let's do that. Now, the other point about this, okay, when projects do do this kind of approach, what they'll do, oh no, sorry, let's take a step back. When an organization, when a client organization says we want fixed time cost scope, what they're actually saying is we're gonna give you the risk. We don't wanna hold on to the risk of this project not delivering as we expect. And this is the legal thing. But what, that's actually misleading because what actually happens is the risk. You give the risk straight back to me. Why? How? Because you charge me 30, 40, 50% more, straight away. So just because I tried to give the risk to you but no, you gave it back to me. So it's misleading to anyone in the first place to think that this is a risk mitigation strategy. It's not. Now, there is a silver lining. But, okay, if you start with time materials, if you do a small time materials piece of work, cap time materials limited to a couple of weeks to a couple of months to understand, truly understand the business, the intent of what the customer is trying to achieve. And at the end of that, let's say it's two months, if they did, and if we decide not to go ahead, then that was probably the best decision. If we do decide to go ahead and they still want this because the great thing about working for T&M for a couple of months is you get to actually build this trust up. They still want capped everything, fixed everything, then you have a lot more confidence in understanding what they want, how long it's gonna take and from there you can calculate those costs, okay? So this is the one silver lining to a client who wants fixed everything. Negotiate some level of flexibility in the beginning. Makes sense? So, can someone tell me how much time I've got left, sorry? Five more minutes, love it. I'm on time, wonderful. Here's the three questions. What am I gonna get? What's the agile answer? No, it's not all of it, it's whatever you tell us you want. If you want all of it, you'll get all of it. At a certain point, you'll decide you don't want it. In which case, we'll get rid of it. Next question, how long is it gonna take? What's the agile answer to that? As long as it's necessary? No, no, no. It'll take as long as it's necessary. If you're gonna give us this much work, then it'll take this much time. And how much is it gonna cost? What's the agile answer to that? As much as you're willing to spend. This is not, this is not a blank check, by the way. This is not, and this is the argument they hear against agile. Developers writing themselves as a blank check, no. It's the customer taking control of their spending, not the developers writing a blank check. It's the customer taking control of their spending to decide when to stop. And that's the critical part about this, okay? If you have a customer who understands, who partners with you at an agile level, who has a level of trust with you, then you can do this effectively, okay? So, because I have a couple of seconds, this is a sort of a PS, okay? You have a second two minute talk. No projects, all right? And with apologies. This is something that I've been working on for the last couple of, about six months now. Change needs to be continuous. When you have a project, it has a start and an end. Nothing, or very little in IT, has a start and an end. You need to start thinking, and when we talk about customer trust, if you're here, if you're in the upper levels of that, you can start to move away from projects, and you can start to move towards outcomes. You can start to move towards continuous outcomes focused change, continuous change, continuous deployment, DevOps, all these things start to come together to give us a wonderful platform in order to get rid of what is a horribly overused concept, which is a project. I'll finish with one thing to understand. Activities, there is a change exists on a continuum. When we look at activities on a continuum, we have activities which are quick, activities which are slow, activities which are high value, activities which are low value, all right? We, when we're actually doing continuous change, we should be able to map any activities that we're working on into this sort of matrix. And by looking at any activity here, a customer and a vendor working together, or whoever has that contract, whoever has that relationship, whether they can be internal contracts, can start to actually effectively plan continuous change and continuous outcome improvements. All right, now I only had a couple of minutes, so I'm not gonna talk any further about that. I just wanted to give you a second mini-talk. All right, now, questions. I've got clients, sorry, sorry guys. So I've got clients who have given us a lot of trust, so they basically believe in us, and we were using kind of a waterfallish kind of a method. So we have continuously given them outcomes, and they trust us because of that. And there's a lot of data that we have, so healthcare and sleep industry has a lot of data. So now that we're going into the second phase of business, so my next set of clients are gonna be hospital systems or chains of hospitals. So they prefer kind of an agile-ish model. So how do I make sure that I keep both sides intact? How do I keep their trust there and build trust with the second type of? Yeah, so you're gonna have trust with multiple parties. So it's about structuring your organization in such a way that you can actually build trust. And one of the things that some organizations do as a cost-cutting measure is that they will focus on certain clients and ignore others. Trust can be lost, okay? So you need to actually have the wherewithal and the organizational structure to support that. I'm on the Board of Advisors for about four different startups, and I've done work in the biomedical and the health space. I worked for Amherst Victoria back in Australia for a few years. So this is something that a lot of organizations, a lot of health-based organizations are struggling with, but it's about structural accountability and it's about making sure that the relationships aren't forgotten just because you're moving to a new market segment. Let's have, that's a very detailed conversation. We probably need to have that outside after this. One more thing. So trust is not basically just between the client and the, I mean, and me. So there's a set of trust between me and my team too. Oh, absolutely. Trust is everyone trusts everyone. I hope you all now are at least sort of here with me in terms of trust. Like you trust, or actually even maybe identification, you trust me because you say, hey, Evan gave me some good advice. I'm gonna use that. I'm gonna trust Evan at this level of identification because I now have some experience with Evan. Now, does that mean that you're going to hire me without a contract? No, okay? Because you don't have that much trust in me. And you shouldn't, absolutely you shouldn't. You shouldn't have that much trust in anybody after you've met them for an hour. But we're always building a level of trust with everyone in every part of our organization in every relationship that we've got. So I'll give other people a chance to talk and maybe you and I can have a conversation a bit after this. Nice talk, Evan. But a quick question about time, cost, and scope. How often in a particular project do you think it is necessary, or if it's necessary at all to actually change the entire working model? For example, if you're fixed time, fixed cost, and flexible scope, and maybe after three months you realize, hey, this is not working for me. Do you recommend a change at project level or this should be a company-wide mandate? Because it depends on the contract. So contracts tend to be enforced for a duration. So the problem with a contract is once you've got it, it's hard to then move to a different kind of model. But if you do have the opportunity, if something's not working for you, and here, when I say cancel the project, I'm actually really true. Sometimes you have to step out of that contract and go, our organizational reputation is going to be negatively damaged because of our contract, because of the way that we're interacting with you, we cannot deliver what you're asking us to deliver. We need to pull back and even if we have to pay a penalty clause, sometimes the reputational impact and our trust impact, I'd much rather rehire someone who was honest enough to pull out of a contract with me because they went, it's not gonna work. Then someone who spent 22-hour days burnt out half their staff and then still didn't deliver on time and on cost. So these are all the things that you do need to balance up in terms of are we gonna change the contract and are we gonna change our structural embedment of how our project or how our organization operates. As a general rule, I actually suggest that when you are doing an agile organization, I don't like projects, obviously, but projects themselves are temporary. If you're gonna make a substantive change, you have to do it at an organizational level. But I'm biased because that's what I do for a day job. There are scenarios in the organization where we use fixed price, fixed go, fixed cost, and we use change management as a tool to subside the loss. Yeah. And that is a very demanding situation here you need in the outsourcing form. From a customer perspective, you link the business using a fixed price and able to capture the business. You use the change management thread, which is in a non-agistic ideal framework or some of the framework which we trust, and you can cash them out. So how would you advise from a contracting perspective? You're talking about the true gyan of contracting, but from a business perspective, business people who go for a business, appetite is selfish in nature, they have to bring that to be, right? So the deal is one through this, this is the mantra. Yeah. And they suck money from the customer using the change management thread. Yeah, but that's where I talk about, if you're being an agile organization, if you're an agile dev team with a cutthroat antagonistic, competitive sales team who actually has no, whose interest is in commission and not in the customer's benefits, then you can't be agile, right? You can use scrum, you can use XP, you can have backlogs and iterations, but customer collaboration over contract negotiation, individuals and interactions, these are the values and the principles of agile. If your organizational values or divisional, as in your sales values, through expression, not necessarily stated, differ substantially and are completely contradictory to the agile values, then no matter how agile principles and practice, sorry, practices you are, you cannot be agile to a customer. You have five vendors competing for a product, you have nothing to compete with. It's about building trust and relationship. Now, that's where I talk about doing the whole T and M stuff first. If you do have to do a fixed product, if you have to win the contract by fixing everything, because you have competitors who are more cutthroat than you and are willing to screw the customer over, then give them an option. Give them the ability to say, look, you and I both know that whatever price we give you, we're gonna gouge you with change requests because we're not gonna get it right first time. Like, everyone knows that and the vendors and the clients all know that, so let's be honest about it. What we're gonna do is we're gonna recommend this and then for two months we're gonna work with you to fully articulate that and if this doesn't work, and if it's not what you want, we'll walk away and we will still have a relationship. And here's the thing. If you have highly antagonistic, highly aggressive sales, I'm gonna bet your repeat customers are probably relatively low. These more trust-based models, you are actually gonna get more and more repeat businesses because you're gonna start to build partnerships. They're gonna start to come to you and you can actually start to bypass procurement processes once you get to this level of partnership. Because you can actually build heads of services. If you use the TNM model, I've seen it in situations where I had a UK customer, two months he got for a prototype done, he got all what needs to be done, he got that intelligence and then he scrapped off the project. Yeah, so what? He got all the customers also. So from a, I mean, we approached from the, this thought process of TNM and then we took the fixed price deal. We went there and we did everything for him. He came to understand, he was not able to understand, so we got everything out of this crap. And that is the best thing for the customer and for your relationship with the customer, the best thing you could have done. Projects, if the project is not adding value to the customer, why should they spend 100 million when they could spend 20K and learn? They gave it to somebody else. Oh, they gave it to somebody else, okay. That's different, but that's the relationship, like it's business, stuff like that does happen. All right, one more question and then I'm completely out of, I am completely out of time. Yep. So whether they use the story points will be printed in the contract, that is these many number of story points will be, in that level we will not be contracted on that. As I said earlier, the problem with story points is that they're team-based. You don't have consistent story points across teams. One team or two different teams estimating for the same activity, depending on whatever reference story they've got to give them the one story point, is they're gonna start, they're gonna give you different story point estimates because it's a relative estimate, not an absolute estimate. And what you're doing is putting a relative estimate against an absolute contract. And so unless you have some level of confidence in those story points, and the only way you do that is if you're, is if those story points, is if that velocity is for a known team who's done it for the last couple of years. It's the only time putting story points in the contract actually adds value because the other thing, story points can be gained. All right, you wanna do 10 story points per iteration? Sure, okay, this one's one, two, three and so it doesn't matter. I can make those story points whatever I want. But even if we have the same, we have the velocity and we are derived upon the story points but that is too risky because the team may vary after the contract as well. That's why I talk about having historical values. So you're gonna have, if the team is more or less the same, one person moves out and the other person moves in, you're gonna have variants and deviations but it should be within tolerance. So every contract's gonna have a small amount of tolerance. It's not gonna be say 10 story points, it's gonna say 8 to 12 story points per iteration. So it's gonna be allowed for some variants. So that's fine. That's range, yeah, that's absolutely fine. It's where it's complete recreation of the team in which case you effectively have no historical trend to draw upon. All right, now if you have any other questions, come and see me at the front. I have a book for you, thank you very much. So come on up. If anyone has any questions, email me, look me up on LinkedIn or come and see me, I'm the one in the three piece suit. Thank you.