120521 agile contracts 2.1

2012 – more presentations at slideshare.net/proyectalis

Agile Contracts

Madrid, March 2012



Ángel [email protected]

@angel_m

www.presionblogosferica.com www.proyectalis.com/en/blog

www.linkedin.com/in/angelm www.slideshare.net/proyectalis








World Agile Conference




My Pleasure!




Enough for a start…




Agile


Values

Principles

Processes

Roles

Tools

Artifacts

Practices


Agile101 Estimate

Ouch!

Estimate

Replan R1.0 ¿R2.0?

BV

t

R1.0 ¿R2.0?


Agile101 Estimate

Ouch!

Estimate

Replan R1.0 ¿R2.0?

BV

t

R1.0 ¿R2.0?

- Self-organized, motivated team - Sustainable pace - Daily collaboration with customer and business people - Face to face communication - Seeking technical excellence - Constant reflection on how to improve and remove waste


Agile101 Estimate

Ouch!

Estimate

Replan R1.0 ¿R2.0?

BV

t

R1.0 ¿R2.0?

- Self-organized, motivated team - Sustainable pace - Daily collaboration with customer and business people - Face to face communication - Seeking technical excellence - Constant reflection on how to improve and remove waste


The Contract Concept


Earn as much as you can

X X X X = -10 -10 -10 -10 X X X Y = +10 +10 +10 -30 X X Y Y = +20 +20 -20 -20 X Y Y Y = +30 -10 -10 -10 Y Y Y Y = +10 +10 +10 +10



Stupidity Quadrant (Carlo Maria Cipolla)


Western vision of contracts


The problem…


Litigation

He said… She said…

The system is not working The client changed his mind

We can’t use it Users are not trained

You should have warned us You did not listen to us

The system is buggy Data was corrput

You gave us no advice You took bad decissions

Under-qualified developers Inadequate interlocutors

Bad development process Non-involved customer

The system did not work in field Client did not adapt his processes

You were late Changes were added


Eastern Vision of Contracts:





Software Contracts


Contract

Good, beautiful, cheap… Choose any two of them!

?

Time Scope

Resources


From a REAL CONTRACT Communitites

The communities section is a new space on the Web where collaborative work environments will be set for the different communities defined by the organization.

Content management roles must be defined for each community so they can manage, update and energize the Web space

Each of these spaces must provide tools that make all the usual social network practices possible, including collaborative tools, knowledge management, etc. In this sense, the communities section can include blogs, forums, document management systems, task management systems, etc.

It will be possible to create as many communities as needed, all of them similar except for the customization of look and feel through colors and logos.


Doubts! Communities

Are these spaces shared? Who uses them? Which roles exists other than manager? What’s the meaning of “managing” or “updating”? Does it include, for instance,

software updates and data backup? Which are those “usual practices on social networks”? What do you understand for

“knowledge management”? And “document management”? What does “etcetera” include?

“Can” include means that they are optional? Is there any restriction on the size or kind of documents to be managed? Is everyone

allowed to upload documents? Is there any kind of search engine to be included in the system? What’s the actual functionality of the forum? Includes avatars? Icons? HTML

embedding? RSS feeding? Can you create sub-forums? What’s a task manager? Does it include some kind of calendar? Alarms? Filtering

tasks? Search? Project Management? Are communities created automatically or by hand? Are the logos and colours the

same in all community views? How are communities indexed or organized? How are they linked or referred from the rest of the web?

…



Complexity R

equi

rem

ents

Technology





Uncertainty


Uncertainty cone


Accuracy vs. Effort Accuracy

Estimation effort


ENOUGH

50-70% accuracy

100% accurate

Accuracy vs. Effort Accuracy

Estimation effort


Traditional Approach vs. Agile

Fix:

Estimate:

Scope

Scope

Cost Time

Cost Time

Plan Oriented

Value Oriented


Project Buffers

Buffer

80% project done

60% buffer used

Min T Max T


Hofstadter’s law: "It always takes longer than you expect, even when you take into account Hofstadter's Law.”


Change is the only constant. Uncertainty is the only certainty

Uncertainty, complexity…


Changes in software projects


Berard’s Law - “Walking on water and developing software from a specification are easy if both are frozen..”


Humprey’s Law: User won’t know what he wants

until the system is live








Ziv’s law: requirements will never be completely understood


