Confidential

smart.proven.bankable.

Polish Agile Users Group

Agile Customer Collaboration

Jay Packlick

June 22, 2006

Confidential 2

In Agile we manage the plan using 3 Variables of project Control

Schedule

Product under development

Customer• When a compromises is necessary but not made…• We consciously or unconsciously introduce a fourth

variable of control• Treating quality as a variable of control is an example of

short term thinking (since it increases ‘true’ cycle time)

Resources

Scope

Quality

Confidential 3

Quality -What is it? IEEE definition: The degree to which a system, component or process is "measurably meeting customer expectations and conforming to requirements

Establishing the context

Confidential 4

Setting the Context

Agile -What is it?

Confidential 5

Two Paradigms

• Agile / Lean• Focus on intelligence, knowledge,

and discipline of front line workers

• Traditional methodologies• Focus on process and conformity to

process

Confidential 6

Two Paradigms

• Agile / Lean• Steering through continuous

planning, feedback and communications

• Traditional methodologies• Steering through detailed predictions

and documentation

Confidential 7

Two Paradigms

• Agile / Lean• Embraces change through

partnership and collaboration with customers (and other team members)

• Traditional methodologies• Attempts to minimizes change

through contract negotiations

Confidential 8

The Uncertainty Dynamic

• “If Las Vegas sounds too tame for you, software might be just the right gamble.”

– Steve McConnell, Rapid Development

Confidential 9

Capers Jones Requirements Change Study

Confidential 10

Agile goal: Thrive in the face of uncertainty

uncertainty

flexibilityChange

Random-ness

Confidential 11

Change Harnessing Model

flexibility

Frequentfeedback

Smallbatchsizes

ContinuousImprovementSimplicity

Values &Principles

driven

Decidelate

knowledge& creativityof peopleFrequent

Planning

Communi-cations

Confidential 12

Establishing the Context

But what is a Customer?

and why do we want them around?

Confidential 13

Confidential 14

•Written communications is inherently more wasteful than direct human connection

•When you encounter a problem, ask yourselves if the problem was caused by a failure in communication.

"Problems with projects can invariably be traced back to somebody not talking to somebody else about something important" –Kent Beck

Key agile value = Communication

Confidential 15

Some BIG question about customers…

• How do we get the customers to want to be involved?• Aren’t real customers too busy to waste time with developers?• Do I really want them in my hair?

• Won’t scope creep kill us? • Won’t they create chaos by changing their minds all the time?

• Do we really want them to see how the sausage is made? <<

Confidential 16

Mind reading doesn’t work

Some projects seem to rely on telepathy as the mechanism for communicating requirements from users to developers, despite considerable evidence that it doesn’t work.

Confidential 17

Requirements - The current state for many projects

It’s much worse for remote development team members who don’t have physical or timely access to subject matter experts (customers)

Confidential 18

The problem with control (at first)

Agile puts scope control in the hands of customers ( they’re usually not used to it! )

Confidential 19

Getting Customer Buy-in

• Interview them• Listen! Try to understand their perspective• Let them tell you what they don’t like about Agile (if anything)

• Educate them• The business case for the Agile model• Show how easy it is to track projects• How to write stories and acceptance criteria• How to participate in planning meetings• Agile planning and estimation• Roles & Responsibilities

• Publicize successes• Tour the open spaces and talk with proficient Agile developers

<<

Confidential 20

•Having a problem does not uniquely qualify you to solve it…• Customers don’t magically transform into business analysts

Don’t underestimate the skill side

Confidential 21

The Agile Customer – Some Common Problems

1. Failure to Identify one!It is often not clear who the Customer is for a project (multiple roles)

2. No clear roles and responsibilitiesThere is no consistent understanding of what the Customer role is

3. Skills• Customers often lack the skills and knowledge necessary

to execute their roles and responsibilities.• Expecting Customers to suddenly become Interaction

Designers / Business Analysts

4. AvailabilityIt can be difficult to get them to work with the team.

Confidential 22

Customer Team

So what’s needed? - Skilled Customer Team

Operations

Documentation

Marketing

Management

Analysts

Project Management

Testers

Customer Support

Sales

Developers

Competitors

Market Place

End Users

Media

Partners

Shareholders

Industry Groups

Stakeholder Community

ProgrammingTeam

On-siteCustomer

Confidential 23

But we still need a single strong voice!

• Agile values simplicity …

Customer TeamCompetitors

Market Place

End Users

Media

Partners

Shareholders

Industry Groups

Stakeholder Community

ProgrammingTeam

Operations

Documentation

Marketing

Management

Analysts

Project Management

Testers

Customer Support

Sales

Developers

ProxyFor the

rest

On-siteCustomer

On-site Customer is the voice of the community

Confidential 24

On-Site Proxy Customer Role

• Responsible for ensuring product meets the end user needs - fulfills the business goals of the organization.

• Represents the actual consumers of the software. Interacts with real users to understand their needs.

• Decides the order in which features are implemented in the software.

• Makes priority calls when there are conflicting deliverable goals.• Has authority to make decisions that ensure that features are

aligned with the end user’s needs• Customer team is more than one person but – proxy customer is

accountable for ensuring that the responsibilities for the role are successfully fulfilled. <<

Confidential 25

On-Site Proxy Customer Skills

• Understands the Agile Model!!!!• A domain expert - understands the business problem• Able to prioritize backlog – evaluate business value, effort, and

risks of each User Story• Able to communicate effectively with all project stakeholders.• Able to work collaboratively with the team. Uses “We” instead of

