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.

Scrum vs ScrumAnd vs ScrumBut: Which one are you doing? :: Agile Tour London 2016

1,237 views

Published on

Scrum vs ScrumAnd vs ScrumBut: Which one are you doing? :: Agile Tour London 2016

Published in: Internet

Scrum vs ScrumAnd vs ScrumBut: Which one are you doing? :: Agile Tour London 2016

  1. 1. Scrum vs ScrumAnd vs ScrumBut: which one are you doing? October 2016
  2. 2. Pedro Gustavo Torres Being Agile since 2010 RAD & Agile Lead @_pedro_torres
  3. 3. The 2015 State of Scrum Report
  4. 4. Team • Product Owner • Scrum Master • Development Team Artifacts • Product Backlog • Sprint Backlog • Increment • Definition of Done (Transparency) Events • The Sprint • Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective Scrum in a (Scrum Guide, July 2016) Framework / Empirical process (Inspection, Adaption, Transparency) Values • Commitment • Courage • Focus • Openness • Respect
  5. 5. Scrum brings clarity to your work
  6. 6. Learning Scrum – Shu Ha Ri Vanilla Scrum Beyond Scrum?ScrumAnd ScrumBut Shuhari roughly translates to "first learn, then detach, and finally transcend." •shu (守) "protect", "obey" — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs •ha (破) "detach", "digress" — breaking with tradition — detachment from the illusions of self •ri (離) "leave", "separate" — transcendence — there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical Thanks to Alistair Cockburn & Martin Fowler Scrum doesn’t work?
  7. 7. Scrum – Addons vs Mod(ifications)s Framework Scrum
  8. 8. Saint Basil’s Cathedral Scrum – Addons vs Mod(ifications)s Addon ScrumAnd
  9. 9. St Pancras Station Scrum – Addons vs Mod(ifications)s Modification ScrumBut
  10. 10. La Sagrada Familia today Scrum – Addons vs Mod(ifications)s Framework Scrum
  11. 11. La Sagrada Familia in the future Scrum – Addons vs Mod(ifications)s Addon ScrumAnd
  12. 12. La Pedrera (Casa Milà) Scrum – Addons vs Mod(ifications)s Modification ScrumBut
  13. 13. Scrum ScrumAnd We use Scrum, AND… (with Addons)
  14. 14. ScrumAnd “…When I was on my first Agile project, Ward Cunningham, one of our project coaches, said to me “Mitch, you need to adopt the XP engineering practices of TDD, pairing, refactoring and continuous integration or you’ll be sorry.” I dismissed this claim as I knew what I was doing. It was not until we were four sprints in when we all realized that we were screwed….” Thanks to Mitch Lacey
  15. 15. ScrumAnd – Popular Addons (1/23) We estimate in points… or maybe #NoEstimates at all!
  16. 16. ScrumAnd – Popular Addons (2/23) We do sprint zero
  17. 17. ScrumAnd – Popular Addons (3/23) We have grooming / refinement sessions
  18. 18. ScrumAnd – Popular Addons (4/23) We have prioritization sessions
  19. 19. ScrumAnd – Popular Addons (5/23) We use XP practices
  20. 20. ScrumAnd – Popular Addons (6/23) We limit WIP (Work in Progress = Work at Risk) Thanks to David Legge @thecodecleaner
  21. 21. ScrumAnd – Popular Addons (7/23) We use swarming (focusing on one story at a time)
  22. 22. ScrumAnd – Popular Addons (8/23) Developing and testing story by story (parallelism instead of mini waterfalls)
  23. 23. ScrumAnd – Popular Addons (9/23) We have multiple reviews per sprint (we don’t wait till the end of the sprint to gather feedback)
  24. 24. ScrumAnd – Popular Addons (10/23) We have all the team testing when needed (usually by the end of the sprint)
  25. 25. ScrumAnd – Popular Addons (11/23) We don’t break user stories into tasks (it was only getting us slower)
  26. 26. ScrumAnd – Popular Addons (12/23) Our team members have t-shaped skills (cross-functional)
  27. 27. ScrumAnd – Popular Addons (13/23) Our sprints start on Mondays and finish on Fridays
  28. 28. ScrumAnd – Popular Addons (14/23) All our teams are aligned (sprint wise)
  29. 29. ScrumAnd – Popular Addons (15/23) Our teams size is 7+-2
  30. 30. ScrumAnd – Popular Addons (16/23) We invite everyone in the department to assist to our Sprint Reviews
  31. 31. ScrumAnd – Popular Addons (17/23) We release often and during the sprint without (a lot of) effort
  32. 32. ScrumAnd – Popular Addons (18/23) We celebrate learning… not failure
  33. 33. ScrumAnd – Popular Addons (19/23) The Scrum Master is trying to be unnecessary (putting himself out of his job)
  34. 34. ScrumAnd – Popular Addons (20/23) We have 80% test / code coverage (Unit tests)
  35. 35. ScrumAnd – Popular Addons (21/23) We do code reviews (or we work with pull requests)
  36. 36. ScrumAnd – Popular Addons (22/23) After starting with directive Scrum… we now let teams grow freely
  37. 37. ScrumAnd – Popular Addons (23/23) We collaborate so closely to our customers that they fall into the "IKEA effect"
  38. 38. ScrumBut We use Scrum, BUT… Scrum (with Modifications)
  39. 39. ScrumBut (ScrumBut) (Reason) (Workaround) Thanks to Ken Schwaber & Ron Jeffries We use Scrum, but having a Daily Scrum every day is too much overhead, so we only have one per week. We use Scrum, but Retrospectives are a waste of time, so we don't do them. We’re doing Scrum, but Retrospectives aren’t effective, so we only do them monthly. We’re doing Scrum, but our stakeholders are too busy to come to Sprint Reviews, so we stopped doing them. We’re doing Scrum, but we couldn’t get everything done in two weeks, so now we just let our Sprints run as long as they need to
  40. 40. ScrumBut – “Popular” modifications (1/33) Our team members think of “my“ sprint / tasks / stories / story points instead of “our” sprint / tasks / stories / story points
  41. 41. ScrumBut – “Popular” modifications (2/33) We have a waterfall inside the sprint (testing only starts after all the coding is “done”)
  42. 42. ScrumBut – “Popular” modifications (3/33) We have QAs / Testers working outside the team / sprint
  43. 43. ScrumBut – “Popular” modifications (4/33) QAs don’t speak to Devs whenever they find bugs (processes and tools over individuals and interactions)
  44. 44. ScrumBut – “Popular” modifications (5/33) The team works for the KPIs and not for the (potential) value delivered
  45. 45. ScrumBut – “Popular” modifications (6/33) The team can't implement (technically) a story without the Dev Lead (or Architect)
  46. 46. ScrumBut – “Popular” modifications (7/33) We don’t have a DoD (nor a DoR)
  47. 47. ScrumBut – “Popular” modifications (8/33) The PO is a “chicken” (isn’t allowed to speak in Dailies and can’t attend Retrospectives)
  48. 48. ScrumBut – “Popular” modifications (9/33) We use 6 to 12 weeks sprints (instead of 1 to 4 weeks) to “avoid pain” / “disguise problems” (e.g. releases, manual regression testing, deploys to test environments)
  49. 49. ScrumBut – “Popular” modifications (10/33) After a sprint we “stop” for 1 week of acceptance tests / bugfixing / stabilization (non consecutives sprints)
  50. 50. ScrumBut – “Popular” modifications (11/33) Team members arrive late to scrum ceremonies
  51. 51. ScrumBut – “Popular” modifications (12/33) We have titles inside the team (Associate, Senior, etc.)
  52. 52. ScrumBut – “Popular” modifications (13/33) We don’t have a Sprint Goal
  53. 53. ScrumBut – “Popular” modifications (14/33) Besides a Product Backlog we also have a Technical Backlog and a Bugs Backlog (so you can guess which backlog as higher priority)
  54. 54. ScrumBut – “Popular” modifications (15/33) We have Daily scrums away from the physical / virtual board
  55. 55. ScrumBut – “Popular” modifications (16/33) We do Big Design Up Front (BDUF) instead of favoring emerging architectures and the Lean & XP concepts Last Responsible Moment (LRM), You Aren’t Gonna Need It (YAGNI) and Just in Time (JIT)
  56. 56. ScrumBut – “Popular” modifications (17/33) We only have one person on our development team
  57. 57. ScrumBut – “Popular” modifications (18/33) In groomings / refinements the Scrum Master assigns user stories to developers (command and control vs self-organizing)
  58. 58. ScrumBut – “Popular” modifications (19/33) In Sprint Planning we focus more in having everybody busy (due to specializations) instead of focusing on the maximum value we can deliver (output)... So we cherry pick / choose the stories that go in the sprint by the skills / comfort zone of each developer
  59. 59. ScrumBut – “Popular” modifications (20/33) We don’t have a Scrum Master… not even a Product Owner (they are M.I.A.)
  60. 60. ScrumBut – “Popular” modifications (21/33) We argue all the time about who is responsible for doing what (roles indefinition)
  61. 61. ScrumBut – “Popular” modifications (22/33) The Product Owner doesn’t have time to write “decent” user stories
  62. 62. ScrumBut – “Popular” modifications (23/33) We stopped doing important things (e.g. visit customers, supporting UAT) because “that's not scrum”
  63. 63. ScrumBut – “Popular” modifications (24/33) Our team is not cross functional
  64. 64. ScrumBut – “Popular” modifications (25/33) We have partially allocated team members (e.g. Developers)
  65. 65. ScrumBut – “Popular” modifications (26/33) We have horizontal and not vertical teams so we can’t deliver working software (increments) by the end of the sprint without depending on all teams Thanks to Jonathan Rasmusson
  66. 66. ScrumBut – “Popular” modifications (27/33) We have horizontal and not vertical stories so we can’t deliver working software (increments) by the end of the sprint
  67. 67. ScrumBut – “Popular” modifications (28/33) We split user stories between development and testing Development Testing
  68. 68. ScrumBut – “Popular” modifications (29/33) Each story has an estimate for backend, frontend, integration and testing User Story 1 5 2 3
  69. 69. ScrumBut – “Popular” modifications (30/33) We are just worried about the How and not the Why
  70. 70. ScrumBut – “Popular” modifications (31/33) We don’t know our velocity
  71. 71. ScrumBut – “Popular” modifications (32/33) We don’t have any predictability whatsoever
  72. 72. ScrumBut – “Popular” modifications (33/33) We focus on idle workers and not on idle work
  73. 73. For what it matters… don’t forget that your goal is to make (awesome) software… and not to (just) do Scrum Final remarks There is nothing “wrong“ in modifying the Scrum framework… you just shouldn’t (probably) call it Scrum! And (at least) make sure that you are doing it for the right reasons! In the end… It is not about effectiveness (ScrumBut) but about efficiency (ScrumAnd) Frameworks don’t fail… people do!
  74. 74. Scrum vs ScrumAnd vs ScrumBut: which one are you doing? Obrigado! Thank you! Gracias! 

×