The Agile Manifesto: Customer Collaboration over Contract Negotiation

This is building better developers, the developer podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season where we're talking about the agile or agile, depending on how you pronounce it, manifesto. We have talked about the 12 principles and now we're looking at their four main statements, I guess, that are the manifesto or the, I guess, the introduction to the manifesto. We have worked our way through the first two statements where individuals and interactions are valued over processes and tools, working software over comprehensive documentation. And now we're going to look at the third one, which is quote, customer collaboration over contract negotiation. This is something that I think most, we'll call them pure developers would dive right into that and say, yeah, there's no question because they probably have not had to spend much time. If you're lucky, you're a developer and you haven't had to spend much time dealing with contract negotiation. By the time you got into anything related to the project, the contracts were negotiated. That is unfortunately not the case for everybody. There are the hosts that spend actually their entire career focusing on contract negotiation and how to make sure that all the T's are crossed and the I's are dotted. And that is really, I guess, the crux of this point. It has become probably a somewhat popular thing, although a little bit of an empty, maybe a sort of buzzword kind of thing that for somebody, contractors consulting in particular, that we partner with our customers, we work with our customers, we feel you're part of the team, stuff like that. It's basically trying to gloss over the us versus them mentality that can come up and instead essentially paint the picture that, hey, we're all on the same side, we're all in the same boat, we're all doing the same thing. Unfortunately that's not true. That's just bottom line. Now as a consultant, as a vendor, yes, it is, I think it is in your best interest to have your customers' best interests at heart. But if push comes to shove, there's going to be, you can't always do that. You could be taken advantage of. Contract negotiation is a perfect example of this. Well it would be nice to just say, sure, whatever you guys want, that may not be feasible. They may say, well, we want the entire world of an application built for 10 bucks. And you say, no, it can't be done. And they say, well, tell you what, better yet, it has to all be done in a week or something like that just to make it really bad. Those are the three prongs that people talk about, which are speed, resources, and quality. So you can get it done fast, you can get it done cheap, but if you do, then time-wise it's going to be, you're going to have to pour, it's going to take a long time. If you want it done well, you can get it done cheap, and it may even be able to get it done fast, but it's going to be cheap. If you're willing to spend the money, then you can put a huge amount of quality and get it done maybe very quickly. But even then, there are realistic limits. And so I want to move beyond the realistic limits because I think that more or less is not too much of an issue. I think most cases, if somebody comes in and says, hey, I want X done in Y amount of time. A customer goes to a vendor and says, I need to get this project done in three months. And maybe that's possible, maybe it's not. And so the starting point is the reality check. If they say, this is what we want done, and this is the initial constraint, and the vendor says, that's not possible at all, then it sort of stops the conversation right there. You guys have to go back to the drawing board. It can't be done, then it can't be done. You can't, miracles are not going to something to count on or anything like that. So you have to go back to the drawing board and figure out, okay, well, what, let's get ourselves into the realm of reality. What I want to talk about here, we're talking more about the, I guess, the edges of what is possible and what is of some benefit to the customer or the vendor. Now the vendor, they've got people they want to keep busy, they've got bills to pay, they've got a certain rate that they expect, things like that. On the vendor side, or on the customer side, then they've got a budget and they've got maybe deadlines and things like that. Maybe they've got competition that they're trying to beat. So they've got a different set of criteria and concerns. And while you can work together, that's not necessarily, those things are not always going to line up. The easiest one would be the financial side. A customer would love for it to be free and that's not possible for the vendor, mostly. Maybe there's some rare case that that would work, but for the most part, you've got to paid for the work you do. It's just a reality thing. And that's where we get into this point. You've got roughly two ways you can approach this. You can either, more or less, be very transparent, put everything out on the table, get everybody together and say, okay, how do we make this work for everybody? Let's find a way to get to a win-win. Or you can keep your cards close to your vest. You can try to manipulate the situation and get the best that you can out of it. And I use the word manipulate. I know that has a negative connotation there. I think there are situations where you can manipulate the situation and it's not that doing it to only benefit your side and to harm the other side. You may be trying to get a win-win, just maybe a win-win where your win is a little bigger than theirs or something that's not even that you have a bigger win, but that you have a win that is more to your liking. And if you can bring them along, so be it. Maybe that's a little bit the point. It's not so much. So in the one case, you're working together. In the other case, you're working for yourself, but it is also important that the other person is successful. So you're not completely free from trying to make them successful as well. And it's just, and this is not, it's not about, I don't know, being selfish or a bad vendor or anything like that. It's just, these are different approaches. And there are reasons that I can hear, have heard good arguments for doing things in different ways. Both of those ways, arguments very strongly for and against both options. This Agile manifesto point says that we value customer collaboration over contract negotiation. So it really shifts and says, look, we've done a lot of software. We spent a lot of time putting this stuff together. And remember, this is when software was not quite as complex as it's become today. And there weren't as many parties by and large involved as there are today, as far as individual businesses and organizations that you may run into. And they said, look, we've sat down, we looked at what we've done and realized that the best way to get to a win for everybody. Remember their number one priority, satisfy the customer, is to collaborate with the customer. Now you're trusting your customer to be a good customer, to be a good steward of the situation, to not take advantage of you. So if you walk into a situation and their goal is to, I don't know, to be blunt, I guess to rip you off. If their goal is to come in, get a bunch of free work from you and then not pay you, okay, that doesn't really fall under a valid software project. That's just somebody trying to steal work and time and effort. So let's throw it, yes, that can happen. You just have to be, do your due diligence, I guess, when you're dealing with projects and stuff like that. I don't think that's the norm. So yes, that can happen. We'll accept that, we'll acknowledge it, but we're going to move on. This is more about when both sides are honorable. So in that case, you can still have both sides honorable, but have them wanting to make sure that their position is clear and that they firmly understand expectations really on both sides of it. That's really where we're talking about this contract negotiation. This is where you nail down all the requirements and what are the expectations and the milestones and the deliverables on both sides. When do you invoice and what gets paid and when do you submit software or when do you open up software or when you make stuff available to them, all of that kind of stuff. All of those deliverables really that are involved in the product and the project itself Now you can either spend a lot of time not arguing or discussing, working through, negotiating all of the timing and the resources and things like that, or you can more or less do a, it's almost a trust but verify, I guess, but even if it's just a pure trust relationship, we say, look, we're going to work with you, we're going to get this thing done and we'll sort of figure it out as we go. So instead of being in a proactive situation and approach, which would be the contract negotiation, you get both sides, sit down, set expectations, all of the related expectations, agree on it, then you move forward. Or you can essentially both say, well, let's get going on it and we'll make sure that we're fair as we go. I mean, I'm simplifying, but that's roughly what we're looking at here. So instead of spending a lot of time trying to iron out the perfect contract, you get stuff done. Now this is, this is antithetical to some people's approach because they don't want to get burned and I get that. But that's what software, that's what this software approach is talking about. And I have to say that it is very much a real issue. There are plenty of projects that I've been involved with where contract negotiation and setting expectations and getting all that stuff down and understood has delayed the start of a project or has sometimes not only derailed a project halfway through, has caused it to fail because you get into a project and then suddenly there's changes or something like that. And then the contract negotiation falls apart and then everybody's dead in the water. Or worse, you're negotiating the contract and the deadlines end up essentially coming and going and then it makes the whole project useless. The time and effort spent trying to negotiate a contract sometimes is earned back by just getting the work done. And this is, this is something that I do that I don't know if I recommend to others or not, it doesn't always end up necessarily well to me in my sense, but I think it's just, it's the better approach to take is to look at some of this stuff and say, you know what, I'm just going to do it and we'll figure it out. I'll trust. And so you say, you know what, instead of spending time with a customer and trying to discuss what's covered and what's not covered and all of that stuff, you say, okay, you want these three things. We're going to get those three things done. Now that does definitely go back to the customer satisfaction. If it gets, if they say I want A, B and C and you provide A, B and C, almost by definition, that is going to improve their satisfaction. Not too many customers are going to say, wow, you gave me what I asked for. I can't believe that. That was horrible. I am very dissatisfied. That's going to move the marker towards the plus side of customer satisfaction if you give them what they asked for. So when you do that, you're solving the number one goal. Now there's a goal I don't even talk about, which is the idea that you need to be rewarded or compensated for your work. And then there's no guarantee that if you do those things, you're going to be able to do that. They're going to be able to compensate you accordingly. But sometimes the time spent, especially for small stuff, I think that's where we often can get really off track. Where there'll be very minor things, maybe as minor as, you know, I want these couple labels changed and this font changed and stuff like that. And then they become trying to figure out how to work that into a project or into a sprint or all the negotiation around doing that becomes that time spent on the negotiation you could have just gotten it done. So sometimes that's the case. It's not big enough that it should be a concern. Now if you want to be safe, then, and this goes back to the collaboration versus a contract negotiation thing, is that maybe instead of a really tightly written contract and negotiating all the details, instead you just allow for some wiggle room, some buffer. So maybe you write up a contract, say, okay, we're going to get paid X amount per hour of billable hour. We're targeting Y number of hours for the project and we're going to include this additional fee of whatever, some set amount or 5% on top of that or something like that that's just to cover other things. So that you've got sort of a bucket that you can use to cover some of the changes and things like that that you're going to run into. Now I say this with small projects, if you're working for a consulting company, doing stuff for yourself as like a side hustle or something like that where, yes, you could spend some serious time going through the contracts and getting lawyers involved in making sure that everything is worded exactly right and all that kind of stuff, or you can find some ways to shorten that. Now I've said before, I'm not a fan of fixed bid contracts and that would shorten the negotiation quite a bit. You just say, all right, what are we going to get done? We're going to get this done. We're going to get done in that time. But there's other issues that come up. So even in that case, it still comes down to you can lawyer up, I guess, you can focus on that contract negotiation part of it. You can focus on what was requested and the requirements and the details about that and whether or not you met those, or you can focus on just getting working software. It's a legalistic or not approach. So if you sit down with your customer and they put together requirements, because this really does go beyond even a contract negotiation, this is a general attitude. If you guys sit down with them and they put together some requirements and say, here's what we're going to do and everybody agrees to it and we're off and running, and then the requirements change, you can dig your heels in and you can say, well, I don't think we can do that change or that change is going to be very costly or whatever it is. You can think of all kinds of different reasons to not do the change. I don't want to disparage the fact that those may be very valid and very critical reasons. It may be that there's a change that just comes too late and it's like, hey, we can do this, but we're going to miss our deadline or something like that. Sometimes it just comes down to that. That's the reality. But instead of always digging your heels in and always saying, no, no, can't do it, can't making the customer fight for every change, just work with them and sort of assume as you go into any change requests that we're going to get this done, we're going to find a way to get this thing into this release, into this project or whatever it is. And yes, that can get out of hand. So it's not that, and this goes back to the things we've said with these other points, it's not that contract negotiation is something that you shouldn't do. It's just saying that when you work with your customer, that's even more valuable than the contract negotiation. Because assuming that everybody is on the level, everybody really wants the project to succeed. The customer wants to succeed because they want the product. The vendor wants it to succeed because they want to be able to use that as a reference and to get paid for it and all that kind of stuff, the things that come with being successful. So while you can and should to some extent have a plan, have expectations set, they're saying that the better approach when you do that plan is to work with your customer to help make sure that that plan covers them as well as yourselves. And this is, when you're an employee, it may not come up very often, but it is still something that is a factor. If your boss asks you to stay 30 minutes late to get this extra fix in, you can say, hey, I've hit my 40 hours of work this week or blah, blah, blah. You can have reasons not to, and they may be valid and they may block the work from getting done. I've already got an appointment. I've got to go. I can't stay late. I've got another prior engagement. Okay. Well, instead of just, hey, I've got a prior engagement, it can't be done. Say, hey, I've got this thing. How about I just, is it okay if I get it done in the morning or the next day or I've got this thing, but if I have, you know, if it's that critical, I can work later tonight or whatever it is. It's essentially saying, instead of just saying no, it's giving them another option. And just instead of just saying, no, we can't do it, saying, can we do it this way? Is there another way we can do it? The constraints that you've put on this thing, you, the customer, you know, whoever's requesting it, the constraints you've made are not feasible for us for these reasons. So how do we make it work? What can we do to make it work anyways, you know, without us, you know, with the reality of it, sort of setting these reality limits of, well, there's certain things we can and can't do, but those should not stop us from getting that request fulfilled. We need to work with our customer, collaborate with the customer to get things done. Instead of falling back on agreements, contract negotiation, instead of falling back on those as an excuse to not get stuff done, let's work with them to figure out how to get it done. Work for a yes instead of digging in on a no. It's worth a thought. It's probably got a bigger application than software as well, but we want to explore that at this point. Challenge of the week. When was the last time you found yourself in a contract negotiation, essentially? When something was requested and you essentially had to fall back and say, we can't do that. How did you handle it? Was it, we can't do it? Or did you say, well, how can we make that work for you? The restrictions, the constraints are such that this is going to be very difficult, but let's see how we can make it happen anyways. If that's not the way you acted, then maybe give that a shot a couple of times and see how that works. See what kind of customer satisfaction comes out of those kinds of arrangements and approaches. That being said, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noir Podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoir.com. Just a step forward a day is still progress, so let's keep moving forward together. Hi, this is Rob from Building Better Developers, the Developer Noir Podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers, and we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you, so please leave a review on Amazon.