training your customer...obstacles to getting agile accepted and running • help the po in removing...

1

Training Your Customer

Petri Heiramo

Agile Coach, CST

Saturday, March 20, 2010

2

We Are Looking at…

• How our customers can benefit from Agile

• How we can get customers understand Agility and its benefits

• How can we help them to be the PO’s they are supposed to be


3

Petri Heiramo

• Age: 38 today

• Own training and coaching company, Agilecraft Ltd, for about a month

• Almost 10 years career in SW development and process improvement at Digia

• Primary focus on processes and projectmanagement

• 6 years as process improvement manager• Agility and Scrum as main focus since

Fall 2005

Outside work– Home in Kotka

– Family – wife and little

daughter– Hobbies – games of

different kinds, if I

just have time


6

BENEFITS TO CUSTOMER


7

Key Benefits

• Better visibility on the reality of things• Knowing where you are is the first step to intelligent

response

• Better and continuous control on priorities, value and risks

• Faster feedback on new ideas

• Better control over their investments


8

Aspects of Agile We Can ”Sell”

• Better visibility through concrete frequent deliveries

• Better fit-for-use through fast feedback

• Flexibility in requirements, and faster response times to changes

• Also elimination of unnecessary features

• Peace of mind

• Earlier start, faster releases


9

Aspects ”Not Safe to Sell”

• Cost savings• When cost savings are the goal, the money is typically saved from the wrong place –

the beginning instead of end

• Higher quality• While true if you do Agile right, this might imply that you don’t do good quality now

• ”Agile is easy” – it isn’t

• Something you can’t deliver, e.g. error free code

• Agile practices if you don’t do them, e.g. TDD

• ”Scrum solves your problems”• It doesn’t, it merely exposes them


10

GE!ING CUSTOMER TO UNDERSTAND


11

1) Arrange Some Training

• Most customers are used to old way of buying• Hard to buy any other way

• Offer some free training or coaching• E.g. 2-3h introduction session

• Give basic understanding of what Agile is and what it isn’t

• Some training done before sale, some inclusive in the

project


12

1) Things I’ve Done

• Different sets for different occasions• 45 min What Agile Is About sessions• 2-3h introductory Agile sessions• 1d PO trainings

• Things I typically emphasize• Importance of vision as guide• Customer’s central role and benefits• Control mechanisms in empirical process control• Golf as iterative planning metaphor (next slide)• The importance of quality right from beginning


©Used with permission

Golf Metaphor

?



Golf Metaphor



Predictable Manufacturing New Product DevelopmentIt is possible to first complete specifications, and then build.

Rarely possible to create up-front unchanging and detailed specs.

Near the start, one can reliably estimate effort and cost.

Near the beginning, it is not possible. As empirical data emerge, it becomes increasingly possible to plan and estimate.

It is possible to identify, define, schedule, and order all the detailed activities.

Near the beginning, it is not possible. Adaptive steps driven by build-feedback cycles are required.

Adaptation to unpredictable change is not the norm, and change-rates are relatively low.

Creative adaptation to unpredictable change is the norm. Change rates are high.

Explaining “Two Process Worlds”












E.g. software engineeringE.g. phone manufacturing

Definedprocess

Empirical

process












E.g. software engineeringE.g. phone manufacturing

Definedprocess

Empirical

processWaterfall

Study – Plan – Act

Iterative

Try – Observe – Adjust

Waterfall model is fundamentally not suitable for software development



Complexity and Causality

Peopleadd another level of complexity

Requ

irem

ents

TechnologySource: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.





Requ

irem

ents


Water-fa"

Agile





Requ

irem

ents


Unknown, but

knowable linear

causality

Known linear

causality

Retrospective coherence

(Most SW Dev is here)

No known causality


17

2) Help Customer Feel Safe

• No amount of coaching will help if the customer

doesn’t feel safe

• Customers are most often afraid of…• Being forced to pay more then they budgeted

• Not getting what they wanted

• In that environment, ”We’re using Agile, we can’t

provide estimates” will lose you the case


18


• Create confidence that customer can get what they want for the money they intend to spend

• Do some story writing with the team to understand project scope and priorities

• If the customer can participate in this, great

• Try to estimate reasonable cost & schedule• If all else fails, do some traditional planning and estimating,

and use those estimates as a base for commitment• That doesn’t mean you have to do the project the old way

• Negotiate target price contract that you can commit to


19

3) Help Create Vision

• Steer the discussion away from specific feature details• And into what the customer seeks to achieve

• Business goals• Key functionality at high level• Whose job is improved as a result

