SlideShare a Scribd company logo
1 of 37
Download to read offline
It’s XP, stupid!
Mike Harris
The Plan
• Introduce myself
• Explain why I think this is important
• Introduce eXtreme Programming
• Outline my favourite development practices
• Story of the example of outcomes
• Summarise that if you’re not doing XP, you’re not really being Agile
Why this talk?
The point is that if you’re not doing XP then it doesn’t matter what methodology
you’re using to manage the project, you’re not writing good software.
Case Study: Project X – From the Outside
• A under performing delivery team
• Experienced crew on same platform for years
• Huge backlog of unprioritized work
• Unavailable in the mornings
• Customer had no faith in team’s ability to deliver
• Master developer telling everyone what to do
• Delivery unpredictable
• Large spreadsheet of backlog representing “Grand Scheme”
Case Study: Project X – From the Inside
• Almost all code is legacy code (not tested)
• Complex tightly-coupled system (hard to change)
• Dragon infested areas of the code (can’t be changed)
• Priorities based on biggest manager ego
• No version control
• Shared dev environment
• Dev was never equal to live
Case Study: Project Y – From the Outside
• A high performing delivery team
• Experienced crew on same platform for years
• Excellent relations with customer
• Excellent inter-personal relations in team
• Perception of delivery fast and on time
• Well managed customer relations and expectations
• Lovely cycle-time graphs produced
• Nice burn-up charts delivered
Case Study: Project Y – From the Inside
• Almost all code is legacy code (not tested)
• Complex tightly-coupled system (hard to change)
• Dragon infested areas of the code (can’t be changed)
• BDD test suite takes a long time to run (and therefore is not run)
• Large overhead of story writing, development, QA hand-offs
• Deployment takes up to a day to arrange
• And up to a day to do
• Production version of code does not exist in version control
• Lots of siloed knowledge
• SysOps folks do not understand the App
My Conclusion
We’re totally flying
LEAN
AGILE
SCRUM
XP
What is XP?
A brief recap of eXtreme Programming
What is XP?
• Kent Beck
• Chrysler Comprehensive Compensation System (C3) (payroll)
• Became project leader in March 1996
• Refined methodology used on project
• Into his book ”Extreme Programming Explained”
• Which was published way back in October 1999
• The 2nd Edition of the book was published in 2004
• He didn’t invent all the practices (such as TDD)
• He codified them into an umbrella methodology: XP
XP Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect
XP Principles
• Humanity
Safe space for collaboration and growth
• Economics
Must be affordable, must meet business values
• Mutual Benefit
What we do we do for the benefit of everyone
• Self-Similarity
Reuse solutions even at different scales
• Improvement
Perfect your process; not a perfect process
• Diversity
Team members have a variety of skills, celebrate this
• Reflexion
Think about how and why we’re working in the way we are
• Flow
Deliver a steady flow of valuable software
• Opportunity
Problems are opportunities for change and improvement
• Redundancy
Solve critical difficult to solve problems in several different ways
• Failure
Don’t be afraid of it
• Quality
Do not accept lower quality to make products go faster
• Baby Steps
Do things a little bit at a time
• Accepted Responsibility
You decide if you are responsible or if you’re not
XP Practices
• Co-Located
• Whole Team
• Informative Workspace
• Energised Work
• Pair Programming
• Stories
• Weekly Cycle (iterations)
• Quarterly Cycle (releases)
• Slack
• Ten-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design
Software Engineering in 2018
Twelve development practices I’ve been doing that I think you should try
Twelve development practices
1. Pair Programming & Mob Programming
2. Test-First Test-Right Development
3. Tiny Tasking
4. Self-Documenting Code
5. Trunk Based Development
6. Systematically Check Assumptions
7. Minimum Viable Product
8. Intelligent Technical Debt
9. Automated Deployments
10. Testers are Developers
11. Know Your Tool
12. Regular Feedback
1. Do Pair and Mob Programming
• Two (or more) people share the keyboard
• Taking it in turns to be the driver
• Swapping every 10-20 minutes
• Or whenever it feels right
• Taking breaks when it feels right (and people need to)
• Breaking off to avoid ‘mob googling’
• Rotating on and off on longer stories
• Holding retros on your mobbing
• Writing a mobbing/pairing charter for your team
2. Do Test-First Test-Right Development (TDD)
• Write a test first; then write the code to make the test pass
• Refactor the code and ensure the test still passes
• Repeat
• Test at the most appropriate level of the test pyramid
• Ensuring that all code is tested once
• Unit tests are faster than high-level behavioural tests
• Don’t write unnecessary tests (for example defensive programming)
• Be careful of your code coverage tools; they can mislead
3. Use Tiny Tasking
• Break a small story into baby steps
• Plan out and agree what you’re going to do with your pairing partner
• Put the critical path on sticky notes and place them on the desk in
front
• Go into a correct level of detail
• Too many tiny tasks indicate:
• Too much up front planning
• A story that’s too big
• Tiny tasks are too small
• A new person rolling on to a story can catch up on the tasks
3. Tiny Tasking Example
4. Write Self-Documenting Code (SDC)
• Comments should document whys not whats or hows
• Code should be self-explanatory
• Use meaningful names for classes, methods, variables, etc.
• When starting out, call something a foo, until you know what it does
• Apply as many SOLID and Clean Code principles as possible
• Use your IDE to help improve your code’s readability
• Get a better IDE if it can’t help you with this (see rule 11)
5. Do Trunk Based Development (TBD)
• Everything we do ought to be production ready
• Merge to trunk as soon as possible
• Ideally multiple times daily
• Branches should only survive overnight
• Delete branches when you start work again
• Use expand and contract techniques
• Spike (experiment) branches may live a little longer
• But they too should be as short-lived as possible
• And they should never become production code (rewrite using TDD)
6. Systematically Check Assumptions
• When you get stuck on something
• Pair or swarm with your colleagues
• Use a board and ask each other
• What you know
• What you don’t know
• What you think you know
• Agree on next steps to confirm what you think
you know
• Timebox and regroup to measure progress
7. Aim for a Minimum Viable Product (MVP)
• Keep the stories small
• Do the smallest thing to prove an idea
• Minimise defensive programming
• Use spikes, showcase prototypes, use the command line
• Stories are placeholders for conversations
• Practice Just In Time Analysis (JITA) where possible
• Descope continually
8. Take on Intelligent Technical Debt (ITD)
• It’s about knowing what the risks are
• Keep a Tech Debt Wall
• Note down any technical debt you accrue as you develop
• Consider the risk of postponing resolution vs the cost of sorting now
• Don’t engineer the future: resolve in the next iteration
• Regularly review the Tech Debt Wall
• Categorise the debt on the wall
• Take highest risk technical debt into backlog and resolve
8. ITD example (using Trello)
9. Aim for Automated Deployment (AD)
• May be a stretch goal in your organization
• SysOps may be siloed and traditional
• Platform and/or stack might not permit it
• Allow developers to learn the platform
• Cloud computing makes this much more possible
• Infrastructure as code (CloudFormation, Terraform)
• Means your infrastructure can be version controlled
• Ensure QA, Dev, Staging environments same as Prod
9. Automated Deployment example
10. Testers are Developers
• Testers are developers; developers are testers
• May work best with smaller teams
• Developers pair to write tests
• Developers pair to write code
• Last pair on story do not do QA; another pair does
• Avoids hand-offs (contracts between Dev & QA)
• Enforces developers’ responsibility for writing quality code
• Developers who do QA also see the code (mob effect)
• Get faster feedback
11. Know Your Tool
• Use your tool’s support for refactoring
• Learn your tool’s most useful keyboard shortcuts
• Learn how to configure your tool
• Ensure you can run tests from within your tool
• Use the best tool for the code base you’re working on
• Insist on licences for the best tool for your team
12. Feedback
• Regularly schedule time with your collegaues
• To give face-to-face feedback
• Discuss what you feel your colleague’s strengths are
• Discuss what you feel your colleagure could do to improve
• Use real examples from your experience working with them
• Make sure you prepare
12. Feedback - Example
Observed Behaviour Observed Result Remarks
Was patient with colleague
who didn’t understand the
reasons why we write the
test first. Spent time to work
with them using coding
dojos.
Colleague felt they were
listened to and their
concerns met; was more
open to pairing.
Supportive and
understanding approach a
great asset to the team.
Helps make people feel safer
when challenged by new
ideas and ways of working.
Regularly arrives at stand-ups
late.
Flow of stand-up is often
disrupted, and colleagues
often have to repeat
themselves.
Arriving late is an anti-
pattern and, even if not
intentionally, shows a lack of
respect.
Outcomes
What we found when we applied the practices
Case Study: Project Z – Where we were
• We were doing the Twelve Practices I’ve outlined
• Our Tech Lead and founding architect left for a smaller company
• Two other contracted developers moved on at the same time
• We took on two new developers shortly afterwards
• We were a small team with lots of risk
• Loosing critical mass on our dev practices was a possibility
• There was potentially a lot of overhead onboarding new folks
• And this would slow us down
Case Study: Project Z – The Results
• The fact we’d done pair programming meant
• All developers had some knowledge of every part of the software
• Within weeks we were able to do a complete hand-over
• And made a smooth transition to a new tech lead
• Pairing and mobbing meant that new devs could do valuable work
from day one
• Our code was self-documenting and covered by descriptive tests
• Helped with onboarding new members
• No balls were dropped
In Summary
• Adopting Scrum or Kanban, or a hybrid, on it’s own is not enough
• It alone doesn’t lead to doing Agile or Lean Software Development
• But rather they are simply ways of doing project management
• XP helps you to mitigate against legacy code
• XP helps you write better software
• You may not be able to do everything
• But at least do some of the things
• Keep at it, you’ll get there
Thank You
Mike Harris . mbharris.co.uk . mike@mbharris.co.uk
ssrn.com . m.harris@elsevier.com . +44 7811 671 893

