
I'm Agile but My Contract Isn't - dmadden
http://www.stridenyc.com/blog/2014/10/3/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams
======
mbesto
> _“No changes will be effective unless and until memorialized in a written
> change order signed by both parties.”_

Ahhh, in the "Enterprise", we call this a Change Request (we would name and
number them CRXXX, for example) and put them in a "register" (Excel doc that
got passed around 100x a day). These become so excessive they needed to be
managed by a Management Consultant (who charges $250+/hr) who specializes in
change management.

> _There are three variables to any project: Money, Time, and Scope._

Every project I approached, I would draw the following diagram to the client:
[http://en.wikipedia.org/wiki/Project_management_triangle](http://en.wikipedia.org/wiki/Project_management_triangle)
and any time one of the corners changed (it always did) I would redraw the
triangle and ask the client how they wanted to proceed with ensuring the
quality of the project.

As someone who has successfully and unsuccessfully implemented agile in
arguably the worst environment possible ("The Enterprise"), my general
conclusion is this: if the client doesn't understand agile fully or is already
implementing practices that are agile-like, then do not begin the project. Set
up workshops, assess their ability to adhere to budget-less (agile) projects,
and make a decision then. For smaller clients, I typically ask the client
"what's your budget?" and then I work backwards from that. So if a developer
is $100/hr, and the client has $5k to spend, I'll say "ok you get a developer
for 50 hrs. Most likely we can build this, this and this" If/when the client
disagrees ("But I can get 2 people in Malaysia for that price!") you simply
tell them to go find someone cheaper on oDesk.

~~~
Joeri
I'm wondering up to what size you managed to do an agile project for 'The
Enterprise'. From what I've seen, as soon as an enterprise contract is big
enough to involve a tender, bidding round and separate purchasing department,
agile is impossible. Being agile actually works against you, since regular
demo's will bring up more opportunities to point out how you aren't sticking
to the letter of the contract, flexible scope means adding scope and never
reducing it, and grooming as you go along means uncovering big requirements
which are sort-of-kind-of in the contract halfway through a big project that's
already late. And those are the easy projects compared to government
contracts.

I keep wondering how you're supposed to negotiate the typical big enterprise
contract so you're allowed to be agile while executing it. I haven't seen it
done successfully yet.

~~~
mbesto
You're not incorrect. But I always like to think there is always a possible ;)
The reality is agile is such a strong buzzword in 'The Enterprise' now that
you can't even avoid it anymore.

The one that was successful was a $250k project - 3 months. Client insisted
fixed price and done "in agile". We estimated the actual work was only 6
weeks, but knew they'd change their minds 100x times (they did). We didn't
optimize the timeline properly (as you are insinuating, it's almost impossible
to predict), so our margins ended up being quite low.

I do know one company which successfully does agile (within a company that
does $100bil in rev). They budget the whole year out for X amount of employees
and then do everything in 3 week sprints. They basically "fit in as much
development as they can with the resources they have" and disregard the high
level 3-year "integration plans" that the management consultants put together.

------
geebee
This article really addresses the need for agile development to be a two way
street [1]. I loved the manifesto when I first read it, and I still do. But
I've noticed it really goes wrong when both sides don't adhere to the
principle - when one side tries to be "agile" and the other side lawyers up,
the agile side will get railroaded if (and probably when) the relationship
turns sour.

"Individuals and interactions over processes and tools" means "we come by your
office to interact with you as an individual about why your story points
haven't velocitized properly in the time tracking system" [2]

In a similar vein, "Customer collaboration over contract negotiation" becomes
"we'll hold your feet to the fire about deadlines and estimates, but we
reserve the right to change our minds at any point."

In this sense, agile becomes unilateral disarmament in the face of a heavily
armed… neighbor. I wouldn't say "foe", yet, but good relationships can turn
bad. It's like one side saying "let's do this with trust and work together",
but they're the only ones with a lawyer at the table.

In some ways, the agile manifesto almost says "peace and cooperation over
fighting and coercion". Yeah! I'm for it. But we _both_ need to do this!

[1] I feel a little embarrassed using the word "agile", but I figure that as
long as it's an adjective, I preserve some dignity. [2] I'm not technically a
_certified_ scrum master, so I may have some of that slightly wrong.

~~~
AnimalMuppet
Let's step away from the contracting scenario for a minute. Let's say it's
purely in-house, and the team is committed to agile. That's great... until you
run into a layer of management that doesn't understand agile. They still want
the old waterfall-style progress reports, and they still make decisions based
on them - decisions that can kill your project. This can force you to suddenly
be less agile, or to present an interface to those outside your team as if you
were not agile.

Back to contracting. If you're a contractor, even if the team you're working
with is fully on board with being agile, you can still get burned by higher
layers of their organization.

------
drawkbox
Clients almost always want it fixed-price, but those same clients, when it
comes to the actual project, they turn into agile scope creepers.

It is very important to discuss all this upfront with clients, many of them
have no idea of estimation, the mythical man month and are horrible at knowing
fully their ideas, the level of detail, before work starts yet will want
fixed. It is especially bad on clients new to apps/games/web or their first
attempt who just see surface level tasks.

Iteration and a more agile approach will hopefully find the way into business
and mba textbooks/processes. Right now almost everyone wants fixed-price and
flexibility to change at will. This will only hurt developers/designers and
ultimately the project chance of success.

And don't get me started on non-competes the most anti-innovation, anti-
business, anti-american (if you are in the US) thing ever being fully pushed
by business at every turn. Most non-competes want you to come in to help a
company compete, then once they know how or you have built it for them so they
can compete, you can no longer compete any longer for a time because you
helped them, makes sense for kings/owners/dictators but not fair business.

------
patrickmay
The underlying issue is risk management. Customers want certain features
within a certain budget, hence their need to constrain at least two of the
variables mentioned in the article. They want the vendor to take the risk of
going over budget.

Vendors, obviously, want the customer to take the risk. This is why we see
articles like this.

If you want to apply agile methodologies in these situations, you need to keep
the scope small and also constrain the time. That keeps the risk for both the
customer and vendor manageable.

~~~
hvidgaard
We have a different approach. If the customer wants a fixed scope and price,
we make an estimate (considering both our internal cost, and the value of the
work for the customer) then double the price.

They usually do not accept and want it cheaper. Then we offer the project at
the estimate and to split any difference. So if we use 1 hour less at 200$/h,
they get it 100$ cheaper. However, if the project ends up taking 1 hour more
it will only be 100$ more for the customer.

I really would wish that the customers would trust us more and accept it at
the hourly rate to get the initial work. Then we can iterate on that until
they're satisfied.

~~~
dmadden
Agreed that if we can get 2 sides to 'trust' each other, we can minimize the
need for this type of approach.

------
Argorak
Fixed contracts (Option 4) are extremely problematic for clients. I rarely
seen one of those going well.

There are 2 options:

a) The supplier is not an expert in this and will have problems with the
project changing scope and maybe running over budget and time which they
cannot invoice. This leads to the supplier being at the unfair end of the
deal, leading to poor work by the numbers.