Ziv’s law: requirements will never be completely understood Wegner’s lemma: an interactive system can never be fully specified nor

can it ever be fully tested


Ziv’s law: requirements will never be completely understood Wegner’s lemma: an interactive system can never be fully specified nor

can it ever be fully tested Langdon’s lemma: software evolves more rapidly as it approaches

chaotic regions


Medinilla’s law for Software Contracts: 40 thousand lines of code won’t fit into a 20 page contract



@ Jeff Patton - www.agileproductdesign.com/

Iterative vs. Incremental


Walking Skeleton


Agile Contract


Agile Contract


Agile Contract


?

Agile Contract


Agile Contract


MVP / MMFS

Agile Contract


Agile Contract

MVP / MMFS


Agile Contract

MVP / MMFS

Scope Creep


Agile Contract

MVP / MMFS

Scope Creep


Agile Contract

MVP / MMFS

Scope Creep


Iterative and Incremental Contract Reduces risk: there’s ALWAYS some working software you can

use More freedom to client: he decides when to release something

or stop the project Provides frequent feedback from client and users Provides real information on project progress Delay is less critical


So… “The best way to achieve predictable software development outcomes is to start early, learn constantly, commit late, and deliver fast. This may seem to cut against the grain of conventional project management practice, which is supposed to give more managed, predictable results. But predictability is a funny thing; you cannot build with confidence on a shifting foundation. The problem with conventional approaches is that they assume the foundation is firm; they have little tolerance for change.”

Mary Poppendieck – ‘The predictability Paradox’


Contract Models


Model 1: Fixed everything


Fixed everyting Breaks every discussed principle All risk for supplier No incentives for client to accept the

product early Assumes you can perfectly define the

system to be built A lot of time and resources spent on

RFP / RFQ RFP / RFQ seldom includes

tolerances, buffers or measure of uncertainty – estimates are given by client in form of delivery dates

Favours the “optimistic” (desperate?) supplier – creates the game of…



Fixed everyting Does not provide the lower costs

(competent suppliers will include buffers in their quotations)

A lot of excess functionality (YAGNI) will be added to the requirements “just in case”, as contracts seldom include a change / add mechanism

If everything goes right, client will pay more for software

If everything goes wrong, supplier will drop quality in order to meet deadlines


What the eye can’t see…

Nobody is in this business to lose money (at least, not for much time)

“Big” firms accept these contracts all the time

Ergo big companies are earning money with these contracts

How?


Options:

a)

b)

c)


Options:

a)

b)

c)


Options:

a)

b)

c)


Win-Win?


Variant 1.1 : fixed everyting + collaboration

“Good faith”: original scope subject to negotiation

Will work on most important items first, and if we can make them all we can drop items or extend the contract

Problem: too fuzzy Problem: the frog and the scorpion


1.2: progressive fixed everything (“UCR3”, “VC”)

Unified Commitment – Rule of 3rds, Venture Capital

Divide project into 3 or 4 parts Execute the first as Fixed Everything to

produce an MVP / MMFS (no additional or low priority features)

Obtains real hands-on information about the system and its usage

Lets the client redefine the next phases depending on the results

If the supplier under-delivers, you can cancel the project and cut your loses soon


1.3: Competitive Sprint ( a“Lean Approach”)

Toyota’s concurrent approach UCR3, but we hire several

suppliers at the same time for phase 1

We select one of the suppliers depending on their deliveries, but as we are paying all of them, we can incorporate everything we learn from the other suppliers to the final contractor’s solution


1.4: Inception A.K.A. “Sprint zero” or consulting contract Contracting supplier for a week or two to build the product backlog Then, supplier can give better estimates of how much and when Can include a first sprint of development or two: supplier will also be

able to demonstrate velocity and delivery


1.4: Inception

-- Uncertainty


…..

1.4: Inception


…..

1.4: Inception


…..

1.4: Inception


…..

1.4: Inception


Histogram


Histogram Average


Histograma

95% SLA

80% SLA

Average


Different kinds of projects

T-Shirt sizes and different histograms: XS – 3 days S – 40 days M – 90 days L – 150 days XL – 220 days


1.5: Money for nothing, change for free

Xebia + Sutherland Money for nothing: client can call the project “done” any time,

paying the supplier 20% of the cancelled scope (client saves 80% if he finds current functionality enough, supplier wins 20% for doing nothing)



But I don’t want to abort the contract!



