You’re ready to go with all the best Agile practices: you’ll develop incrementally and iteratively, you’ll have sprints and retrospectives, and you can’t wait to tell your clients about your velocity and show them your burndown charts. But all of your prospective clients are telling you they want firm quotes, and contracts with detailed specifications and delivery dates. Clients almost always start with a preference for these types of traditional Fixed Price, Fixed Scope contracts. Such contracts provide them with a sense of security and confidence that they will get what they want.
How do you convince them a traditional contract is actually riskier than they think, and persuade them to instead sign a contract that facilities Agile development? This is the most significant challenge facing consultants who want to follow Agile practices. At PromptWorks we use Time & Materials contracts with our clients. In this talk we’ll discuss:
* What different types of contracts imply about the nature of the relationship with your client, and what it means for it to be a professional relationship of equals. Risk and reward should be shared, and the relationship should feel like a partnership.
* The persuasion and negotiation process for getting your prospective clients to sign a Time & Materials contract. We’ll discuss real-life situations from our experience at PromptWorks.
* PromptWorks' typical project proposal, Master Service Agreement, and Scope of Work documents. We'll highlight key aspects of our approach, and things to look out for if you work with contract documents provided by your client.
Philly ETE 2015: Agile Contracts for Software Consultants
1. Philly ETE April 8, 2015
Agile Contracts for
Software Consultants
Michael Toppa
@mtoppa
2. 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.
3. 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
4. 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.
5. 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
6. 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.
7. 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.”
8. “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
9. 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.
10. “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.
11. image source
It's typical to see a Japanese worker perform the lowliest job as if it were the best. [cashier story]
12. 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.
13. 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.
14. 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.
15. お持て成し
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…
16. 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.
19. “We want a blog”
[client with blog idea story]
20. “Don’t do it that way,
do it this way”
[client project for modeling energy efficiency]
21. Omotenashi and contracts
A traditional fixed scope, fixed price contract typically implies a typical Western style hierarchical relationship with your client.
22. 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.
23. “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.
24. 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.
25. 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.
26. 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.
27. 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
28. Assumptions of FPFS contracts
Limited feedback
Feedback is only possible late in the project, and cannot play a large role in shaping deliverables
29. 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.
30. 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.
31. These assumptions are invalid in an
Agile project!
The Agile approach instead assumes a highly variable, research and development process.
32. 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.
33. 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.
34. 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.
35. 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
36. 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
37. 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
38. 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.
39. 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
41. 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
42. 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
45. * 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
46. 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
47. 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
50. 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.
