The Continuous Refinement of Extreme Programming

Ken Auer RoleModel Software, Inc. [email protected] http://rolemodelsoftware.com

• Documentation is not Understanding (tacit) – One Study of Typical Requirements Documents (Source: Elemer Magaziner): • 15% Complete, • 7% Correct, Not cost effective to increase • Formality is not Discipline • Process is not Skill • Initial Requirements define a fuzzy view of a point on the horizon

* Some slide content supplied by Jim Highsmith, —Adaptive Software Development“

Pragmatic

Technical Business

Academic

Pragmatic

Technical Business

Academic

Pragmatic – Making computers do something useful without actually thinking critically

Technical Business

Pragmatic – Making computers do something useful without actually thinking critically

Technical – understanding how Business – wanting to make things work, wanting things to work without someone to pay them to any desire to understand how play and gain more understanding or paying for someone who does

Pragmatic

Technical Business

Academic

Pragmatic

Technical Business

Academic

Pragmatic

Iron sharpens iron, Technical Business So one man sharpens another. (Prov 27:17)

Academic

* Alistair Cockburn, “Agile Software Development”, Addison-Wesley 2002

• Requirements • Design • Results • Plan • People

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

• Bright people are good to have – I don’t pay them to be bright – I don’t pay them to learn – I pay them to produce something of value for someone other than them • Bad “individual” things – Only one who has a clue about X or Y – Knows nothing about W or Z – Not communicating with the people defining the value • Good “individual” things – Learning about another part of the system (or another approach) – Teaching someone else what he knows about some part of the system – Working each day on something the customer would like to see done • AND is the operative word – bright people uncovering clues and sharing the information

• How do we engage them? – End user demos and feedback on “Working Software” – Informal planning sessions – Daily or weekly meetings • Case study – Scientist engaged daily – Representatives engaged weekly (demo, feedback, and prioritization) – Planning with scientist weekly – Sponsors involved in planning bi-weekly or monthly – Sorting out cards

• Person defining system pays for everything out of his own pocket – Gets immediate feedback when he made a good/bad decision • Good: Profits • Bad: Feels a loss – Though he only makes good decisions • Can anticipate every change in the market • Can efficiently negotiate the best price/value point – Is given accurate options and estimates from multiple sources – Is not locked into using any particular person/team to make stuff happen – Can instantly find and engage the best sources for each feature Copyright © 2003, RoleModel Software, Inc. The Realistic(?) Agile Situation

• Person defining the system makes educated guesses about the value and cost of everything – To the nearest… $1000, $10,000, … – Recognizes his own cost and cost of requests – Recognizes the cost of delaying vs. acting on what they know – Recognizes the value of being able to change a decision – Focus on revenue stream and cost stream • Everyone on the team is focused on providing the best value for the least cost – Provides “customer” with educated guesses about options/costs – Always looking to improve, but not fixing what ain’t broke – Thinks about the best way to get what’s most important – Without being so short-sighted that they’ll be sorry Copyright © 2003, RoleModel Software, Inc. Five Dysfunctions of a Team*

• Absence of trust • Fear of conflict • Lack of commitment • Avoidance of accountability • Inattention to results

These Need to be Attacked Every Day!

• XP is setting up a game which attacks dysfunctions daily • Two categories of rules: – Rules of Engagement – The big picture • These are similar to what I suspect the rules for most agile methodologies are about • There are those doing SCRUM/XP… SCRUM is basically used as the strategy for the Rules of Engagement – Rules of Play – The basic daily activity • This is what happens every day, to make sure the details are being followed through on • Most other Agile methodologies don’t appear to have them • This is daily accountability

1. An XP team consists of a group of people dedicated to the production of a software product… there must be at least a customer and a developer role. 2. The customer must set and continuously adjusts the objectives and priorities based on estimates and other information provided by the developers... 3. The customer is always available and supplies information on demand to assist developers in forming estimates or supplying desired deliverables. The customer is an integral part of the team. 4. At any point, any member of the team must be able to measure the team's progress towards the customer's objectives. 5. The team must act as an Effective Social Network, this means: a. Honest communication leading to continuous learning. b. Minimal degrees of separation from what is needed by the team to make progress and the people/resources that can meet those needs. c. Alignment of authority and responsibility. 6. Timeboxing is used to identify segments of development effort and each segment is no more than one month in duration.

1. Work produced must be continuously validated through testing. 2. Write unit tests first (before coding), Program in pairs (if there is more than one developer on the team), and refactor code to meet Coding Rules (P3) while working on current customer priorities. 3. All code written for potential use in the software product must a. Pass all the unit tests (or not make any unit tests fail) b. Clearly express every concept c. Contain no duplication d. Contain no superfluous parts 4. Collective Ownership. Everybody has the authority and at least two people have the understanding necessary to do any task.

• Requirements • Design • Plan • People • Code?

Potential Value!