But I don’t want to abort the contract!



Change for free: any feature can be exchanged for another of similar size (exchange instead of change)



Rule: I cut the pie, you choose the piece you want


4.6 Change Control Both parties recognize that there will be change to scope throughout this project. Change will be accommodated provided that the total Story Points do not exceed the total amount stated in Section 5. No changes shall be made to Stories being delivered in the current Sprint, Stories already delivered but not yet accepted and Stories accepted. Any changes, which impact user stories, which have already been delivered, will usually require additional rework and will be considered as new Stories. Changes to the requirements defined by the Stories and Story Tests listed in the Annex A of this SOW or otherwise affecting the scope (in terms of total Story Points to be delivered) of the “Project” must be approved following the Change Request Process set forth below.

4.7 Change Request Process The standard change control for this project will be as follows. The only decision makers required here are the Exigen Services SCRUM Master and “Client” Project Manager. Once a change is accepted the following steps will occur: For each change that Exigen Services and “Client” agree to define as a new story the definition of the story is to be completed by the “Client” Product Owner. Analysis of the change by the Exigen Services will take place during the next planned Sprint Planning session. This analysis will define the story point cost of the new story. If the change applies to an already implemented story then any rework required will be included in the story point cost of the new story.The “Client” Product Owner must attend this session The “Client” Product Owner must make the decision concerning the change. There are two possible options: Accept the change into the Product Backlog and decide which story (or stories) are to be removed or Reject the change. Finally, the “Client” Product Owner should prioritize the new story (if added) against the Product Backlog

http://coactivate.org/projects/agile-contracts/sample-fixed-price-agile-contract



Sutherland, Agile 2008 – “Agile Contracts”:

1/3 of organizations admit to be “too disfunctional” to use this approach: Not able to build a proper product

backlog Not able to prioritize features

according to their business value Not able to trust development

teams Supplier still suffer the cost of delay if

initial estimates are wrong or features are not well described / understood.




Time and materials

“From a client’s perspective, this is like a contractor saying he’s not sure how much of a house can be built for $100,000, but they’ll use five people for

three months, build one room at a time and see how far he can get.”

Bruce Eckfeldt and Rex Madden, “Selling Agile: target cost contracts”


Time and materials

Wrongly considered “the Agile contract” (“pendulum law” - all risk is for client now)

Could be cheaper to hire developers Does not give incentives to the

supplier to deliver and be efficient – be careful to include SLA’s!!

Invested time does not necessarily mean value delivered

It can go on for ever You need to trust your supplier a lot


2.1: hour stock/ maintennance contract

T&M with a ratio (i.e., “between 180 and 240 hours every month) during a given time (10 months) until you reach a total (2000).

It’s very important to set SLA’s (you don’t want your client to ask for 2.000 hours the last month of the contract)

Setting value SLA’s can be important (i.e., minimum and average velocity, measured as functional product delivered per every 100 hours)

Can include prioritization and wanted functionality (MOSCoW) based on min. V / max. V

M

O

S

C

W


2.1 Hour stock (+scope goal)

Min. V

Max. V

Sure we can do that

You gotta’ be kidding me!

We will probably end somewhere over here


2.2: Iterative and Incremental time and materials (“True Agile”)

Functional deliveries at the end of every sprint, cost per sprint

Excellent engineering that can incorporate changes in the future

Possibility of ending the project after any sprint, with or without cost (incentive for supplier)

Some risk sharing © Jeff Patton


Agile Contrac.ng -‐ ADP 2008 -‐ Chris Spagnuolo and Rachel Weston

Agile Contracting/Proposal

- In our agile approach, budget and time select the requirements that can be delivered. Our clients have the ultimate project control and may declare their satisfaction with the application as a whole at any time in the development process. Our clients can decide that although there is budget remaining, the delivery team has met their objectives and can call the project complete.

- On the flip side, although the total budget may be expended on a project, and all backlog items may not have been developed, our clients are guaranteed to have live, working functionality that is of the highest value to them due to the constant inspection and adaptation of the project backlog.


2.3: price per Story Point Incentivizes the delivery of

working software as soon as possible

Changes are welcome as long as you pay for them

Problem: may need an external, neutral party (what’s a Story Point?)

Problem: it can produce unwanted software just to cash in points


2.4: Points + hours

Robert C. Martin (Uncle Bob) Fixed scope / variable time Calculate points and velocity Calculates the project cost Reduce the hour cost and put the

