too fast for scrum? | agilept 2015

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