Extreme Programming for Customers
Steve Hayes / Cameron Bricker
Cogent Consulting / Varian
Agenda
- What is XP?
- XP Structure
- XP Practices in brief
- XP Roles
- The Customer
- Responsibilities
- Participation
- Deliverables
What is XP?
- Extreme Programming is a software development methodology
- It's not a complete project management methodology
- Keep going with lots of things you're already doing
- It changes the way you interact with the software developers
- It is intended to make software development more effective
- It uses scope as a control variable, not cost, time or quality
- It is iterative and incremental
XP is Iterative
- Iterative so that the project can be steered to the best possible outcome
- In real projects things change - market requirements, costs, timelines
- Short term vision is clear, but long term vision is of necessity cloudy
- XP projects iterate to provide many opportunities for steering the project to the best
possible outcome, given all the project constraints
- Constraints include time and cost - release dates and available resources are fixed.
It's important that everyone understand it's the customer who decides that gets done *with the resources available, within the time available*. At every point in the project, the customer should be asking themselves "what gives me the biggest bang for the buck?"
XP is Incremental
- Incremental, because production ready features are added in each iteration
- Contrast this with prototyping, where a skeleton of all the features is done upfront, but nothing is production ready
- Although features are delivered incrementally, everyone benefits from having a shared vision of the overall objective
Bill of Rights
- XP is sometimes expressed as one way to deliver certain rights to different stakeholders
The Manager Has The Right ...
- to an overall estimate of costs and results, recognizing that reality will be different.
- to move people between projects without paying exorbitant costs.
- to monthly updates of progress, and to help the customer set overall priorities.
- to cancel the project and be left with a working system reflecting the investment to date.
The Customer Has The Right ...
- to plan on a large scale with costs and options.
- to set development priorities weekly.
- to see progress in the form of a working system at the end of the first week, and to see a little more functionality every week thereafter.
- to updates of the schedule, good or bad, as soon as the information is available.
- to change his/her mind without paying exorbitant costs.
The Programmer Has The Right ...
- to estimate work and have those estimates respected by the rest of the team.
- to honestly report progress.
- to produce high-quality work at all times.
- to know what is most important to work on next.
- to ask business-oriented questions whenever they arise.
XP Structure - Project
- At the highest level we have a project.
- A project should have a goal.
- We don't need all the details at the start, just enough to plan with
- It needs to have estimates that justify at least starting work.
- Use whatever goal/requirements/scope elaboration techniques you would use for other approaches
XP Structure - Releases
- Projects are broken down into releases
- Releases are equivalent to high level milestones
- These are the candidates that you might release to the wider world for feedback
- Each release should have a theme, a goal, or a target audience
XP Structure - Iterations
- Releases are broken down into iterations
- Iterations are equivalent to low level milestones
- Iterations are short, fixed and constant length
- They are the heartbeat of the project
- Start a project with the planning game, finish it with a "show and tell" and/or a retrospective
XP Structure - Stories
- All work is represented by stories
- Stories have value to the business
- Stories are testable. It must be clear where the boundary of a story is, and when it is finished.
- Initially, stories have just enough detail to be estimated
- Stories are scheduled in releases/iterations
- Stories frequently need to be split
- Stories are later broken into technical tasks
XP Practices
TODO - Need to revisit formatting of this slide to make it look like a title
Briefly...
This is the point where we discuss the practices, without going into depth on any of them. The ones that need to be handled in depth will be revisited later.
XP Techniques - Early Estimation
- Shouldn't start a project until there is a business case
- This requires estimates of both benefits and costs
- Estimates should be bounded, not single numbers
- Benefits are estimated by the customer, costs by the developers
XP Techniques - Estimation
- Traditional estimation (person-days) conflates size and productivity
- Estimate in some unit of size - points, gummi bears, kilos...
- Then estimate productivity (points per unit of time for the team)
- Duration = size / productivity
- Effort = Duration * size of team
XP Techniques - Big Visible Charts
- Try to provide maximum visibilty
- This includes dates, estimates, and progress
- Progress is determined by working software
- Where "working" means passing tests and usable
XP Techniques - Standup Meetings
- Daily synchronisation of the team
- Ensure everyone knows what is happening, and where there are problems
- Helps the customer steer
- be confident that highest priorities are being worked on
- adjust the content of the iteration if there are problems
- Agenda is : what have I done, what am I going to do, am I on track or do I have problems?
XP Techniques - Planning Game
- Decides what stories become part of an iteration
- Customer lists all stories that are candidates for the iteration
- Developers review estimates, adjust if necessary
- Customer picks stories whose estimates total "yesterday's weather"
- Developers "sign up" for stories
XP Roles
- End User
- Software Customer
- Software Lead Designer, Developer
- Software Process Coach, People Coach
- Software Tracker
- These are roles, not individuals
End User
- The person who is going to use/buy the software
- You probably don't have direct contact with them
- Goal-driven design (Alan Kay) is a useful approach
Software Lead Designer
- Lead the system design
- Ensure that the design is followed
- Ensure commonality with other project designs
- Present system design for external peer review
Software Developer - Part 1
- Communicate with the customer & other developers
- Work with the customer to understand his/her stories
- Estimate the amount of work each story will take
- Identify risky features that use new technology, are poorly understood or are complicated and communicate the associated risk to the customer
Software Developer - Part 2
- Turn customer stories into working code that meet the customers needs
- Create task cards from the customer story cards when required
- Follow team conventions so that the system is simple, test driven, refactored and agile as possible
- To implement only what is necessary and keep the project as simple and valuable as possible for the customer
Software Coach
- Process Coach
- Guide and mentor the team to understand the XP process, and ensure it is being followed
- People Coach
- Facilitate discussions and conflict resolution
- Serve as an intermediary between the team and management
Software Tracker
- Track the team velocity
- Provide feedback to the team and project management regarding the teams progress
- Monitor if the project is on schedule for the iteration by checking with developers on their progress
- Keep track of the schedule
Focus on the Customer
Responsibility versus Accountability
- Dictionaries don't help much in distinguishing these two ideas.
- The Macquarie
Dictionary says:
- Responsible - answerable or accountable, as for something within one's power, control or management
- Accountable - Liable to being called to account; responsible
Difference in perception
The term 'responsibility' is not synonymous with accountability. One who is authorized to act or who exercises authority is 'responsible'. However, responsible officials are also held to account. An individual who exercises power while acting in the discharge of official functions is responsible for the proper exercise of the power or duties assigned. A person exercising supervisory authority is responsible, and hence accountable, for the manner in which that authority has been exercised.
The quote is from the Report of the Somalia Commission of Inquiry (http://www.dnd.ca/somalia/vol0/v0s10e.htm) produced by the Canadian National Defence Forces.
In XP projects
- Everyone on the team should contribute ideas, insights and opinions
- There should be a strong culture of collaboration
- Responsibility can (and should) be shared, BUT it needs to be clear who is accountable for decisions, especially when there's no consensus
- We tend to blur this distinction, in both speech and writing
Customer Deliverables - Stories
- A description of something with business value
- ...in plain English
- ...that delivers value to the customer
- ...and can be tested and estimated
- Customer creates and runs acceptance tests (with developer assistance) to verify features are complete
- Tests are mandatory
Customer Deliverables - Ownership
- customer maximises ROI by ensuring that at every point the software contains the most valuable features possible
- customer decides what should and should not be done (based on discussions with other parties)
- Responsiveness - make decisions quickly, clearly
Customer Deliverables - Direction
- Help the developers understand what's important, how you define sucess
- Priorities need to be clear
- The better the developers understand, the more trade-offs/alternatives they can suggest
Customer Deliverables - Scope
- Ultimate control variable for an XP project
- this isn't just a matter of picking and choosing stories.
- It's means separating high value wheat from low value chaff, and working with developers to find lower costs means to ends.
- it requires creativity and flexibility in the face of changing costs.
Customer Participates in ...
- Release and Iteration Planning
- Planning game
- Standup meetings
- Ongoing consultation
Means to these Ends
- Radical Geographic Colocation
- a.k.a sitting together
- Communicate all the time
- Be part of the team, not apart from the team
- Big Visible Charts, domain models, prototypes...
Exercise
- Produce a picture of a coffee making machine (or something else)
Tasks - Project and release planning
- As a group, brainstorm a list of story names - generate a lot quickly (10 mins)
- Break into two groups, each with a copy of the story names. (15 mins)
- Customers estimate value
- developers estimate cost of drawing the feature.
- As a group, break the work into three equal (+/-20%) releases. (25mins)
- Customers are the final arbiters of what goes into each release.
- Stories may (should!) be split.
- Give each release a theme/name.
Tasks - Iteration planning and execution
- From the first release, pick how much can be drawn in 10-15 mins (we'll decide based
on estimates). (2 mins)
- decide based on initial estimates
- Add acceptance tests to these stories. (15 mins)
- Review estimates (5 mins)
- Do an interation :-) (10-15 mins)
- Discuss experiences and repeat.