b) The supplier is an expert, works on a fixed scope and denies all requests
for changes (without renegotiation). This rarely works in favour of the
client. I had prospective clients coming back to us after another company
wrote them a software perfectly for their spec, but they realized in the
middle that the spec was not fitting their business case properly.

------
snlacks
This clause sounds more like it has to do with changing features that a
developer may see as an improvement and a client may see as a "holy crap, what
happened, now I have to retrain my staff."

We're agile, working with established businesses. We have to take in our
clients real world needs into account. Agile is a set of principles and a
guide, not a set of physical or economic rules. Sometimes the tool isn't the
best for the job, sometimes two conventions (client's work, developer's work)
contradict.

~~~
snlacks
Reply to self: Of course, as relationships grow, we know our clients better
and they trust us to make the right decision or fix it quickly on production.

------
idlewords
If "Agile" really works (and I have no opinion on whether it does), then its
use should be an implementation detail that the client doesn't need to care
about, but which allows the consultancy to offer much better estimates of time
and cost for a given scope.

In other words, if your methodology is so great, use it to your business
advantage.

~~~
rcvassallo
Agile is definitely an implementation detail but good clients will care about
it for precisely the reason you provided.

They won't care to hear about the specific labor pains, but they will love it
when you tell them your "agile" development process allows them to get
prototypes quickly and provide further input as their ideas take shape.

"In other words, if your methodology is so great, use it to your business
advantage."

I did and it resulted six-figures worth of contract work last year from just
one client. Part of my sales pitch was to explain agile development in a way
that focused on their business.

When I asked the client why they chose to work with me instead of the bigger
agency, they mentioned 2 things: 1) They liked the feedback-driven development
process and 2) I talked about their business instead of the technology that
would go into the software.

The best part is that an agile process helps you position yourself as a
trusted advisor instead of a commodity laborer. When you do that, your clients
get better results and provide repeat and/or referral business.

TLDR: The best clients do care if you're agile about their business needs.

------
cowls
The article mentions this as a question if you want to confine the amount of
money you spend: “How much do you want to invest before we stop?”

I think this is one of the fundamental issues with Agile, if a client wants to
hire a consultancy to complete a project, they want to know how much it will
cost and what will actually be completed.

Forming the question as: “How much do you want to invest before we stop?”
requires a large amount of trust in the consultancy, personally I have worked
with a number that supply below par developers and so asking “How much do you
want to invest before we stop?” gives the client no guarantees and the
consultancy no obligation to what will actually be delivered.

