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.

Xp revisited

102 views

Published on

Over the past two decades agile has solved our inability to deliver software frequently. Largely this can be attributed to AGILE PROCESS improvements, smaller tends to flow faster.
• smaller work items (user stories and features)
• smaller batch sizes (Sprint backlogs/ WIP limits)
• shorter cadence (2-4 week iterations)
ENGINEERING improvements seem less necessary & teams feel like agile process is being done TO them.
Is the ability to release frequently with existing engineering practices sufficient? Should we declare victory now?
Surely the next step is to amplify our focus on ENGINEERING? Not WHAT we build or HOW MUCH we build but HOW we actually build it. Engineering efficiency is the key to moving beyond frequent delivery, to continuous or on-demand delivery. We cannot get there without "Continuous attention to technical excellence enhances agility" and for this we need engineering teams fully engaged and on board.
XP was once our solution for "Uncovering better ways of developing software". This talk revisits XP in the context of where Agile is now and looks to rediscover XP as a pathway to increased agility.

Published in: Technology
  • Be the first to comment

Xp revisited

  1. 1. XP REVISITED REDISCOVERING XP AS A PATHWAY TO ENHANCED AGILITY EDDIE KENNY AGILE COACH
  2. 2. • http://leanagilebrighton.co.uk/ • https://www.meetup.com/Lean-Agile- Brighton/ AGILE COACH • http://his-scrum-masters-voice.blogspot.com/ • http://coachmachine.blogspot.com/ • http://agilementors.blogspot.com/ @eddiekenny9
  3. 3. FAST FEEDBACK LOOPS
  4. 4. TECHNICAL PRACTICES NEED TO BE A PRIMARY CONCERN FOR AGILE ADOPTION & TRANSFORMATION EFFORTS
  5. 5. ENGINEERING EFFORT IS DISCONNECTED FROM AGILE PROCESS
  6. 6. ANOTHER MEETING?
  7. 7. LIBERTARIAN PATERNALISM WE KNOW WHAT’S BEST FOR YOU
  8. 8. AGILE PROCESS TECHNICAL PRACTICE
  9. 9. LET’S REWIND
  10. 10. THE ORIGINAL PROBLEM AGILE WAS SOLVING FOR?
  11. 11. FRAMEWORK ADOPTION
  12. 12. AGILE ADOPTION = FRAMEWORK ADOPTION
  13. 13. THE GREAT REDUCTIONIST FAÇADE A.K.A. SLICE & DICE A.K.A. TAYLORISM
  14. 14. COMMON PATTERNS OF SCRUM ADOPTION
  15. 15. SLICING THINGS DIFFERENTLY SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5 DEVELOP TEST UAT RELEASE DEVELOP TEST UAT RELEASEDEVELOP DEVELOP
  16. 16. MOVING THE WORK AROUND A BIT DEV TEST UAT RELEASEDEV TEST DEV TEST D T UAT RELEASED T D T D T D T D T D T D T D T
  17. 17. OVERLAPS & CARRYOVER DEV TEST UAT RELEASEDEV TEST DEV TEST D T UAT RELEASED T D T D T D T D T D T D T D T DEV TEST DEV TEST DEV TEST D T D T D T D T D T D T D T D T D T
  18. 18. DESTRUCTIVE ABUNDANCE
  19. 19. TWICE THE WORK – HALF THE TIME? WATERFALL DELIVERY SCRUM SCRUM SCRUM SCRUM SCRUM XP XP XP
  20. 20. THE POTENTIALLY SHIPPABLE INCREMENT DELUSION
  21. 21. FLACCID SCRUM SCRUM IS A PROCESS THAT’S CENTRED ON PROJECT MANAGEMENT & DELIBERATELY OMITS ANY TECHNICAL PRACTICES .. IN CONTRAST TO EXTREME PROGRAMMING
  22. 22. COURAGE RESPECT COMMUNICATION SIMPLICITY FEEDBACK COURAGE RESPECT FOCUS OPENNESS COMMITMENT
  23. 23. SCRUM XP DAILY SCRUM SPRINT PLANNING SPRINT REVIEW PRODUCT BACKLOG SPRINT RETROSCRUM MASTER PRODUCT OWNER SPRINT BACKLOG INCREMENT TEAM SPRINT ITERATION PLANNING GAME DAILY STAND UP DEMO RETRO TEAM XP COACH ONSITE CUSTOMER PRODUCT BACKLOG ITERATION BACKLOG INCREMENT? CONTINUOUS INTEGRATION TDD BDD REFACTORING SUSTAINABLE PACE PAIR PROGRAMMING COLLECTIVE OWNERSHIP AUTOMATED ACCEPTANCE TESTS
  24. 24. SCRUM = *ARTIFACTS = Product backlog + sprint backlog + Potentially shippable increment XP = Values + Ceremonies + Roles + *Artifacts + Technical practices Values + Ceremonies + Roles + *Artifacts
  25. 25. XP = + Technical practicesSCRUM
  26. 26. TECHNICAL PRACTICES MATTER Many Agile adoptions have treated technical practices as secondary compared to management & team practices. Our research shows that technical practices play a vital role
  27. 27. CONTINUOUS INTEGRATION?
  28. 28. UNIT TESTING vs TDD DEVELOP CHECK IT WORKS DEVELOP CHECK 1 & 2 WORK DEVELOP CHECK 1,2 & 3 WORK DEVELOP STOP CHECKING DEVELOP DEVELOP DEVELOP DEVELOP DEVELOP DEVELOP DEVELOP DEVELOP TEST …. WTF? WRITE UNIT TESTS GET BORED
  29. 29. UNIT TESTING vs TDD DEVELOP IT WORKS TEST? WRITE TEST RUN TEST DEVELOP THEY WORKWRITE TEST RUN TESTS DEVELOP THEY WORKWRITE TEST RUN TESTS DEVELOP THEY WORKWRITE TEST RUN TESTS
  30. 30. REFACTOR MERCILESSLY
  31. 31. POWER TOOLS
  32. 32. CONTINUOUS ATTENTION TO TECHNICAL EXCELLENCE ENHANCES AGILITY THE TECHNICAL PRACTICES ARE PART OF YOUR METHODOLOGY AND THIS IS HOW WE INVITE THE ENGINEERING COMMUNITY IN
  33. 33. BUILD PROJECTS AROUND MOTIVATED INDIVIDUALS MOTIVATE TECHNOLOGISTS WITH CONTINUOUS LEARNING
  34. 34. CONTINUOUS LEARNING LEADS TO HAPPY ENGINEERS
  35. 35. TECH PRACTICES POSITIVELY IMPACT SOFTWARE DELIVERY PERFORMANCE AND ORGANISATIONAL PERFORMANCE
  36. 36. BRANDING ISSUE 1. EXTREME 2. PROGRAMMING
  37. 37. XP
  38. 38. BASED ON WHERE WE ARE NOW REVISIT XP
  39. 39. CHANGE AGENTS – ADVOCATE FOR XP (SCRUM ALONE WON’T GET YOU THERE) LEADERS/ DECISION MAKERS – ADD XP TOO (SCRUM ALONE WON’T GET YOU THERE) ENGINEERS – DOUBLE DOWN (LEARN XP TECHNIQUES PROPERLY) TO DO
  40. 40. EVERYONE ADD THE XP
  41. 41. DEVELOP SOFTWARE 7-Oct-18 AXP Internal 54 BETTER, FASTER, HAPPIER
  42. 42. Thank you
  43. 43. XP READING • Flaccid SCRUM https://martinfowler.com/bli ki/FlaccidScrum.html • SCRUM & XP (Mike Cohn) https://www.mountaingoats oftware.com/blog/differenc es-between-scrum-and- extreme-programming

×