More Related Content

What's hot

Scrum and-xp-from-the-trenches 05 release planning & scrum with xp
Scrum and-xp-from-the-trenches 05 release planning & scrum with xpScrum and-xp-from-the-trenches 05 release planning & scrum with xp
Scrum and-xp-from-the-trenches 05 release planning & scrum with xpHossam Hassan
 
Morph your mindset for Continuous Delivery, Agile Roots 2014
Morph your mindset for Continuous Delivery,  Agile Roots 2014Morph your mindset for Continuous Delivery,  Agile Roots 2014
Morph your mindset for Continuous Delivery, Agile Roots 2014lisacrispin
 
Don't scale agile. Descale your organisation.
Don't scale agile. Descale your organisation.Don't scale agile. Descale your organisation.
Don't scale agile. Descale your organisation.sbargon
 
Scrum and-xp-from-the-trenches 01 intro & backlog
Scrum and-xp-from-the-trenches 01 intro & backlogScrum and-xp-from-the-trenches 01 intro & backlog
Scrum and-xp-from-the-trenches 01 intro & backlogHossam Hassan
 
Scrum and-xp-from-the-trenches 03 sprint backlog & daily scrum
Scrum and-xp-from-the-trenches 03 sprint backlog & daily scrumScrum and-xp-from-the-trenches 03 sprint backlog & daily scrum
Scrum and-xp-from-the-trenches 03 sprint backlog & daily scrumHossam Hassan
 
