WordCamp Nashville May 16, 2015

Agile Contracts for WordPress Consultants

Michael ToppaCo-founder, CTOPoka Yoke Designswww.pokayoke.co@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. * I’ve been involved with WordPress since I developed my first plugin inn 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.

I’m here today representing two companies. The first is PromptWorks, where I work currently. We’re a 15 person consultancy in Philadelphia. We do a lot of work in Ruby, Rails, Python, JavaScript, and infrastructure automation. We’ve signed over 30 time and materials contracts over the past 2 years, and most of this talk is based on that experience.

ポカヨケ

www.pokayoke.co

My wife has a new job in Boston, so we’re moving, and I’ll be starting a new job too. I’ll be co-founder and CTO of Poka Yoke Design, and I’m looking forward to working more with WordPress again. My partner is based in Memphis, so I’m very pleased to be strengthening my ties to the WordPress community here in Tennessee.

Disclaimer #1

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 specific language for use in your contracts

Disclaimer #2

I see WordPress as a web application development framework

* The WordPress community is big and vibrant, and an unfortunate consequence is we tend to talk only to each other. There’s a lot we can learn from people using other technologies and platforms.

* As my mother says to me, “you think you’re special, you’re not so special”* WordPress isn’t a full stack framework in the conventional sense, but for many purposes it’s competitive with other frameworks, and for CMS projects, it’s hard to beat* There’s no particular reason why your approach to negotiating a contract for a WordPress project should be different than a project using a different platform.

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 professionalism. Contracts are only meaningful in the context of a business relationship, so I first 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 suffer 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 inflexible, 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 refining until it is good enough.

Frequent delivery of working software

image source

* The product backlog contains a prioritized, high level breakdown of the project, but not in great detail* When it’s time to take new work from the top of the backlog, the details are worked out, and we estimate how much we’ll get done in the next sprint* standup…* demo…* retrospective…* feedback is ket

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 first 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 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. * 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]

3. 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 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 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 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 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

* [tell story behind this email]

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?