WordCamp Boston 2015: Agile Contracts for WordPress Consultants

WordCamp Boston July 18, 2015
Agile Contracts for
WordPress Consultants
Michael Toppa
Co-founder, CTO
Poka Yoke Designs
www.pokayoke.design
@mtoppa
#wcbos

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.
* I’ve been involved with WordPress since I developed my first plugin in 2007, I’ve made contributions to WordPress core, and I was the lead developer
for the NBC Latino news site on the WordPress VIP platform.
* Over the years I’ve worked at Ask Jeeves, E-Trade, Stanford, Georgetown, Penn, WebDevStudios, and others.
* 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.

My new house in Boston…
* I just moved to Boston from Philadelphia

* I took this picture of my house yesterday

* …and it looks pretty much the same today

A lot of this presentation draws on my recent experience at PromptWorks, which is a 15 person consultancy in Philadelphia. In the past 2 years they’ve
signed over 30 time and materials contracts, and much of the information I’ll share with you today about contracts draws on that experience.

ポカヨケ
www.pokayoke.design
@pokayokedesign
My wife has a new job here in Boston, and I have a new job now too. I’m co-founder and CTO of Poka Yoke Design. I was an active member of the WordPress
community in Philly, and I look forward to becoming part of the community here in Boston.

Disclaimer
image source
* I am not your lawyer

* I am not a lawyer at all

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

* I am here to give you business advise, not recommend speciﬁc language for use in your contracts

Agenda!
1. Agile
2. Professionalism
3. Agile contracting
Before talking about contracts, I want to explain what I mean when I say “Agile” and I want to talk about professionalism. Contracts are only meaningful in the context of
a business relationship, so I ﬁrst want to talk about what those relationships look like.

1. Agile
image source
* It would take a couple days to explain Agile properly, so unfortunately I don’t have time to explain the details of Agile practices, but it’s important that I explain the
beliefs and values that motivate these practices.

* In 2001, a group of 17 very experienced software developers got together and came up with the Agile Manifesto. They had spent their careers struggling with the all
too common pattern in software projects: they would be late, go over budget, quality would suﬀer as people rushed to meet big deadlines, and customers and
developers would end up frustrated.

* One of the key problems they saw were big plans that were inﬂexible, which meant opportunities were missed for feedback, learning, and adapting to change.

* Another key problem they saw was a lack of a strong partnership with customers. Energy went into contract negotiation and lengthy documentation instead of working
together to get things done.

Plans vs. experiments
image source
* With a traditional FPFS contract, you’re taking the approach shown on the left: that with enough detailed planning you can correctly understand and estimate all the
specifics of a project, and deliver it on time and on budget.

* With software projects this is hard, because every project is different, and experience has shown that there are always unknowns that you will encounter, no matter
how much you plan, and the fast pace of business often requires changes to the plan.

* We know this, so we deliberately overestimate, to cover the unknowns. We can’t overestimate by too much, because we don’t want to lose the bid, and we don’t want
to overestimate by too little, because we want to actually make some money.

* As the project progresses, you can end up at odds with your customer:

* The work often takes longer than you thought, even beyond your padded estimate, which tempts you to rush and cut corners

* The customer may come up with new business requirements, which threaten the plan

* With an Agile approach, a project is instead seen more as a series of small experiments, which both you and the customer learn from, and you use that learning to
constantly refine your ideas for what to do next.

* Change is welcome, as opposed to being a source of contention.

Incremental & iterative development
image source
* An Agile development approach focuses on developing in small incremental steps, through repeated, iterative cycles.

* The idea is to focus on developing one feature at time, starting with the features that have the most business value. With each feature, you start with the simplest thing
that could possibly work, get feedback, and continue reﬁning until it is good enough.

* [NBC image carousel example]

2. Professionalism
* The question is, how do you successfully negotiate a contract that will support this open-ended Agile approach?

* Before I can answer that, I need to ﬁrst talk about professionalism: 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 staﬀ, to get them to a Japanese level of quality service

image source
Go to a department store when it ﬁrst 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 eﬀort 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 selﬂess 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 diﬀerent cultural context.

お持て成し
Omotenashi
* Omotenashi has two diﬀerent literal translations: “single-hearted” and “achieve.” It’s the combination of these meanings that deﬁnes 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.

* 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 ramiﬁcations 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.

image source
[gift wrapping story]

“We want a blog”
So what does any of this have to do with working with clients on web projects?

[client with blog idea story]

“Don’t do it that way,
do it this way”
[client project for modeling energy eﬃciency]

“Our new web site is awful…
but we don’t want to change it”
[prospective client with a terrible new site from another vendor]

3. Omotenashi and contracts
A traditional ﬁxed scope, ﬁxed 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.

“If you go to the store with a huge shopping list and twenty
dollars, you need the authority to go to the money machine
for more cash, or the authority to make changes to the list.”
Ron Jeffries, Making the Date
What’s happening is that the client is trying to retain authority on the project while giving you the responsibility. But ultimately, for the project to be successful and for both
you and the client to be happy, responsibility and authority need to be brought into alignment.

“I find your lack of faith disturbing”
Copyright Lucasﬁlm Ltd
If you don’t, 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 iterations 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 they spell out what will be delivered, when, and for how much. At ﬁrst 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

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

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

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 6 months, and the contract is
terminated at 4 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 oﬀshore 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 aﬀect 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

* PromptWorks has signed over 30 time and materials contracts in the 2 years they’ve been in business. AT PYD, we’re just starting, but we’ve signed 3 so far in our first
2 months 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 a 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 insuﬃcient

How do I know we’ll stay on budget?
How do I know we’ll stay on schedule?
These are trust and conﬁdence 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 ﬁrst. Your budget will go to the most important aspects ﬁrst.

* We’ll actually want to go live before your launch date, with test users

…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

* [tell story behind this email]

Master Services Agreement (MSA)
❖ Services
❖ Term
❖ Cooperation
❖ Payment: Expenses
❖ Changes
❖ Warranties
❖ Conﬁdentiality
❖ 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

WordCamp Boston 2015: Agile Contracts for WordPress Consultants

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-
speciﬁed 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.

WordCamp Boston 2015: Agile Contracts for WordPress Consultants

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to WordCamp Boston 2015: Agile Contracts for WordPress Consultants (20)

More from mtoppa (18)

Recently uploaded (20)

WordCamp Boston 2015: Agile Contracts for WordPress Consultants