Devops, the future is here it's not evenly distributed yet
Devops, the future is here it's not evenly distributed yetDevops, the future is here it's not evenly distributed yet
Devops, the future is here it's not evenly distributed yetKris Buytaert
 
Scrum and-xp-from-the-trenches 04 sprint demo & retrospective
Scrum and-xp-from-the-trenches 04 sprint demo & retrospectiveScrum and-xp-from-the-trenches 04 sprint demo & retrospective
Scrum and-xp-from-the-trenches 04 sprint demo & retrospectiveHossam Hassan
 
Pair Programming, TDD and other impractical things
Pair Programming, TDD and other impractical thingsPair Programming, TDD and other impractical things
Pair Programming, TDD and other impractical thingsMarcello Duarte
 
A CTOs Perspective on Agile
A CTOs Perspective on AgileA CTOs Perspective on Agile
A CTOs Perspective on AgileBradley Brown
 
Shipping code is not the problem, deciding what to ship it is!
Shipping code is not the problem, deciding what to ship it is!Shipping code is not the problem, deciding what to ship it is!
Shipping code is not the problem, deciding what to ship it is!Mauro Servienti
 
Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklist
Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklistScrum and-xp-from-the-trenches 08 distributed teams & scrum master checklist
Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklistHossam Hassan
 
Scrum and-xp-from-the-trenches 07 handle multiple scrum teams
Scrum and-xp-from-the-trenches 07 handle multiple scrum teamsScrum and-xp-from-the-trenches 07 handle multiple scrum teams
Scrum and-xp-from-the-trenches 07 handle multiple scrum teamsHossam Hassan
 
Scala Days Chicago 2017: Building a Company on Scala
Scala Days Chicago 2017: Building a Company on ScalaScala Days Chicago 2017: Building a Company on Scala
Scala Days Chicago 2017: Building a Company on ScalaNatalie Vegel
 
High Quality C# - Codequality in Practice
High Quality C# - Codequality in PracticeHigh Quality C# - Codequality in Practice
High Quality C# - Codequality in PracticeRainer Stropek
 

What's hot (20)

Scrum and-xp-from-the-trenches 05 release planning & scrum with xp
Scrum and-xp-from-the-trenches 05 release planning & scrum with xpScrum and-xp-from-the-trenches 05 release planning & scrum with xp
Scrum and-xp-from-the-trenches 05 release planning & scrum with xp
 
Morph your mindset for Continuous Delivery, Agile Roots 2014
Morph your mindset for Continuous Delivery,  Agile Roots 2014Morph your mindset for Continuous Delivery,  Agile Roots 2014
Morph your mindset for Continuous Delivery, Agile Roots 2014
 
Don't scale agile. Descale your organisation.
Don't scale agile. Descale your organisation.Don't scale agile. Descale your organisation.
Don't scale agile. Descale your organisation.
 
Scrum and-xp-from-the-trenches 01 intro & backlog
Scrum and-xp-from-the-trenches 01 intro & backlogScrum and-xp-from-the-trenches 01 intro & backlog
Scrum and-xp-from-the-trenches 01 intro & backlog
 
Scrum and-xp-from-the-trenches 03 sprint backlog & daily scrum
Scrum and-xp-from-the-trenches 03 sprint backlog & daily scrumScrum and-xp-from-the-trenches 03 sprint backlog & daily scrum
Scrum and-xp-from-the-trenches 03 sprint backlog & daily scrum
 
Devops, the future is here it's not evenly distributed yet
Devops, the future is here it's not evenly distributed yetDevops, the future is here it's not evenly distributed yet
Devops, the future is here it's not evenly distributed yet
 
The Road to DITA
The Road to DITAThe Road to DITA
The Road to DITA
 
Intro to Agile Practices and Values
Intro to Agile Practices and ValuesIntro to Agile Practices and Values
Intro to Agile Practices and Values
 
Scrum and-xp-from-the-trenches 04 sprint demo & retrospective
Scrum and-xp-from-the-trenches 04 sprint demo & retrospectiveScrum and-xp-from-the-trenches 04 sprint demo & retrospective
Scrum and-xp-from-the-trenches 04 sprint demo & retrospective
 
Pair Programming, TDD and other impractical things
Pair Programming, TDD and other impractical thingsPair Programming, TDD and other impractical things
Pair Programming, TDD and other impractical things
 
A CTOs Perspective on Agile
A CTOs Perspective on AgileA CTOs Perspective on Agile
A CTOs Perspective on Agile
 
Shipping code is not the problem, deciding what to ship it is!
Shipping code is not the problem, deciding what to ship it is!Shipping code is not the problem, deciding what to ship it is!
Shipping code is not the problem, deciding what to ship it is!
 
Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklist
Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklistScrum and-xp-from-the-trenches 08 distributed teams & scrum master checklist
Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklist
 
Agile Room Dynamics
Agile Room Dynamics   Agile Room Dynamics
Agile Room Dynamics
 
Scrum and-xp-from-the-trenches 07 handle multiple scrum teams
Scrum and-xp-from-the-trenches 07 handle multiple scrum teamsScrum and-xp-from-the-trenches 07 handle multiple scrum teams
Scrum and-xp-from-the-trenches 07 handle multiple scrum teams
 
Agile engineering practices
Agile engineering practicesAgile engineering practices
Agile engineering practices
 
Scala Days Chicago 2017: Building a Company on Scala
Scala Days Chicago 2017: Building a Company on ScalaScala Days Chicago 2017: Building a Company on Scala
Scala Days Chicago 2017: Building a Company on Scala
 
DevOps Requires Agility
DevOps Requires AgilityDevOps Requires Agility
DevOps Requires Agility
 
