Fixed Price Contracts
SUMMARY KEYWORDS
Join Murray Robinson and Shane Gibson in a no-nonsense Agile discussion. In this podcast, Murray and Shane talk about why projects with fixed-price, fixed-scope contracts often go way over time and budget. We talk about uncertainty, sales incentives and underestimating. How fixed-scope agreements lead to big design upfront, siloed delivery, authoritarian management and conflict with suppliers. We discuss how to use an agile approach to solve these problems. We talk about testing suppliers by starting small and scaling up. And we talk about agile contracts where you engage a supplier to provide a fixed team for a fixed time and budget to achieve a goal with a variable scope.
Shane Gibson
So today, we will talk about the idea of a fixed price, fixed scope contract and how they're complete bullshit in the Agile world.
Murray Robinson
And how bad they are for clients, as well.
Shane Gibson
Where should we start? Should we start with, you giving us a definition of what you mean by fixed-price contracts.
Murray Robinson
It's common for companies to request a proposal or tender to build software and websites or whatever because they haven't got the capacity or the skills internally. The government does that with all of its work. A lot of companies do it for their work as well. They do a big, upfront piece of work to define the requirements and architecture, which takes a long time and costs a lot of money. Then they create a request for tender or proposal, and they get a bunch of companies to compete to win the work. Then when somebody has won it, they agree to deliver a fixed scope defined in all of those extensive documents. A fixed scope for a fixed price, time usually isn't set. So it's a legal contract that people sign up for after a bidding process.
Shane Gibson
What they're asking for is certainty for a whole lot of business reasons. They believe that by writing down all the requirements upfront, they will get certainty of cost. But, in my experience, we all know that nothing is certain. You can have a guess and write it down, but as soon as you start building it out or delivering it, all the surprises come out of the woodwork, and everything becomes uncertain.
Murray Robinson
Yes, I agree with you. Organisations have fixed-scope contracts because they don't trust their service providers or development partners. They're worried that they're going to rip them off somehow, so they try to make the scope fixed. And the government requires competitive tenders because they think it's going to be the way to get the best value for money.
Shane Gibson
I can see how senior people would be nervous about signing off on a solution without understanding what it might cost. The behaviour I see is that managers put the requirements into a tender, get back a bunch of guesses on the cost, talk to the vendors and find the one they like. They may or may not pick the lowest price.
Murray Robinson
They nearly always pick the bids with lower prices. So I've been on both sides of the fence.
Shane Gibson
Same here, but I've seen times where the price is low, that they get discounted straight away because the bid is not credible. So they sign all the paperwork, the vendor comes in, they run a couple of initial discovery workshops, they then say, Oh, well, what you wrote down isn't the actual scope of what you need, let's start the change request process.
Murray Robinson
Yes, the change request process, which is always very painful. If the vendors are clever, they will charge you for the change request process because they can make a lot of money from it. And to be fair, you've got business analysts and project managers who have to do work to understand the change.
Shane Gibson
Work needs to be done, so why shouldn't the vendor get paid for that work?
Murray Robinson
Then they tell you that this change you want will cost a surprisingly large amount of money. That's nearly always the way it works. There are a few reasons for that. When you go through a project, you will discover, in my experience, that 30% to 50% of the requirements, architecture and design will change. There's a vast number of change requests on these sorts of projects. How many there are, depends on how strict your service provider or partner is. The big ones, tier-one providers, will usually raise change requests at the drop of a hat. Other smaller providers will try to accommodate changes where they can. It depends on how much financial stress they're under as a supplier. In my experience, major service providers underbid these contracts knowing that they can make a profit on the change requests. Many people don’t know that they're underbidding because there's so much uncertainty about how much things cost. Once they get into it, they discover that they have to charge a lot for change requests to make money.
Shane Gibson
I've seen that. I've also seen the other side of the coin where the requirements require interpretation because they are written words. The context of those words is often more important than the words themselves. The vendors make assumptions around those requirements about what needs to be done and what doesn't need to be done, which differs from what the customer had in mind. That's where the disconnect is. In that case, a change request is valid because the work they expect to do is more than what they thought it was. I've seen both sides. It comes back to the idea of writing words down, giving them to a whole lot of vendors and expecting them to give you a price back that has any relation to the work needed to be done. Assuming that work has no uncertainty is bullshit. It is a broken idea to go to tender and then figure out what it will cost you.
Murray Robinson
It's in the service provider’s interest to assume that every requirement is as simple as possible and write those assumptions in their proposal. It's in the interest of the client to assume that every requirement is as complicated as possible. Because if it's a fixed price, fixed scope project and you can make the requirement complex, you're getting more work for the same amount of money. Whereas if you can do less work, you're better off as a supplier. I've seen clients take the attitude that we are paying for it anyway, so let's try and get everything we can. Let's gold plate this requirement.
Shane Gibson
The other thing you have to do as a vendor if you're doing that billing process is to bring in fat. You put a percentage risk margin on the estimate for the uncertainty that's typically hidden. You hide that margin from all those estimates from the customer. They don't know whether vendor A has put 50% on and vendor B has put 100% or whatever. They don't see those core assumptions because they are hidden.
Murray Robinson
There's a good reason for that, Shane. I once did a more open tender for a large car company where I said the project would cost between A and B. The difference is contingency. When we won the RFP, the Project Manager told us to take the contingency out of the budget. Then, when we needed the contingency later, they criticised us for going over budget. This is very common. I've been a project manager at waterfall and Agile places for quite a long time. It's common for project managers to find that senior managers have promised stakeholders that they will do something for far less than it will cost.
Shane Gibson
Humans are crap at estimating. It's always seriously underestimated. It depends on what your definition of success is. I experimented when I ran a consulting business. I told customers we would bid based on the worst-case scenario and split the difference between what was spent and the worst-case scenario by halves. You save half of it, and we get half of it. They didn't take it. I wondered if they had, would it have given us an incentive to cheat on the features, to get them good enough to get across the line, but not great. A bit of technical debt because it's always hidden. Bad behaviour may have come in. That was my idea for a more Agile contract.
Murray Robinson
Before we go on to Agile contracts and the solution, I want to say that fixed price fixed scope competitive bidding drives a lot of terrible behaviour. I wanted to go through what that is. The first thing is that there's a powerful incentive for salespeople to lowball. If a salesperson asks the delivery team for an estimate, they will get a wide range because of uncertainty. The salesperson will usually put in a bid at the bottom of that range. They know that clients are looking for value for money and therefore always prefer the lower price. Usually, clients pick a bid in the lower middle of the pack, not the absolute bottom. When you measure salespeople on revenue, they will bid as low as possible to win the work. And delivery will have to work out how to make a profit once you've won. Often they don't even talk to the delivery people at all when they're quoting. I worked for a digital agency that lost a lot of money on all of their retail projects because partners and salespeople were estimating everything at half the actual cost so they could win the work.
Shane Gibson
I've seen that. When I'm talking to founders of new startups, starting their journey, I'll often say to them that at some stage, you're going to think that you're not the person to be selling to your customer. You're wrong, but you'll feel that. Then you'll think you need to bring on an experienced sales professional to drive that business for you, and you're going to compensate that person for the sales revenue they make. You shouldn't. You should pay them for successful delivery to the customer in terms of customer happiness and profitability. Because otherwise, they're going to sell your product for whatever they can get for it. Then you're going to spend more money delivering it than what you got. This means that you're going to make a loss, and it will kill your startup. I've seen that time and time again. So what’s the salesperson compensated for? They are compensated for revenue on sales made.
Murray Robinson
Let's say it's done in good faith, and the sales team is not deliberately lowballing. They're just trying to put in the lowest price they think is realistic. After they win the project, it gets handed over to a delivery project manager who is measured on profit. If the PM makes a loss, there's an excellent chance that they'll get fired. The Project Manager will start off thinking the estimate is reasonable. They want to have a good relationship with everyone so they will be nice about the requirements and changes, to start with. As they're going through the project, they'll begin to realise that it has been underestimated, and they're going to lose a lot of money and could get fired. So they start being extremely controlling so that they can charge the client a lot for changes. They start telling all of the people in contact with the clients, the BA, the designers and the architects that they've got to be very strict about changes. They will tell people not to commit to anything in meetings without review by the PM. Maybe the company will put in place a reward and incentives for the team to raise change requests. They might set up a change request factory. When the team thinks a change could be one to 10 days work, the PM will make it 30 days work. I know a major insurance company that got a quote from a tier-one consulting company to do a piece of work for 30 days. It turned out that one of their staff was able to do it in two hours.
Shane Gibson
But the question is, what did the velocity of that vendor working with that customer look like in the past. Perhaps it was two hours of work for an internal developer, but if you're external as a vendor, you've got all these gates to go through. You can't get access to people in time. You've got people on the bench charging but not delivering because of the customer. So maybe that's where it comes from. But the idea that delivery team members can't make any estimates or decisions in meetings with clients, all I can do is write something down and hand it off to somebody else to go through a whole process to come back with a guess before I can deliver value. How unAgile is that?
Murray Robinson
It's incredibly unAgile. For everything written down in the beginning, there's a wide range of interpretations possible when you get into it. But if you're in these unprofitable contracts, it's better to build the wrong thing because it was written down and then make it again profitably. That's much better for the supplier. It's terrible for the client, though.
Shane Gibson
Sometimes the first supplier exit's and a second one comes in. But what happens when you force a partner to do work that becomes unprofitable? They're not going to go under. Instead, you're going to get something that has massive hidden technical debt. Or you're not going to get the features you need to be successful because they have to reduce the work done.
Murray Robinson
I agree. That’s precisely what happens. They'll start positively because they don't usually know yet that it will be unprofitable. Then they start getting super strict. The decision making power gets taken away from the people interacting with the customer, except for the project manager. The PM ramps up the estimates dramatically to improve margin. The project manager starts giving people a lot less time to do things, and they start delivering crap. I know of one project with a major Indian company, where they delivered code modules into UAT that were copies of other code modules for other areas. That code didn't do anything like what was expected. I found out later that their managers were telling them to deliver crap into test because they'd have more time to fix it after.
Shane Gibson
Yes, I've seen that behaviour as well. The relationship between the vendor delivery team and the customer was bad, so the milestones were now important. Unfortunately, the milestones were poorly worded, and the acceptance criteria were woeful, so they could deliver crap and then treat everything else as a bug.
Murray Robinson
These fixed scope, fixed price tenders force the client and the supplier in different directions. Instead of having a common interest to deliver something of value, which helps the business, the supplier becomes wholly focused on making money. So the client ends up fighting with them the whole time, which leads to very negative behaviours, which are very common in waterfall projects.
Shane Gibson
That's where there's a whole lot of uncertainty. I'll give you an example.
Murray Robinson
I would say every software project has a lot of uncertainty.
Shane Gibson
But it's the level of uncertainty. I will give you an example of where a fixed price does work, but there are consequences. We identified a piece of enterprise software that was relatively hard to manage and maintain in a previous life. Customers were spending quite a lot of time upskilling their staff on maintaining this stuff or hiring vendors to come in and maintain it for them. It was quite an expensive space. We found a way to automate support tasks to reduce the uncertainty of managing that software. There was quite a lot of work upfront for us to go in and deploy our automation because every customer's site was different. There was no standardisation because of the enterprise software vendor. When we deployed our automation techniques, it would take a couple of months to get the platform healthy and for all the problems to disappear. Then we charged them a fixed monthly fee for maintaining their platform in a healthy state. What's interesting and comes back to this win-win bullshit that everybody thinks happens is, after a while, the customer worked out that we weren't spending a lot of time looking after the platform anymore because we'd automated it. They started saying, Well, we don't think it's fair to pay you that fixed monthly fee because you're not putting the hours in. Then they wanted to reduce the bill, which wasn't acceptable to us. We'd spent a lot of time investing in automation, and we had a fixed price that we all thought was fair when we solved their problem. If our margin was higher over time because of automation, then good on us. Or if there was an alternative in the market that was cheaper that did the same thing, the client could go for it. We priced wrong there. It goes back to that win-win. If it's a fixed price, and they happen to make a 100% margin on the work they're doing, and you're getting what you asked for in a good way, then that's okay.
Murray Robinson
The other thing you mentioned was changing suppliers midstream. Generally, it’s impossible to get a second quote on changes once you're in the middle of a development contract with a supplier. Nobody else knows what's going on, and they couldn't come in and do it because the first supplier would refuse to cooperate. So what happens is that these fixed-scope projects tend to go way over time and way over budget and do not deliver much. Many large projects come to a crunch point where the client decides to keep going because of sunk costs, or they decide they've completely lost faith in the supplier and get rid of them. When that happens, they have to take six to 12 months to go through the tender and initiation process again. Then the new supplier comes in, saying everything the previous supplier did was crap, and they have to start again with a different solution. They won't use what's been done before, and they’ll delete it. That can happen three times: you get the first big consulting company, they get fired after you've spent most of your money, then the next big consulting comes in, and they delete all the old code and start again. Then they start behaving like the first supplier, and the client fires them. Then a new supplier comes in, deletes the code and begins again. There are plenty of big projects that have been done three times.
Shane Gibson
There are also examples on your side of the Tasman, where they carry on with the first one and end up running over budget by hundreds of millions or billions of dollars. Sometimes the platform never works properly. We can see this in the government because it becomes visible.
Murray Robinson
The Australian Census Bureau engaged IBM to put the census online. However, when it went live on Census night, it couldn't handle the load. It may have been because the load was never specified in the contract.
Shane Gibson
I'm guessing it was one of those fixed price scenarios,
Murray Robinson
Yes, and as soon as people started to use the online census, it fell over.
Shane Gibson
Why was this such a level of uncertainty on a Census system? From memory, it was one of the new digital ones designed for citizens to come in and do the census online. It was a relatively new system around the world, therefore uncertainty.
Murray Robinson
You get a consulting soup in these situations. IBM said it wasn't their fault because another service provider that the government had commissioned to do the platform hosting that was responsible for the system performance. They said it was IBM’s fault. So they all pointed fingers at each other.
Shane Gibson
Which gets us to the idea of a systems integrator. A consortium, one throat to choke model.
Murray Robinson
IBM was the systems integrator in this case,
Shane Gibson
We double or triple down on the stupidity of fixed price upfront contracts when we appoint a systems integrator to take the risk for all the fixed prices. You get a bunch of other vendors to fix price parts of the solution for you. But we're going to hold you accountable for their price and your fixed price.
Murray Robinson
The systems integrator will say they'll take responsibility. Still, then they'll say that the client has to contract with all of the other parties separately because they don't want to be responsible for paying them. Usually, the client wants to do that because it's cheaper and gives them more control. But then the systems integrator says we can't be held responsible for those other suppliers because we are only a coordinator. They contracted with you and not with us. Even if they take responsibility for all the subcontractors and pay them themselves, they'll say that they were blocked by your internal departments, which is often the case. It's difficult being a provider because the client usually stuffs it up themselves. I can understand why suppliers misbehave in that situation. It's because of the system they're in.
Shane Gibson
Fixed pricing uncertainty early is bullshit, and you should never do it. Have you seen any Agile techniques or practices that give us hope?
Murray Robinson
There's a couple of solutions. The first one is to build trust with the supplier before you engage them to do something big. It's incredible how many companies will give a $10 million, $100 million or billion-dollar project to one of the big consulting companies when they don't know them. You should do something small with a supplier to establish trust and understand how they work and see if that works for you. Start small and scale-up. Do a $100,000 piece of work, then a million-dollar piece of work, then a $10 million piece of work,
Shane Gibson
So, that's exactly like the conversation we had last time around scaling. Don't try to start with 100 teams and scale your delivery out on day one. Instead, start with something small, prove it's working, and you're happy and then deal with the scaling problem. It's the same pattern. Start figuring out how you will work together, then figure out how you can scale to do bigger pieces of work.
Murray Robinson
Yes. If you do fixed price, fixed scope contracts, keep it short, like one month or two months. Suppliers are pretty good at estimating for one month of work. They are reasonable at estimating two months of work, and after that, it becomes quite tricky. So if you're going to do fixed, price fixed scope, do short ones. Then once you've got to know your supplier, move away from fixed scope altogether. Move to a fixed price, fixed time for a fixed team to deliver on a goal with variable scope.
Shane Gibson
I'm going to disagree with you on that one because I will flip it around the other way entirely. When they start, teams are crap at estimating even a month. We should work with the supplier on a small piece of work and fix the price. We can do this because we're saying there's going to be four of your team and four of our team, and we're going to work together for a month.
Murray Robinson
Is it fixed scope as well, Shane?
Shane Gibson
No, because that's when it hits us. It's a fixed price for four of your people and four of our people for a month to build stuff. We've got a vision, but we have no idea what we're going to deliver because we haven't worked together before. When we get good at working together and get better at estimating, we can fix the scope. The team has a velocity with repeatable practices; the only thing that is uncertain is what's going to be delivered. Therefore we'll get better.
Murray Robinson
How are you fixing the scope? Are you setting it by velocity?
Shane Gibson
Repeatable velocity gives us more certainty on what we could deliver in the time we have. When we work together and build stuff, we get better estimates because we're having better conversations. The conversations when we do these estimates are more robust. It's not one supplier's project estimator making up the numbers; it’s the team doing the work. We can get to more of a fixed scope when we have maturity amongst the vendor’s team.
Murray Robinson
We're not that far apart. But I don't think that teams get a whole lot better at estimating. I've tracked teams, and the cost per story point changes considerably over time, even with the same team. It can double or halve from sprint to sprint because there's much uncertainty about how big a story point is, with teams getting it wrong all the time.
Shane Gibson
That's not how I measure success. For me, teams are successful at estimating when they get better at delivering what they said they would when they said they would. It's a very unscientific method, but it's based on all the teams I've coached. You can see the team get better at estimation because they're getting better at delivering what they thought they might in that time.
Murray Robinson
There is still a lot of uncertainty and variability in estimates even when teams have worked together for a long time. That's because there is still a lot of uncertainty about features that you haven't done before. There might be a few words about the feature, but it's hard to know what that means. If you're fixing the price and scope of features, it brings back the incentive for the client to add all the bells and whistles after you've agreed to deliver it for a fixed price.
Shane Gibson
I've seen that even with internal teams. The team tells the product owner that there are different ways to deliver a feature. If they pick the more complex option, they probably won't get the other features in the backlog in this iteration. The product owner says, well, I want both. So we do it to our internal teams as well as our vendors.
Murray Robinson
I agree; it does happen to internal teams. But the solution for me is a short time-boxed project initiation and planning approach we talked about a couple of episodes ago. I like to offer clients a fixed price for two weeks or four weeks of scoping and planning to develop a release plan. Then we will provide a fixed team for a fixed price and a fixed team to do the work. But the scope won't be fixed. We're going to take the roadmap and the design concepts and start working through them. But we all agree that we're going to change our roadmap and our priorities as we go. As we learn more, some things will get bigger, and other things will get smaller. Things will get added in, and things will get taken out. As we go, we will work together to plan what to do, and we will show you the things we've done. With this approach, both parties have a strong incentive to align around value for the client. The client has to try and get the highest business value out of the team because they will finish on a specific date. And the team wants to provide the best value they can to the client in the available hours. It's not about somebody trying to get more hours or do fewer hours. The hours are there. You're both looking to get the best value out of the team you've got for the hours you've got. I find that brings everybody together in collaboration.
Shane Gibson
So what we're saying is feel free to fix the price but never fix the scope. But over time, as you work together, you can get slightly more certainty about the scope that might be delivered within time. Because again, remember that our stakeholders are saying, I'm uncomfortable with this open cheque book, and you can't tell me how long or how much, and that makes me feel nervous.
Murray Robinson
The approach I'm describing is not an open cheque book. I'm talking about a fixed price and fixed time for a fixed team.
Shane Gibson
Yes, but if they're building a product, that product has to get to a certain level before it provides value back to the organisation. Stakeholders don't usually think that one feature has value on its own.
Murray Robinson
I agree. In your initial planning, which should never take more than a month, you should work out the ballpark budget to achieve your goal. That will be a combination of what the client wants and what they can afford. You end up agreeing on a budget that should let you get two-thirds of the things you want. That should give us enough confidence to go ahead. But we all agree that what comes out at the end could be different to this plan.
Shane Gibson
You should have the ability to replan as you learn more and as the business changes while we're building things. To go back to procurement, we should still provide a list of requirements in our tenders to show what we think is essential, and the vendors can still come back with a guesstimate of what it might take to deliver that. But what we should do is tell them that we're not focusing much on the number; we’re focusing on the workings. Don't give us the answer. Show us how you got there because that's going to let us know how you estimate. That's one way of comparing vendors because the idea of the tender was to pick the best one.
Murray Robinson
Tenders are not a good way to pick the best vendor because you don't have much exposure to them during the process. You put out a document, you have a meeting with a bunch of vendors, then they present their proposal, and you've only spent two hours with them. You don't know them. It's a terrible way to get to know your suppliers. In the tender, you'll ask suppliers 1000 questions, and the salespeople will agree to everything, whether it's true or not, so they can get the sale.
Shane Gibson
Having been a pre-sales or sales engineer in a previous life, it's like the pricing thing. You never want to be the highest, you never want to be the lowest, you want to end up in the middle.
Murray Robinson
I have been in pre-sales too. You end up saying yes, but. Yes, we can do everything you say but.
Shane Gibson
Then you look at it and realise that your response looks dodgy because you've said yes too much, so you back and change some of them to no.
Murray Robinson
Clients always say that you have an 85% fit or it's not worth it.
Shane Gibson
I don't think we can go on to a better way of evaluating a partner than an RFP. If you're in government, you can't choose to change that process.
Murray Robinson
They have to change the process. That's my recommendation because it's bullshit.
Shane Gibson
What's going to happen? If they change the process to buy off anybody and there are no competitive tenders, everybody's mates will get the work. All the large tier suppliers will do all the work because they can afford to develop personal relationships.
Murray Robinson
I agree that's bad as well. You should do small pieces of work to get to know suppliers and then gradually move them onto bigger pieces of work. You have to prove yourself on a $100,000 piece of work before you can bid for a million-dollar piece of work. I would qualify suppliers over time and run an internal log on your experience with them. I strongly recommend that people do not go and hire one of the giant service providers for a big piece of work straight away because you can have a bad experience.
Shane Gibson
I liked that idea, but then, as a start-up owner, I hate it because it makes it hard to get into companies with preferred partners. I agree that it's too risky to kick off a billion-dollar project. We should never start with 100 squads of 10 people. We should start small, figure out what works and get better at it.
Murray Robinson
If you have two or three suppliers that you trust, then you can get them into a room together to estimate a project with you. I went to a talk on Agile procurement by Mirco Kleiner. He suggests that you pick three suppliers you trust and spend two days with all of them doing open estimates. Every supplier can see and question the assumptions the others make. It looks like a fascinating open-book approach.
Shane Gibson
I like it. There could be many commercial problems with it, but if your suppliers want to work with you going forward, they might have to do it. That's the same idea as never having a business team estimate on their own for delivering something involving technology. If you're running a siloed hierarchical organisation, you should always have somebody out of the technology side of the business involved in estimating and planning. Everybody's view has value, and when you work together, you get a better estimate when you remove barriers.
I thought I would say never fixed price, never fixed scope, because it's bullshit. I'm going to change my mind. I'm going to say fixed pricing is OK, but fixed scoping is the problem. Never fix the scope.
Murray Robinson
Fixed scope contracts are awful for clients and suppliers, even though it feels better at the start. You could fix the scope for small things because the risk is pretty low, but I'd only do that to get to know people.
Shane Gibson
I'd say that you could fix the scope for a small thing because it's safer to fail.
Murray Robinson
I'd prefer not to fix the scope but to set a fixed time and cost price for a fixed team. That makes a lot of sense to me, and it works very well in my experience.
Shane Gibson
Because it's an Agile mindset, many of the old patterns and practices are based on a fixed scope philosophy. Agile patterns and practices are based on a variable scope mindset.
Murray Robinson
Agile values collaboration over contracts and working software over documentation. Fixed scope projects are all about deliverables, documents and change requests. Agile values individuals and interactions over processes and tools. If you're in a fixed scope contract, you've got to focus on change control processes and requirements tools to make money. Agile values responding to change over following a plan because there will always be a lot of change. Procurement managers have a factory model of software development that assumes that there's very little uncertainty about anything. They use the same process for buying 10,000 reams of paper as they do for purchasing customised software. The factory mindset is utterly wrong for software development because it assumes that you do the same thing repeatedly. Product development and software development are not like that. It has far too much uncertainty, far too much change and far too much learning.
Shane Gibson
It's not just the customers who are at fault; it’s also the vendors. The global ERP vendors claim that their software is all out of the box. It's easy to implement as long as you follow their best practice implementations. I have yet to see one of those implementations where there hasn't been changing required. Suppliers have this idea that there's no uncertainty when you're deploying their ERP packages out of the box. That bullshit; there's uncertainty.
Murray Robinson
I've been on the client-side when they've engaged the big three-letter acronym software product companies. When you get into it, you find that what you bought is an extensive tool kit. It's like a big box full of Lego that you can do different things with. It's common to spend half your budget on customisation because it turns out that the product doesn't do what you want to do or that you thought it would do,
Shane Gibson
I don't mind buying Lego because it's better than buying a bunch of resin and making your own to put together. The problem is they're selling us the Bumblebee Transformer robot, but we are not getting it. Agile is a better way to work when there is any uncertainty. We should not allow fixed-scope contracts because there is always too much uncertainty. We are lying to ourselves and were lying to our customers. That's why the problem happens.
Murray Robinson
There is an ethical issue here. Sometimes underquoting is deliberate and unethical, and sometimes it's inadvertent, and you get yourself into a difficult spot. That happens a lot. But I would say that the Agile way is far more honest and collaborative for everybody.
Shane Gibson
I suppose if I liken it to a surgeon who's going to do heart surgery, they're not going to fix the time; they’re not going to fix the scope because they're walking into a mess of uncertainty.
Murray Robinson
I want these contracts to focus on outcomes. Imagine if you contract a supplier to build a marketing website to generate leads for your travel company. In an agile project, you would develop a plan, agree on a budget and work through the product backlog until you reach the end of your time and budget. But wouldn't it be better if the contract was defined by how many leads you could get each month rather than what features you could implement? So after the first month, we could show that we made these changes, producing these leads. Then in the second month, we implemented more features and got more leads and so on. Every month you're showing your client that you're helping them achieve their business objectives rather than just producing features. When you focus on outcomes, you give the team a lot of flexibility to say we could do feature X or this other feature Y, which looks like a much simpler and easier way of getting more leads.
Shane Gibson
It's interesting because the psychology of fear of missing out happens. When we had a fixed monthly fee to deliver a healthy software system, people started worrying about the effort we were putting in. I worked for a large analytics vendor with a good fraud detection solution. They offered to sell their fraud detection solution based on a percentage of the drop in fraudulent transactions they delivered.
Murray Robinson
And how did that work?
Shane Gibson
Few customers picked it up. Clients said that we could do it without paying you a fee per transaction. We will build it and run it and take all the money. That idea of a win-win and a shared outcome, where you're both successful, didn't happen. This was 15 years ago. Maybe the world's changed, but humans don't tend to.
Murray Robinson
I haven't got anyone to sign up for it. Software development teams are full of smart, creative people. If you tell them to build features, you're limiting the value you're getting from them. But, on the other hand, they might have a lot of good ideas about how to generate leads that your product people haven't even thought of.
Shane Gibson
It's what we coach agile teams to do. You should discuss the outcome with the product owner, iterate on the things you can build to help them achieve the outcome and work together to deliver it. Why don't we do that with our vendors?
Murray Robinson
We should summarise
Shane Gibson
Fixed price is ok, but fixed scope is bullshit.
Murray Robinson
I agree with you. A fixed scope drives a massive wedge between the supplier and the client, but a fixed contract for a fixed team for a fixed time brings you together.
Shane Gibson
Make it happen
Murray Robinson
Thanks, Shane. That was the no-nonsense Agile podcast from Murray Robinson and Shane Gibson if you'd like help with Agile contact Murray at evolve co that evolve with zero thanks for listening