Philly ETE April 8, 2015

Agile Contracts for Software Consultants

Michael Toppa@mtoppa

About me…

Copyright Random House Books

* I’ve been developing for the web since the days of HTML 1.0, when web pages were first painted on cave walls * Over the years I’ve worked at Ask Jeeves, E-Trade, Stanford, Georgetown, Penn, ElectNext, and currently at PromptWorks, which is a consultancy shop

here in Philadelphia. * Most of my work has been as a developer, but I’ve also done a good deal of project management and team management, and I’m a big believer in

Agile and lean practices.

About you…

You know Agile

I’m assuming you’re familiar with core Agile principles and practices. I won’t be explaining sprints, standups, velocity, inspect & adapt, etc

PromptWorks is a small consultancy in Philadelphia. We do a lot of work in Ruby, Rails, Python, JavaScript, and infrastructure automation. In addition to building products for our clients, we work closely with them, and pair program with them when possible. So that when we leave, they can continue on the path using TDD and good object oriented design.

Disclaimer

❖ I am not your lawyer

❖ I am not a lawyer at all

❖ Nothing you may take from this presentation should be considered legal advise

❖ Consult your own experts

Preamble

Professionalism

Before talking about contracts, I want to lay some groundwork by talking about professionalism. Specifically, what it means to form a professional relationship with your client. This relationship is crucial to how you approach negotiating a contract, and how you work with your client once the project is underway.

image source

* Like some of the concepts in Lean, like Kaizen and Kanban, we can learn from the Japanese.* [My time in Japan]* A hallmark of Japanese culture is the consistent level of politeness, kindness, and excellent service you will receive.* A forbes.com columnist said: “Wherever I ventured, in stores large and small, I experienced what would be considered white-glove service back home, delivered with

the kind of warmth, enthusiasm and salesmanship typically found in black-and-white movies.”

“There is customer service, and then there is Japanese customer service”

Tadashi Yanai, CEO, Uniqlo

source

When Uniqlo opened a store in Melbourne, Australia, they spent a full year training the Australian staff, to get them to a Japanese level of quality service

image source

Go to a department store when it first opens in the morning, and no one is there [story about bowing]. If anything goes even slightly wrong, the people helping you will be profusely apologetic, and work to address the situation as quickly as possible. When you leave a store after making a purchase, the person who helped you will follow out the door, and bow deeply – staying bowed until you've reached the end of the block.

“I just wanted to hug everyone” a friend visiting Japan for the first time

The Japanese aren’t known for being friendly, but they actually are, especially if you venture outside of Tokyo. If you make an effort to engage socially, you may be surprised at the warmth of the interactions you’ll have.

image source

It's typical to see a Japanese worker perform the lowliest job as if it were the best. [cashier story]

image source

People take pride in their work. They are treated with respect by everyone, and paid a living wage. The culture also emphasizes the interests of the collective group over individual interests.

In Japan, the customer is king

…?

Westerners typically perceive this as a selfless devotion to the customer: that Japanese workers will do anything to please you, since you are made to feel so well taken care of.

The customer is king

But this perception is the result of our own Western cultural assumptions, where we presume a hierarchical relationship, and it’s not what’s really going on. The Latin root of the words service and servant are “servus.” This is also the same word for slave. The Japanese concept of service has a different cultural context.

お持て成し Omotenashi

* Omotenashi has two different literal translations: “single-hearted” and “achieve.” It’s the combination of these meanings that defines the Japanese concepts of service and hospitality. It’s about anticipating your customer’s needs, and pro-actively meeting them.

* You and your customer each have a role to play, and you are equals. The devotion is to consistent excellence, not necessarily a particular customer* As a customer, you never tip waiters, taxi drivers, or anyone else. You’re not even expected to say thank you.* But you are expected to respect the professional judgement of your service provider, and respect their expertise.* If the customer presses you for something, it means something has gone wrong. It could mean you’re not doing your job well, or…

In Japan, the customer is incompetent, but is made to feel like a king

…the customer has overstepped the bounds of their role. Maybe they don’t realize it, or don’t fully understand the ramifications of what they’re asking for. For the sake of the customer actually having a good experience, and for the sake of your reputation, you have a responsibility to not be pushed into behaving unprofessionally. In this kind of situation, a Japanese service provider will still be incredibly polite, will patiently try to educate you, and will resist doing the wrong thing with steely resolve.