High Quality C# - Codequality in Practice
High Quality C# - Codequality in PracticeHigh Quality C# - Codequality in Practice
High Quality C# - Codequality in Practice
 
Scrum intro
Scrum intro Scrum intro
Scrum intro
 

Similar to It's XP, Stupid

Driving application development through behavior driven development
Driving application development through behavior driven developmentDriving application development through behavior driven development
Driving application development through behavior driven developmentEinar Ingebrigtsen
 
Twelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btechTwelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btechIIITA
 
The 360 Developer
The 360 DeveloperThe 360 Developer
The 360 Developerenteritos
 
Agile Software Development
Agile Software DevelopmentAgile Software Development
Agile Software DevelopmentAhmet Bulut
 
Lessons learned after 190M lessons served
Lessons learned after 190M lessons servedLessons learned after 190M lessons served
Lessons learned after 190M lessons servedRicardo Bánffy
 
Creating change from within - Agile Practitioners 2012
Creating change from within - Agile Practitioners 2012Creating change from within - Agile Practitioners 2012
Creating change from within - Agile Practitioners 2012Dror Helper
 
TDD - Seriously, try it! (updated '22)
TDD - Seriously, try it! (updated '22)TDD - Seriously, try it! (updated '22)
TDD - Seriously, try it! (updated '22)Nacho Cougil
 
Random thoughts and dev practices / advices to build a great product
Random thoughts and dev practices / advices to build a great productRandom thoughts and dev practices / advices to build a great product
Random thoughts and dev practices / advices to build a great productGuillaume POTIER
 
Getting Started with Architecture Decision Records
Getting Started with Architecture Decision RecordsGetting Started with Architecture Decision Records
Getting Started with Architecture Decision RecordsMichael Keeling
 
Arch factory - Agile Design: Best Practices
Arch factory - Agile Design: Best PracticesArch factory - Agile Design: Best Practices
Arch factory - Agile Design: Best PracticesIgor Moochnick
 
Become Efficient or Die: The Story of BackType
Become Efficient or Die: The Story of BackTypeBecome Efficient or Die: The Story of BackType
Become Efficient or Die: The Story of BackTypenathanmarz
 
TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)
TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)
TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)ssusercaf6c1
 
TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)
TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)
TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)Nacho Cougil
 
Technical Writing Overview: WTD Nigeria
Technical Writing Overview: WTD NigeriaTechnical Writing Overview: WTD Nigeria
Technical Writing Overview: WTD NigeriaMargaret Fero
 
Chris Covell Collaboration for distributed teams
Chris Covell   Collaboration for distributed teamsChris Covell   Collaboration for distributed teams
Chris Covell Collaboration for distributed teamsAgile Lietuva
 
TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012Alan Christensen
 

Similar to It's XP, Stupid (20)

Driving application development through behavior driven development
Driving application development through behavior driven developmentDriving application development through behavior driven development
Driving application development through behavior driven development
 
Twelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btechTwelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btech
 
Agile
AgileAgile
Agile
 
The 360 Developer
The 360 DeveloperThe 360 Developer
The 360 Developer
 
Agile Software Development
Agile Software DevelopmentAgile Software Development
Agile Software Development
 
Lessons learned after 190M lessons served
Lessons learned after 190M lessons servedLessons learned after 190M lessons served
Lessons learned after 190M lessons served
 
Creating change from within - Agile Practitioners 2012
Creating change from within - Agile Practitioners 2012Creating change from within - Agile Practitioners 2012
Creating change from within - Agile Practitioners 2012
 
