 Today in the Agilentia podcast Sean and I are gonna be talking about this concept of firm fixed price contracts so The road to waterfall was paved with good intentions right How do we arrive at water waterfall? It's through the natural Reaction to things going wrong Okay, so I that makes sense to me. I'm thinking of When I worked at a company that we invented Essentially invented Requirement specifications. It was a direct result of quality issues. So the idea came where if If you the later in a process you discover you're wrong the more expensive it is right? So logically you should do more investigation early to eliminate those problems before you waste time building stuff Because once you've built it you've spent that money you want to find you want to find out you're wrong early and the way you do that is through Discussion and documentation of the discussions that you've had that makes sense Right, so something goes wrong and we what do we do we add a process right we add More documentation we try to spend more time making sure we're right to make sure we Never go we'll never go wrong again, you know, let's do root cause analysis And let's prevent us from being wrong right Well, what does that do? What's the consequences of that? What are the second and third order effects of trying to not be wrong? so what do we do we add these things these documents and requirements and upfront thinking and stage gates and what happens and I think too often We tend to hold on to this concept of of a firm fixed-price contract as something that we have a hard time letting go of and I don't necessarily mean a physical contract that we're signing with an external customer I mean these forms of in it might be an internal contract between and and and you can hear the language when we talk about commitments and accountability It's what's the what's the purpose of a contract? What's the fundamental purpose of of a firm fixed-price contract? When something doesn't go according to plan who eats the cost right it is a risk transference mechanism It says when things don't go right I Did the burden of that responsibility that the risk is burdened by one of the parties and it's predefined in such a way that now I have I'm the customer. I don't trust my supplier. I Don't trust the motivation in my supplier. I don't trust that they're not going to fleece me therefore, I'm going to write it in such a way that if they don't perform it is on them It is their responsibility. They are burdening the risk. Okay, and then if I'm the supplier I'm now incentivized to make sure everything is documented to an excruciating detail because I don't want to be held responsible When we get to the end and they're saying well, that's not what I wanted you to build I in fact I want it to be specified to a degree so that there's no ambiguity about what I'm agreeing to build for you At the end of the day, I need to cover my butt Yeah, I need to be able to go back and say no look I built exactly what you asked for so The Stephen Covey in his book that the speed of trust kind of talks about this trust tax and so by insisting on a firm first firm at fixed price contract What are the second and third order effects of that now the supplier needs to have a firm specification of what you want? right and that takes time and it takes being right and It means that we've now front-loaded a lot of the work And we've trying to trap in attempts to try to transfer the risk So I want that I I've heard a lot is the debate over is that a bug or is that a story? Is this is probably something you've heard? Yeah, and I think this is a result of this type of risk transference because as a developer If you come to me and say well, this is a bug And I don't want to be responsible for not meeting my commitments. I might say well No, no, that's that's not what we agreed to that's actually a new story what I'm trying to do is force the responsibility back on to the business and and sort of Deflect the the responsibility because I'm what I'm what I'm engaged in is Meeting my commitment not in producing a product that's really solving the end customer's needs Yeah, so let's think about for a moment. How much time and effort and mental energy is spent Trying to either cover our own butts or transfer risk or transfer responsibility or Make sure that if something goes wrong the appropriate person is to blame Right. Well, it's not me as the developer. I was following instructions Well, it's not me as the business because the developers didn't meet their commitments and and all of this All of this paperwork and paper trail to try and prove that that is that is a Steven Covey puts at the speed of trust so if we're talking about firm fixed-price contracts, what's an alternative way of of Getting work done The alternative way is time and materials. I can either Contract out things as a firm fixed-price or I can get a time and materials contract and I say Spill me for the number of hours that you work. Why would I choose? Why would I not choose that? If I have a mental model that people are not intrinsically motivated Then I might believe that in that model people are just gonna sit in their hands because they're getting paid already You're gonna get fleeced, right? I go. I think it doesn't matter how long they take because They've got no interest in getting things done fast, but why do we accept that in certain cases? My lawyer charges me by the hour Well, you trust your lawyer you believe that they have a level of professionalism In fact, their profession requires them to behave ethically My accountant the same way they I get charged by the hour so why Why are software developers different now? I I believe that this is often a Trained behavior It could be that somebody has spent a great deal of time in their career interacting with developers who have Not instilled them with trust Maybe I've been burned. Maybe I've tried to extend trust before and it's gone poorly and I've I've felt the brunt of that So how do you develop a trusting relationship? That is a good question. I think one thing that we need to start with is Declarity around that the relationship we want to have is that of a time and materials Don't even try don't even start with agile Don't even get out the door with trying to say you're trying to be agile until you can Get to that point of saying this is going to be a time and materials relationship so so what would be some smells if you were listening to the language a Team is using or a product owners using that would lead you to believe that they are using firm fixed price contract as a mindset around their work There's all types of language that we use that basically imply a risk transference Where we are not co-equal partners in a venture by the business and development team And we are Engaging in a risky enterprise because it is only through this risk that we actually generate value But it's a I am now pushing the respect something goes wrong I'm pushing the responsibility to you so what are what are some of these words like you say commitment is one And how do we use that? Have you met your iteration commitments? Have you met your iteration committed you get that done on time? Yeah, estimates versus actuals You're on the hook for that Who's whose head's going to roll? In fact, this is very violent language even though we're deadline It's a very violent language around this. Yeah, you cross it if you don't cross this line, you're dead And so there yeah, you're right. There's all this there's a violent Violent language that we use to try and convey the fact that something is important and Why does that matter why do we need that I Think I think language communicates values It's when people hear that type of language It's going to it's going to motivate their behaviors. It's going to incentivize certain behaviors So so one of the things one of the behaviors we want to incentivize is transparency of information So if we have a firm fixed-price contract, I Am not incentivized to share with you all of the information if I have new new information arises It's going to make something take longer. I may actually hide that information from you I'll you know, I'll figure out a way to get it done, right that the deadlines in moving a moveable It's on my head. So why on earth would I share things going wrong because? It's just going to come back and say well, it's on you know It's on your head to to solve them So we then we place our hopes and our dreams on well, you know Maybe we'll have a miracle and maybe we'll just work some extra overtime in the end and therefore We ignore information that's available to us. I think we even avoid seeking out that information you know one of the things that Scrum and other methodologies encourage is getting customer feedback Right, but if customer feedback is going to change the requirements. I Don't want to go seek that information out, right, you know Oh, that's great that they want a new user story, but we still have to meet our deadline and and that's not what I agreed to That's not what I yeah, that's not what I agreed to so here's my point is yeah if if you're not willing to engage with your developers on a time and materials basis then Don't pass go right don't pretend that you're agile because you're doing a process because fundamentally you don't you have not built a Either you have not built a project around motivated people or you have and you don't actually try that motivation and you're trying to use fear as a mechanism and risk transference is a I believe a fear-based motivational tool So this is my mental model of this relationship we can have with development teams that risk is There that's acknowledged risk. It exists. We are not a We are not a manufacturing line We are building everything we build is something that's never been built before because that's where it derives its value from we do not know exactly how to build it going in because that's what we're getting paid for is to figure that out and There is inherently risk in that but let's share that as a team the business side development side let's acknowledge it share it and then use information and incentivize this flow of This transparency of information as we go through because we can use that to our advantage Thanks for joining us today on the agile India podcast. We're your hosts Chris Edwards and Sean Dunn Agile India is Asia's premier conference on agile lean methods. You can join us in Bangalore March 6th to 10th We hope to see you there