By Rebecca Jones
In Episode 32 of The Board, we talk about:
Full Transcript
Gavin Coughlan: Hello and welcome to episode 32 of The Board.
I’m Gavin Coughlan, Agile coach here at Boost Agile, and today, we are going to be talking about one of the most misunderstood, possibly, of the four Agile values, which is customer collaboration over contract negotiation. I’m joined by…
Paul Flewelling: Hi there. My name is Paul Flewelling. I’m also an Agile coach here at Boost. As you can see, it’s just the two of us on the couches today.
Kristin is actually overseas on holiday. She’s in London and Paris. Hopefully, she is having good times.
Gavin: I imagine she is.
Paul: Gavin and I decided to talk about the Agile value customer collaboration of a contract negotiation.
Because often, when we are working with teams, we will remind them of the values and how what they are saying kind of holds with the values in terms of how it compares back to…or, if they are stuck on something in particular, then, think about the Agile values and how they might apply in this situation.
Gavin: Yeah, and I think it’s…I’ve been having a lot of conversations recently with people about doing Scrum and a lot of companies want to do Scrum.
They just learned how to do that. They learned all the right artifacts and the right meanings to do, but don’t necessarily concentrate on the Agile values. That’s missing the point entirely, because then, you’re doing agile rather than being Agile.
Paul: That’s right. I know that…for example, the guys from ICAgile, Ahmed Sidki or Sidky.
Sorry I mispronounced his name. They talked about this agile mindset quiet a lot. I think really to go from doing agile to being agile, you really have to think about the underlying principles, i.e. the Agile Manifesto and how that works in your situation.
Gavin: Yeah, absolutely. If we ever have issues with our Scrum projects, if there’s ever a thing going around, we tend to look back on the four Agile values.
They help us find sort of the root cause of what’s going on. That Agile mindset is the hardest thing to be in and to become. It’s really, really easy just to do Scrum or to do Kanban, and ignore all that. It’ll probably help, because you’ll be visualizing your work and breaking things down to iterations. It’ll probably give you some benefits. But certainly, it won’t give you all the benefits and the true benefits of being Agile.
Paul: To me, I’ve said many times before probably on this show, Scrum is a set of training wheels, unless you understand the principles underneath Scrum that are holding it up, you can’t take those training wheels off.
Gavin: Yeah, that’s right.
Paul: And so, the team will often come to us and say, “You know, we want to do… the most common thing is we want to stop retrospectives, and then, we really have to ask them how that compares back to the Agile values and what they…and the Agile principles and understand the teams.”
We do get the greatest benefit if we’re analyzing what we’re doing and having some empirical nature to our motivation, because otherwise, we can’t improve. We’ll just be doing the same things over and over again. As Einstein said, “That is the definition of madness”.
Gavin: Was it Einstein that said that? It was, wasn’t it?
Paul: I think so, yeah, doing the same things over and over again expecting different results.
Gavin: And you know when we do Scrum workshops for people, we always go through the values, first of all, and then, we take them through.
Usually, the Scrum process and we say this is a framework, which helps support these Agile values and its…because it’s hard to look at the Agile values and put a framework in yourself that’s going to help support that, Scrum is a great way of doing that.
That brings us back to customer collaboration over contract negotiation. That’s one that people find hard to understand, sometimes.
Paul: It comes up so many times for us, especially, because we’re a vendor, as well as a consultancy.
We often…we’re negotiating contracts, often, in terms of the number of contracts we do, but also, those contracts I was thinking the other day, because I see little mini contracts popping up in each, in every aspect of the agile approach.
People trying to hold the team to, “You said you would do this and it would include this, and so on.”
Or, they’re trying to set that contract up ahead of time and not realizing that they’re, actually… by creating that contract they’re actually going to minimize the value that’s delivered. And so, we’ll often…it is customer collaboration over contract negotiation. It’s not saying contracts aren’t important, it’s saying that you’re…we think you’ll get a better result the more you collaborate.
And so, going back to the beginning of the process, when we start a new project, for example, like one of the worst things we can hear, from one of our customers is that, “You’re the experts, you build up.” Because we don’t know what they want to build, we don’t understand what they’re vision is. We can build software, we build a lot of software. We are the experts in building software, but we don’t know what they want at the end of the day.
Gavin: That’s right. Because somebody can give you a very thorough list of requirements, but any individual or any group that goes through those requirements can read them in different ways, and have different ideas about what that means.
If you don’t have that collaboration all the way through a project, you’re just going to build something that you think the customer needs rather than what the customer actually needs. I think contracts, a lot of the time, people spend a lot of time locking everything they possibly can in place, before they get it signed off and start, because there’s a lack of trust there. They want to cover themselves.
Paul: The other thing I noticed, as well, is when you’re saying these are the requirements. This is the scope of our work.
This is the contract, essentially, for what you’re going to deliver. Because people see it as the only opportunity they’ve got to get this work done, they just add and add to these requirements, stuff that they don’t really need, because it’s the last, the only opportunity we’ve got to do this.
Let’s add as much in there as we can, even if it’s of very low value, and actually, going to cost much more money to develop. They’ll present me with this huge set of requirements. [inaudible 0:06:42] half of them aren’t necessary.
Gavin: Exactly. In terms of the trust that people feel contracts help put in place, the customer collaboration is something that fosters absolute trust with people because you’re there throughout the day.
It’s complete transparency. Nothing can be hidden or pushed under the carpet. One thing I read today, was a…
I can’t remember who said it, but they were doing a training course for people in Agile, and they’re talking about this very value. They asked the whole group, “Can you put your hands up if you foster a close collaboration with your customer?” Everybody’s hands went up, and they’re all very proud of themselves.
And they said, “OK, keep your hands up if you have talked to the customer within the last five days.” Most of the hands went down. That’s obviously not customer collaboration, because a week is a long time to go without talking.
Paul: That’s not close customer collaboration. That’s for sure.
Gavin: No, it’s not. Obviously collaboration means communication. That’s the most important part of that collaboration.
Paul: Yeah. I think my big focus is on what I’ve witnessed recently, is this. What happens when contracts fail is litigation, essentially.
The us-and-them thing starts popping up. You get the blame game. You said this, you wanted this, you said in requirement four point three point ten point one, or whatever, blah blah blah. And we’ve delivered blah blah blah.
Then, the customer comes back and says, “Well, it’s not what we wanted.” It’s just litigation, people arguing about the failed contract. Most of your time gets spent litigating and very little time gets spent resolving the problem.
Gavin: That’s right.
Paul: And then, what the ideal outcome is. “Oh, that’s not what you wanted. OK, let’s do the work until we get what it is you need.” It’s the ideal response.
Gavin: Exactly. I recently was involved in a project that wasn’t being run in an Agile way. There was a large, large contract with a list of requirements.
It was, I think, 250 must-have priority requirements. But I was actually working in an Agile space, I was bringing a lot of that too to the project, and just discussing with people that this was unnecessary. Completing the list, I got a little bit nuts, as well.
It was very difficult, because the negotiations went on for a long time, going over each of the requirements and saying nothing’s going to meet all 250 requirements. That just got really tense and really put everybody in a bad place. Everybody was butting heads about this contract, and nothing had even started being built, yet.
Paul: Yeah. Huge impediment to even just starting the work.
Gavin: Yeah, absolutely.
Paul: How are they going to get anything built in that scenario? Everybody’s going to be too busy covering their backsides. [laughs]
Gavin: Exactly. It was all about that contract. That’s all it was. That huge document. I was [inaudible 0:09:54] to see that much time being wasted on that and no actual progress being made.
Paul: That’s why we work so hard with our teams is to create this environment of trust, because trust is fast. Trust is incredibly fast.
If you can do things and know that you’re going to get into trouble, just because you’ve done your job, then you get things achieved much quicker.
Gavin: That’s right.
Paul: There’s a great book, which is on my reading list at the moment. I’ve only read excerpts from it, which is called The Speed of Trust, I think.
It talks about how valuable trust is, especially, to a team of developers, software developers, where they’re building something that’s complex, technologically it’s going to be complex or new. They’re normally solving complex problems.
They’re not going to get it right first time. In that environment, we talk about failing fast so that you can get that information serviced out as quickly as possible, be completely transparent. You can’t be transparent unless you’ve got trust.
If every time you come back to the product owner and say, “This is really hard. This is going to cost you much more than we thought it was going to cost.” The product owner starts freaking out, because they’re not going to get what they want.
We’re not going to get anywhere in that project. We’re not going to move forward. We have to sit down as a team and work out what’s possible and work as a team to get over those humps together.
Gavin: There’s different ways to get that sort of customer collaboration. It all came out from, I suppose the foundation of this value sort of came from extreme programming, in a way.
Because they demanded the customer be in the office or wherever you’re working with the team, working side-by-side with them, which is fantastic, but obviously, not possible in a lot of real-world situations.
We try to make that happen at Boots when we can, and it’s brilliant when it does happen. We have a product owner in the office, for the last two weeks, at the start of a project, and it’s worked incredibly well. But if that’s not possible which it usually isn’t, you just have to find other ways to allow that communication to always happen. It’s great if people can make it to the stand-up and be available for any catch-ups after the stand-up.
If you can have people available through Skype throughout the day, it’s fantastic. If not, at least, available by phone or instant message. Just make sure that they’re always there so if the team has a question or is about to make a decision about a direction they’re going to go in, they can get in touch with the project owner and make sure they don’t go off track.
Paul: That’s right.
Gavin: We still have contracts at Boost for our agile projects, obviously. As everybody will know it’s not that you will ignore contract negotiation. It’s still there. It’s just that collaboration is more important.
But we’ve changed our contracts. We started working in this way and rather than have fixed scope, fixed time frame, fixed budget, which used to mean we’re working nights and weekends, we have a capped time and materials.
Paul: That’s right. Capped time and materials. Just going back to what you were saying about fixed scope, fixed price, fixed budget.
No, sorry, fixed scope, fixed price, fixed schedule. Get those three right. The thing that suffers at the end of the day is not just us working weekends. It’s the quality of the overall product, the final delivery. You might get what you want on time and to budget, but it will not be of a high enough quality to take you forward.
Gavin: It’s usually not on budget for somebody. It might be on budget for the client, but not on budget for the vendor. Somebody’s going to lose out in that situation.
Paul: The capped time and materials, we realized that we needed to work on time and materials if we were going to be successful as a company. But of course, that doesn’t really work well for the client, because it’s…
Gavin: A lot of risk for them.
Paul: A lot of risk, exactly. In the capped approach, you’re saying, “Well, we will deliver something, something of value for you, within this time frame for this budget.”
Gavin: And work with them to make sure that the important stuff is being worked on and that we’ve prioritized stories in that way.
Paul: And continually work with them on re-prioritizing those stories, at the end of the project, they absolutely get the highest value they’re offered for that budget. That’s been really successful, hasn’t it?
Gavin: Yeah, it’s worked really well. It doesn’t work for every client. It does involve still a bit of a trust, because a lot of people are so used to working that way where they give you the list of requirements, and they give you the budget and they just want that done. No matter what, they want all that stuff done.
I suppose you can’t work in a truly Agile way if you don’t get that trust from both those parties, from the outset anyway. Because they have to understand that things are going to change. As soon as you start working on something, things are going to change and ideas are going to emerge and what you thought at the start is going to be very different than how you think about the project at the end of it.
Paul: What’s interesting, this is an idea taken from Toyota. I was reading about the way that Toyota approached.
They have maintained long-term relationship with their suppliers. The way they do that is a kind of bonus or fine system. If the supplier comes in ahead of time or under budget, then, they both share the benefits of that. They’ve worked out a deal where they split the reward. The client, if they come in under budget, Toyota will say, “OK, you’ve come in under budget. Let’s half the difference and you can have that.”
The supplier gets rewarded for coming in under budget. Vice versa if they go over time. Then, they half, or they have some arrangement, where the supplier gets fined. But they get fined equally, if you like. And they get rewarded equally. Working as a team.
Gavin: I read about that approach. I’ve never seen that happen in my experience. But I have read that Toyota go down that road and it sounds a pretty interesting idea.
Paul: It means that they’ve established a long-term relationship, high degree of trust with their suppliers.
I know Toyota have got some issues at the moment with the massive recall, and so on. But they are, if not the number one car manufacturer in the world, they are very high up. They’ve been using the lean approach to developing, building cars since the 1950s. They’ve been highly successful. I’d like to see it first-hand myself, but apparently, they have a very good culture there where they include their workers.
Gavin: It looks like we have a question here from Tony. With the capped time and materials model, what do you do if the customer decides really early that they have enough? How does this affect long-term planning for you guys?
That’s an interesting question. We have had situations like this. If the customer decides that they have enough, that’s fine. In our situation, we’ve dealt with that by…
In fact, we put that as a clause within our contracts that the caped time and materials gives a lot of freedom to the client, and if they do decide at some point that they have enough and that they want to stop development, they can actually do that.
Paul: Yeah. I think going back to what we were saying, I think having some clause in our contract, because of course, it’s in the client’s interest for us to get the work done sooner or under budget.
I think we should talk maybe as a team about introducing some incentives for us to deliver what the client needs sooner under budget, and then, work out that reward system to, like I say, if we come in under budget, we split the differences and we still get rewarded for a very successful project
Gavin: What I found in our situation quite a lot, because we are working with these caps time material contracts.
That if the client decides they have enough functionality in place, they quite often say, “Well, we have enough functionality and we still have budget, so we want to put that budget into user testing and enhancing.”
The functionality that we already have in place, and that’s the way it’s always worked for us so far, and who’s to say down the road it might be a little bit different. But so far, it’s working out for us, it’s pretty good, because the client has that freedom, there’s quite a bit of trust, and it also affects long term planning for us. At the moment, so far, it hasn’t been an issue, because…
Paul: We really have something waiting, in the wings, and we can bring that on faster.
Gavin: Exactly, and the clients have chosen to use their remaining budget for enhancements and stuff like that.
Paul: It is quite an issue if we go over, time of course, and we do have to reschedule just like any team would.
Gavin: That’s the thing. If you are coming to the end of the budget lower, even if you are not where you thought you’ll be halfway through the project. That’s what this collaboration, when this collaboration comes into play, as well.
We actually talked to the client about what’s the situation, because everything is absolutely transparent, and they are with you on this journey, it shouldn’t be a surprise for them either.
Go negotiate at that point, what can we do? What isn’t as important as we thought it would be? What can we push down? And that’s where the prioritizing of work really comes into it. We haven’t been burnt by these contracts ourselves, and nobody has left, say three quarters of the way through a project, and taken the budget with them. We’ve been quite fortunate in that regards.
Paul: It’s interesting, on Monday, we’ve got some guys within some workforce, who are just exploring the possibilities of this way of working, and so, we are just doing one sprint with them. Obviously, I don’t want to jinx this, but we do this quite a bit with people, and they often they just want to see how this way works, and see what is possible.
A lot of the time we get a good result, and the programmer or the company will want to continue working with us, that causes a whole different set of problems, because obviously, we need to then redo our schedules or work out what is on the horizon, that they can get that work schedule.
Gavin: Exactly, and I mean, that’s part of the benefit of being a small company, as well, because our planning is quite flexible.
That’s a bit of luxury that being a small company…it’s part of one of the benefits of being a small company, as that you can be flexible on that way and we don’t do a very long term planning. We do some sort of vague planning, but that’s constantly changing really.
Paul: That’s the answer, as well, you don’t really, you have a good idea of what you are going to do in the next three months, and then each subsequent three months at, you have a less of an idea. That’s good planning in general, and most good project managers would adopt, they’ll further out be looking, the more volatility there is in. That’s just accepted.
Gavin: Keeps you on your toes.
Paul: Exactly. Just before we stop talking, for us to say, I just want to bring out the fact that Nathan often talks about factors in our job, there’s a pattern within a pattern, within a pattern, and so on.
But these contracts often…So we have the contract to the project level, but we also have the contracts that get formed between the product owner and the team as they start to build the project, or build the software, and they are usually around the user story.
What’s interesting, I’ve been working with a team at the moment, who have just converted to Agile-M. We are going through an Agile transformation with them. They’ve still got some requirement, if you like that, held over from the old way of doing things. I saw one today, it was a huge, detailed screenshot and requirements for this major report that they want generated out there, a visual report they want generated out of their system.
The problem we’ve got now is negotiating what’s of the highest value, because we have to break this for work down. They can’t deliver this entire thing in one go, they have to break it into stories and do it within sprints.
Now, we’ve got this whole problem of renegotiating that contract, because that contract was formed months ago, eight months ago. And now to get it built, they have to build the highest value first, and the product, not everything is of equal importance. There’s that saying, a story that we are talking about earlier where they had 300 stories and they are all of equal value and priority.
It’s just interesting to see how these customer collaboration and the contract negotiation, filter these damage, the smaller chunks of what you do within a project in itself, and it’s really good to remind the customer, and the team at that point, this is a collaboration the whole way through, and you want to avoid forming those contracts as much as possible, because contracts are turning to litigation when they file. And you spend more time litigating than you do actually solving the problem.
Gavin: It’s interesting as you can see that the, people do ask me quite a few times what problems you run into when you are running squirm project.
It can be a variety of things like what you just described, or a product owner who is not available or teams who work separately and blame each other for a situation.
But everything that the core of all those issues is almost always communication. If you have communication lines open all the time and people are actually using them, because there’s no point having somebody sitting beside if you are not talking to them. But as long as everybody is communicating, it really solves so many of these problems.
Paul: All I know is, having spent so many years in the industry, is time and time again, the customer often doesn’t know exactly what they want until they see it. anything in between that, requirements, documents, markups, they all have a place.
Keep the collaboration heavy, keep the focus on collaboration, stop trying to form contracts, deliver something that this customer can see as soon as possible, and accept that that isn’t necessarily going to be right the first time, and it’s going to be revised or reworked, or enhanced, or elaborated, and accept that. Software isn’t tangible until it’s almost green.
Gavin: That’s right that stuff, you are right. And the most difficult situation that I’ve seen to concur in Agile projects, is when people are working in different times, because that communication, there’s nothing you can do, you can’t bend time.
That’s the most difficult one to solve. People have asked me to help them with their problem, because they’ve got some new work in it. At times, I’m 12 hours behind them. There’s no easy answer there, because it’s really tricky. We have another question from Tony. Just found this in the week, great for helping that, everything is of equal value discussion.
Paul: Great. Has he included the link?
Gavin: I don’t see a link in there, but I’ll follow up on that Tony.
Paul: If you can post a link Tony, if you’ve got something, that would be great.
Gavin: I do, like, because we often need help with our everything is of equal value discussion. That’s something that pops up huge amounts, we are beginning to see that. I think just about that for this week.
Paul: Thanks, I’ve enjoyed today’s discussion.
Gavin: It was good. In the future, we are going to try and concentrate just on one topic per episode of the board.
Again, if anybody is watching, whether you are watching on YouTube or live stream, and you have a topic you’d like to see us discuss, please leave it on the comments and we’ll try and address that in future episodes.
Thank you, and see you next time.
Paul: See you.