TDD - Seriously, try it! (updated '22)
TDD - Seriously, try it! (updated '22)TDD - Seriously, try it! (updated '22)
TDD - Seriously, try it! (updated '22)
 
Random thoughts and dev practices / advices to build a great product
Random thoughts and dev practices / advices to build a great productRandom thoughts and dev practices / advices to build a great product
Random thoughts and dev practices / advices to build a great product
 
Getting Started with Architecture Decision Records
Getting Started with Architecture Decision RecordsGetting Started with Architecture Decision Records
Getting Started with Architecture Decision Records
 
Secrets of Scrum
Secrets of ScrumSecrets of Scrum
Secrets of Scrum
 
What is xp
What is xpWhat is xp
What is xp
 
Arch factory - Agile Design: Best Practices
Arch factory - Agile Design: Best PracticesArch factory - Agile Design: Best Practices
Arch factory - Agile Design: Best Practices
 
Become Efficient or Die: The Story of BackType
Become Efficient or Die: The Story of BackTypeBecome Efficient or Die: The Story of BackType
Become Efficient or Die: The Story of BackType
 
Extreme programming (xp)
Extreme programming (xp)Extreme programming (xp)
Extreme programming (xp)
 
TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)
TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)
TDD - Seriously, try it! - Trójmiasto Java User Group (17th May '23)
 
TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)
TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)
TDD - Seriously, try it! - Trjjmiasto JUG (17th May '23)
 
Technical Writing Overview: WTD Nigeria
Technical Writing Overview: WTD NigeriaTechnical Writing Overview: WTD Nigeria
Technical Writing Overview: WTD Nigeria
 
Chris Covell Collaboration for distributed teams
Chris Covell   Collaboration for distributed teamsChris Covell   Collaboration for distributed teams
Chris Covell Collaboration for distributed teams
 
TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012
 

More from Mike Harris

Clean COBOL Lightning Talk - Ox:Agile 2019
Clean COBOL Lightning Talk - Ox:Agile 2019Clean COBOL Lightning Talk - Ox:Agile 2019
Clean COBOL Lightning Talk - Ox:Agile 2019Mike Harris
 
Using neuroscience to build high performance teams - Elaine Sullivan
Using neuroscience to build high performance teams - Elaine SullivanUsing neuroscience to build high performance teams - Elaine Sullivan
Using neuroscience to build high performance teams - Elaine SullivanMike Harris
 
Kotlin - A very quick introduction
Kotlin - A very quick introductionKotlin - A very quick introduction
Kotlin - A very quick introductionMike Harris
 
A Brief Introduction to Kanban
A Brief Introduction to KanbanA Brief Introduction to Kanban
A Brief Introduction to KanbanMike Harris
 
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018Mike Harris
 
Contract Testing: An Introduction
Contract Testing: An IntroductionContract Testing: An Introduction
Contract Testing: An IntroductionMike Harris
 
Being a better programmer: Writing Clean COBOL
Being a better programmer: Writing Clean COBOLBeing a better programmer: Writing Clean COBOL
Being a better programmer: Writing Clean COBOLMike Harris
 
Aws assimilation
Aws assimilationAws assimilation
Aws assimilationMike Harris
 
This is heavy doc! Lessons on just in time architecture - Adrian Potter
This is heavy doc! Lessons on just in time architecture - Adrian PotterThis is heavy doc! Lessons on just in time architecture - Adrian Potter
This is heavy doc! Lessons on just in time architecture - Adrian PotterMike Harris
 
Working towards ideal ux, product and tech partnership
Working towards ideal ux, product and tech partnershipWorking towards ideal ux, product and tech partnership
Working towards ideal ux, product and tech partnershipMike Harris
 
Agile around the World - Glaudia Califano
Agile around the World - Glaudia Califano Agile around the World - Glaudia Califano
Agile around the World - Glaudia Califano Mike Harris
 
How To Handle Your Tech Debt Better - Sean Moir
How To Handle Your Tech Debt Better - Sean MoirHow To Handle Your Tech Debt Better - Sean Moir
How To Handle Your Tech Debt Better - Sean MoirMike Harris
 
Welcome to Elsevier - presentation for Ox:Agile Conference
Welcome to Elsevier - presentation for Ox:Agile ConferenceWelcome to Elsevier - presentation for Ox:Agile Conference
Welcome to Elsevier - presentation for Ox:Agile ConferenceMike Harris
 
HacktionLab: how LEAN is your non-hierarchical community education project
HacktionLab: how LEAN is your non-hierarchical community education projectHacktionLab: how LEAN is your non-hierarchical community education project
HacktionLab: how LEAN is your non-hierarchical community education projectMike Harris
 
How I Learned to Stop Worrying and Love Legacy Code.....
How I Learned to Stop Worrying and Love Legacy Code.....How I Learned to Stop Worrying and Love Legacy Code.....
How I Learned to Stop Worrying and Love Legacy Code.....Mike Harris
 

More from Mike Harris (15)

Clean COBOL Lightning Talk - Ox:Agile 2019
Clean COBOL Lightning Talk - Ox:Agile 2019Clean COBOL Lightning Talk - Ox:Agile 2019
Clean COBOL Lightning Talk - Ox:Agile 2019
 
Using neuroscience to build high performance teams - Elaine Sullivan
Using neuroscience to build high performance teams - Elaine SullivanUsing neuroscience to build high performance teams - Elaine Sullivan
Using neuroscience to build high performance teams - Elaine Sullivan
 
Kotlin - A very quick introduction
Kotlin - A very quick introductionKotlin - A very quick introduction
Kotlin - A very quick introduction
 
A Brief Introduction to Kanban
A Brief Introduction to KanbanA Brief Introduction to Kanban
A Brief Introduction to Kanban
 
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018
 
Contract Testing: An Introduction
Contract Testing: An IntroductionContract Testing: An Introduction
Contract Testing: An Introduction
 
Being a better programmer: Writing Clean COBOL
Being a better programmer: Writing Clean COBOLBeing a better programmer: Writing Clean COBOL
Being a better programmer: Writing Clean COBOL
 
Aws assimilation
Aws assimilationAws assimilation
Aws assimilation
 
This is heavy doc! Lessons on just in time architecture - Adrian Potter
This is heavy doc! Lessons on just in time architecture - Adrian PotterThis is heavy doc! Lessons on just in time architecture - Adrian Potter
This is heavy doc! Lessons on just in time architecture - Adrian Potter
 
Working towards ideal ux, product and tech partnership
Working towards ideal ux, product and tech partnershipWorking towards ideal ux, product and tech partnership
Working towards ideal ux, product and tech partnership
 
Agile around the World - Glaudia Califano
Agile around the World - Glaudia Califano Agile around the World - Glaudia Califano
Agile around the World - Glaudia Califano
 
How To Handle Your Tech Debt Better - Sean Moir
How To Handle Your Tech Debt Better - Sean MoirHow To Handle Your Tech Debt Better - Sean Moir
How To Handle Your Tech Debt Better - Sean Moir
 
Welcome to Elsevier - presentation for Ox:Agile Conference
Welcome to Elsevier - presentation for Ox:Agile ConferenceWelcome to Elsevier - presentation for Ox:Agile Conference
Welcome to Elsevier - presentation for Ox:Agile Conference
 
HacktionLab: how LEAN is your non-hierarchical community education project
HacktionLab: how LEAN is your non-hierarchical community education projectHacktionLab: how LEAN is your non-hierarchical community education project
HacktionLab: how LEAN is your non-hierarchical community education project
 
How I Learned to Stop Worrying and Love Legacy Code.....
How I Learned to Stop Worrying and Love Legacy Code.....How I Learned to Stop Worrying and Love Legacy Code.....
How I Learned to Stop Worrying and Love Legacy Code.....
 

Recently uploaded

Business Analyzopedia - Your Pocket Gita for Business Analysis
Business Analyzopedia - Your Pocket Gita for Business AnalysisBusiness Analyzopedia - Your Pocket Gita for Business Analysis
Business Analyzopedia - Your Pocket Gita for Business AnalysisDEEPRAJ PATHAK
 
Enhancing Supply Chain Visibility with Cargo Cloud Solutions.pdf
Enhancing Supply Chain Visibility with Cargo Cloud Solutions.pdfEnhancing Supply Chain Visibility with Cargo Cloud Solutions.pdf
Enhancing Supply Chain Visibility with Cargo Cloud Solutions.pdfRTS corp
 
Advantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptxAdvantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptxRTS corp
 
Keeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository worldKeeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository worldRoberto Pérez Alcolea
 
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdfSteve Caron
 
Ronisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited CatalogueRonisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited Catalogueitservices996
 
logical backup of Oracle Datapump-detailed.pptx
logical backup of Oracle Datapump-detailed.pptxlogical backup of Oracle Datapump-detailed.pptx
logical backup of Oracle Datapump-detailed.pptxRemote DBA Services
 
VictoriaMetrics Q1 Meet Up '24 - Community & News Update
VictoriaMetrics Q1 Meet Up '24 - Community & News UpdateVictoriaMetrics Q1 Meet Up '24 - Community & News Update
VictoriaMetrics Q1 Meet Up '24 - Community & News UpdateVictoriaMetrics
 
Effort Estimation Techniques used in Software Projects
Effort Estimation Techniques used in Software ProjectsEffort Estimation Techniques used in Software Projects
Effort Estimation Techniques used in Software ProjectsDEEPRAJ PATHAK
 
Osi security architecture in network.pptx
Osi security architecture in network.pptxOsi security architecture in network.pptx
Osi security architecture in network.pptxVinzoCenzo
 
Revolutionize Your Video Editing with InVideo.io: A Comprehensive Review
Revolutionize Your Video Editing with InVideo.io: A Comprehensive ReviewRevolutionize Your Video Editing with InVideo.io: A Comprehensive Review
Revolutionize Your Video Editing with InVideo.io: A Comprehensive Reviewjw364beach
 
2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdf
2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdf2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdf
2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdfAndrey Devyatkin
 
Understanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptxUnderstanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptxSasikiranMarri
 
Introduction to Firebase Workshop Slides
Introduction to Firebase Workshop SlidesIntroduction to Firebase Workshop Slides
Introduction to Firebase Workshop Slidesvaideheekore1
 
Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...
Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...
Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...OnePlan Solutions
 
Zer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdfZer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdfmaor17
 
Key Steps in Agile Software Delivery Roadmap
Key Steps in Agile Software Delivery RoadmapKey Steps in Agile Software Delivery Roadmap
Key Steps in Agile Software Delivery RoadmapIshara Amarasekera
 
Effectively Troubleshoot 9 Types of OutOfMemoryError
Effectively Troubleshoot 9 Types of OutOfMemoryErrorEffectively Troubleshoot 9 Types of OutOfMemoryError
Effectively Troubleshoot 9 Types of OutOfMemoryErrorTier1 app
 
Santander Stream Processing with Apache Flink
Santander Stream Processing with Apache FlinkSantander Stream Processing with Apache Flink
Santander Stream Processing with Apache Flinkconfluent
 
What is Mendix and the concept of low-code development.docx
What is Mendix and the concept of low-code development.docxWhat is Mendix and the concept of low-code development.docx
What is Mendix and the concept of low-code development.docxTechnogeeks
 

Recently uploaded (20)

Business Analyzopedia - Your Pocket Gita for Business Analysis
Business Analyzopedia - Your Pocket Gita for Business AnalysisBusiness Analyzopedia - Your Pocket Gita for Business Analysis
Business Analyzopedia - Your Pocket Gita for Business Analysis
 
Enhancing Supply Chain Visibility with Cargo Cloud Solutions.pdf
Enhancing Supply Chain Visibility with Cargo Cloud Solutions.pdfEnhancing Supply Chain Visibility with Cargo Cloud Solutions.pdf
Enhancing Supply Chain Visibility with Cargo Cloud Solutions.pdf
 
Advantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptxAdvantages of Cargo Cloud Solutions.pptx
Advantages of Cargo Cloud Solutions.pptx
 
Keeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository worldKeeping your build tool updated in a multi repository world
Keeping your build tool updated in a multi repository world
 
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
[ CNCF Q1 2024 ] Intro to Continuous Profiling and Grafana Pyroscope.pdf
 
Ronisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited CatalogueRonisha Informatics Private Limited Catalogue
Ronisha Informatics Private Limited Catalogue
 
logical backup of Oracle Datapump-detailed.pptx
logical backup of Oracle Datapump-detailed.pptxlogical backup of Oracle Datapump-detailed.pptx
logical backup of Oracle Datapump-detailed.pptx
 
VictoriaMetrics Q1 Meet Up '24 - Community & News Update
VictoriaMetrics Q1 Meet Up '24 - Community & News UpdateVictoriaMetrics Q1 Meet Up '24 - Community & News Update
VictoriaMetrics Q1 Meet Up '24 - Community & News Update
 
Effort Estimation Techniques used in Software Projects
Effort Estimation Techniques used in Software ProjectsEffort Estimation Techniques used in Software Projects
Effort Estimation Techniques used in Software Projects
 
Osi security architecture in network.pptx
Osi security architecture in network.pptxOsi security architecture in network.pptx
Osi security architecture in network.pptx
 
Revolutionize Your Video Editing with InVideo.io: A Comprehensive Review
Revolutionize Your Video Editing with InVideo.io: A Comprehensive ReviewRevolutionize Your Video Editing with InVideo.io: A Comprehensive Review
Revolutionize Your Video Editing with InVideo.io: A Comprehensive Review
 
2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdf
2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdf2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdf
2024-04-09 - From Complexity to Clarity - AWS Summit AMS.pdf
 
Understanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptxUnderstanding Plagiarism: Causes, Consequences and Prevention.pptx
Understanding Plagiarism: Causes, Consequences and Prevention.pptx
 
Introduction to Firebase Workshop Slides
Introduction to Firebase Workshop SlidesIntroduction to Firebase Workshop Slides
Introduction to Firebase Workshop Slides
 
Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...
Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...
Revolutionizing the Digital Transformation Office - Leveraging OnePlan’s AI a...
 
Zer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdfZer0con 2024 final share short version.pdf
Zer0con 2024 final share short version.pdf
 
Key Steps in Agile Software Delivery Roadmap
Key Steps in Agile Software Delivery RoadmapKey Steps in Agile Software Delivery Roadmap
Key Steps in Agile Software Delivery Roadmap
 
Effectively Troubleshoot 9 Types of OutOfMemoryError
Effectively Troubleshoot 9 Types of OutOfMemoryErrorEffectively Troubleshoot 9 Types of OutOfMemoryError
Effectively Troubleshoot 9 Types of OutOfMemoryError
 
Santander Stream Processing with Apache Flink
Santander Stream Processing with Apache FlinkSantander Stream Processing with Apache Flink
Santander Stream Processing with Apache Flink
 
What is Mendix and the concept of low-code development.docx
What is Mendix and the concept of low-code development.docxWhat is Mendix and the concept of low-code development.docx
What is Mendix and the concept of low-code development.docx
 

It's XP, Stupid

  • 2. The Plan • Introduce myself • Explain why I think this is important • Introduce eXtreme Programming • Outline my favourite development practices • Story of the example of outcomes • Summarise that if you’re not doing XP, you’re not really being Agile
  • 3. Why this talk? The point is that if you’re not doing XP then it doesn’t matter what methodology you’re using to manage the project, you’re not writing good software.
  • 4. Case Study: Project X – From the Outside • A under performing delivery team • Experienced crew on same platform for years • Huge backlog of unprioritized work • Unavailable in the mornings • Customer had no faith in team’s ability to deliver • Master developer telling everyone what to do • Delivery unpredictable • Large spreadsheet of backlog representing “Grand Scheme”
  • 5. Case Study: Project X – From the Inside • Almost all code is legacy code (not tested) • Complex tightly-coupled system (hard to change) • Dragon infested areas of the code (can’t be changed) • Priorities based on biggest manager ego • No version control • Shared dev environment • Dev was never equal to live
  • 6. Case Study: Project Y – From the Outside • A high performing delivery team • Experienced crew on same platform for years • Excellent relations with customer • Excellent inter-personal relations in team • Perception of delivery fast and on time • Well managed customer relations and expectations • Lovely cycle-time graphs produced • Nice burn-up charts delivered
  • 7. Case Study: Project Y – From the Inside • Almost all code is legacy code (not tested) • Complex tightly-coupled system (hard to change) • Dragon infested areas of the code (can’t be changed) • BDD test suite takes a long time to run (and therefore is not run) • Large overhead of story writing, development, QA hand-offs • Deployment takes up to a day to arrange • And up to a day to do • Production version of code does not exist in version control • Lots of siloed knowledge • SysOps folks do not understand the App
  • 10. What is XP? A brief recap of eXtreme Programming
  • 11. What is XP? • Kent Beck • Chrysler Comprehensive Compensation System (C3) (payroll) • Became project leader in March 1996 • Refined methodology used on project • Into his book ”Extreme Programming Explained” • Which was published way back in October 1999 • The 2nd Edition of the book was published in 2004 • He didn’t invent all the practices (such as TDD) • He codified them into an umbrella methodology: XP
  • 12. XP Values • Communication • Simplicity • Feedback • Courage • Respect
  • 13. XP Principles • Humanity Safe space for collaboration and growth • Economics Must be affordable, must meet business values • Mutual Benefit What we do we do for the benefit of everyone • Self-Similarity Reuse solutions even at different scales • Improvement Perfect your process; not a perfect process • Diversity Team members have a variety of skills, celebrate this • Reflexion Think about how and why we’re working in the way we are • Flow Deliver a steady flow of valuable software • Opportunity Problems are opportunities for change and improvement • Redundancy Solve critical difficult to solve problems in several different ways • Failure Don’t be afraid of it • Quality Do not accept lower quality to make products go faster • Baby Steps Do things a little bit at a time • Accepted Responsibility You decide if you are responsible or if you’re not
  • 14. XP Practices • Co-Located • Whole Team • Informative Workspace • Energised Work • Pair Programming • Stories • Weekly Cycle (iterations) • Quarterly Cycle (releases) • Slack • Ten-Minute Build • Continuous Integration • Test-First Programming • Incremental Design
  • 15. Software Engineering in 2018 Twelve development practices I’ve been doing that I think you should try
  • 16. Twelve development practices 1. Pair Programming & Mob Programming 2. Test-First Test-Right Development 3. Tiny Tasking 4. Self-Documenting Code 5. Trunk Based Development 6. Systematically Check Assumptions 7. Minimum Viable Product 8. Intelligent Technical Debt 9. Automated Deployments 10. Testers are Developers 11. Know Your Tool 12. Regular Feedback
  • 17. 1. Do Pair and Mob Programming • Two (or more) people share the keyboard • Taking it in turns to be the driver • Swapping every 10-20 minutes • Or whenever it feels right • Taking breaks when it feels right (and people need to) • Breaking off to avoid ‘mob googling’ • Rotating on and off on longer stories • Holding retros on your mobbing • Writing a mobbing/pairing charter for your team
  • 18. 2. Do Test-First Test-Right Development (TDD) • Write a test first; then write the code to make the test pass • Refactor the code and ensure the test still passes • Repeat • Test at the most appropriate level of the test pyramid • Ensuring that all code is tested once • Unit tests are faster than high-level behavioural tests • Don’t write unnecessary tests (for example defensive programming) • Be careful of your code coverage tools; they can mislead
  • 19. 3. Use Tiny Tasking • Break a small story into baby steps • Plan out and agree what you’re going to do with your pairing partner • Put the critical path on sticky notes and place them on the desk in front • Go into a correct level of detail • Too many tiny tasks indicate: • Too much up front planning • A story that’s too big • Tiny tasks are too small • A new person rolling on to a story can catch up on the tasks
  • 20. 3. Tiny Tasking Example
  • 21. 4. Write Self-Documenting Code (SDC) • Comments should document whys not whats or hows • Code should be self-explanatory • Use meaningful names for classes, methods, variables, etc. • When starting out, call something a foo, until you know what it does • Apply as many SOLID and Clean Code principles as possible • Use your IDE to help improve your code’s readability • Get a better IDE if it can’t help you with this (see rule 11)
  • 22. 5. Do Trunk Based Development (TBD) • Everything we do ought to be production ready • Merge to trunk as soon as possible • Ideally multiple times daily • Branches should only survive overnight • Delete branches when you start work again • Use expand and contract techniques • Spike (experiment) branches may live a little longer • But they too should be as short-lived as possible • And they should never become production code (rewrite using TDD)
  • 23. 6. Systematically Check Assumptions • When you get stuck on something • Pair or swarm with your colleagues • Use a board and ask each other • What you know • What you don’t know • What you think you know • Agree on next steps to confirm what you think you know • Timebox and regroup to measure progress
  • 24. 7. Aim for a Minimum Viable Product (MVP) • Keep the stories small • Do the smallest thing to prove an idea • Minimise defensive programming • Use spikes, showcase prototypes, use the command line • Stories are placeholders for conversations • Practice Just In Time Analysis (JITA) where possible • Descope continually
  • 25. 8. Take on Intelligent Technical Debt (ITD) • It’s about knowing what the risks are • Keep a Tech Debt Wall • Note down any technical debt you accrue as you develop • Consider the risk of postponing resolution vs the cost of sorting now • Don’t engineer the future: resolve in the next iteration • Regularly review the Tech Debt Wall • Categorise the debt on the wall • Take highest risk technical debt into backlog and resolve
  • 26. 8. ITD example (using Trello)
  • 27. 9. Aim for Automated Deployment (AD) • May be a stretch goal in your organization • SysOps may be siloed and traditional • Platform and/or stack might not permit it • Allow developers to learn the platform • Cloud computing makes this much more possible • Infrastructure as code (CloudFormation, Terraform) • Means your infrastructure can be version controlled • Ensure QA, Dev, Staging environments same as Prod
  • 29. 10. Testers are Developers • Testers are developers; developers are testers • May work best with smaller teams • Developers pair to write tests • Developers pair to write code • Last pair on story do not do QA; another pair does • Avoids hand-offs (contracts between Dev & QA) • Enforces developers’ responsibility for writing quality code • Developers who do QA also see the code (mob effect) • Get faster feedback
  • 30. 11. Know Your Tool • Use your tool’s support for refactoring • Learn your tool’s most useful keyboard shortcuts • Learn how to configure your tool • Ensure you can run tests from within your tool • Use the best tool for the code base you’re working on • Insist on licences for the best tool for your team
  • 31. 12. Feedback • Regularly schedule time with your collegaues • To give face-to-face feedback • Discuss what you feel your colleague’s strengths are • Discuss what you feel your colleagure could do to improve • Use real examples from your experience working with them • Make sure you prepare
  • 32. 12. Feedback - Example Observed Behaviour Observed Result Remarks Was patient with colleague who didn’t understand the reasons why we write the test first. Spent time to work with them using coding dojos. Colleague felt they were listened to and their concerns met; was more open to pairing. Supportive and understanding approach a great asset to the team. Helps make people feel safer when challenged by new ideas and ways of working. Regularly arrives at stand-ups late. Flow of stand-up is often disrupted, and colleagues often have to repeat themselves. Arriving late is an anti- pattern and, even if not intentionally, shows a lack of respect.
  • 33. Outcomes What we found when we applied the practices
  • 34. Case Study: Project Z – Where we were • We were doing the Twelve Practices I’ve outlined • Our Tech Lead and founding architect left for a smaller company • Two other contracted developers moved on at the same time • We took on two new developers shortly afterwards • We were a small team with lots of risk • Loosing critical mass on our dev practices was a possibility • There was potentially a lot of overhead onboarding new folks • And this would slow us down
  • 35. Case Study: Project Z – The Results • The fact we’d done pair programming meant • All developers had some knowledge of every part of the software • Within weeks we were able to do a complete hand-over • And made a smooth transition to a new tech lead • Pairing and mobbing meant that new devs could do valuable work from day one • Our code was self-documenting and covered by descriptive tests • Helped with onboarding new members • No balls were dropped
  • 36. In Summary • Adopting Scrum or Kanban, or a hybrid, on it’s own is not enough • It alone doesn’t lead to doing Agile or Lean Software Development • But rather they are simply ways of doing project management • XP helps you to mitigate against legacy code • XP helps you write better software • You may not be able to do everything • But at least do some of the things • Keep at it, you’ll get there
  • 37. Thank You Mike Harris . mbharris.co.uk . mike@mbharris.co.uk ssrn.com . m.harris@elsevier.com . +44 7811 671 893