too fast for scrum? | agilept 2015
TRANSCRIPT
too fast for Scrum?
Antonio Arrais de Castro
about.me
cto@
by
Antonio Arrais de Castrohttps://www.linkedin.com/in/arraisdecastro
going sustainably fast =>
clear
goals
manage over
load
team
motivation
even with all that…. may you get too fast for Scrum?
“too fast” symptoms…“It is a struggle to keep the sprint backlog stable during each sprint.”
“Priorities change daily… sometimes hourly…”
“Aren’t we spending too much time planning?”
“It looks we are being productive but not too effective…”
“We can’t support our maintenance efforts with timeboxed sprints.”
“Multitasking is increasing, we have devs working on too many small tasks at a time.”
“Some people talk about the cone of uncertainty. Our looks like a rectangle…”
“too fast” symptoms…
When “move fast” under uncertainty becomes the mission statement, you start to see teams feeling that Scrum starts to block their agility.
Sprint backlog changes should be avoided in scrum, as a principle.
But building a stable environment for your team during the sprint duration should not be an impossible mission….
scrum.misconceptions
“Scrum, by itself, makes your teams faster”
“Scrum, by itself, makes your teams faster”
A poorly designed agile process may turn your teams slower at the end!
“the need to move hyper fast makes your backlog so organically alive that timeboxed sprints become impossible to achieve”
“the need to move hyper fast makes your backlog so organically alive that timeboxed sprints become impossible to achieve”
Challenging… hell yes… but not impossible!
“Scrum and Kanban are recipes for success”
“Scrum and Kanban are recipes for success”
There is not such thing! Scrum and Kanban are helpers, not recipes.
“The agile methodology is great”
“The agile methodology is great”
There is no such thing as an “agile methodology”.
Scrum may be considered an agile based framework.
Remember, no recipes available!
“Scrum is based on the assumption that teams are good at estimating”
“Scrum is based on the assumption that teams are good at estimating”
Most of the team members are lousy estimators.
But they can improve continuously.
Scrum assumes that it is not possible to work with precise time based
estimations and promotes using intervals instead.
“Sprints are incompatible with having maintenance work”
“Sprints are incompatible with having maintenance work”
Yes, it is tricky! But you need to find your optimal strategy to deal with it.
And it is not impossible.
sharing.experiences
jumia.team
288 jumia IT
91 Porto Tech center
4 Porto Tech
companies jumia (all)
2500
ALGERIA
SENEGAL
ANGOLA
CAMEROON
IVORY COAST
EGYPT
BANGLADESH
MYANMAR
PAKISTAN
GHANA
KENYA
MOROCCO
NIGERIA
UGANDA
TANZANIA
…
porto.tech.center
Scrum Kanban 4 now
Each time decides Scrum Scrum+Kanban Each team
decides
2 weeks N.A. 2 weeks 2 weeks N.A.
Distributed maintenance
Maintenance team
Each team handles own issues
Distributed maintenance
Each team decides
9 teams 5 teams 3 teams 3 teams 6 teams
our road to awesomeness
Radi
cal C
ode
Fix
Scrum
Scrum + Kanban Kanban Scrumban Scrum
Man, we’re driving fast!
road to awesomeness
Radi
cal C
ode
Fix
Scrum
Scrum + Kanban Kanban Scrumban Scrum
Deeper team
involvement. Great!
road to awesomeness
Radi
cal C
ode
Fix
Scrum
Scrum + Kanban Kanban Scrumban Scrum
Maintenance vs. feature
development focus.
road to awesomeness
Radi
cal C
ode
Fix
Scrum
Scrum + Kanban Kanban Scrumban Scrum
Reacting faster, prios are
queen.
road to awesomeness
Radi
cal C
ode
Fix
Scrum
Scrum + Kanban Kanban Scrumban Scrum
Humm… there was a strange factory feeling
around.
road to awesomeness
Radi
cal C
ode
Fix
Scrum
Scrum + Kanban Kanban Scrumban Scrum
Balancing fast reaction to
changes, product commitment and
stability.
effectiveness productivityfocus.on instead.of
is this our recipe?
be.prepared(game-is-hard)
development.zen is reachable
and a.never.ending.journey…
thanks