scrum vs scrumand vs scrumbut: which one are you doing? :: bpi 2016
TRANSCRIPT
Scrum vs ScrumAnd vs ScrumBut:
which one are you doing?
Pedro Gustavo Torres
Being Agile since 2010
RAD & Agile Lead
@_pedro_torres
The 2015 State of Scrum Report
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
Scrum brings clarity to your work
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?
Scrum – Addons vs Mod(ifications)s
Framework
Scrum
Saint Basil’s Cathedral
Scrum – Addons vs Mod(ifications)s
Addon
ScrumAnd
St Pancras Station
Scrum – Addons vs Mod(ifications)s
Modification
ScrumBut
La Sagrada Familia today
Scrum – Addons vs Mod(ifications)s
Framework
Scrum
La Sagrada Familia in the future
Scrum – Addons vs Mod(ifications)s
Addon
ScrumAnd
La Pedrera (Casa Milà)
Scrum – Addons vs Mod(ifications)s
Modification
ScrumBut
Scrum
ScrumAnd
We use Scrum, AND…
(with Addons)
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
ScrumAnd – Popular Addons (1/23)
We estimate in points… or maybe #NoEstimates at all!
ScrumAnd – Popular Addons (2/23)
We do sprint zero
ScrumAnd – Popular Addons (3/23)
We have grooming / refinement sessions
ScrumAnd – Popular Addons (4/23)
We have prioritization sessions
ScrumAnd – Popular Addons (5/23)
We use XP practices
ScrumAnd – Popular Addons (6/23)
We limit WIP (Work in Progress = Work at Risk)
Thanks to David Legge
@thecodecleaner
ScrumAnd – Popular Addons (7/23)
We use swarming (focusing on one story at a time)
ScrumAnd – Popular Addons (8/23)
Developing and testing story by story (parallelism instead of mini waterfalls)
ScrumAnd – Popular Addons (9/23)
We have multiple reviews per sprint (we don’t wait till the end of thesprint to gather feedback)
ScrumAnd – Popular Addons (10/23)
We have all the team testing when needed (usually by the end of the sprint)
ScrumAnd – Popular Addons (11/23)
We don’t break user stories into tasks (it was only getting us slower)
ScrumAnd – Popular Addons (12/23)
Our team members have t-shaped skills (cross-functional)
ScrumAnd – Popular Addons (13/23)
Our sprints start on Mondays and finish on Fridays
ScrumAnd – Popular Addons (14/23)
All our teams are aligned (sprint wise)
ScrumAnd – Popular Addons (15/23)
Our teams size is 7+-2
ScrumAnd – Popular Addons (16/23)
We invite everyone in the department to assist to our Sprint Reviews
ScrumAnd – Popular Addons (17/23)
We release often and during the sprint without (a lot of) effort
ScrumAnd – Popular Addons (18/23)
We celebrate learning… not failure
ScrumAnd – Popular Addons (19/23)
The Scrum Master is trying to be unnecessary (putting himself out of his job)
ScrumAnd – Popular Addons (20/23)
We have 80% test / code coverage (Unit tests)
ScrumAnd – Popular Addons (21/23)
We do code reviews (or we work with pull requests)
ScrumAnd – Popular Addons (22/23)
After starting with directive Scrum… we now let teams grow freely
ScrumAnd – Popular Addons (23/23)
We collaborate so closely to our customer falls into the “IKEA Effect”
ScrumBut
We use Scrum, BUT…
Scrum(with Modifications)
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
ScrumBut – “Popular” modifications (1/33)
Our team members think of “my“ sprint / tasks / stories / story pointsinstead of “our” sprint / tasks / stories / story points
ScrumBut – “Popular” modifications (2/33)
We have a waterfall inside the sprint (testing only starts after all the coding is “done”)
ScrumBut – “Popular” modifications (3/33)
We have QAs / Testers working outside the team / sprint
ScrumBut – “Popular” modifications (4/33)
QAs don’t speak to Devs whenever they find bugs (processes and toolsover individuals and interactions)
ScrumBut – “Popular” modifications (5/33)
The team works for the KPIs and not for the (potential) value delivered
ScrumBut – “Popular” modifications (6/33)
The team can't implement (technically) a story without the Dev Lead (or Architect)
ScrumBut – “Popular” modifications (7/33)
We don’t have a DoD (nor a DoR)
ScrumBut – “Popular” modifications (8/33)
The PO is a “chicken” (isn’t allowed to speak in Dailies and can’t attend Retrospectives)
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)
ScrumBut – “Popular” modifications (10/33)
After a sprint we “stop” for 1 week of acceptance tests / bugfixing / stabilization (non consecutives sprints)
ScrumBut – “Popular” modifications (11/33)
Team members arrive late to scrum ceremonies
ScrumBut – “Popular” modifications (12/33)
We have titles inside the team (Associate, Senior, etc.)
ScrumBut – “Popular” modifications (13/33)
We don’t have a Sprint Goal
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)
ScrumBut – “Popular” modifications (15/33)
We have Daily scrums away from the physical / virtual board
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)
ScrumBut – “Popular” modifications (17/33)
We only have one person on our development team
ScrumBut – “Popular” modifications (18/33)
In groomings / refinements the Scrum Master assigns user stories to developers (command and control vs self-organizing)
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
ScrumBut – “Popular” modifications (20/33)
We don’t have a Scrum Master… not even a Product Owner (they are M.I.A.)
ScrumBut – “Popular” modifications (21/33)
We argue all the time about who is responsible for doing what (roles indefinition)
ScrumBut – “Popular” modifications (22/33)
The Product Owner doesn’t have time to write “decent” user stories
ScrumBut – “Popular” modifications (23/33)
We stopped doing important things (e.g. visit customers, supporting UAT) because “that's not scrum”
ScrumBut – “Popular” modifications (24/33)
Our team is not cross functional
ScrumBut – “Popular” modifications (25/33)
We have partially allocated team members (e.g. Developers)
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
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
ScrumBut – “Popular” modifications (28/33)
We split user stories between development and testing
Development Testing
ScrumBut – “Popular” modifications (29/33)
Each story has an estimate for backend, frontend, integration and testing
User Story1
5
2
3
ScrumBut – “Popular” modifications (30/33)
We are just worried about the How and not the Why
ScrumBut – “Popular” modifications (31/33)
We don’t know our velocity
ScrumBut – “Popular” modifications (32/33)
We don’t have any predictability whatsoever
ScrumBut – “Popular” modifications (33/33)
We focus on idle workers and not on idle work
One last comparision between And and But
If a Smart (Swatch + Mercedes + Art) Fortwo was Scrum…
ScrumAnd
ScrumBut
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 justshouldn’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 aboutefficiency (ScrumAnd)
Scrum vs ScrumAnd vs ScrumBut:
which one are you doing?
Obrigado! Thank you! Gracias!