3. Can you just tell us a little bit about yourself?
I have been working in software for a long time and in the Agile space for over 15 years now. So during that time I have seen a lot of things get better and then a lot of things still not get solved and if you do not like the conversation, change the conversion. One of the things I found really difficult across the board is dealing with legal contracts and not just legal contracts, but contracts that are implied. So every time you enter into some sort of project, you do some sort of statement of work. You are kind of bound by the requirements in this contract form so I think that is something that I have been really wanting to change and that is why I have been working on this flexible contract model.
4. What is special about this flexible contract model? What is different?
Well, I think as the name suggests, contracts are such a dry topic, right? You immediately think of contracts and you think inflexible, barriers to getting anything done. One of the arch-nemesis.
Shane: And lawyers making money.
Yes, and lawyers are making money, which is kind of funny when you think of lawyers. They always bill time-and-materials, don’t they? But many of the contracts that we work on, the traditional contract models, they have terrible set up. They are meant to reduce risk. You think of the way lawyers think about contracts. They think: “OK. It is like a goods and service bill. You write down all the things you want, you give it to a supplier, they give it back to you, we get to tick it off going – yes, they have made the date and off you go. You get paid.” And of course, in today’s dynamic business world, the way we build things and think about things works anything but in a fixed form. The idea that we could possibly understand all the requirements out front by both parties, get them perfectly right and execute is an impossible dream and the sooner we realize that, the more that we can then look at changing these models.
What do you need to do? Well, I think we need to first recognize that contracts themselves are a problem. We have gone off the process so many in the Agile community say: “It’s this waterfall model, it is flawed, it has got solid requirements up front. What are going to now iterate” and all of these things are fantastic, but of course, you then get into a contract which pushes you back to a waterfall way of thinking. Immediately you have got to set your requirements up front. So, of course, the obvious work around has being people saying “Let us do a time-and-materials.” You are taking it to a chaotic other side where you do not have a direction, you are just going to keep building things in the hope that eventually you can find the right path and I think both of those areas have many risks built in.
What you want to find is a flexible middle ground. Instead of using the common metrics in contracts, one of which is output based, so we are going to measure you by the amount of features you deliver. Or time-based through-put; it doesn’t matter if you are measuring points, function points, time, any of these things have nothing to do with value. So instead I really think we should be creating an outcome based contract. Outcomes? Think of it as you desired business results, where you want to end up. There are many customers who give us what they want, which is very different from what they need. Now, when they come to us, customers do not know what they need, right? Something that - I was once horrified by a conversation: I was there and there was an Agile contractor supplier and someone from one of the big consulting firms, traditional ones, they have been competing on the same bid. The traditional firm had won it and the Agile people said “There is no way you can get it done for that much money and that much time” And the guy laughed and said “Yes, of course. It is going to take twice as long, and cost twice as much. Did you see the customer did not know anything, they were completely clueless which means that everything they are going to tell us they need isn’t right and they are going to do have to now make change requests.” And he said “Change requests are a license to print money. So we are going to make up our ridiculously low quote by then making more and more features and it is going to take twice as long”.
So, of course, that is incredibly risky. It is just this awful model that we have ended up with.
The flexible contract is all about set outcomes. Think of those like you “commander’s intent”. A lot of us have been reading about this military strategy: instead of setting down exactly how you are going to fight the block battle, the commander will say: “This is the intent. These are the desired results that we will actually win this battle”, but not how. “You on the field, you need to decide how you are going to action that”. So, the outcomes are the commander’s intent. This is where we need to end up. Now, you, suppliers, figure out the most expedient way to get there. So, what that means is that the contract model itself we set – you can either draw it as the master services agreement or as terms and conditions, if you want a very light-weight contract form. Within that we put very, very little. What you don’t want to do is have to go back to the contract, spend lots of money and lots of time, go through change control mechanisms to make amendments at that level. It is very expensive and slow.
Instead, what we do is we constrain it. We say: “This is the total amount of money we are willing to spend.” There could be dates we need to hit and there could be regulatory things we need to be aware of. Underneath it, we create SOTOs. A SOTO is a Statement of Target Outcome. Like a statement of work, it could be bound by either time or money. So, you set it for small amount, might be, say, two months long. Within that, we will set a target that we want to achieve, we are going to measure that progressively and the supplier does everything in their power to hit that as quickly as possible. Where the charging comes in, the fee structure, you can have a pure value–based fee. What that means is that if you achieve that target outcome, you will get paid, which means we could set that if you want to do it within three months, if you did it three days in, you, the supplier – Bingo! You get to cash out, right? Which is brilliant. The customer gets value quicker, the supplier gets paid quicker. That is one of the most pure models. Many people would not be comfortable with that, we recognize that. So what they would often do is to set a day rate or a discounted day rate and think of the outcome as a bonus. But again, what we want to have is a very clear, very measurable goal in the form of a target outcome so that both parties know what success looks like. Then they do the least amount of work to hit that.
6. Defining those goals, those target outcomes - that becomes the key to it. Am I correct?
It does. And you are going to hit on the thing which is probably the greatest challenge we found: getting people to move from metrics like features which are very easy – that is why we do it, right? Just because it is easy does not mean it is right – and moving people to an outcome based model. So why we have been working on this – when I say “we”, Susan Atkinson is the IT lawyer who I have been working on this with over the last three years. That is a long time. At one point, I think, we created the biggest wonderful book on contracting ever. Then we realized it was all completely wrong because we have been trying to create a contract for Agile, instead we created a contract for complex work. As soon as we made that distinction we removed all the process pieces from it, so we created a much lighter weight-contract. So, while I was working on that I have also been working with someone called Ryan Schreiber on something called the “O model”. This is an outcomes options model. What we realized is that people need a simple way of being able to create these measurable goals. Tom Gilb is the guru in this land of measurement. He has been doing this since the 60’s but it is really complicated, so I found people who have had a really hard time getting started. The outcome of O model which works it is actually the foundation for the contract, as well. That is open source so you can get that online, at omodel.com. Within that we show you how to go in and explore. What you want to do is figure out what are the problems or opportunities. Let us take a real example. Do you want to walk through one?
An example would be: let’s say you are an online retailer. Maybe you sell books and you come to me and say: “Hey, we have got a problem. We are noticing there is lots of competition in the market. More people are stealing our customers. We are getting lots of customer complaints about our service and we measure that when someone enters the purchase flow to buy a book, only 26% of them complete it. We don’t know why everyone else doesn’t complete it. Can you help us?” And we say to them: “Sure, let’s set an outcome. What do you think the target should be?” “Well, we believe that compared to other retailers we should be up at, say, 40%” “OK. And how much is every percent worth to you?” I don’t know, let’s make up a number – let’s say it’s 100.000 a year. “OK. Great. Why don’t we, as a supplier, we can take 10% of that.” “OK. That sounds good”. So we go in and we start studying what is going on. I go and look at the data. I can do click stream analysis to see where are people leaving. I notice on certain pages, things like payment pages, people are disappearing. I also notice that in your homeland, Shane, in Australia, a lot of people are disappearing far higher than anywhere else. So we come up with all these hypotheses. We are very scientific about it. We say: “Here is the problem. Now, let’s experiment and see if we can get that number up. People in Australia - why are they disappearing?” Well, weirdly enough our data center is in Luxemburg. It’s so far away, we think the speed is the real problem. So people come up with options. Option 1 is we set up a data center in Australia –that is going to be really expensive. That is a big, expensive option. One is we can check the latency of the network – maybe that is causing problems. And someone else says: “Hey, tomorrow I can cache some of the page elements, make them really fast to load.” So, we can experiment with all of those and as soon as we hit those magic numbers and see it going up, which we keep measuring, we now have the causative effect which can impact the business objectives. So the supplier is constantly experimenting, working on fixing it. And they might be able to do it in a simple way because the customer is going to say: “Well, I want to replace my whole purchase flow”. But actually, maybe we can do it in other ways, iteratively, get them value sooner. We might not have to replace the whole thing.
7. You have actually got examples of this contract or you have got a template of this contract?
We do. It was a funny moment where we created this template which was very light weight and I said to the lawyer – Susan – “Well, let’s open source it”. And she said: “No. Lawyers never open source contracts. That is their IP”. And I went “Yes, but we want to disrupt that model. We want to get it to as many people as possible” So, actually, we are happy to say it is on the Creative Commons License and that is going to be freely available at felxiblecontracts.com.
Shane: flexiblecontracts. com.
Yes.
Gabrielle, thank you so much for taking the time to talk to InfoQ today. This is a really interesting move in the Agile space and we look forward to seeing where it goes.
Thank you, Shane.