eXtreme Programming Pushing Back The Boundaries

1
eXtreme ProgrammingPushing Back The Boundaries

• David Putman
• eXoftware
• Graham Wright
• Workshare

2
CHAOS

• Almost since the beginning of computing observers
  have been commenting on the failure of the
  industry to deliver despite well documented and
  heavyweight methodologies..
• In 1994, the Standish Group began to publish the
  yearly CHAOS report, detailing the number of
  project failures in the industry.

3
The Chaos Continues
Things have improved since 1994 - but not
much Two thirds of all projects still fail
4
Why Agile Development ?

• We want to produce better quality software in a
  way that makes the business more profitable
• This is a win-win situation
• We want to be more productive

5
Agile Software Development

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

6
What determines productivity ?

• Organisational culture is the biggest determinant
  of productivity
• your organization's productivity is influenced
• by the production process itself- Deming
• You can only be as productive as your environment
  allows you to be

7
Enforced Culture
Only management can influence the culture and
influence the way that employees behave. This has
a direct effect on productivity.
8
Emergent Culture
employees are also allowed to contribute toward
the development of the organisations
culture. the people doing the work have a say in
how the work is done.
9
XP Core Values

• Values necessary for an emergent culture and
  improved productivity
• Communication
• Feedback
• Simplicity
• Courage

10
XP Practices

• To support and reinforce the core values, XP
  recommends a whole range of planning, testing
  and development practices that can be divided
  into 3 groups
• 1. Programmer practices
• 2. Team practices
• 3. Project practices

11
XP Practices
programmer practices
team practices
project practices
12
The Limits of XP

• A good idea but it would never work on my
  project
• Technical limitations
• Programming language
• Domain
• Legacy code
• Cultural limitations
• Team size
• Colocation
• Product development
• Regulated industries
• Competitive tender / fixed price contracts

13
Pushing back the boundariesProgramming languages

• XP traditionally Smalltalk or Java
• JUnit clones exist for any language you can think
  of
• Structure code to facilitate refactoring and
  testing
• C Reduce dependencies, forward declaration,
  interact via interfaces

14
Pushing back the boundariesDomain

• COM and component based development
• Separate interface from implementation
• Fix expected behaviour of 3rd party components
  using testing framework
• GUI intensive projects
• Isolate GUI from functionality
• Envelope/ Letter idiom or Bridge pattern

15
Pushing back the boundariesLegacy code

• Fix existing behaviour in unit and higher level
  tests
• Refactor to increase granularity of functions
  under test
• Wrap complex and unstable code to isolate from
  rest of application

16
Pushing back the boundariesLarge teams

• Communication Overhead
• As the team grows, the number of connections
  necessary between them grows even faster.

17
Information Radiators

• People shouldnt have to seek information, it
  should be readilty available.
• Whiteboards / intranet / internet
• Task/story tracking
• Acceptance tests passing/not passing
• Whatever the team needs to emphasize

18
Pushing back the boundariesColocation

• Communication is a core XP value, how can teams
  survive when they are geographically separated?

• The effectiveness of communication decreases as
  the participants become more remote

19
Pushing back the boundariesProduct development

• Product managers act as on-site customers
• Leverage existing customer relationships to
  verify assumptions
• Market test as soon as possible

20
Pushing back the boundariesRegulated industries

• Nothing in XP contradicts ISO or GAMP standards
• Process must auditable
• Stack of story cards not sufficient
• Auditors love tests
• Map XP practices to waterfall / V model

21
Pushing back the boundariesTenders fixed price
contracts

• Initial planning game as requirements gathering
• Rolling and Optional Scope Contacts
• Win-Win relationship based on trust rather than
  conflict leading to litigation

22
What can not be changed

• The core values
• The core practices
• Learn by doing
• Coaching and mentoring

23
Recommendations

• SCRUM www.controlchaos.com
• DSDM www.dsdm.com
• Breaking up the team
• Interactions and interfaces
• Information radiators

24
XP and Scrum
When XP projects are wrapped by Scrum, they
become scalable and can be run simultaneously by
non-colocated teams.
25
XP and DSDM
pre
feasibility
business
project
study
study
DSDM
functional
model
Life-Cycle
iteration
xp
design
post
and build
implement
project
iteration
26
XP and DSDM

• Functional Model Iteration
• 1. Identify what is to be produced.2. Agree how
  and when to do it.3. Create the product.4.
  Check that it has been produced correctly (by
  reviewing documents, demonstrating a prototype or
  testing part of the system
• Design and Build Iteration
• 1. Use XP practises like TFD to develop solution

27
Further information

• Agile Alliance
• www.agilealliance.org
• eXtreme Programming
• www.xprogramming.com
• eXtreme Tuesday Club
• http//www.xpdeveloper.com/xpdwiki/Wiki.jsp?pageX
  tC
• David Putman
• dputman_at_exoftware.com
• Graham Wright
• graham.wright_at_workshare.com