[bags story]

image source

[gift wrapping story]

“We want a blog”

[client with blog idea story]

“Don’t do it that way, do it this way”

[client project for modeling energy efficiency]

Omotenashi and contracts

A traditional fixed scope, fixed price contract typically implies a typical Western style hierarchical relationship with your client.

Schedule

CostScope

* They will try to squeeze you all 3 sides of the triangle: they’ll try to get the scope - all the features you’ll build - the price, and the schedule, all written into the contract.

* At the beginning of the project is when you know the least about it. This is when you are given a narrow window to exercise your judgement about the scope and cost of the project.

* Most of the risk and responsibility is placed on you. It’s not a relationship of equal partners.

“I find your lack of faith disturbing”

Copyright Lucasfilm Ltd

With these kinds of contracts, things almost always start to go wrong part way through the project, and when that happens, you don’t want to end up like this guy.

So you don’t want to go that route - instead you want to take an Agile approach. Maybe you’re an Agile Jedi. You know the Agile Manifesto values collaboration over contract negotiation. If your potential client has not worked in an Agile way before, you talk to them about adapting to change, about working in short sprint cycles that deliver functioning features, and velocity to track progress.

Copyright Lucasfilm Ltd

* But that’s not enough. Even if your potential client likes what you’re saying, you’re asking them to take a leap of faith into something they don’t fully understand yet. So it sounds risky, and they and their lawyers don’t like risk.

* You need to explain the benefits of taking an Agile approach, and not using a FPFS contract, in concrete terms they will find persuasive.

Examine the assumptions of fixed price - fixed scope (FPFS)

contracts

* Clients have a natural preference for traditional contracts because the spell out what will be delivered, when, and for how much. At first glance, they appear to protect the client from risk, and put the risk on the contractor.

* So a good starting point is to highlight the misplaced assumptions and expectations your clients may have about FPFS contracts.* These contracts assume a waterfall development process, where software development is treated like a construction project.

Assumptions of FPFS contracts

Long lead times

There is a long delay between the start of the project and the delivery of a useful product

Assumptions of FPFS contracts

Limited feedback

Feedback is only possible late in the project, and cannot play a large role in shaping deliverables

Assumptions of FPFS contracts

Infrequent, large payments

Payments are made only when major milestones are achieved. This raises the pressure and anxiety for both parties around milestones.

Assumptions of FPFS contracts

Early termination = failed project

The client will have major problems if the project stops at an unplanned point before the scheduled time. If the project was scheduled for 12 months, and the contract is terminated at 8 months, that can only mean something has gone disastrously wrong.

These assumptions are invalid in an Agile project!

The Agile approach instead assumes a highly variable, research and development process.

Frequent delivery of working software…

❖ means the customer realizes value at regular intervals

❖ means the contractor can get paid at regular intervals

❖ mitigates risk and liability for both parties

Iterative and incremental… launch early… note this assumes:* The contractor has a mature and disciplined development process – that they have the ability to deliver complete, tested features in short cycles* The client will stay strongly engaged in the project throughout it's lifecycle.

Adapting to change decreases risk

Ongoing opportunities for feedback and change also decreases risk. The traditional approach obligates delivery of the original set of requirements, and requests for change only add time and cost.

FPFS contracts actually increase risk and cost

* Lack of frequent feedback is a root cause.* The Agile Contracts Primer mentions an offshore outsourcing company in India that has learned to game the system of FPFS contracts. They know from experience

that the contract's requirements won't end up meeting the customer's actual needs, and they look forward to the ongoing “rent” of the work they're asked to do after the contract is complete, evolving the unsatisfactory system they built, to meet the true needs.

An Agile contract is more an agreement about a collaboration process,

and less about deliverables

* FPFS contracts can encourage an adversarial mindset. They require BDUF, which means all the particulars need to be negotiated in detail up front. This pushes worry about risk to the forefront, and who is bearing the risk.

* An Agile contract instead focuses on having an agreement about how we will work together, to deliver a successful project.* This gets us much closer to an Omotenashi kind of relationship

Contract documents

❖ Project proposal

❖ Master Services Agreement (MSA)

❖ Scope of Work (SOW)

So what goes into an Agile contract?* The project proposal makes the case for why the client should choose you, and describes the project at a high level* If the client likes the proposal you can move on to the MSA and SOW* The MSA is the “legalese” document that talks about liability, warranties, etc* The SOW is the agreement describing the work for the project