rest as point cost If there’s excess of hours, we can

slightly rise prices If we do it in less time, we get a

slight bonus (incentive)


2.4: Points + hours

1000 points, 100 points a week (10 weeks) with a team of 5 (5x40x10=2000 hours). 40€/h 80.000€ Charge 10€/h and 60€ per point (2000x10+1000x60 = 80.000)

If you take 12 weeks, project cost will be 1000x60 + 2400x10 = 84.000

If you do it in 8 weeks, 1000x60 + 1600x10 = 76.000


2.5: IDIQ

Indefinite Delivery / Indefinite Quantity We want at least 1000 story points We want deliveries to be between 4

weeks and 6 months We will always give notice with 4

weeks that we want some delivery It’s essentially T&M, but with some

estimates on demand and terms


Modelo 3: Agile

Compromise


“Agile Compromise”

Many names and approaches (“target cost”, “not to exceed/fixed fee”,”shared profit”, “Lean Approach”…)

As always, what’s important is principles, not the specific set of tools



Progressive (iterative and incremental)

Shared risk, shared profits, incentives to win-win behavior

Assumes positive intention and client-supplier collaboration (Agile)

Limits the chance of opportunistic behavior



Scope is fixed at high level There’s a target cost / time and certain margin / buffer for

uncertainty A mechanism is needed so supplier nor client abuse that

margin

Fixed Everything Time & Materials Shared Risk

I don’t trust the supplier I trust the supplier


“Agile compromise”

“Target time” for a prioritized backlog, aggresive minimun and maximum time (“double worst case scenario”)

Under the minimum, supplier wins. Over the maximum, supplier loses…

BUT… in the middle, we share costs or profits 50/50 Incentivizes both client AND supplier to end as soon as

possible

Min Max Target

We share profits We share costs


Possible Mechanic: Define stories with your client Estimate in points or days = Min t Add some buffer (10% for known

clients, 30% “hostile” clients) = Target t

Add your profit = Max t (if you last more than that, you lose money)

If I last more than Target, I earn less than expected

If I last less than Target, I earn more than expected


Possible Mechanic: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Profit= 20% (12) Max t = 72 days

Bad estimates: you need 58 development days = 64 to deliver = +4 over target. We assume half (2 free days) and client drops de bottom 2 days of the backlog. Our profit drops from 12 days to 10.


Possible mechanic: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Profit= 20% (12) Max t = 72 days

Good practice: we manage to build it in 44 days = deliver in 50 days = -10 under target. We share the whole buffer (6 days / 2 = 3 days) and even earn 4 additional days (under min), so we earn 7 days more than expected and client adds 3 free dyas worth of development to the backlog (his half of the buffer)


Possible Mechanic: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Profit= 20% (12) Max t = 72 days

Catastrophe: we need +24 days = we deliver in 78 days =( +12 over target +6 over max). The 6 over max are totally assumed by supplier. The 12 over target are shared, 6 for supplier and 6 are drop from clients’s backlog. Supplier is assuming +12 days and develops at costs, without any profit.


Another example: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Cost/day: 100S$ Target cost = 6KS$ Profit(25%) = 1.5K$ Budget= 7.5KS$

Bad estimates : We need 58 development days = deliver in 64 = +4 over target. As there is no maximum defined, client and supplier might have agreed that they would share costs, so client removes 2 days and we assume 2 days. Final cost =6.2KS$, profit = 1,3KS$. Client loses some features, supplier loses some profit.


Another example: Good practice: we only need 44 dev. days =

deliver in 50 = -10 under target. We share buffer. Supplier earns 7 days (4 under min + 3 buffer) and client adds 3 free development days. Final cost: 5KS$, profit 2.5KS$ - and client is receiving extra features.

Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Cost/day: 100S$ Target cost = 6KS$ Profit(25%) = 1.5K$ Budget= 7.5KS$


Yet another:

‘Joe’s bucket’ (Thoughtworks): buffer for client and provider – each manages the part he is more able to Client buffer is for additional scope Supplier buffer is for re-estimations and unidentified

tasks

Target Scope Client’s buffer Supplier’s buffer


Joe’s bucket:

Target Scope Client Buffer Supplier Buffer

Dev Days = 48 Plan Days = 6 Min t = 54 days Min cost = 5.4KS$

10% scope creep

