Polish Agile Users Group Agile Customer Collaboration

1. Customer Expectations Delivered Polish Agile Users GroupAgile Customer Collaboration Jay Packlick June 22, 2006

2. Schedule Resources Scope Quality Product under development Customer In Agile we manage the plan using 3 Variables of project Control • 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)

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

4. Setting the Context Agile -What is it?

5. Agile / Lean Focus on intelligence, knowledge, and discipline of front line workers Traditional methodologies Focus on process and conformity to process Two Paradigms

6. Agile / Lean Steering through continuous planning, feedback and communications Traditional methodologies Steering through detailed predictions and documentation Two Paradigms

7. Agile / Lean Embraces change through partnership and collaboration with customers (and other team members) Traditional methodologies Attempts to minimizes change through contract negotiations Two Paradigms

8. The Uncertainty Dynamic • “If Las Vegas sounds too tame for you, software might be just the right gamble.” – Steve McConnell, Rapid Development

9. Capers Jones Requirements Change Study

10. Agile goal: Thrive in the face of uncertainty flexibility Change uncertainty Random- ness

11. Change Harnessing Model Continuous Improvement Simplicity Communi- cations Frequent feedback flexibility knowledge & creativity of people Frequent Planning Small batch sizes Decide late Values & Principles driven

12. Establishing the Context But what is a Customer? and why do we want them around?

14. Key agile value = Communication • 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

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

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.

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)

18. The problem with control (at first) Agile puts scope control in the hands of customers ( they’re usually not used to it! )

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

20. Don’t underestimate the skill side • Having a problem does not uniquely qualify you to solve it… • Customers don’t magically transform into business analysts

21. The Agile Customer – Some Common Problems • Failure to Identify one! It is often not clear who the Customer is for a project (multiple roles) • No clear roles and responsibilities There is no consistent understanding of what the Customer role is • 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. Availability It can be difficult to get them to work with the team.

22. Stakeholder Community Customer Team So what’s needed? - Skilled Customer Team Competitors Market Place End Users Media Partners Shareholders Industry Groups Operations Project Management Documentation Programming Team On-site Customer Testers Marketing Customer Support Management Sales Analysts Developers

23. Stakeholder Community On-site Customer is the voice of the community Customer Team Competitors Market Place End Users Media Partners Shareholders Industry Groups Operations Project Management Programming Team On-site Customer Documentation Testers Marketing Customer Support Management Sales Analysts Developers But we still need a single strong voice! • Agile values simplicity … Proxy For the rest

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

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

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

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

28. Agile Contracts

29. Primary Source for following • Lean Software Development – an agile toolkit • Mary & Tom Poppendieck

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

31. Contract Models • Non-agile model • Fixed Bid • Agile Models • Time-and-Materials • Progressive • Target Cost • Multi-Stage

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

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

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

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

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

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

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 <

39. Contact jay.packlick@sabre.com