7. 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?
15. 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
16. ScrumAnd โ Popular Addons (1/23)
We estimate in pointsโฆ or maybe #NoEstimates at all!
40. 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
41. ScrumBut โ โPopularโ modifications (1/33)
Our team members think of โmyโ sprint / tasks / stories / story points
instead of โourโ sprint / tasks / stories / story points
42. ScrumBut โ โPopularโ modifications (2/33)
We have a waterfall inside the sprint (testing only starts after all the coding
is โdoneโ)
44. ScrumBut โ โPopularโ modifications (4/33)
QAs donโt speak to Devs whenever they find bugs (processes and tools
over individuals and interactions)
45. ScrumBut โ โPopularโ modifications (5/33)
The team works for the KPIs and not for the (potential) value delivered
46. ScrumBut โ โPopularโ modifications (6/33)
The team can't implement (technically) a story without the Dev Lead
(or Architect)
48. ScrumBut โ โPopularโ modifications (8/33)
The PO is a โchickenโ (isnโt allowed to speak in Dailies and canโt attend
Retrospectives)
49. 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)
50. ScrumBut โ โPopularโ modifications (10/33)
After a sprint we โstopโ for 1 week of acceptance tests / bugfixing /
stabilization (non consecutives sprints)
54. 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)
55. ScrumBut โ โPopularโ modifications (15/33)
We have Daily scrums away from the physical / virtual board
56. 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)
58. ScrumBut โ โPopularโ modifications (18/33)
In groomings / refinements the Scrum Master assigns user stories to
developers (command and control vs self-organizing)
59. 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
60. ScrumBut โ โPopularโ modifications (20/33)
We donโt have a Scrum Masterโฆ not even a Product Owner (they are
M.I.A.)
61. ScrumBut โ โPopularโ modifications (21/33)
We argue all the time about who is responsible for doing what (roles
indefinition)
62. ScrumBut โ โPopularโ modifications (22/33)
The Product Owner doesnโt have time to write โdecentโ user stories
63. ScrumBut โ โPopularโ modifications (23/33)
We stopped doing important things (e.g. visit customers, supporting UAT)
because โthat's not scrumโ
65. ScrumBut โ โPopularโ modifications (25/33)
We have partially allocated team members (e.g. Developers)
66. 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
67. 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
68. ScrumBut โ โPopularโ modifications (28/33)
We split user stories between development and testing
Development Testing
69. ScrumBut โ โPopularโ modifications (29/33)
Each story has an estimate for backend, frontend, integration and
testing
User Story
1
5
2
3
74. 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!
75. Scrum vs ScrumAnd vs ScrumBut:
which one are you doing?
Obrigado! Thank you! Gracias! ๏