• Discuss and identify key constraints• Time, cost, available people, technology, …

• Formulate into simple release plan

• Requires that the customer can be ”lured” into this• Typically not possible in public tenders


20


• I haven’t actually used this one !

• But I do see it as one option I could use to drive a contract between customer and provider


21

4) In Public Tendering

• If the request isn’t Agile, you can’t sell Agile

• You can sell ”Waterfall”, but made using Agile practices• Provide enough paper (based on real implementation) to pass

acceptance gates• Plan as you normally would in Agile, but publish ”Waterfallified”

docs to customer• After all, doing some implementation work is equivalent to doing a

prototype, isn’t it? !

• Contractual constraints reduce customer’s ability to make changes, but that’s their problem

• Traditional change control is needed


22


• Never done this, either, always been able to convince the customer to actually accept Agile

• Maybe I haven’t just had the hardest cases


23

5) Don’t Hype

• Customers are wary of hype• There have been fads before, and they have faded

• Agile isn’t hype or a fad• It’s a process control framework for complex environments• It has always existed

• Agile doesn’t work everywhere• Don’t make it sound like a silver bullet• When asked, be forthright where it doesn’t work, e.g.

• Traditional engineering (for most part)• Organizations which don’t ”accept” Agile thinking• Very simple projects (ok, it works, but these are simple enough to be done with any

methodology)


24

HELPING THE CUSTOMER TO BE A G#D PO


25

1) Train More

• Provide more training, if you already didn’t do so in sales phase

• Some training can be sold as part of the project, so it doesn’t have to be free

• Study and develop skills & materials to do the training

• Should be ”standard SM stuff”


26

2) Make Things Easy

• It’s SM’s job to guide the PO through the process

• Tell what the PO should do (but not what decisions to make)

• Facilitate workshops for the PO

• Help PO to carry out his/her responsibilities

• Never assume PO responsibility!• Always emphasize that the PO is ultimately responsible for

business decision


27

3) Facilitate Backlog Management, Don’t Manage It

• Always keep in mind that the PO owns the product backlog• Even if there’s contractual restrictions to changing content• With fixed scope, it is usually possible to reprioritize

• Facilitate story writing workshops for PO• Also facilitate feedback gathering during iterations

• Facilitate grooming sessions with team and PO

• Suggest useful process issues, such as• Useful Product Backlog format (Excel, tool, cards, etc.)• Useful Product Backlog ”columns” (risk, value, release, etc.)• Tool choices• Useful scope for more detailed refinement


28

4) Help in Release Planning

• Most PO’s don’t know how to create meaningful release plans

• Facilitate workshops or other activities to create and maintain a release plan

• Remind, as necessary, to review iteration level progress against release plan

• Have the PO reprioritise or rescope, if release plan objectives cannot otherwise be met


29

5) Ensure Communication to PO

• Make sure that the PO has good information available about, e.g.

• Development velocity• Technical dependencies and risks• Technical debt

• Don’t tell them yourself (if you’re SM), have the team tell them

• Create trust and rapport between PO and team

• Big visible charts or dashboards


30

6) Help Removing Obstacles

• In most customer organizations, there are many obstacles to getting Agile accepted and running

• Help the PO in removing these, e.g.• Volunteer to do awareness events or training at customer

site• Collaboratively act to influence key individuals• Help find metrics or reports that ”prove” Agile is working• Make the PO look good in the organization’s metrics


31

7) Challenge the PO

• Continually challenge the PO to think PO stuff• What is value? Has it changed over time? Are we still headed for the

right goal?• Are there ideas that should be added to Backlog?• Are there items that could be dropped or done in simpler form?• How can we get better and faster feedback from stakeholder and

users?

• Make this in positive way• Genuinely seek higher business value for the customer

• Suggest ideas, but always let the PO decide


32

SU$ARY


33

Customer Understanding

• You need to provide training• Customers can’t buy what they don’t understand

• Help them feel safe in choosing Agility• Provide confidence against key risks

• Help create vision - goals over specific functionality

• Don’t hype – this is real work to real goals

• Agile can be disguised as Waterfall• Customer doesn’t understand, but you can do Agile


34

Helping Customer to Be a Good PO

• Train more

• Make things easy

• Facilitate Backlog management, don’t manage it

• Help in release planning, focus on project goals

• Ensure PO gets enough information

• Help in removing obstacles, also in customer organization

• Challenge the PO


35

THANKS!

For more information:

[email protected]


training your customer...obstacles to getting agile accepted and running • help the po in removing...

Documents