48*0,1 ≈ 5 days

Cost= 0,5KS$

10% uncertainty

48*0,1 ≈ 5 days

Cost=0,5KS$

GLOBAL BUDGET = 6.4KS$


Joe’s bucket:

Target Scope Client buffer Supplier buffer

Dev Days = 48 Plan Days = 6 Cost = 5.4KS$

4 days of unpredicted scope added

Cost= 0,4KS$

4 days worth of re-estimations and rework

Cost= 0,4KS$

0.1KS$ client (deducted from price)

0.1KS$ supplier (adds to price as Profit)

FINAL PRICE= 6.3KS$ (-0,1KS$)


Joe’s Bucket:

Alcance objetivo Buffer cliente Buffer Proveedor

Dev Days = 48 Plan Days = 6 Cost= 5.4KS$

No added scope or changes

Cost= 0

8 days of delay Cost= 0,8KS$

0.5KS$ client (deducted)

0.5K$ added to price as costs

-0.3KS$ payed by supplier (loses)

FINAL PRICE= 5.9KS$ (-0,5KS$)


Joe’s Bucket:

Alcance objetivo Buffer cliente Buffer Proveedor

Dev Days = 48 Plan Days = 6 Cost = 5.4KS$

5 days of added scope

Cost= 0,5kS$

0 days of delay Cost = 0

0.5KS$ extra profit

FINAL PRICE = 6.4KS$ (-0,0KS$)


Summary


Still no silver bullets…


“Fixed” projects

More risk to supplier – worse on the long term

Use buffers for some uncertainty Do progressive development / contracting “Inception” - collaboration Have mechanisms deal with and trace

changes Incentivize the early delivery and

acceptance of the project


“Variable” projects More risk to client Limit risks by limiting scope or budget Periodic and frequent deliveries – define “done, done” Business value based prioritization Incentivize deliveries of value Use SLA’s and target velocity


Agile Approach

Share risks and benefits Inception – Joint Backlog

Development High level definition of Scope Target Scope / Time / Budget Collaboration Incentivize deliveries and early

finishing of the project


Challenges


Client Collaboration Joint Application Development (JAD), daily collaboration Meetings High level definition of scope / stories, including acceptance criteria Accepting deliveries (can block advance!) Client process can be an obstacle (“gantt charts, task lists and man-

hours”)


Team Communication with client Iterative and Incremental development Accept uncertainty – embrace change! Reject non-approved changes (in some kind of contracts)


Sales Force

Make the team participate in proposals Develop Agile proposals Sell Agile Be careful with some Agile term (“fail

fast”, “variable scope”, “uncertainty”, “changes”…)

Don’t sell “Silver Bullets”


To convince…

Try some Sprints Success stories: burn-downs, metrics,

comments of other clients… Examples of companies using Agile

(specially industry leaders, clients and competitors)

Follow the pain: What’s not working right now? How Agile solves that?

Share some retrospectives with your client Offer Ágile metrics and tools (dashboards,

access to source repository or continuous integration servers…)




Jeff Sutherland, Agile 2008


Worst case… We can’t do it It sound good in theory, but it is not

realistic My client won’t allow me My supplier won’t allow me My company won’t allow me My boss My peers won’t allow me My mommy won’t allow me…


Worst case…

Use a buffer according to your historical average uncertainty

Do more generalistic scope documents Do iterative and incremental development -

Prioritize your project plan according to business value

Do follow-up meetings every two weeks and show working software to your client

Watch closely for changes (Money for nothing / change for free)

Report daily to your clients (excel or simillar) Gradually introduce other practices (CI,

TDD, retrospectives…)


Last Advice:

Stop complaining about fixed-price, fixed-scope, fixed-time contracts. Implement Scrum, double your performance, accept the contract at industry-average price and get rich by keeping the difference

Jeff Sutherland (or wasn’t him??)


Be Agile, My Friend…


Debate and questions

[email protected]


Thank you!

[email protected]


This presentation is based upon the ideas and work of many people. And while I’ve tried to recognize copyrights and give credit and attribution where possible, I cannot possibly list them all, so if you feel like there’s something that should be added, changed or removed from this presentation, please drop me an e-mail at [email protected]

http://creativecommons.org/licenses/by-nc-nd/3.0/

Date post:	17-May-2015
Category:	Business
Upload:	proyectalis
View:	2,235 times
Download:	6 times