Training Your Customer

Size: px

Start display at page:

Download "Training Your Customer"

Melanie Jefferson
5 years ago
Views:

1 Training Your Customer Petri Heiramo Agile Coach, CST 1

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 2

Petri Heiramo Age: 38 today Own training and coaching company, Agilecraft Ltd, for about a month 3 Almost 10 years career in SW development and process improvement at Digia Primary focus on processes

3 Petri Heiramo Age: 38 today Own training and coaching company, Agilecraft Ltd, for about a month 3 Almost 10 years career in SW development and process improvement at Digia Primary focus on processes and project management 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

4 BENEFITS TO CUSTOMER 6

5 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 7

6 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 8

7 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 9

8 GETTING CUSTOMER TO UNDERSTAND 10

9 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 11

10 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 12

11 Golf Metaphor? Used with permission

12 Golf Metaphor Used with permission

13 Golf Metaphor Used with permission

14 Golf Metaphor Used with permission

15 Explaining Two Process Worlds Predictable Manufacturing It is possible to first complete specifications, and then build. Near the start, one can reliably estimate effort and cost. It is possible to identify, define, schedule, and order all the detailed activities. Adaptation to unpredictable change is not the norm, and change-rates are relatively low. New Product Development Rarely possible to create up-front unchanging and detailed specs. Near the beginning, it is not possible. As empirical data emerge, it becomes increasingly possible to plan and estimate. Near the beginning, it is not possible. Adaptive steps driven by build-feedback cycles are required. Creative adaptation to unpredictable change is the norm. Change rates are high. Used with permission

16 Explaining Two Process Worlds Predictable Manufacturing It is possible to first complete specifications, and then build. Near the start, one can reliably estimate effort and cost. Defined It is possible process to identify, define, schedule, and order all the detailed activities. E.g. phone manufacturing Adaptation to unpredictable change is not the norm, and change-rates are relatively low. New Product Development Rarely possible to create up-front unchanging and detailed specs. Near the beginning, it is not possible. Empirical As empirical data emerge, it becomes increasingly possible to plan and estimate. Near the beginning, it is not process possible. Adaptive steps driven by build-feedback cycles are required. E.g. software engineering Creative adaptation to unpredictable change is the norm. Change rates are high. Used with permission

17 Explaining Two Process Worlds Predictable Manufacturing It is possible to first complete specifications, and then build. Near the start, one can reliably estimate effort and cost. Defined Waterfall It is possible process to identify, define, schedule, and order all the detailed activities. Study Plan Act E.g. phone manufacturing Adaptation to unpredictable change is not the norm, and change-rates are Waterfall relatively model is low. fundamentally not suitable for software development New Product Development Rarely possible to create up-front unchanging and detailed specs. Near the beginning, it is not possible. Empirical As empirical data emerge, it becomes increasingly possible to plan and estimate. Iterative Near the beginning, it is not process possible. Adaptive steps driven by build-feedback cycles are required. Try Observe Adjust E.g. software engineering Creative adaptation to unpredictable change is the norm. Change rates are high. Used with permission

18 Complexity and Causality Requirements People Technology add another level of complexity Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Used with permission

19 Complexity and Causality Requirements Agile Waterfall People Technology add another level of complexity Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Used with permission

20 Complexity and Causality Unknown, but knowable linear causality Known linear causality Requirements People Technology add another level of complexity No known causality Retrospective coherence (Most SW Dev is here) Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Used with permission

21 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 17

22 2) Things I ve Done 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 18

23 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 19

24 3) Things I ve Done 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 20

25 4) In Public Tendering If the request isn t Agile, you can t sell Agile 21 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

26 4) Things I ve Done Never done this, either, always been able to convince the customer to actually accept Agile Maybe I haven t just had the hardest cases 22

27 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) 23

28 HELPING THE CUSTOMER TO BE A GOOD PO 24

29 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 25

30 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 26

31 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 27

32 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 28

33 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 29

34 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 30

35 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 31

36 SUMMARY 32

37 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 33

38 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 34

39 THANKS! For more information: 35

Agile Thinking. Petri Heiramo. Agile Coach, CST

Agile Thinking. Petri Heiramo. Agile Coach, CST Agile Thinking Petri Heiramo Agile Coach, CST What is Important in Agile? Values Principles Practices Rules It is important to know why things work so that we do not sabotage them (by accident). Copyright