“You”. • Has the courage to change his or her mind to adjust priorities in

order to fit the facts. <<

Confidential 26

On-Site Proxy Customer Activities

• Defines and communicates business requirements – including acceptance criteria

• Collaborates with the development team to decompose features into User Stories

• Attends release planning sessions. • Decides release dates for the system• Collaborates with the team to prioritize back log

• Monitors projects status and story completion through team interactions, stand up meetings, and closing meetings.

• Communicates with all project stake holders• Adjusts priorities between iterations to reflect learning <<

Confidential 27

On-Site Proxy Customer Activities

• Attends stand up meetings to monitor the status of the project• Works in the open space (or able to answer questions in a timely

manner)• If unavailable to the team, has an empowered backup. • Demands and attends demos of the product at end of iteration.

Provides feedback. • Works with the real end customers to validate the system <<

Confidential

smart.proven.bankable.

Agile Contracts

Confidential 29

Primary Source for following

• Lean Software Development – an agile toolkit• Mary & Tom Poppendieck

Confidential 30

Agile Contracts

Goals• The ideal: Don’t lock down the full scope up front!

• Acknowledges the uncertainty dynamic• Structure the incentives to align with (rather than hinder) execution of

the agile model• Just-in-time decision making (i.e. acceptance criteria)• Scope adjustment • Incremental releases• Elevated role of quality

• Create a shared stake in the results• Localize responsibility for managing risk with the party best able to

manage the risk:• Uncertainty in business domain – with customer• Uncertainty in technical domain – with vendor <<

Confidential 31

Contract Models

• Non-agile model• Fixed Bid

• Agile Models• Time-and-Materials• Progressive• Target Cost• Multi-Stage

Confidential 32

Least Agile – Fixed Price Contracts

• Fundamentally an adversarial relationship (lose / lose)• Vendor bears project failure risk• Requires early definition of scope • Vendor tends to absorb cost of over-runs

• Customers lack incentive to manage scope• Customer has little incentive to accept the work as complete

• Customer tends to get what was specified – not what is needed• Early Scope Definition (to protect the vendor)• Low value features (pre-contract scope padding by customer)

supersede needed features detect after project start• Vendor is strongly motivated to resist changes to requirements

• Often costs the customer more (not less)• Uncertainty must be factored into the bid as a buffer• Inevitable change orders create unexpected costs for the customer• Higher operational costs – due to lower quality. Reduced quality

results when scope, schedule, and price are all fixed. <<

Confidential 33

Fixed Bid + Agile

• Run it as an agile project anyway!

• Requires some elements of waterfall• Capture written requirements up-front sufficient to create the bid• Decompose written requirements into Stories – use these as basis for

estimates• Get the customer to prioritize the stories (if possible) • Doing high value features first tends to increase trust – low value stories at

the end are easier to negotiate if estimate buffer exceeded.

• Regardless of contract structure (fixed bid, etc.) several elements can increase agility:• Create incentives for customers to participate in iteration testing /

demos periodically (ideally each iteration).• Create incentives for customers to iteratively contribute to and review

acceptance criteria periodically (ideally each iteration)• Where possible – get the customers on site <<

Confidential 34

Most Agile – Time and Materials

• Better than fixed bid when solving business problem is more important than price

• Customer bears risk of costs overruns• Vendor lacks incentive to manage technology costs• Vendor lacks incentive to finish the project• Increased risk of vendor gold plating

• Customer can better manage scope • can create tendency to micro-manage and over-control

• Increased tendency to get what is needed• Low value features tend to be postponed or canceled• Creates incentive to build higher value features first• Improved quality (since scope is the flexible variable) <<

Confidential 35

Target Cost Contracts

• Basically fixed-bid with overrun clause• When schedule (or total hours) exceeded - switches to hourly rate• Can be a stair step rate: cost, 90% cost, 80% cost, 70% cost, etc.

• Sometimes includes vendor bonus for early completion• Total cost – including changes – is the joint responsibility of the

customer and vendor. • Better distribution of risk / benefits

• if target cost exceeded, both parties will end up paying more• if total cost is under the target cost, both parties will share in the

benefits.• Much more of a partnership! • Variable of control becomes scope (consistent with agile model)

• Creates customer motivation to keep feature demands in check <<

Confidential 36

Multi-Stage Contract

• Trust based - the relationship will continue as long as expected value is delivered.

• Project broken in to a set of releases – (agile ‘fixed bid’)• Within terms of master contract – after each release options are

• Continue, re-negotiate, walk away• Deliver value with each increment in proportion to the money spent.• Much more aligned with agile:

• Learn as you go• Small releases• Scope adjusted each ‘iteration’ (release)• Deliver priority features first in fully working system

• Risk: Either party can walk away <<

Confidential 37

Progressive Contracts

• Structure• Start With An Umbrella or Framework Contract• Release Work In Stages• Keep Stages Small• Each Stage is an Iteration• Often Early Stages are Fixed Price• Scope Beyond the Existing Stage is Negotiable

• Incentives• Customer is at risk if supplier starts and doesn’t finish• Supplier is at risk of sudden cancellation• Risks mitigation: Trust increases as risk increases <<

Confidential 38

1/3 – 2/3’s Contract

• Estimate entire project (ballpark)• Divide the estimate into thirds

• Deliver workable system in first third of the time• Minimum functionality• No bells and whistles• Gives customer general idea of what is being done

• Customer can change the contract at that point <

Confidential 39

Contact

jay.packlick@sabre.com