Project proposal

❖ Supplier information

❖ Project motivation

❖ Initial requirements

❖ Risks

❖ Project participants

❖ Project plan

❖ Deliverables

❖ Project timeline

❖ Project cost

❖ Next steps

* Our project proposals are typically 10 or 11 pages. Things to highlight:* We make the case for why they should hire us: our depth and breadth of experience, the quality of our work and technical practices, and our other awesome clients* We make the case for an Agile approach, including emphasizing the importance of their being strongly engaged in the project throughout it’s lifecycle* We highlight risks we see, that could affect the quality, timeliness, or cost of the project* Our deliverables section is short: source code, automated tests, browser compatibility, and deployment

Peter Stevens: Types of Contracts❖ Time and Materials with Variable Scope

❖ Time and Materials with Variable Scope & Cost Ceiling

❖ Fixed Price, Fixed Scope

❖ Time and Materials with Fixed Scope & Cost Ceiling

❖ Phased Development

❖ Fixed Profit

❖ “Money for Nothing, Changes for Free”

❖ Joint Ventures

* There are many possible types of contracts. In the proposal we make the case for a time and materials approach. * We use T&M contracts because they’re simple, easy to understand, easy to bill, and provide the flexibility needed for running an Agile project* At PromptWorks we’ve signed over 30 time and materials contracts in the 2 years we’ve been in business.

Our Time and Materials Approach❖ Ballpark project estimate based on initial requirements

❖ Do an initial prioritization if not already provided

❖ Give them a dedicated team

❖ Deliver working features weekly

❖ Bill monthly for “developer weeks”

❖ Work continuously to evolve and prioritize features

❖ Stop when it makes sense

* We make it clear this is non-binding estimate only, based on our initial understanding of the requirements* A small project estimate can take just an hour or two, a large one can take a day* Involve at least two people in estimating* Sometimes you may need to do a 2nd round of estimating, if the initial project scope information turns out to be insufficient

About 50% raise concerns

How do I know we’ll stay on budget?

How do I know we’ll stay on schedule?

These are trust and confidence questions. Building trust is key to an agile approach. If you don’t succeed in building trust, that doesn’t bode well for the project, regardless of the type of contract

Responses

❖ Provide references

❖ Re-iterate Agile advantages

❖ We can include a “not to exceed” clause

❖ Client can cancel at any time, with 30 days notice

❖ Our TDD code is portable to other contractors

* We work closely with you to prioritize features, so the most important parts of your application are built first. Your budget will go to the most important aspects first.* We’ll actually want to go live before your launch date, with test users

We still lose about 25%…

…and that’s ok

* Sometimes our price is too high for them* Sometimes we just can’t win them over.

* Some prefer the lower level of day to day client engagement that typically goes with FPFS contracts* Some remain attached to the feeling go security and familiarity if an FPFS contract

* Sometimes they face insurmountable bureaucratic obstacles to accepting a T&M contract

Master Services Agreement (MSA)

❖ Services

❖ Term

❖ Cooperation

❖ Payment: Expenses

❖ Changes

❖ Warranties

❖ Confidentiality

❖ Ownership

❖ Infringement Indemnity

❖ Limitations of Liability

❖ Force Majure

❖ Miscellaneous

* This is the legalese document* These are the sections in our MSA

MSA Highlights

❖ Code ownership

❖ Open source aspects

❖ 30 days notice to cancel by either party

❖ Services: “software development”

❖ Beware extreme requirements from clients

❖ “most favored nation” clause

* Sometimes they are uncomfortable with clauses indicating we may use open source software, which the client will not own, and which PromptWorks does not warranty

Scope of Work (SOW)

Keep it simple

An Omotenashi relationship

* In our project proposals, we observe that traditional BDUF contracts sets the developer and client at odds, as each tries to bend ambiguity in the contractually-specified features to their advantage. If the big-design estimate is too low, the developer can only absorb so much of the risk before calling it quits.

* We want to be our clients’ partner over the long term. We’ve learned the best way to align our interests and succeed together is to charge on a time-and-materials basis and cooperatively manage the risks inherent in all software projects.

* We bring our expertise in software development and Agile practices, and we work together with ours clients who bring their domain expertise, business requirements, and priorities. We work to respect each other’s roles, and together, we do great things.

終わり

Questions?