eXtreme Programming
rediscovered
Krešimir Fertalj
University of Zagreb
Faculty of EE & Computing
Department of Applied Computing
Aug 2014
DAAD \ Fertalj
1
Intro
Aug 2014
DAAD \ Fertalj
2
XP is …
• Programming under extreme conditions 
•
•
•
•
Lightweight software development process ? methodology
Focused on continuous change throughout SW product L-C
Non-linear, adaptive, incrementally oriented
Based on longstanding practices, including
• evolutionary prototyping,
• short release cycles, and
• active end-user involvement in requirements definition
Aug 2014
DAAD \ Fertalj
3
Suitability [sorted]
• Business software
• Changing requirements
• Fast-pace
• In-house development
• On-site customer
• Vague requirements
Aug 2014
DAAD \ Fertalj
4
Usability
+use
•
•
•
•
small to medium-size projects
using co-located teams
of a dozen or fewer programmers
total duration of 1-6 months
!use
• large projects, long projects, or
• projects with high reliability requirements
• projects that face risks
• in areas other than requirements, schedule, or staff inexperience
Aug 2014
DAAD \ Fertalj
5
Values
• Communication
• Oral + electronic, frequent / continuous, everyone
• Simplicity
• Design the simplest + KISS & grow the system as & when required
• Feedback
• From both teammates & customers – early and often
• Courage
• Actions & decisions, even unpopular, YAGNI
• Respect
• Mutual respect among all stakeholders
Aug 2014
DAAD \ Fertalj
6
XP LifeCycle (LC)
Aug 2014
Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J.
Agile Software Development Methods:
Review and Analysis. VTT Publications, 2002, p.19
DAAD \ Fertalj
7
XP LC briefly
• Exploration = Requirements Analysis
• Writing user stories
• Planning = Forecasting and Estimating
• Planning Game
• Development = Sequence of iterative cycles
• Concludes with a product release - „a couple of cycles before
production”
• Iteration Planning Game (IPG ) – tasks for each cycle assigned,
estimated
• Test-First Programming, Pair Programming, Regression Testing
• Implementation
• Continuous integration – „very short intervals”
• on separate server, regression & integration tests
Aug 2014
DAAD \ Fertalj
8
Primary practices
Aug 2014
DAAD \ Fertalj
9
Requirement Analysis & Planning
• [User] Stories
• Short descriptions of customer-visible functionalities
• Weekly Cycle
• SW development performed a week at the time
• A meeting where the stories are chosen by the customer
• A cycle may start in the middle of the week !
• Quarterly Cycle
• „rolling wave planning”
• Slack
• Lower-priority tasks that can be dropped if project gets
behind the schedule
Aug 2014
DAAD \ Fertalj
10
Team & Human Factors
• Sit Together
If the customer won’t move to
the team, move the team to
the customer
• Co-located team, open space
• Whole Team
• All the skills needed, sense of belonging
• Informative Workspace
• [B|W]board, visible wall graphs, …, CMS/GSS/PMS
• [mostly] Energized Work
• Limited overtime
• Pair Programming
Working overtime
occasionally does not violate
the goal of working at a
sustainable pace (Hunt, 2010)
• 2 programmers { driver,
observer/navigator } at 1 machine
DAAD \ Fertalj
11
Aug 2014
Design
• Incremental Design
• No Big Design/Modelling/Requirements Up-Front (BDUF,
BMUF, BRUF)
• Design + refactor incrementally during coding
• [dislike] Test-First Programming
• Test-Driven Development
• Automated unit tests incrementally written
• All stories have at least one acceptance test
• preferably automated
Aug 2014
Repeat
write a failing automated test
write just enough code to pass the test
refactor
DAAD \times
Fertalj
12
A few
an hour
Software Coding & Releasing
• Ten-Minute Build
• „System should be built & all of the tests should be finished in
10 minutes” 
• Continuous Integration → Daily Build & Smoke Test
• Continuous = at least daily
• By regularly integrating with current build
• And getting every else’s code
• Code may only be checked in if all tests pass
• CI server
• Release builds in the morning
• Messaging „fix the build”
• Penalty for breaking the build [or leaving w/o checking in]
Aug 2014
DAAD \ Fertalj
13
Corollary practices
• real customer,
• incremental deployment,
• negotiated scope
contract,
• pay-per-use
• team continuity,
•
•
•
•
•
•
shrinking team,
root cause analysis,
code and tests,
shared code,
single code base
daily deployment,
• daily stand-up meetings
# unofficial practice
Aug 2014
DAAD \ Fertalj
14
XP team
• Self-organizing, cross-functional, sufficiently competent
• Team size : optimal 7 ∓ 2, like 5
• Team roles
•
•
•
•
•
Manager – management of team & problems # manager, “team lead”
Coach – tutoring, monitoring, issue control
# programmer, “tech lead”
Programmer – estimating, coding incl. tests, refactoring
Tester – test development
Customer – story selection and prioritizing, acceptance test writing
• More roles
• Tracker, Trainer, Doomsayer, …
• Product Manager, Domain Expert, Interaction Designer, Business Analyst
…
Aug 2014
DAAD \ Fertalj
15
[some] Practical issues
Aug 2014
DAAD \ Fertalj
16
Controversies [& how to deal with]
• XP is a hackers paradise or at the very least
encourages hacking
• Active PM, n stories 90% done = 0 stories
• XP Programmers get to work in pairs!
• Not all, but sophisticated functions
• Programmers should switch roles and change partners
• XP doesn’t force team members to specialize
• Specialization is not always a good thing
• Paraprofesionalism, Fach-idiotism, …
• Versatility is good, for small teams!
Aug 2014
DAAD \ Fertalj
17
[continued]
• XP promotes gradual development of the infrastructure &
frameworks
• ! necessarily → CSLA.NET, EntLib, Spring, GWT, Struts, Oracle ADF,
…
• XP doesn’t conduct a complete up-front analysis & design
• What about iterative SAD | parallel development ?
• XP does not encourage the … implementation
documentation
• The code is not sufficiently self-documenting # the weakest point
!
• Comments, round-trip engineering, frameworks & patterns, …,
help += manual
• XP is not a complete methodology
• Common sense & best practices over methodologies (Fertalj)
Aug 2014
DAAD \ Fertalj
18
[Iteration] Planning [Game]
• Elaboration:
• { write + estimate + split } a story
• Commitment:
• Sort by value of { must, should, nice to } have → { 0, 1, 2,
3, 5, 9 }
• Sort by risk { confident, reasonably sure, cannot estimate }
• Choose scope = set of USs
• Set velocity – map Ideal Engineering Days (IED) to reality
• Steering:
• Iteration planning, project recovery, identifying new story,
project re-estimation
Aug 2014
DAAD \ Fertalj
19
Ideally short iteration(s)
• The idea
• pre-determined iteration length - timeboxing
• the scope is reduced to fit the iteration length
• No consensus
• Scrum 2-4 weeks, XP & FDD 1-2 weeks → 2 weeks seems fine 
• Criteria
• team's maturity (novice-longer, experienced-shorter)
• effort = TeamSize * Iterationlength
• Variable iteration lengths
• shorter at the beginning (1wk), longer later in the project (>=2wks)
• longer 1st iteration due to the prep of infrastructure
Aug 2014
DAAD \ Fertalj
20
User story
• US is not a detailed requirement
• „A promise to have a conversation” (Cockburn)
• detailed enough to allow an effort/time estimate
• should be short – e.g. 3 sentences
• US != UC
• details are obtained during iterations
• [not] written by the customer(s)
• Partitioned interview
Aug 2014
DAAD \ Fertalj
21
“no design modeling before programming”
• The idea of avoiding „analysis paralysis”
• over-engineering and over-modelling
• Often distorts to „model & fix” approach
• code-first programming
• database refactoring
• PowerPoint architecture
• Instead, try
• Agile modelling in workshops
• Throwaway prototypes in a different language
• use of application/enterprise framework(s)
Aug 2014
DAAD \ Fertalj
22
Testing
• Unit tests can’t test overall system behaviour
•
•
•
•
Selective, e.g. unit tests for the business logic
Incremental - evolving
Repeated - regression
Automated – where possible
• Other tests
• Integration: { UI, UC, interaction, interface } testing
• System: { reqs, usability, security, performance, doc } testing
• Acceptance: { alpha, beta } testing, audit test
Aug 2014
DAAD \ Fertalj
23
Refactoring
• When to refactor
• “if it ain’t broke, don’t fix it” - refactor with a purpose
• When examining existing code to understand how it works
• After implementing a new feature
• When not to refactor
• When there is no clear plan of the improvement
• Within bug fixing
• How to refactor
• Tool support, IDE integrated
• Don’t over-refactor
• Limit to 7 ∓ 2 common out of 72++ refactorings
Aug 2014
DAAD \ Fertalj
24
Release
• „release early”
• As soon as it can add a business value to the customer
• “small release”,
• Relative: „on a 2-year project small can be after 2-3 months”
• 60-100 stories (Khramtchenko, 2004)
• „release often”
• Frequency of iterations
• Not all iterations may result in a release !
Aug 2014
DAAD \ Fertalj
25
[mostly] Energized Work
• Extended overtime is a productivity-reducing technique
(DeMarco)
• If you come in on Monday and say “To meet our goals, we’ll
have to work late again,” then you already have a problem
that can’t be solved by working more hours. (Beck & Andres
2004, 60)
• Overtime can be good 
• every now and then team members need to kick it up a gear
• such as when nearing a finish line
• or perhaps attacking a critical, user-reported defect
Aug 2014
DAAD \ Fertalj
26
Relation to other
practices
Aug 2014
DAAD \ Fertalj
27
Optimizing Agile for Your
Organization
Jenny Stuart, Vice President of
Consulting,
Construx Software Version 1,
September 2008
Positioning
Aug 2014
DAAD \ Fertalj
28
XP
Scrum
FDD
• Evolutionary
prototyping
• Evolutionary delivery
• Incremental, iterative
• 10-12 co-located,
OOPs
• XP Coach, informal
• Small teams, 6 roles
• Scrum Master,
certified
• Scalable to larger
teams
• Chief programmer(s)
• 13+11 highlyspecified, disciplined
dev. practices
• 7 practices
• 8 highly-specified dev.
practices
• 1-2 week iterations
• Stand-up meetings
• 30-day sprints
• Daily Scrum meetings
• 2-week features
• 6 milestones / feature
• Visible wall graphs
• Minimal archival doc.
• Burndown chart
• PM wrapper around
dev.
• „Burn Up” chart
• UML modelling
Aug 2014
DAAD \ Fertalj
29
Scrum vs XP
•
•
•
•
High level
Focused on PM
Sprint 2-4 weeks
The team is free to
choose features;
sequence irrelevant
• Customer cannot change
•
•
•
•
• Scrum Master, certified
• XP Coach, informal role
• requirements within
sprint
Aug 2014
Engineering practice
Programming and testing
Iteration 1-2 weeks
Features developed in a
strict order
• Requirements can change
• before work on feature
started
• new or equivalent can be
swapped
DAAD \ Fertalj
30
Scrum with XP
(Mar & Schwaber, 2002)
IPG → Sprint Backlog
„eXtreme sPrint” (Fertalj)
Variant:
Sprint Review +
Refactoring
(Zuiderveld, 2004)
Aug 2014
DAAD \ Fertalj
31
FDD vs XP
• Feature = a client-valued function that can be
implemented in 2 weeks
• Features are treated as tasks to be performed
• FDD controls the process without saying how to
implement
Aug 2014
DAAD \ Fertalj
32
FDD with XP
(Hunt, 2006)
revise features
plan iteration
repeat
start feature
break into tasks
repeat
AM & XP
until feature completed
until all features
implemented
Aug 2014
DAAD \ Fertalj
33
RUP and XP
• Universal development
framework
• Adaptable “templates”
(roadmaps)
• Best [supporting]
practices
• Detailed documentation
• Programming and testing
practice
• Basic principles
• Development practices
• dX : A minimal RUP Process (Booch et.al, 1998)
• RUP Plug-In for XP (Rational, 2002)
• RUP and XP – A Modern Perspective (Fertalj et.al, 2006)
Aug 2014
DAAD \ Fertalj
34
• Based on UP
• XP mini-waterfall
• Minimal set of UML
MOOSAD (Dennis et.al, 2005)
Minimalistic Object-Oriented Systems Analysis & Design
Aug 2014
DAAD \ Fertalj
35
IXP vs XP
• Industrial XP – „XP evolved within diverse
industries”
• Organic evolution of XP
• Minimalistic, customer-centric, test-driven spirit
• New practices
•
•
•
•
•
•
Readiness assessment
Project community
Project chartering
Test-driven management
Retrospectives
Continuous learning
• Redefined practices
• SDD, DDD, Pairing, Iterative usability, …
Aug 2014
DAAD \ Fertalj
36
References & Resources
• Hunt: Agile Software Construction, Springer, 2006
• Larman & Vodde: Practices for Scaling Lean & Agile
Development, Addison-Wesley, 2010
• Williams: A Survey of Agile Development Methodologies, 2007
• http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
• http://collaboration.csc.ncsu.edu/laurie/publicationsAll.html
• http://extremeprogramming.org/
• http://xprogramming.com/
• http://www.industrialxp.org/
Aug 2014
DAAD \ Fertalj
37
Aug 2014
DAAD \ Fertalj
38