I think agile can work for in house software teams but not so much for
consultancies, where in reality there are normally 2 or 3 of those variables
mentioned in the article fixed.

~~~
dmadden
Yes, it does require trust. I have personally seen Agile work for
consultancies (It works well for my consultancy, Stride). The trust factor is
paramount. We take a lot of care and implement many practices outside the
contract to ensure we deliver what the client wants.

------
kris_lander
If as the OP says, it's about treating the contractual relationship as an
investment to deliver value then I believe we can do better than simply "fix
scope". I've recently written about this at length including why the contract
model (and agile derivatives) do little to align the interests of client and
supplier to deliver value.
([http://www.energizedwork.com/weblog/2014/09/commercial-
contr...](http://www.energizedwork.com/weblog/2014/09/commercial-contracts-
guarantees-commitments-risks))

------
Animats
In the US, if you're "agile", you're an employee, not a contractor, for tax
purposes. Read IRS Publication 15-A, page 7. A fixed-goal, fixed price
contract is a real contract. "Agile" puts you under the "behavioral control"
of the employer at a more detailed level, which makes you an employee.

[http://www.irs.gov/pub/irs-pdf/p15a.pdf](http://www.irs.gov/pub/irs-
pdf/p15a.pdf)

~~~
rcvassallo
It's not that simple. Being "agile" does not necessarily makes you an employee
in the US. From IRA Pub 15-a:

"The general rule is that an individual is an independent contractor if you,
the person for whom the services are performed, have the right to control or
direct only the result of the work and not the means and methods of
accomplishing the result."

As an agile contractor you can give clients options that allow them balance
quality & cost without being under "behavioral control." The client gets to
say they want to build a widget that does X and Y, then you choose to build it
at time T using whatever tools and methods you deem appropriate.

Couple that with offering these services to the public: "People such as
doctors, veterinarians, and auctioneers who follow an independent trade,
business, or profession in which they offer their services to the public, are
generally not employees."

That said, "whether such people are employees or independent contractors
depends on the facts in each case" so make the facts obvious in your contract
with a section like this:

"Independent Contractor. The Parties agree that Contractor is an independent
contractor and that Contractor has full control over the methods utilized in
performing the Services. Contractor will not make any representation of an
employment relationship between Contractor and the Company and will not claim
any benefits provided by the Company to its employees. Contractor has no
authority to contract for or bind the Company in any manner, except with prior
written consent of the Company. Contractor shall devote such amount of his or
its time, attention, knowledge, and skills as may be required to create and
deliver the Product and to perform the Services."

------
codingdave
It sounds like the author is working with contracts that are too detailed.
Contracts should specify the legal obligations and structure of a relationship
between two parties, but if it is getting into procedural detail, or dictating
the policies of an organization, it is just asking for trouble. At that point,
an internal process change could violate a contract clause. That just doesn't
make sense.

~~~
Argorak
You can always amend a contract. Just write a sideletter. A contract should
always contain a definition of the services and the mode they are supplied and
invoiced in.

~~~
zachrose
I work with two types of documents: master consulting agreements and work
orders. The master consulting agreement has all the "standard" stuff like IP,
confidentiallity, indemnity, etc. The work orders are where I specify what
we're going to do(1), how much it's going to cost, and when it will be
delivered. Both are dated and signed. This works well for me and allows me to
do agile-style sprints with work orders. This is usually in addition to a
ballpark price range for ballpark scope.

(1) Where "what I'm going to do" can be substituted for "what I'm going to
try," when the client understands why I can't guarantee something.

~~~
Argorak
That, I do a lot as well. Basic point being: a fitting contract doesn't have
to be a hassle.

------
saosebastiao
Based off of reading this, I can imagine a lot of people not wanting to hire
you. _I get what you 're saying_, but all you've communicated to the customer
is that you always need enough wiggle room to successfully screw them over.
You should still place contractual bounds on how something can change.

~~~
dmadden
Yes, if all I offered a client was an Agile contract, they shouldn't want to
hire us.

But, the contract is 1 piece of the puzzle. In order for businesses to want to
hire Agile teams, whether consulting teams, freelancers or otherwise, many
factors have to exist in addition to an Agile contract.

These factors include - high quality development teams, visible work, high
collaboration, working agreements, trust, a cancellation clause, definition of
"done", and more.

------
pnathan
\- Why push agile onto the contract?

\- Why not move to a whirlpool (or other milestone-based iterative process)
with fixed milestones?

------
netcan
lol.

On one hand we have culture and art and philosophy and technology. We have
technological culture and art. We have philosophies for creating a culture for
creating technology. Then, OTOH, we have this. An inability to collaborate for
fun or profit.

We need to account for various skill levels, failures in communication,
philosophical differences. Scheisterism, baseless accusations of scheisterism.
Bugs. etc. etc.

Collaboration is ultimately a fundamental problem, perhaps the most
fundamental one.

