Selling Agile – Paul Klipp


All right, what I am going to talk about today
is selling Agile. Selling Agile inside an organization and to external clients. I’m
not going to waste any time talking about myself, my background and whatever; you can find me later if you are interested. But I do want to know a little about you so I can
tailor this presentation as necessary to your interests. So, first, how many people in this
room would describe themselves primarily as programmers? Okay. Testers? A handful of Testers.
Scrum Masters, wow a bunch of Scrum Masters, terrific. Project Managers? And how many of
you are in one way or another involved in sales? And a good number of sales people,
good, okay. So what I am going to talk about is how to
go about convincing people inside your organization, especially your Project Managers, to consider
adopting Agile practices. How to convince your sales teams that it’s easier to sell
an Agile process then alternatives and and finally how the sales team can go about communicating
the benefits of an Agile development process to your customers. Okay, so, first, Project Managers. You can’t
really begin to speak to a Project Manager about how their life might be different if
they had tried a different approach unless we get into the mind of a Project Manager
to understand what their world is like. Okay, that’s been around for a while but
I never get tired of it. Has anyone never seen that before? Good. I saw that for the
first time back in the days when I hadn’t discovered XP yet. And it spoke to me. So,
what is it like to be a Project Manager on waterfall style, traditional project. It’s
important to understand that no matter how enamoured you are with whatever Agile development
approach that people are sitting in the comfort zone which is called the comfort zone for
a reason. It is comfortable. Now I use to be a Project Manager on projects large and
small using standard, traditional waterfall practices and I’m going to tell you what
if feels like. When a project first comes to you it comes
in the form of a group of people or an individual who have some need and some vision and some
idea. And you become, for a little while their saviour. You’re the only person they are
talking to about this. And they talk to you a lot. So for a large project that might span
years, you’re going to be married to the person for three to six months and your job
is to write the “Doc”. And writing the document as much as people may dread the idea
of that big functional specification, writing the document is a very creative and absorbing
process. And so during that time the Project Manager
and client and other stakeholders who might be involved spend a lot of time sitting in
meetings and when they’re not in meeting they are working on documentation. And what
this feels like from a Project Manager’s standpoint is a very structured day in which they know
exactly what they are doing, exactly what’s expected of them and there are lots of donuts.
A lot more donuts in waterfall then in Agile. There’s lots of meetings. And the best part
about it is the Project Manager is really in control of the entire process. If you’re
talking about like a two year involved multimillion dollar project then the first three to six
months the Project Manager is king. He knows where he is supposed to be, he knows what
he’s supposed to be doing and he’s creating something of value and because the definition
of what a complete functional specification is, is so flexible it is something they have
a lot of control over. And so almost in every instance this phase of the project is done
on time, on budget and when it’s finished everyone celebrates that their one third of
the way through the project and they’re still on time and on budget cause they wrote
the book. And that’s when they being to lose control.
Talking to a Project Manager about less documentation and such is probably not the best approach.
But it’s when they begin to lose control which is when they’ve taken this documentation
to the technical teams and they get their first estimates and the technical teams sit
down and they break down all the functionality that’s in detail in the document and the
tasks and they estimate all of the tasks using whatever mechanism that they use and they
come back and they say that these are all of the tasks and these are the dependencies
and
these are the estimates and they all add up to X which will cost so much. Then the Project Manager has to take that
to the client and the negotiation begins. But even here it’s not that bad because
usually there is a discrepancy between what the client expected it to cost and what the
client expected it to take in terms of time and what the technical team has come back
well there still talking about something that’s really fuzzy, they’re talking about resources
as though they weren’t people with specific skills and abilities, they’re talking about
tasks as though they were real things rather than just an expectation and
so once you’ve got all this into your Gantt
chart you can still tweak a lot of things. You can toss some more resources on here and
take some resources on here and you can make this a little simpler and they estimated that
in ten hours but if we just take this thing out we can save the client five hours until
they get this thing looking like it’s supposed to. So they’re still somewhat in control. And then it’s when development begins that
it becomes very uncomfortable for a Project Manager. Because up until now they know exactly
what’s going on with the project. But from this point on they only have one tool for
finding out what’s going on with the project. Project Manager: Are you almost done?
Resource: No, not yet. Project Manager: How far along?
Resource: Twenty four hours. Project Manager: Like?
Resource: Like that much. Okay. And that is the essence of the reporting
they get for the next nine months. Everything is ninety percent done, almost done, finished
my part just waiting on Bob, what have you. And within a matter of days things start to
slip just a little bit. And
with any large project, if you’ve broken down your Gantt charts into small enough task
based components things are slipping within the first week or two. But you still have
a lot of things you can work with. You can still shuffle resources in the future. But
as the future becomes the present you get less and less flexibility. Luckily you’ve
built in a huge buffer at the end of this project. Anyone know what that buffer is called?
Testing. Testing is your buffer because come on the project has taken longer than you expected
which means the guys have been working harder than you expected so the code’s got to be
solid, they are not going to find anything in testing anyway. So you budgeted two months
for testing but two weeks will have to do. And then of course, when the testers get hold
of it and bugs start blossoming and blooming and you’ve got fifty bugs, a hundred, two
hundred, four hundred, six hundred. I’ve seen projects with development teams as small
as fifty people that were juggling two thousand plus bugs in the bug tracking system. Has anyone seen that? And then most of the time, according to the
Standish group study, most of the time it will go dramatically over and it then becomes
the Project Managers job to try to control and contain the problem as much as possible.
Like getting the damn thing shipped before the company goes out of business. So this is what it looks like to be a Project
Manager on a traditional project. What you should approach your Project Manager swift
is the idea of what it could like if it was different by tackling the specific issues
in which the Project Manager is uncomfortable because you cannot institute change in a person
or an organization without first creating or identifying the satisfaction. So these
are some of the things that an Agile process can give your Project Managers. More structure
throughout the process in terms of knowing exactly what they are supposed to be doing.
Faster and more accurate reporting rather than sticking their heads into a developers
cubicle and saying “still ninety percent, you’ve been ninety percent for two weeks
now.” You’ve got burned down charts, you’ve got definitions of done , you’ve got philosophy,
you’ve got much better tools for reporting on what’s really happening in the project
even in the very early days. The opportunity of spending their days doing
value adding activities. So the first chunk of the project feels value adding but the
creation of this big document doesn’t actually bring any value whatsoever to the stake holders
or the end users. But the idea as a Project Manager of spending your days of first creating
a document and then trying to cover your ass, instead being responsible for making sure
the process is going as smoothly as they can, making sure people are learning from your
experiences to make sure the best practices are being followed and removing impediments.
These things directly add value to the end user and that can be very satisfying throughout
the process. Shared responsibilities for success also means
shared responsibility for failure. It takes a lot of weight off a Project Managers shoulders
when they have a set directive team that’s taking responsibility when they are working
closely with a client and the client is sharing responsibility for helping to identify and
solve problems as the project progresses. They have a working relationship with clients
and co-workers. Instead of having a client who they are constantly making excuses to
or constantly answering very uncomfortable questions and having a bunch of co-workers
who they have to micromanager and put pressure on and motivate. Instead they are facilitating,
they’re solving the problems, they’re part of the solution, they’re part of the
team which makes for much better more comfortable working relationships and as I said less time
spent trying to cover their ass or their companies and instead working on solving problems rather
than finding blame. The high level view of what’s different
for a Project Manager in an Agile project the primary goal is facilitation. Right now
the primary goal is reporting. Facilitation is a much more comfortable and much more meaningful
role to have. Less upfront planning and more ongoing planning. So instead of spending three
months writing documentation and the rest of the time trying to keep it from completely
becoming a train wreck they’ll be constantly involved in working with ongoing planning
on an iteration by iteration base. Less reporting and a whole lot more talking. A big chunk
of the Project Managers job is writing weekly reports or monthly reports or sitting in monthly
update meetings and what have you and instead of creating all of these reporting documents
they will spend a lot more time talking to the team and a lot more time talking to the
clients in structured ways that keep everybody on the same page. Fewer long meetings and more short meetings.
So it’s not that they are being relieved of the responsibility for meetings and it’s
certainly not that “oh my goodness I am trading six meetings for six hundred meetings.”
Generally speaking, in my experience, total commitment is about the setting. Instead of
having those four hour, six hour and eight hour long meetings that go on for weeks at
the beginning of the project they have a fifteen minute meeting every single day plus a retrospective
and a spring planning meeting once every iteration. And like I said less time trying to avoid
blame and more time acting in a real problem solving capacity. If I go to fast feel free to stop me. So this first step is building the right team.
And this is a topic for a whole other reason. You can tell your Project Manager that if
they put together the right team for the project then the whole rest of the job becomes a whole
lot easier. Picking the right people with the right set of skills with the right personalities
to work together. And then the company to understand the problem that needs to be solved.
This is something I love about the software industry. My very first management experience
was working in prison and a couple of years my job was cooking food for a couple of hundred
inmates and my team was a bunch of rapists, murderers and drug dealers. And after that
then going to software where suddenly I’m surrounded by people who are more intelligent
than me, it’s terrific if you try and get the team on board with what it is that they’re
trying to solve, the problems that the customer’s trying to have. You harness all of
that brainpower and then them from code monkeys,
fulfilling tasks on
the Geth [ph] Chart into part of a creative solution to problems and then give them space,
time and the structure and sources they need to do their job and you get a motivated team
and you don’t have to have all-night pizza debugging sessions or threaten or control
or whatever in order to try to accomplish the client’s purposes and your purposes.
They’re motivated themselves because their emotionally connected in what you’re doing. There’s skill planning and — this part
of the presentation is tools in this that was covered really well in the keynote so
occasionally I’m going to skip forward because I don’t assume you want to hear the same
thing that you just heard a couple hours ago again. So the process of planning becomes,
as Penny [ph] described it it’s tied with the discreet planning. If you can plan the
overall high level plan but rather than writing up all that documentation, instead there’s
instructional user’s stories and roles communicating that they’re working with the team to get
their initial essence of backlog and the clients and prioritize and stuff. Interim documentation is lessening the huge
stockpiles of documents to manage and in-house reports to manage but there’s a lot more
conversations to manage. The big physical charts which allow everyone to see exactly
what’s going on in the project. In terms of daily tracking, they’ve got these stand-up
meeting, they’ve got the break down charts which gives them really active data that they
don’t have to go and bust out of the heads of the programmers. They get to actually see
features as they’re being finished and they get to see them with clients and get real
time feedback. And of course, they can also see the long term risks and look for potential
problems that might crop up. So once the project manager says that sounds
really good, that’s the kind of life I would like to be living with my family and in this
workplace with all of you, how do I do it? There’s a school of thought that will dramatically
disagree with my who says that the only way to introduce Agile processing is doing it
with an Agile coach who can make sure the team doesn’t make any common mistakes due
to bad experiences and scrapping the idea entirely and they have a point. I’m sure
that happens in some organizations. All of my experience leads me to believe that taking
your best shot at it, as long as you do it with an open mind, leads to enough improvement
to create a continuous cycle of improvement. So it will take longer without bringing in
an expert coach but I believe that the best way to start doing an Agile process is you
take project, you get a good small team — preferably something that’s internal, maybe something
that’s not being too highly scrutinized by the outside for your first few iterations
— but take the project and set a demo date. Tell the stakeholder, whoever it is, we will
show you working software on X day not too far in the future, two weeks, three weeks.
Sit with that person and the team and figure out what you can demo on that day, what they’d
feel comfortable demoing on that day. Then start doing stand up meetings — and the
scrum approach is a very good way to start. If you haven’t done it, the three scrum
questions and then it takes the rules and such. You can adapt these if something else
works better for your team. Then on that day, at that time do the demo that you promised
you would do, no excuses, whether it works or not. Sometimes the demo fails simply because
there was a bug that kept anything from working. That’s a valid learning experience the team
has a right to have no matter how uncomfortable it may be. Then sit together as a team, reflect
on what that felt like and try to identify areas for improvement. If you do that and you do it with an open
mind with a group of intelligent people that want to see it work, I believe you’ll see
dramatic improvements in your process. I first said ‘I think I agree that any team that’s
intelligent and open minded and does introspective will eventually come across the Agile process
whether they’ve been trained in it or not. There’s so much in it that’s just common
sense. Now, give me some water, selling Agile to
sales people. Sales in software is really, really difficult mostly because sales people
are not technical and what they’re selling needs to be a very technical thing, software.
And so not being able to clearly understand the technology they start selling software
but what they’re actually selling is a service. And how do you sell software? It’s kind
of like ‘it does this.’ You say okay and I need to do this too. And you say ‘sure,
our guys could do that.’ And I need to have it before Christmas. We’ll make it happen,
buddy.’ Without really necessarily understanding what goes into the promises they’re making,
you’ll end up with that Dilbert kind of scenario in which marketing makes the promises
and then maybe come in with the problem and then somehow or other either has to solve
the problem or again, as standard studies reveal, usually they fail. I think one of
the big areas in which projects collapse is because when the contract is signed most sales
people get that commission and then they’re done. Well again, think about what motivates sales
people. Mostly it’s that commission or a person involved in sales is also an owner
or senior intern in the company so their interest in the company is success. Nothing brings
higher commissions or more success than repeat business and good references and so creating
a great customer experience leads to repeat business or leads to customer recommendations
and referrals. It’s a great way to automate the sales process. If you do this well enough
long enough you can stop selling altogether, people will be pounding on your door to ask
you to build their software for them, which is essentially the situation that I find myself
in now. I do no marketing anymore. So with that generally view what we should
be telling the sales people is that the benefits of an Agile process are easy to understand
— and we go over that in the next segment — that happy clients bring repeat business,
that experienced buyers know the cost of poor quality because they’ve seen cost overruns,
they’ve seen budget overruns and they’ve seen the enormous maintenance costs that come
from overly complex project that are poorly architected and that have spent the last several
months of their life being cobbled by a bunch of unpaid interns because it was so far over
budget that nobody wanted to put a good team on it and they just had to get the darn thing
done. Then it cost a fortune to maintain so it’s eventually scrapped. If they’re experienced
they’ve seen this and they fear it and if they’re inexperienced they’ve heard the
stories and they fear it. So if you can sell quality, quality in process,
that addresses that fundamental fear most clients have and you can sell the experience
of being a purchaser of an Agile software service, the experience of being a product
owner as a key benefit, the key differentiating benefit, which is a rather easy sell and this
is how you do it. For clients, the main points you want to make to the clients — and I’ll
explain these in a bit more detail — is that a high quality process leads to lower
maintenance cost, to a lower full cost of ownership. The client remains in control of
the project. Clients are not used to having any measure of control at all once a software
project is initiated. That they have great career flexibility. Most clients have experienced
the dreaded change requests. How many of you are in companies where a client has to submit
a change request for evaluation? That’s a horrible experience for a client to have
a great idea and toss it into the bureaucracy of grumbling managers and programmers who
all say this is going to screw up everything. So the idea that they can get new ideas and
incorporate them into the process or if the competitor comes up with a great new feature
that they didn’t think of they can do that without going through that process. It’s
very compelling. That Agile processes produce lower cost software and I think that was well
illustrated in Bennett’s [ph] presentation. And that they have a lot of insight into the
process so they’re not going to be stressed about what’s going on. Let’s take a look at how your clients think
about software. How many of you have seen this video? What you’re about to witness
is a software overflow. Okay, I can go on and give a list of all the big catastrophic
software failures. Google the term ‘famous bombs’ and you come up with a list of all
the projects where software bugs killed people with radiation overexposing and things like
that. But even closer to home, just take a look at the software that your clients use
every day. I remember a time — and anyone my age or older will remember a time when
a perfectly good, fully functional word processor that did everything you needed with advanced
formatting and mail merge and everything fit onto a 360K floppy and now it takes a DVD
to hold all 4.7 gig of Microsoft Word and you still have to download patches every week.
Software in general is faulty, awkward, difficult to use, bloated, buggy and full of security
holes. This is the kind of software that’s written by some of the best minds who have
been working on it for years and it’s in widespread use worldwide. Just think how a
custom project would look compared to that with a fraction of the testing and a fraction
of the real world usage. Customers expect the software that you write
for them to suck even worse than the stuff they use every day and when somebody expects
software to suck the natural thing to do is to not pay any more for it than they have
to. So this is the problem that you’re running into. They expect to have a miserable experience
of throwing their ideas over a wall and then getting a bunch of excuses back and then finally
having to force the project out however it is that they can get it with no other tool
at their disposal than volume based motivation. If you can give a guidance use to dealing
with the software company in this way where there’s cost overruns and they’re not
satisfied in the way in which the product works, an alternative which is compelling,
a positive experience in which they are in control and get what they want, they will
choose it every time. Here’s where we’ll be able to skip a bunch
of stuff. Yeah, more code leaks, more bugs, the best way to produce errors is to — you’ve
seen this? Everybody using this stuff? This is an old study. This is from the 2000 study.
My goodness, we should all know this. By the way, side note, never ever trust the inclusions
of any study you haven’t read, really! The number of times that I’ve seen some study
quoted in the Press and I go and I read the study and the Press expressed the conclusions
that was not what the study was about at all. Go to the site and see the report. It takes
about a half an hour to read, it’s not a big read and very enlightening and the projects
they use in the study may have nothing whatsoever to do with the kind of work that you’re
doing. But in any case, obviously the best way to produce less buggy, less complex software
faster and cheaper is just to write less of it so we can skip that. I have always liked talking about the triple
constraints a little bit differently than everybody else does because I’ve seen what
happens when a company starts losing money every day because the project is over budget,
it’s fixed price and what-have-you and they start taking their best people off because
it’s too expensive and they start working long hours with people who do their best work
and such. So these are the constraints: the amount of time it takes to do it, what gets
done and how high quality it is, because it’s quality that suffers when you start trying
to double a project that’s so over budget. This is the kind of thing that a client can
understand. You can tell this to a customer and they get it, which is that if you want
to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality
and you always pay for quality in the end, you always do. Havi [ph] used to say something about used
cars, and this is a bit dated but he used to say a used car costs you $1000. You can
either buy one for $100 and it’s going to cost you $900 to get it running smoothly or
you can buy it for $1000. Same thing with software except I think even more exaggerated,
its poor quality costs more later on than building with quality would cost. So you sell
them that idea of getting what they can afford, the best software that they can afford without
all of those major costs. It’s a very, very compelling argument. One of the things that
I’ve found is if you do a condensing of that job, selling something, especially if
you have clients coming to you and saying we’re putting this out to bid, we’d like
you to enter a bid, we’re talking to 20 other software companies. If you can get them
on the phone and you can talk to them the way I’m talking to you right now and you
can get them nodding their head and saying yes, yes in fact I would like this control,
I would like the quality and I would like a process that’s transparent and the next
thing that happens is they get 19 proposals in from other companies who’ve just filled
in the proposal like they always do based on the RFP but that’s not what they’re
looking for anymore. What they’re looking for is this experience, a high quality software
in the way that keeps them in the driver’s seat and you’re not even competing against
them anymore. You’ve already won because the business changed, the request has changed. Time iterations are a great selling point.
The main things that I like to talk about with clients is one can stop only one. This
may be — I once had a client who stopped just a few iterations into a project because
he was trying to create something that was already operating in a larger market and that
company moved into his market and he realized he just couldn’t compete so he stopped.
Sometimes clients stop, in fact usually clients stop because they’re done. My experience
is that customers who do come to me with a functional specification or a list of features
they want generally are happy and cancel the project and release when they have about 80%
of those features done and some other things that they thought of along the way. So the
idea that they can release when there’s If you’re building a big accounting system
and hundreds of features for your whole accounting If you’re building a big accounting system
and hundreds of features for your whole accounting department but at the end of the second iteration
it generates this one report that Bob has to run every Friday and it takes him a whole
day to get the numbers together and now it’s automated, if eight hours a week of Bob’s
time worth more to you than the cost of deployment then you can go ahead and deploy that iteration
two deployment and all of a sudden Bob is really happy and is using your product and
giving you valuable feedback and becoming an enthusiastic supporter of the project. You can change vendors easily. This makes
some people uncomfortable but the fact of the matter is that right now you’re just
trying to get a customer to make a decision and the biggest fear is that they’re going
to be tied into a never ending relationship with the wrong person because they don’t
know until they’re well into their commitment whether or not you’re actually capable of
doing what you said you were going to do. So when you tell them typically when you do
a big project halfway through it if you pick it up and take it to another team you’re
going to have a bunch of half finished features, you don’t know what the quality of the project
is and most of the time the other team will a bunch of half finished features that we
don’t know what they’re supposed to do, a bunch of half finished features that we
don’t know what they’re supposed to do, help me to understand. You’re better off
just writing it from scratch and you can trust us, we won’t do to you what just happened.
Of course they will. The reason production and quality work on
an interim basis is that at the end of every iteration you’ve got something you can take
back home to another team if for some reason the first team goes out of business or you’re
not satisfied with the relationship or whatever you can take it to another team and say this
is the software that works, it’s fully functional, there’s nothing half finished in this, there’s
not spaghetti cone, we just need you to add these ten more features to what’s already
there. It’s a much easier thing for them to do with another client so this makes your
customers feel very comfortable. And finally, they have control over the scope.
Clients don’t often know that this means they can pull things out. That’s not what
they’re thinking but being able to put these things in without this complete disaster and
go through that big bureaucratic change process is very comforting for a client. And then you can sell them on the experience
— what they’re going to be doing, what their role is and the fact that they’ll
have a role. A lot of clients don’t realize once the planning process is over, they’re
not used to having any role other than receiving products and getting on the phone and yelling
at the project manager when it looks like things aren’t going well, even though that
doesn’t actually accomplish anything. Having that ongoing role in which they get to meet
every single human being who’s going on the project, they get to see features and
get immediate feedback to make sure everything is done right from the start as opposed to
getting something at the end they’re not fully satisfied with is really exciting and
compelling and it can be the huge differentiator if your competitors are not doing this. So they’re the ones who are going to be
living this project for the next month, six months, year, two years, however long it’s
going to be. Let them know that their life is going to be good. It’s going to be positive,
it’s going to be pleasant, it’s going to be social, it’s going to be informed,
they’re going to be part of the process. No matter what’s going on they’re going
to have control. If you’re betting on doing that, you wouldn’t say it because everyone
needs to see what it’s going to look like in their life with a waterfall project. All right, so more general observations about
sales in general that I just want to share. One, a lot of people try to sell the technical
expertise. If you’re on the phone with the client, they’ve already decided that you
qualify. Most clients are not competent to assess your abilities as a development company.
What clients are incredibly good at is figuring out if you’re paying attention to them,
whether you understand them and whether you care about them. So when the time comes to
make a decision between one or another service provider, that’s going to be the deciding
factor, not the guy who’s got 100 years combined experience but the guy who gets them,
has some ideas and has some enthusiasm to communicate the value to them. Another point that I’ve noticed over the
years of working with other software companies is I like to create cooperative competitive
environments wherever I work. If that’s internally within the ecosystem companies
might compare themselves to each other but it’s not very helpful when you do that with
your customers, when you say we are great because we do this and everybody else does
this or we are better than them because we have more people, we have more experience
or what-have-you. Because your biggest competitor is not the other team down the street, you’re
biggest competitor is that the client is afraid that none of you are very good because everything
they know about the software element was very negative and maybe it would be better if you
were in-house or maybe it would be better good at, one thing — and I think the experience
of being a client in an Agile process where good at, one thing – and I think the experience
of being a client in an Agile process where big time [background cough] is a poor differentiator
rather than trying to compare yourself to big time [background cough] is a poor differentiator
rather than trying to compare yourself to others. I can skip this too because of the last presentation. So get one thing to stand out. It’s another
mistake that sales people across service industries always make is they say you should choose
us because this, this, this, this and this. 10 things good about this company, there’s
20 about this company, there are 6 things 10 things good about this company, there’s
20 about this company, there are 6 things that are good about this company and they
don’t remember any of them. But if you tell you do, whether it’s quality, quality, quality
or control, control, control or fun, fun, you do, whether it’s quality, quality, quality
or control, control, control or fun, fun, fun or whatever it is. Interviewer In my opinion it’s fun. I’ve
had customers — this is a funny story and Interviewer In my opinion it’s fun. I’ve
had customers – this is a funny story and it leads into my next slide. I had a customer
once I asked him what his budget was to build what he wanted to build and he said I’m
not telling anybody my budget because I’m afraid you’d spend all of it. I said that’s
no problem, I’ll find out because in my experience if you make the software building
process fun and engaging and the client really last penny they have. So their budget is what
they’re going to end up spending. last penny they have. So their budget is what
they’re going to end up spending. One of the things that we’ve done in my
company and we’re doing now, which is kind of funny is we’ve actually bought a hostel
and we’re working, outfitting a hotel room in it for our customers to stay there on the
theory that when they come to visit us they development too. development too. Lastly, be honest with clients, talk simply,
don’t try to overwhelm them. Don’t use jargon. For example, let’s say you want
to hire a house painter to paint your home and I come to you and say you should choose
me because I’m committed to excellence. Jargon goes in one ear, out the other and
actually lowers the credibility of whoever ask me how do you guarantee that you’ll
complete this within the estimate and I say ask me how do you guarantee that you’ll
complete this within the estimate and I say I can’t. We’ve done over a hundred projects
now and I’ve got some real doozies under I’ve had four that have gone dramatically
over budget, more than 15% and three of them I’ve had four that have gone dramatically
over budget, more than 15% and three of them really small projects. They were projects
that were originally estimated at two to six really small projects. They were projects
that were originally estimated at two to six weeks so what we’ve learned from this is
we really, really suck at estimating small to adapt. to adapt. And the client then trusts me, unless they
have a very small project, then they don’t you know that person’s the small boat, 200
percent over, but everybody else is saying, you know that person’s the small boat, 200
percent over, but everybody else is saying, no, right on the money. ___ 00:41:08 are always
correct because we’re committed to excellence. Then they’re still more inclined to trust
me and not believe those other people. Because if a guy like me can have three projects to
manage that device out of budget, then how simply, use plain English, and don’t try
to use jargon. It doesn’t work, yes, tell simply, use plain English, and don’t try
to use jargon. It doesn’t work, yes, tell them straight through without embellishment. that when they’ve got the signature on the
contract they won, that the client had some that when they’ve got the signature on the
contract they won, that the client had some of their infinite wisdom look through all
of the options and said, you guys, you are at all and it leads to some of the biggest
problems that people have with their clients at all and it leads to some of the biggest
problems that people have with their clients during the first weeks or months of a project.
And the problem is this. When the client’s they’re saying, okay I’m willing to do
a huge favor and give you guys a chance to they’re saying, okay I’m willing to do
a huge favor and give you guys a chance to And it’s a huge favor the client is doing
you helping them software project. They’re And it’s a huge favor the client is doing
you helping them software project. They’re not going to start realizing value to even
with an agile process for weeks and they’re the project with the balance on their side.
They have given you something, their giving the project with the balance on their side.
They have given you something, their giving you a great deal of trust, they’ve made
a big commitment in you and they expect you to appreciate that. So, now and you can read
everything I just said later. So, show gratitude before you start. How do you show gratitude,
by creating a great experience for the customer, Never stop market, don’t stop marketing
when you get that signature on the contract. Never stop market, don’t stop marketing
when you get that signature on the contract. Every single point of contact that your company
has with a customer is marketing. If they that he answers that phone is marketing. If
you send the contract he signed, that’s that he answers that phone is marketing. If
you send the contract he signed, that’s marketing. And if it’s not as good as it
can possibly be your missing the opportunity highest. I’m not giving away all my secrets
but one of the things I do that’s made a highest. I’m not giving away all my secrets
but one of the things I do that’s made a days, with a number of referrals that I got
from the client, is a simple thing. It used days, with a number of referrals that I got
from the client, is a simple thing. It used to be when I finished the sales call and the
clients said okay let’s do it. I would then email them a contract that said,
please print this sign, and fax it back to me. Does that sound common enough? Is that
the way it usually works? Just me? When I of signing my contract better and better,
and better, and better, and better, until of signing my contract better and better,
and better, and better, and better, until it’s as good as it can possibly be. And
so I commissioned a company to design and make a box, a very nice black box, black on
black printing, embossed logo, Apple set the standard for packaging, and I thought I could
match the standard ___ 00:44:42 match. So which I think is the best book I’ve ever
read for easily introducing clients to what which I think is the best book I’ve ever
read for easily introducing clients to what is going on in the background when their ad
___00:44:55 team is working. printing company I could, to do the best quality
printing on poker card, plastic, laminate printing company I could, to do the best quality
printing on poker card, plastic, laminate them, put that look in there. I had custom
printed Moleskine notebooks with our logo other top quality brands. So that goes in
there. Then there’s two copies of the contract other top quality brands. So that goes in
there. Then there’s two copies of the contract from me thanking them for their trust their
putting in us. And then I put in a self-addressed from me thanking them for their trust their
putting in us. And then I put in a self-addressed envelope ___ 00:45:34 to be return. that my clients were in. They don’t have
to go to the post office and they don’t that my clients were in. They don’t have
to go to the post office and they don’t have to ask how much do I have to put on this
envelope in order to send a copy of the contract detail. And we’ve taken this similar approach
to every single point of contact you have detail. And we’ve taken this similar approach
to every single point of contact you have with the clients. And the result is, oh, and
we sent it by FedEx, so person you talked to on the phone who says okay I want to work
with, before it launched the next day it sits yes I’ll work with you. yes I’ll work with you. And it really changes the atmosphere of those
early interactions when there’s a developer on the team who doesn’t understand how something
has to happen before we begin. The client mustn’t think he must be oblivion. So the
client comes into this already feeling like this is something different, this is something
special. And you have to keep that feeling alive in the client. Otherwise they interpret
everything they see to their other filter which may not be so flattering.

3 comments on “Selling Agile – Paul Klipp

Leave a Reply

Your email address will not be published. Required fields are marked *