Copyright © , RoleModel Software, Inc. The Continuous Refinement of Extreme Programming Ken Auer RoleModel Software, Inc.

Copyright © 2003, RoleModel Software, Inc. * Some slide content supplied by Jim Highsmith, “Adaptive Software Development” Requirements Documents* 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

Copyright © 2003, RoleModel Software, Inc. Dichotomies Academic Pragmatic BusinessTechnical

Copyright © 2003, RoleModel Software, Inc. Perceptions Academic Pragmatic BusinessTechnical

Copyright © 2003, RoleModel Software, Inc. Charicatures Academic – critical thinking about how computers work without actually doing anything useful Pragmatic – Making computers do something useful without actually thinking critically BusinessTechnical

Copyright © 2003, RoleModel Software, Inc. Charicatures Academic – critical thinking about how computers work without actually doing anything useful Pragmatic – Making computers do something useful without actually thinking critically Business – wanting things to work without any desire to understand how or paying for someone who does Technical – understanding how to make things work, wanting someone to pay them to play and gain more understanding

Copyright © 2003, RoleModel Software, Inc. The Pragmatic/Business Dialog BusinessTechnical Academic Pragmatic

Copyright © 2003, RoleModel Software, Inc. The Technical/Academic Dialog BusinessTechnical Academic Pragmatic

Copyright © 2003, RoleModel Software, Inc. The Essential Dialog Academic Pragmatic BusinessTechnical Iron sharpens iron, So one man sharpens another. (Prov 27:17)

Copyright © 2003, RoleModel Software, Inc. Cost of Communication* * Alistair Cockburn, “Agile Software Development”, Addison-Wesley 2002

Copyright © 2003, RoleModel Software, Inc. Continuous Refinement of… Requirements Design Results Plan People

Copyright © 2003, RoleModel Software, Inc. Agile Manifesto* * “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.”

Copyright © 2003, RoleModel Software, Inc. Individuals and Interactions 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

Copyright © 2003, RoleModel Software, Inc. Requires an Engaged Customer 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

Copyright © 2003, RoleModel Software, Inc. The Ideal Project Sponsor 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 * “The Five Dysfunctions of a Team: A Leadership Fable”, Patrick Lencioni, ISBN These Need to be Attacked Every Day!

Copyright © 2003, RoleModel Software, Inc. Rules of XP* 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 *

Copyright © 2003, RoleModel Software, Inc. Rules of Engagement 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.

Copyright © 2003, RoleModel Software, Inc. Rules of Play 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.

Copyright © 2003, RoleModel Software, Inc. Continuous Refinement of… Requirements Design Plan People Code? Potential Value!