Putting the XP in Scrum
summary
Argues that Scrum or SAFe without engineering practices stalls adoption and prevents true continuous delivery, so teams must add concrete techniques: CI pipelines that make tactical decisions, TDD with micro-iterations, continuous refactoring, pair programming and collective code ownership. Recommends small experiments and pilots, measuring hard lagging indicators (escape bugs, release frequency, lead time, MTTR) and team-level costs (example: 50 developers waiting one hour = 50 dev-hours/day) to move teams out of survival mode into learning mode.
AI-written summary · about
chapters (11)
- 0:00Introduction and speaker intro
- 1:49Why XP in Scrum matters
- 6:04Missing engineering practices in agile
- 11:15Extreme Programming explained
- 15:28XP engineering practices deep dive
- 24:16Why organizations avoid XP practices
- 27:02Moving from survival to learning mode
- 30:12Measuring and proving the need for XP
- 34:23Running small XP experiments
- 37:35Overcoming cultural barriers to XP
- 38:17Q&A and closing remarks
related talks
53mDevOps and Agility with Visual Studio, Azure and Scrum
52mSmall Steps Are the Fastest Way Forward: Life Beyond Agile & Scrum
29mHow thinking small is changing software development big time
01h 22mAgile - The Road Towards Organizational Agility - Progress & Challenges Examined
33mCulture of Continue Delivery
01h 02mThe Enterprise DevOps Challenge
40mContinuous Delivery Anti-Patterns
54mGetting Unstuck. Strategies for Surviving in a Rapidly Changing Post-Agile World
