Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 37

It's XP, Stupid

1

Share

Download to read offline

Presented at Agile on the Beach, 13th July 2018.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

It's XP, Stupid

  1. 1. It’s XP, stupid! Mike Harris
  2. 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. 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. 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. 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. 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. 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
  8. 8. My Conclusion We’re totally flying
  9. 9. LEAN AGILE SCRUM XP
  10. 10. What is XP? A brief recap of eXtreme Programming
  11. 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. 12. XP Values • Communication • Simplicity • Feedback • Courage • Respect
  13. 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. 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. 15. Software Engineering in 2018 Twelve development practices I’ve been doing that I think you should try
  16. 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. 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. 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. 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. 20. 3. Tiny Tasking Example
  21. 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. 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. 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. 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. 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. 26. 8. ITD example (using Trello)
  27. 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
  28. 28. 9. Automated Deployment example
  29. 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. 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. 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. 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. 33. Outcomes What we found when we applied the practices
  34. 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. 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. 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. 37. Thank You Mike Harris . mbharris.co.uk . mike@mbharris.co.uk ssrn.com . m.harris@elsevier.com . +44 7811 671 893

×