Speaker's Notes 12/02/02

Agile Methodologies and Extreme

Programming in Context

An Organizationally Targeted Presentation on

Agile/Extreme Methodologies

12/02/02 Agile/Extreme in Context 1

Agile/Extreme in Context 1
Speaker's Notes 12/02/02

Our organization - Strengths and

weaknesses
• Strengths
– Autonomous business units
– Software development (IS) groups collocated with business units
• High degree of autonomy on managing activities
– Head IS functions provide
• Infrastructure planning
• IT architectures
• Service delivery
• Weaknesses
– System enhancements take longer than is desired by clients
– Upgrade implementation take longer than is desired by clients
– Inconsistent spawning of e-commerce web-sites by site marketing
departments
– (perceived) different process models adopted by individual IS units

12/02/02 Agile/Extreme in Context 2

Set the scene by considering where our organization is currently.

Doesn’t need too much detail, attendees should be aware of this.
Putting into the SWAT structure simply provides a useful categorization.
There are a few ambiguities in the information that has been provided, but if
noticed, questions from the audience are likely to clarify the situation.

Agile/Extreme in Context 2
Speaker's Notes 12/02/02

Our organization - Opportunities and threats

• Opportunities
– Replacement of legacy systems with an ERP system
– Consistent coordination of web site development through Business
unit’s IS function
– Integration of web front-ends with Transaction Processing systems
(TPS)
• Threats
– Availability and currency of TPS interface information available to
e-commerce development groups may impede their ability to
respond to market opportunities
– Imposition of organizational processes may diminish autonomy of
Business area IS development groups and impose far-reaching
cultural changes

12/02/02 Agile/Extreme in Context 3

Main threat is probably going to be the responsiveness of the HO IS to the TPS

interface, infrastructure and architecture information needs of the distributed
autonomous group so that they can react fast enough to the e-commerce needs
of their business groups.

The perceived weakness of the ‘different processes’ indicates a potential move

to organization process definitions (possibly as the result of pressure by HO
IS) which may not sit well with the autonomous, ‘fit the process to the team’
philosophy of Agile methodologies. Carefully hint at this contentious area
now, in preparation for later discussion.

Agile/Extreme in Context 3
Speaker's Notes 12/02/02

A Spectrum of Process Methodologies

• Rigorously defined ‘one size fits all’ process-based
methodologies
– Software CMM, ISO 12207, ISO 15504, ISO 9001, or other SE
standards
– Large team processes and high artifact count that ‘confirms’ process
execution
• Tailored sets of loosely defined processes
– Requires tacit understanding of project parameters and process
parameters and outcomes to effectively and successfully scale down
a defined process set
– Results in a subset of processes and artifacts having clearly
articulated work-flows that negate effects of consequent ‘process
gaps’
• Anarchy and/or chaos
– Little/no explicit process; developers concentrate on coding
12/02/02 Agile/Extreme in Context 4

•The ‘defined’ processes and model frameworks have been well-described in many forums over
the last ten years or so; and have been proposed as the solution to the ‘software engineering
crises’.
•As McBreen suggests, we have a systemic problem with smaller applications (ie not DOD,
NASA, Ericsson, PeopleSoft size applications) we have been trying to control and manage these in
that same way that we do the massive projects, with some level of ‘tailoring’
•scaling down is difficult, generally experts with the necessary competencies are not used
to determine an appropriate process, its often a hack and slash approach that becomes more
frenetic as project time slips away.
•Of course, even at the anarchic end of the spectrum there is still process, it is simply
unrecognized, implicit and individual - the heroic process
Winchester’s Yangtse management description is useful here:
• Taoists supported the building of only very low levees beside rivers and letting the rivers devise
their own way to the sea. Thus, as parameters changed the river still ended up at the sea without
too much effort
•Confucianists believed that massive dykes should be built to corral the waterways along man-
made courses of man’s choice. Thus as parameters changed (frequently, due to natural events)
unexpected and undesired effects occurred, requiring massive amounts of rebuilding.

•“Rigorous processes are designed to standardize people to the organization; agile processes are
designed to capitalize on each individual and each team’s unique strengths.” (Cockburn and
Highsmith)
Agile/Extreme in Context 4
Speaker's Notes 12/02/02

Agile Software Development

Manifesto:Purpose

“We are uncovering better ways of 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 the plan
That is, while there is value in the items on the right, we
value the items on the left more.”
Agile methodologies are people-centred rather than
following a Taylorist Scientific Management approach.
12/02/02 Agile/Extreme in Context 5

