Allan Kelly
Transcript
As I was saying a little bit before, I have a presentation I've been doing for a few years called No Projects, which I know some of you in this room have seen. And I talk about why the project model as a management tool is ill-suited to the 21st century digital software development arena. Especially when we think agile.
One of the valid criticisms of that presentation is that while I tell you what's wrong with no projects, that project, that presentation alone doesn't actually tell you much about what to do instead. I think For me, part of the answer is just stop using the word project.
This presentation kind of continues on from that no project. So if you've seen no projects, this should build on it. If you've not, this should stand alone. Perhaps you'll want to go and look up no projects. It's online a few places after this.
Part of the reason the project model is not a good fit is because what are the project success criteria?
On schedule, on budget, on time, or features, no value. We're not actually incorporating value and thinking about delivering business benefit to our customers, our users. So let's talk about value, or to put it another way, how much, when? Because that's the question we get asked, isn't it? How much, when?
How many of you have been asked this question? How many of you have had to debate this question with people?
Is this project right for Agile or is Waterfall better here? And you just know the person asking that question is a dyed-in-the-wool Waterfall person, isn't it? Or since we're at a lean Kanban conference, perhaps the question you have is, is this project right for Kanban? Or would Scrum be better here? Yeah, yeah, yeah. I have a very simple answer to both these questions. Who cares? Who cares what is right for this project? Because after all, we live in a post-truth world. What is right? Since when did we care about right when we're getting to the architecture and selecting Oracle as our database? The real question is, which will make more money? Which will deliver more business benefit value? And although I talk about money, I know when we say value, it's very easy to think about money. And, you know, money is the best feedback, isn't it? When you get money as feedback, you can do things with it. We're really talking about... business benefit something your business or your organization because you might be a not-for-profit you might be a government sector something like that your organization considers valuable business benefit shortened to the word value valuable and so which one which approach will give us more value more money and the answer is very simple agile and I don't really differentiate between lean I think lean and Kanban are all part of that big agile family I know some people like to differentiate them but I kind of see them as you know all parts of the same agile family and certainly when it comes to the waterfall question I think it is mathematically provable that agile will deliver more business benefit more money greater return on investment I can show you some slides on that another time but right now let's push on
We need to think about the value we're delivering rather than the cost. The project management model is very concerned about cost. How much will this cost? We need to get ourselves onto the value side of the equation. How much value, how much business benefit are we delivering to the organisation? If you are on the cost side, if you are arguing from a cost point of view, there is always somebody somewhere who will promise to do it. do it for less money than you will. Whether that person can deliver as they promise is an open question, but I guarantee you there is somebody somewhere who will say they can do it for less money. We have to get ourselves onto the value side of the equation and show that we are delivering more value to our businesses, to our organisations. Value delivered over cost to build, to paraphrase the Agile Manifesto. Or, as my good friend Warren says, price is what you pay, value is what you get. If you are constantly talking about how much is going to be spent, you're going to find yourself in a difficult position. Get onto the value side of the equation. So let's see how good you are. Let's say we've got two stories here.
with some value and some time to delivery.
Who would like to do story one first?
Any hands up for story one? Yeah, there's a few hands coming up there. You know, just four weeks, you know, you could quick turn and return on investment. Story two, a bit longer, more money. Anyone for story two?
Few more hands there yeah and yeah and you know scrum is quite clear do do the highest business value first so we should do two shouldn't we my friend chris matts likes to describe um software development as an information arrival process so let's give you some more information
Story one is for Halloween. Story two is for Christmas.
Who would like to do story one?
A couple of hands, yeah? And who's for story two?
You're thinking Halloween is being, Christmas is coming. It is November the 25th, isn't it?
Hmm. The purpose of this presentation, let's pretend it's September the 1st.
Who is for story one?
Oh, a few more hands. Story two? Yeah, okay. Let's do the analysis.
I call this a time value curve. Andy Carmichael, who's here somewhere, has been drawing some similar curves, and we're both drawing on the work of Don Reinston, who, I apologize, I'm not saying you're right, Don, I always stumble at that point. The idea of how much money, how much value you can deliver at different points in time.
This is our Santa app. If we deliver it on September the 1st, we're going to get just over a million dollars. Deliver it on the 15th of September, just over a million. Thereafter, you start losing some money. If you deliver it after the 27th of October, the return falls off quite rapidly. Deliver it January 5th. You know, there's only Russian kids then. You know, they're the only ones who want Christmas presents then.
So there you go.
There's six weeks of development. Let's just pretend we know all. It takes six weeks, okay? Let's not get into no estimates. See, a six-week line is there. If it's September the 1st and you begin developing today and it takes you the six weeks you think it will take, you cannot realise the $1,025,000 that this app promises to deliver. It's impossible because by the time you get to the delivery date, some of those sales will have gone.
Yeah? It's how long it takes. I just live every day. Think of this as going down to a supermarket, and when you pick up a packet of sausages or a packet of fish or something, you will likely find either a best before date or perhaps a use by date or perhaps both. This app is best delivered before the 27th of October. Delivering it on any date after that means it will not taste so good. Some of the taste, some of the value of this app has been lost if you deliver it later than there.
However, if you deliver this app after the 5th of January, no value, no taste. There is no point in delivering it there. That's the use by date. If you deliver it after that, you're going to get food poisoning. Okay?
Here's the Halloween app. Similar profile, but notice there's a very steep drop here. Once again, four weeks to develop. We can't realise the entire value that is being delivered. The four weeks to deliver, we're going to lose some of that value.
Those you use by date, those are best before date.
Now, what do you want to do?
There you go, that helps. I don't think it does, but if you want. Once again. Would you like to, let's go through the options here. Who would like to do the Halloween app and then the Santa app?
Two, three, four. Who would like to do the Santa app and then the Halloween app? One. Most of you can't decide, can you?
We could do Halloween and forget about Santa. By the time we've built Halloween, Santa, you know, we've lost a load of value on Santa. But we could do Santa and forget Halloween. Oh, there's a big show of hands.
There might be value in that. We can change the estimates.
I know we laugh. I also know I'm not alone in having heard that as a realistic suggestion. I'm sure some of you have. Do you think changing the estimates would help?
Not at all. Unless, of course, you're running one of those mythical scrum teams that believes in commitment. And when the estimates are reduced, that's not committed! Yeah, I don't believe in commitment.
Could change estimates. I think that's a popular technique with outsourcers. And the further away the outsourcer is, the more likely they are to do it because they won't get found out. We could do both and pray.
Anyone for that?
Okay, so there's a couple of product managers in the room.
This is the option of people who really don't like limiting work in progress. Couldn't we do them both in parallel?
Any other suggestions out there?
Anything I've missed?
What's that?
Forget everything. Yes, go and spend the money on something completely different. What's that?
What? Do none. Do none?
Yeah.
Reduce the requirements, reduce the scope. Yeah, yeah, yeah, that'd be the agile way of doing it. Our customer's a bit prickly. Go on, another.
Eastern, Easter app.
There's another suggestion which is usually called out at this point.
Particularly developers or developers'managers think it's a really clever option.
Two teams, do both. Splitting our resources, they'll both go more slowly. Some people at this point suggest we could reuse the app. Doesn't that sound like a good idea? Because Halloween and Christmas, they're kind of similar, aren't they? They're all about giving presents and things.
We also get to add more people. But how long does it take to hire somebody in Paris? Three months, four months, six? Four months. Yeah. If you weren't so picky about who you hired, there's loads of people you could just have. That guy pushing the streets.
So then we get this reuse question.
Reuse is proposed, but there's an old bunch of questions that have to go as reuse. Like, how much of these apps can be reused? How much can we really reuse here?
How much Halloween can be reused? How much can Santa take from Halloween? And that also raises the question of intellectual property. You know, there are plenty of consultancies in the world who make really good money for building a product for this company over here, and they give them all a source code, and then the same people go and build a very similar product over here for a different kind of company. You can't really take the code from Alstrom and give it to Siemens. They get upset.
We also get into the question of how much time does reuse add?
If you write something to be reusable, how much time does that add to your delivery? Anybody know? Anybody ever seen a study on this? It's actually a very difficult figure to come across. I usually cite Fred Brooks, which goes back to 1974. Fred Brooks says writing for reuse takes three times as long as writing for single use. Which means you have to be guaranteed that you're going to use that thing four times before you show a profit. A friend of mine, Kevin Henney, says he's seen a figure of 1.8 quoted, but he can't find a reference. That's a bit better. But an awful lot of code that's written for reuse never gets reused. You pay for the cost of reuse, whether that be 1.8 or 3, but you never get the reuse. And in the meantime, writing for reuse takes longer, so you're pushing that initial delivery date back.
So how much money do we lose? If we push the initial delivery date back for Santa, they get something that's reusable for Halloween or vice versa, how much do we lose because the first app is delivered later? as writing for single use, which means you have to be guaranteed you're going to use that thing four times before you show a profit. A friend of mine, Kevin Henney, says he's seen a figure of 1.8 quoted, but he can't find a reference. That's a bit better. But an awful lot of code that's written for reuse never gets reused. You pay for the cost of reuse, whether that be 1.8 or 3, but you never get the reuse. And in the meantime, writing for reuse takes longer, so you're pushing that initial delivery date back.
So how much money do we lose? If we push the initial delivery date back for Santa to get something reusable for Halloween or vice versa, how much do we lose because the first app is delivered late?
And how much do we get from delivering the other one early?
But most importantly, when you go for reusable code, you increase the risk to both. If you decide there's a component in here that can be used in both applications, and you set about building that component, both of those are dependent on that one thing. There's a high risk for both of them. If you want to reduce the risk, you separate them.
So I don't think reuse is a good way of going here. So we'll cross that option out. Let's look again at our model.
If we do Santa first,
We can make $1,025,000. We can't make the entire $1,050,000 because we cannot have it ready until the 13th of October. Therefore, we have to lose $35,000. Any business case which depends on it making exactly or more than $1,050,000 does not stand up. However, if we're busy building Santa, Halloween will make us zero dollars. Therefore, the total is... just over a million. However,
If you build Halloween first, you can't have it ready by 29th of September. Or you can't have it ready before the 29th of September. So you still lose $15,000, but you make $340,000.
And in the time remaining, you can deliver Santa. Now, Santa's not going to make you a million dollars. It's only going to make you $800,000 because you haven't got it in the market at the time you need it most. However, despite losing $225,000 less, you can still make more. If you do Santa, then Halloween, you make $1,140,000. If you do Santa, you make just 1,025,000. Yeah?
But you can only do this if you've got an idea of how much money you're going to make on different dates.
This is what Don calls opportunity cost to delay.
When, maybe it's just me, but I find when you introduce people to this idea, maybe because we're talking about cost, people... Very quick to cotton on to the extra costs you incur because you are delayed. So temporary staff while you fulfil a process manually or before you can hire, fire some people. Paying. for priority shipping, penalty fines, particularly to in a regulatory environment, the extra costs you'll incur because you were late. However, there's the value foregone, the money you could have made if you had that thing in the market sooner. So lost revenue opportunities, not being in the market, not being on sale at the key time in the Christmas market, the Halloween market, Easter market. Not being ready by a critical date. Not being in the market before your competitors. First mover advantage.
The value for gone, I think we can expect that to be far greater than the extra cost you incur. But we only know this if we know the profile of the value against time. How am I doing for time, by the way?
You know the old saying, time is money? Completely true. More time equals more costs. We all get that. But it's also true that more time means less revenue. More time building this thing means it's going to be in the market for less time. More time building this means our competitors can steal a lead on us. More time building this thing may mean we miss some crucial date.
Usually, there's exceptions, revenue is inversely proportional to the delivery time. Later delivery means less revenue.
I said, the man himself is sitting here. This is the original study.
I don't know.
Six months delay can be worth 33% of your total profits.
That's a lot of money. Six months. What was it? It took Apple 18 months to build the iPad.
There's a more detailed, thorough examination in Don's book there. Speak to the man yourself. What's this leading to is that we think of deadlines as fixed things and they're not.
Deadlines are analog. Deadlines are not binary. Deadlines are not all or nothing dates. Deadlines have different values or delivery dates, different dates have different values. So the deadline is analog. And I can prove this quite simply. We'll in a moment.
Have you ever faced this? Someone comes along, must have this, I need it yesterday.
If you're faced with such a person, the right answer is what?
What's the right answer? What's that?
You there?
That's very rude. No, facing this situation, we have the technology. Well, we do in England anyway. You all know this? Time machine, yeah. We just simply go back in time to a date where we can build it to be ready for the date. Yes, there you are. So, you do have time machines in France, don't you?
Somebody's nodding, somebody's shaking their head there. Think of this time value profile. What we're saying is that he needed it yesterday. All the value accrued yesterday. Today, there is no value. The value was yesterday. Without a time machine, you cannot go back and capture that value. So end the conversation. Duh.
The best before date was yesterday. The use by date is today and you don't have it. So, oh dear, I don't have a TARDIS, but maybe I can get something for you by tomorrow. Is that what you say? Is that what your developers come back and say? I will work all night. I'll slog my guts out. I will do the near impossible. That's what happens, isn't it? Yeah. And what does the other guy say?
Brilliant. I knew I could count on you.
But if all the value accrued yesterday and it's gone, faced with somebody saying, I need this by yesterday, it's not a very useful conversation because you cannot go back. The question needs to be, well, what can we do? So if the value accrued yesterday, it's gone, let's move forward, something else. If there's still value, it might be worth doing, but we need to understand what that value is.
So, I'm quite fast in this presentation. I don't know why I'm going so fast today.
Time is money, yes. I seem to be flying through.
A little bit soon is worth a lot more, is worth more than a lot later.
Even people like Apple know this. Do you remember the original iPhone?
Yeah, 2.5G. In a world that was becoming a 3G world, the original iPhone was a 2.5G phone with a battery life of what? A few hours. It didn't even have cut and paste. Yeah, even Apple who are held up as this great example of companies that only create perfect products They create products and they iterate they produce something now. They could have waited another year for the iPhone But they could have their cake and eat it by delivering something now Getting some revenue and getting all those people to upgrade in a year's time So the first lesson is a little bit of something now is worth more than a lot later I'm sure some of you have faced product managers, product owners, who want everything and they don't see any point in you delivering a little bit of it. And the usual agile answer is, if we deliver a little bit, you can get those feedback loops running and you can find out what your customers want. That's the usual. Agile answer, isn't it? But in truth, those people, those product owners, product managers, nine out of ten times, they are convinced they know what the customer wants, and they are convinced that they can give the customer what they want if you only give them all of it. So the usual answer about, you know, well, we can get feedback loops working, doesn't tend to carry a lot of weight with them. Perhaps talking money instead might.
Second lesson is, know the time value profile? What is the value of this thing if you delivered it tomorrow? What is the value of this thing if you delivered it next week, next month, in six months'time? If you know what the time value profile is, then you can engineer within that profile. Most of you, I'm assuming, are engineers. That's what engineers do. You are given a problem with some constraints and you craft a solution within those constraints. Given a constraint of one week, you will create a different solution than giving a constraint of one year. That's what engineering is. We get the constraints, we build within those constraints. And there's a trade-off. Different dates result in a product coming to market at different values. You may not capture all the value with your first release, but you'll get some of it.
The third. Third lesson, deadlines are elastic by value. Deadlines are not drop dead. Of course there's some drop dead ones, you know, where the value just disappears overnight. But on the whole, deadlines are elastic by value. You can have later deliveries, you can also have early deliveries. There's a novel idea for you.
One problem. How do you know the value of what you're building? Confronted by a product owner bearing user stories, how do you know the value of those stories?
Do anyone put value on your user stories?
Let's try a simpler question. Anybody put effort estimates on user stories?
There's two people being on, three, four, yeah? It's a very common practice to put effort estimates on user stories, isn't it? Yeah? How many people put value on user stories?
Somebody's shaking his hand. One person's got a hand. You really, yeah? You very rarely see any kind of requirements directly linked to the value. People may talk about, here's a project, here's our wonderful requirements here, and the total value of all of this is a large number over here. If we're working in a flow system with lots of little stories flowing through the system, if we expect developers to put effort estimates on the stories,
shouldn't we expect the business side, the product owners, to put some kind of value estimate on there?
It would be nice if we had the real number. But you know what? If you do the most detailed financial analysis, you get out your spreadsheets and you crunch all the numbers and you put some values on those stories, you can still face people saying, you know what? I don't think that number's right. Did you account for? Did you factor in the anticipated inflation rate? And even if you do the most detailed analysis, people can still come back to you and say, I'm not sure about your number here because... My answer, well, one answer is just to ask your stakeholders. Go around the people who want these things and say, how much is this worth? And if they can't put a number on it, get a statement. And another, as I said, do the analysis.
Or estimated. If estimation is good for developers and effort, why isn't estimation good for value? So I call it value poker, and you play it much the same as you've seen planning poker. This is a picture, I don't think you can see it too well there.
This is a picture of some user stories laid out at a law firm in London. We took a user story, somewhere over here actually, and we arbitrarily assigned it 10,000 business points. Sometimes I call them business points. Sometimes I call them French francs. Sometimes I call them American shillings. Sometimes I call them Paulist Gilder or, you know, whatever.
And then the product owner read out the user stories. The stakeholders, in this case an external client, asked some questions about the story, and they had their planning poker cards, and they played their planning poker cards. But instead of effort points or story points, those cards were denominated nominally in thousands of business points. So if they played a five card, it was 5,000 business points. If they played a 20 card, it was 20,000 business points. And just as we do, you do with planning poker and effort, we called out the numbers, we talked about them, we agreed, averaged usually, an answer. And we produced a list of stories with value on them. Nominal value it's good enough it's relative ranking what we want to know is what are the value of these things compared to each other that's the first step once you have value on these stories it becomes a lot easier to say here's a story which we have valued at 5,000 business points if we deliver it later does the value decline If we deliver it earlier, does the value increase? an effort we called out the numbers we talked about them we agreed averaged usually an answer and we produced a list of stories with value on them
nominal value it's good enough it's relative ranking what we want to know is what are the value of these things compared to each other that's the first step
Once you have value on these stories, it becomes a lot easier to say, here's a story which we have valued at 5,000 business points. If we deliver it later, does the value decline? If we deliver it earlier, does the value increase?
You may have, take that one, 4,000. There's one over here, 8,000. If those two things, if they're the same profile, they don't change their value at all, of course, do the 8,000 first. But you know what? That 4,000 one, Maybe we're less than the 8,000 one, but if that 4,000 is going to decline, go off, rot quickly, and the 8,000 is going to maintain its value, it makes more sense to do the 4,000 first and the 8,000 later. And some of you will spot we're getting perilously close to weighted first, job first, or something.
Yes, it fits in with all those. It's the same kind of idea. estimate, put a value on there, you can then discuss the value, you can rank them compared to each other, you can play with how does value change over time. I find without a value on these things, talking about value change over time is too abstract, people don't really grasp it. But once you've put a number, and it could almost be any number on a story, you can then talk about how it increases and how it decreases.
So you find out the value profile, you get some idea of value, you're setting out to obtain as much value as possible. And that may mean you do stories in an order which isn't dictated by their simple value, you do them in an order dictated by how they will mature, how fast they will go off.
The other thing to think about here is, and this goes back to what I said about the project model. Let's suppose you have two projects in front of you, project A and project B. And because we're doing the project model, we want to complete project A before we complete project B, right? So we go through project A and we rate it all by value. And we do the high value items and we're working down project A. There comes a point in project A where the items you are working on in project A have a lower value than the items in project B. You have a project that's going to come along when you finish this project and it has a collection of stories, a collection of use cases, a collection of whatevers. And if you have value on them, you will see that the project you are working on over here, you've got all the high value items, you're working on the low value ones. At which point you need to ask yourself, we are finishing off a project with low value. We're finishing off the low value items because we are chasing after schedule, features, etc. And there's another project waiting for us to do which would release more value. Is it right to finish off the first project when actually starting work on the second project would deliver a lot more value? Rather than doing the last five on that project, do the first five on the other project. At which point the whole project model starts to break down. You start to see projects as a collection of things to be built. They just have them in different buckets. And if you're working on a flow model, the work is flowing along. Why would you go to the bottom of that bucket when there's more value to be had from starting another bucket? The project model breaks down. We're starting to see this again and again. The language of projects usually isn't very helpful. It wraps us up in all sorts of constraints, whereas we should be thinking about flow.
Think about value as an input rather than an output.
I shouldn't tell you this.
I have an exercise I do sometimes with teams. And I divide the room in two. And we'll have some teams on the left here and some teams on the right here. And I put a user story up on screen that says, as a widget maker, I want an online store to sell my widgets directly to customers. Yeah?
And I give the teams on this side of the room a story that says, as a home-based artisan widget maker, I would like to sell my widgets directly to my customers. If I can make $100,000 a year, I can give up my day job. My accountant tells me a website usually costs around $5,000.
And the people on this side of the room, I give them a story that says, as a multinational widget maker, I want to cut out the middleman and sell my widgets directly to customers. I intend to make $10 million a year within the first three years. I budgeted $1.2 million to build this online shop. And I say to the teams, you're in competition. You're bidding for this work. And I give them some time and they write some user stories and I say, come back to me, estimate how much time and how much money do you want to undertake this work? Yeah?
And then I go to the teams, we finish, go to the teams on this side, and I say, how much? And they will say, oh, well, we were... think we need a million dollars and a year to build this and we'll continue next we need one and a half million dollars we need two years to build this and while the teams on this side are reading out their answers the teams on this I kid you not they are in hysterics they are laughing the guys on this side of the room can't work out why they are being laughed at
And then we turn to these people. And I think, how much? And they say, oh, well, we think we can do it in three weeks. We'll do it for $10,000. Yeah? And you get answers on this side of the room, which are an order of magnitude lower than on this side of the room. Because once the value, once the expected output is known, teams factor that into their planning. So the guys on this side of the room, they're going to take some fancy content management systems, some fancy e-commerce system, they're going to have a server farm, they're going to, yeah. The guys on this side of the room are saying, we're going to take WordPress, plug in Magento, and we'll just run with it. The engineering is different depending on the numbers. And you as engineers, faced with a story and being asked to put an effort on it, if you know it's worth a million dollars, you're going to consider it very differently from one that's worth 10,000. It also illustrates the idea of anchoring. You know when you hear a number and you update your internal thinking? It's shocking. You're engineers. You engineer within constraints. If you know something is only going to deliver, $10,000, $100,000. It's a very different engineering challenge from something that is intended to deliver millions.
So, know your time profile, know the profit you are targeting,
Work out how much you can spend to get that profit. Work backwards. You know the date you're aiming for. You know how much money you've got to play with. What can you build in that time? Engineer. Engineer. That's what engineers do.
Got a few minutes for questions.
Stunned silence.
I have a question.
Yes.
For Jim Benson.
Oh, for Jim.
He has a book titled, We Are Not Engineers.
Oh.
Are we not, Jim?
We aspire to be engineers. I think we aspire to be engineers. I say that, I consider myself a third generation engineer. At the age of eight, I was going down engine rooms and I was watching ships being overhauled at sea.
I believe a lot of my software development, software development engineers informed by engineering, but I believe we still have a long way to go. But you know, most engineers don't do what software people think they do. We talk about engineers and we rapidly start talking about bridge building. Most engineers don't build new bridges, don't build new machines, they keep the existing ones running. And you keep them running within constraints.
Clark?
Any thoughts on value for non-profits?
Value for non-profits.
Maybe with a not here, we can say hospitals with no reason for existence.
So, what is valuable to a hospital? It's not money, it's... Is it patients alive? Is it patients who've improved their conditions?
I once had some people from the Department for International Development in London and Waller Courses, and for them,
business benefit, value, could be people drinking clean water, water wells in sub-Saharan Africa, something like that. In a commercial organisation, it's pretty easy, it's probably money. If you're not in a commercial organisation, then I think one of the things to do is to ask yourself, what is it that this organisation values? Which probably takes you to question what are the organisation's values.
In a second language, some of you might be struggling with that as a first language speaker, it's difficult anyway. What is it the organisation wants as an outcome? What will benefit the organisation? So as a wider question, what is beneficial? What is the business benefit? Whatever your business, whatever your organisation. So you need to define that. And if you're lucky, you can put a number. On it.
Although, of course, we always have to be careful with numbers. People here in Paris know Goodhart's Law. Goodhart's Law, coined by a former economist at London School of Economics and Bank of England, a statistical measure which becomes a target will lose its information value and change its behaviour. If you have something, story points is a classic one. If you say to a team, well then team, it's a great deal getting 20 story points a week done, but do you think we could do 25? Should we go for 25 this week? The team will find a way of meeting that target. In the process, the behaviour will change and the information content of that measurement will change.
So ask what is, go back to Clark's question, what is valuable to the organisation? What does the organisation want? Which might be an interesting conversation in its own right.
Mike.
I've done some work with non-profits. Yeah. Jim has as well, I think. They care very much about sustainability and they care very much about keeping a connection with supporters and sponsors, which is no different really to any business.
Yeah. I suppose it depends which bit of the business you're in. Which bit of the business you're in, whether you're in the fundraising or the delivery. But, yeah, Jim?
You mentioned how when you gave the left side of the room a certain command and the right side, that that framed their conversation. You asking also framed that conversation. So I've gotten in trouble. We're doing the opposite, where people come and say, we would like to give you a million dollars to do this, and I say, I can do that for $250,000, and then they get pissed off and they go find someone to do it for a million dollars. Because they feel like I'm undermining the awesomeness of their problem by coming up with a less expensive solution.
Yeah.
That's an interesting point and maybe a story to leave you on. A few years ago I did some work with an insurance company in the UK. It isn't a happy story. And there was this group in there and they had a load of Agile consultants and coaches in. And it was a small group and they bought into this idea that we could introduce Agile in a kind of a guerrilla fashion. A bit of training over here, a bit of coaching. We could get all these little teams to do a little bit of Agile, a little bit of Agile. And I said, it wasn't going particularly well. And then I discovered in this organization there was a software process group. And the software process group were tasked with maintaining the organization's CMMI level rating. For those of you who don't know, it's a way out of the car. and E.G. Mellon University of measuring how mature your development process is. And found out this organization had a few years before been warned by the financial regulator they were going to be shut down because their IT was so bad.
And they had gone out and they had hired IBM to fix them. And IBM had come in and IBM had given them a beautiful waterfall process. And IBM had flooded them with consultants. And IBM had fixed their problem. And the regulator was happy. Roll forward a few years and the organization was now trying to retool that process because it was hideously inefficient to work in an agile fashion. But you kept reaching a point where people wouldn't make decisions or people didn't seem to want to take the medicine. It was a bit difficult to take. And what I realized was that when they had IBM in there, IBM's bill was very big. And I guarantee you, IBM's bill for the month was on the agenda of every board meeting. And they really felt they had to take IBM's medicine because the regulator was telling them and they were spending a lot of money on it. The people at the top were spending millions.
Five, six years later, when the agile folks turn up and say, oh, we can do this on the cheap, a little bit here, a little bit there, they didn't have to take it seriously because the bill was much smaller.
You know, I think, again, sometimes the amount of money is information, and actually charging a larger amount of it A large amount, as Jim says, shows you're serious about their problem. But also, he says, you know what? If you really want to change, you've really got to put some skin into the game. This isn't just something that can happen to your developers. All of you need to put your money, literally, where your mouth is.
Thank you very much. I'll let the next speaker say something.