•The agile group are practitioners who ‘mine’ best practices, reformulate them as
abstractions and then disseminate them - they do not sit in offices and simply pontificate!
Although many of them work as managers of projects it is in the context of project
leadership rather than by command and control.
•Corollary to the manifesto - we have to find ways to adapt the way we ‘value’ the things
on the right to achieve the higher value on the left. This does not necessarily imply simply
discarding them.
•Relying on interactions between individuals facilitates sharing of information and
rapid changes to process when needed
•Working software allows us to determine the project velocity and gives feedback
•Increased interactions means that tacit knowledge can be shared, thus minimises
reliance on ‘high maintenance’ documentation
•Customer collaboration puts us on all the same team but we have to make sure that
we have users with domain-experience not simply whoever hasn’t got too much
work to do (the latter has often been the case with customer representatives
•Cast iron contracts often result in delivering the ‘wrong’ product

•Important to note that the Agile approach is a generative approach - i.e. processes emerge
that are useful in the context of the specific project, rather than the more usual inclusive
approaches that try to account for every possible project eventuality.
•This context sensitivity of process means that any centralized control/management
is only going to be at the macro level of detail (what is required) rather than micro
Agile/Extreme level (how we achieve what is required).
in Context 5
Speaker's Notes 12/02/02

Agile Software Development Manifesto:

Principles
• Customer satisfaction through early and continuous
delivery of software using short (in weeks) iteration cycles
• Accept and accommodate changing requirements at any
time during development
• Developers work daily with business people
• Build the project around team strength’s and provide them
supportive environment
• Minimize documentation and maximize face to face
exchange of information
• Maximize the amount of work not done
• Encourage reflective practitioners and continuous learning

12/02/02 Agile/Extreme in Context 6

•The ‘plan’ is updated for each iteration with information about working software from the
previous iteration and what is to be implemented in the next iteration
•Working software is a measure of progress
•Reduce the elapsed time between making a decision and seeing its consequences
•Accommodating change accepts that the customer’s organization is probably emergent rather
than stable and supports the customer’s need to meet changing organizational goals (possibly
unknown or unidentified earlier in the project)
•useful parameter for determining if Agile is appropriate for a project
•The team environment is the most difficult from a project management perspective;
developers are not interchangeable units; developers are more skilled than their managers in
their ability to produce software which is what the customer wants; managers provide
interfaces, facilitation and coaching rather than command and control; team’s internal
organization may change over time to reflect the current needs of the project (anecdote -
architect to integration champion transition)
•Self-organizing teams; Processes support sustainable development
•Strive for good design and technical excellence
•Developer’s decide what is needed for good design and technical excellence; if there is
an organizational requirement for specific processes/documents then either these need
to be accommodated as required project outcomes, or the feasibility of an agile
approach should be questioned?

Agile/Extreme in Context 6
Speaker's Notes 12/02/02

Consequent Agile Practices

• Feature planning and dynamic prioritization
– features lists
– priorities determined by customer
• Feedback and change
– Working software elicits feedback and change requests
– Clean, maintainable design ensures that such changes can be
accommodated
• Focus on people and teamwork
– Individual competence
– Team competence
– Collaborative work
“Agile teams are characterized by self-organization and intense
collaboration, within and across organizational boundaries.”
(Cockburn and Highsmith, 2001)
12/02/02 Agile/Extreme in Context 7

•Each of the methodologies determines when features can be added and

reprioritized e.g. at the end of iteration N; only interested in current iteration
•plans features not tasks because this is what the customer understands

•Points 1 and 2 both require really close collaboration with a useful customer,
preferable on-site to be part of the team

•Clean design is something that needs to be explained, seen and mentored. Could
be the focus of a presentation or workshop on ‘what is simple design’ not within
scope of this presentation.

•Team independence and team-context-sensitive process is so fundamental that if

the organization culture cannot accept it, any attempt to move to Agile methods is
almost certainly doomed to failure.
•A good pre-indicator of this could be how much flexibility current project
manager’s have in terms of their planning process and plan structure and
detail??

Agile/Extreme in Context 7
Speaker's Notes 12/02/02

Some Agile Methodologies

SCRUM
– Initial architectural phase, backlog, 4 week Sprints, daily scrum meetings,
end of Sprint customer demonstration
• ASD (Adaptive Software Development)
– Mission-driven, component-driven (results), time-limited, timeboxed; risk
driven; change tolerant
• Crystal Clear
– Strong communications; frequent deliveries; reduce overhead; management
by milestones and risk lists
• DSDM (Dynamic Systems Development Model)
– User involvement, stakeholder collaboration; empowered team; frequent
delivery; backtracking to reverse changes; high-level requirements
baselining; iterative and incremental development; integrated lifecycle
testing;
• XP (eXtreme Programming)
– short cycles, continuing feedback, incremental planning, automated tests
12/02/02 Agile/Extreme in Context 8

Insufficient time to go into any detail on these other than these few points.
Audience should be advised to read further if they have an interest.

•More information on SCRUM in PLoP4 p637 - 651 which describes the

process in a pattern language.
•Definitive source of information on ASD is Jim Highsmith’s Adaptive
Software Development, Dorset House, 2000.
•Best source for information about Crystal Clear is Crystal “Clear”: A Human
Powered Software Development Methodology for Small Teams. At
http://members.aol.com/humansandt/crystal/clear.2001
•More about DSDM at the consortium site
http://www.dsdm.org/about/principles.asp
•More about Extreme in the series of six Extreme books published by
Addison-Wesley.

•Important to note that there are few reported case studies (the Chrysler 3C
informs the Extreme methodology) about the efficacy or otherwise of any of
these approached; information is mainly anecdotal and with some apparent
biases.
(Fertile ground for Iterative Action Research style projects).

Agile/Extreme in Context 8
Speaker's Notes 12/02/02

Extreme Programming (XP)

XP is the best-known of the Agile methodologies
XP is decomposed into several perspectives
• Four Values - ie how software development should ‘feel’ is
based on
– Communication; Simplicity; Feedback, and Courage
• Five Principles - used to determine whether a practice can
be used successfully in an XP context
– Rapid Feedback; Assume Simplicity; Incremental Change; Embrace
Work, and Quality Work
• Four Activities - the cornerstone of software development
– Coding; Testing; Listening, and Designing
• Twelve Practices - used to successfully carry out activities
Additionally, Strategies to execute practices in real projects
12/02/02 Agile/Extreme in Context 9

Values, principles and activities are self-explanatory, and can be mapped back
to the Agile Manifest Value statements and Principles.

Next slide covers the twelve practices. Then some proposed strategies.

Agile/Extreme in Context 9
Speaker's Notes 12/02/02

The 12 Extreme Practices

• The planning game
• Small releases
• Metaphor
• Simple design
• Testing
• Refactoring
• Pair programming
• Collective ownership
• Continuous integration
• 40 hour week
• On-site customer
• Coding standards
12/02/02 Agile/Extreme in Context 10

•Planning - scope, business priorities, composition of releases, technical estimates, release dates
•Small releases - most valuable business requirements, short cycles
•Metaphor - overarching, sometimes akin to an architecture - problematic area, metaphor isn’t the
system; metaphor may provide domain vocabulary
•Simple design - runs all tests, no duplicated logic, states intentions to developers and hasn’t
smallest number of classes and methods to achieve goals - area subject to abuse
•Testing - write tests for production methods before methods themselves, use automated testing
framework (eg JUnit), all tests must run - strength, identifying tests encourages better designs
•Refactoring - small low risk steps to clean-up code that has become ugly through iterations, a
direct outcome of code evolution
•Pair programming - dynamic, strategic and operational pair members (thinker and mouser);
whole is better than sum of parts; culturally problematic unless evolved naturally like
brainstorming; skills transfer and mentoring; distribution of tactic knowledge
•Collective ownership - if there’s a problem anyone can fix it (highly dependent on continuous
integration); adding value to code;
•Continuous integration - daily at least; avoids merge clashes, identifies progress, set up and run
integration and regression testing avoid ‘big-bang’ testing problems; easy to identify where
problems are (ie most recent check-ins)
•40 hour week - all about sustainable development and ‘get a life’, productivity and and
identifying schedule problems within an iteration
•On-site customer - set internal priorities; resolve disputes; answer questions; team bonding
•Coding standards - essential for dynamic pair programming and effective refactoring
Agile/Extreme in Context 10
Speaker's Notes 12/02/02

Some Extreme Strategies

• Management
– phased delivery; quick & concrete feedback; clear articulation of business needs;
specialists for special tasks
• Facilities
– open workspaces; private places; common programming areas
• Planning
– plan quickly and cheaply; incremental detailing of planning horizons; plans that are
amenable to change
• Development
– craft a solution to today’s problems, trust that we can solve tomorrow’s problem
tomorrow
• Design
– start simple; continuous refinement; remove non-useful complexity
• Testing
– tests before code; test preservation; frequent regression tests; customer perspective
12/02/02 Agile/Extreme in Context 11

Since this is a group of IS people ( and time is limited) just look at how the
principles/practices/values support instantiating a subset of these strategies
•Development
•continuous iteration; collective (artifact) ownership; pair programming;
•Design
•simplest thing that can work (relies on all four values communication, simplicity,
feedback and courage); refactoring; assume simplicity (Occam’s razor) - resulting
constraints that define the simplest thing are
•system communicates everything you want to communicate
•system contains no duplicate code
•system has fewest possible classes
•system has fewest possible methods
•travel light; incremental change;
•throw away designs (rather than CASE-based pictures)
•design is in the code
•Testing
•developers write tests method-by-method before coding
•write tests before refactoring to assess viability of refactored code
•customers write tests from their stories, developing scenarios

Agile/Extreme in Context 11
Speaker's Notes 12/02/02

XP Practices - resolving weaknesses

No single practice works well by itself, each needs the
other practices to keep them in balance (Beck2000)
On-site customer

Planning game

40 Hour week

Metaphor
Simple design
Refactoring

Testing Short releases

Pair programming

Coding standards

Continuous integration

Collective ownership

12/02/02 Agile/Extreme in Context 12

Agile/Extreme in Context 12
Speaker's Notes 12/02/02

When to use an Agile Methodology

Home Ground Area Indicator for Agile Methods Indicators for Plan/Process-
driven Methods

Developers Agile, knowledgeable, collocated Plan/process-oriented; adequate

and collaborative
Customers Dedicated, knowledgeable,
collocated, collaborative,
representative and empowered
Requirements Largely emergent; rapid change
skills, access to external
knowledge
Access to knowledgeable,
collaborative, representative, and
empowered customers
Knowable early; largely stable

Architecture Design for current requirements Design for current and future
requirements

Refactoring Inexpensive Expensive

Size Smaller teams and products Larger teams and products

Primary Objective Rapid value High Assurance

(Boehm 2002)
12/02/02 Agile/Extreme in Context 13

Agile/Extreme in Context 13
Speaker's Notes 12/02/02

Conclusion and Recommendations

• Agile Methodologies are not for all organizations or
even for all projects
• Agile Methodologies respect, and leverage off,
differences between people
• Agile Methodologies are process-generative rather than
process-inclusive
• Implementing an Agile Methodology, as with any other
organizational change, requires support from the top-
down and action from the bottom-up
• Should we become Agile?
– Not until we have done some assessment of organizational and project
parameters in order to determine its suitability, and thus the risks in, and the
potential for, a successful transition!
– Assessed the Agile variants for organizational ‘goodness of fit’ and
development capability improvement potential
12/02/02 Agile/Extreme in Context 14

At this point, need to avoid the ubiquitous ‘steering committee’ approach and
suggest some original alternatives to prompt buy-in across the organization
and get access to real information about projects and cultures rather than the
shelf-ware procedural manuals and management perceptions about what is
happening, for example
‘study groups’ to find out about Agile variants, disseminate
information and generate ideas as to who each would ‘fit’ into the
organization
‘brown bag’ lunches at each location to determine perceptions of the
current organizational and project parameters
web discussion group(s) on the intranet to promote informal exchange
of ideas
encourage HO IS to form a working group determine what it is they
really need to ‘standardize’ in terms of process, artifacts and
tools/technology

Agile/Extreme in Context 14
Speaker's Notes 12/02/02

Useful Agile/XP Information Sources

• Fowler and Highsmith’s Web article about the Agile Manifesto is at
www.sdmagazine.com/documents/s=844/sdm0108a/0108a.htm [Accessed Sept
28, 2001]
• IEEE Software - issues July/August 2000 and November/December 2001 have
articles relating to Extreme Progrmming
• IEEE Computer - issues September, November 2001, January 2002 have
articles relating to Agile Methodologies
• Kent Beck Extreme Programming Explained; Embrace Change. Addison-
Wesley, 2000
• Jim Highsmith Adaptive Software Development, Dorset House, 2000.
• Alistair Cockburn Crystal “Clear”: A Human Powered Software Development
Methodology for Small Teams. At
http://members.aol.com/humansandt/crystal/clear.2001
• Mike Beedle et al “SCRUM: A pattern language for hyperproductive software
development” in Pattern Languages of Program Design 4. Edited by Neil
Harrison et al. Addison-Wesley, 2000
• There are five other books currently available in the Addison-Wesley XP series
12/02/02 Agile/Extreme in Context 15

Agile/Extreme in Context 15