InfoJobs Agile

Introduction to Agile
Scrum, kanban & scrumban

InfoJobs - Introduction to Agile by Gabriel Prat is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License. 1
diumenge 29 d’abril de 12

WHO
AM
I?

h'p://www.infojobs.net/
gabriel-‐prat-‐masramon.prf

h'p://www.slideshare.net/
gabriprat/infojobs-‐agile
InfoJobs - Introduction to Agile by Gabriel Prat is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

What do
you
Expect ?
3

GROUND
RULES
Change order Interrupt as
needed

Control
Add topics
schedule

4

COMMON
PROBLEMS
(SACWIS Implementation)
Florida Minnesota

Budget

Scheduled
dura3on

Staﬀ
Jim Johnson, chairman of the Standish Group, at the XP (eXtreme Programming) 2002 conference

5

COMMON
PROBLEMS
Florida Minnesota

Budget $32M

Scheduled 8
years
dura3on

Staﬀ 109
people

5

COMMON
PROBLEMS
Florida Minnesota

Budget $32M $1,1M

Scheduled 8
years 1
year
dura3on

Staﬀ 109
people 8
people

5

COMMON
PROBLEMS
Florida Minnesota

Budget $32M $1,1M

Scheduled 8
years 1
year
dura3on 15
years
Staﬀ 109
people 8
people

5

COMMON
PROBLEMS
Florida Minnesota

Budget $32M $1,1M
$230M
Scheduled 8
years 1
year
dura3on 15
years
Staﬀ 109
people 8
people

5

COMMON
PROBLEMS
Florida Minnesota

Budget $32M $1,1M
$230M
200x
Scheduled productivity!ear
8
years 1
y
dura3on 15
years
Staﬀ 109
people 8
people

5

VICIOUS
CIRCLE Rings a bell? :)

Unsatisﬁed client

Late deliveries Rush

Bugs & rework Low quality

6

VICIOUS
CIRCLE Rings a bell? :)

Unsatisﬁed client

Late deliveries Rush
Demotivation +
never ending project

Bugs & rework Low quality

6

AG·ILE - adjective

Quick and well-coordinated
in movement; lithe.

7

CUSTOMER
1 COLLABORATION
over contract negotiation
AGILE
MANIFESTO

8

CUSTOMER
1 COLLABORATION
AGILE
MANIFESTO
INDIVIDUALS and
2 INTERACTIONS
over processes and tools

8

CUSTOMER
1 COLLABORATION
AGILE
MANIFESTO
INDIVIDUALS and
2 INTERACTIONS

RESPONDING to
3 CHANGE
over following a plan

8

CUSTOMER
1 COLLABORATION
AGILE
MANIFESTO
INDIVIDUALS and
2 INTERACTIONS

RESPONDING to
3 CHANGE
over following a plan

WORKING
4 SOFTWARE
over full documentation
8

1
DELIVER SOFTWARE
2
EMBRACE CHANGE
3
SHOW OFTEN
AGILE
PRINCIPLES
4
WORK TOGETHER
5
PROVIDE ENVIRONMENT
6
CHAT FACE-to-FACE
7
MINIMIZE WASTE
8
MAINTAIN PACE
9
SEEK TECH EXCELLENCE
10
LOVE SIMPLICITY
11
SELF-ORGANIZE TEAMS
12
IMPROVE CONTINUOUSLY
9

1
DELIVER SOFTWARE

10

1
DELIVER SOFTWARE

WATERFALL

10

1
DELIVER SOFTWARE

WATERFALL

AGILE

10

AGILE
PRINCIPLES

2
EMBRACE CHANGE

11

FEAR OF
CHANGE

12

FEAR OF
CHANGE

13

AGILE
PRINCIPLES
2
EMBRACE CHANGE

14

AGILE
PRINCIPLES
2

3
EMBRACE CHANGE
SHOW OFTEN

14

AGILE
PRINCIPLES
2

3
EMBRACE CHANGE
SHOW OFTEN

http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change

14

AGILE
PRINCIPLES

15

AGILE
PRINCIPLES
Increase adaptability

Plan Develop

User feedback

15

AGILE
PRINCIPLES
Increase adaptability Reduce risk

Plan Develop
Risk

User feedback
Release size

15

AGILE
PRINCIPLES 3
SHOW OFTEN

Increase adaptability Reduce risk

Plan Develop
Risk

User feedback
Release size

15

AGILE
PRINCIPLES

16

AGILE
PRINCIPLES 3
SHOW OFTEN

16

4
WORK TOGETHER
AGILE
PRINCIPLES

17

4
WORK TOGETHER
AGILE
PRINCIPLES

How the customer How the project How the analyst
explained it manager understood it designed it

How the programmer How pathes were What the customer
wrote it applied really needed
17

AGILE
PRINCIPLES

5
PROVIDE ENVIRONMENT

18

6
CHAT FACE-to-FACE

MORE EFFECTIVE
AGILE
PRINCIPLES
Chat with whiteboard

Effectiveness of communication
Chat face to face
Videoconference
Telephone

Email
Doc
LESS EFFECTIVE

http://en.wikipedia.org/wiki/Media_richness_theory
19

7
MINIMIZE WASTE

#1 Partially Done Work
AGILE
PRINCIPLES
#2 Extra Features
#3 Relearning
#4 Handoffs
#5 Delays
#6 Task Switching
#7 Defects

http://agile.dzone.com/articles/seven-wastes-software
Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
20

RESULTS ≠ TIME
Focus on results, minimize waste, be brave, learn from failure

21

8
MAINTAIN PACE

Maximum
AGILE
PRINCIPLES

Capacity

Sustainable pace

No work

22

AGILE 9
PRINCIPLES
Automate test
Write docs
Refactor...
Because We don’t...

Because
We don’t have
time

23

10
LOVE SIMPLICITY

“Perfect is the
enemy of good”
Voltaire

24

10
LOVE SIMPLICITY

25

AGILE 11
SELF-ORGANIZE TEAMS
PRINCIPLES

26

AGILE 12
PRINCIPLES
Kay = Change

Zen = Good

Kayzen = Continuous improvement
27

1
DELIVER SOFTWARE
2
EMBRACE CHANGE
3
SHOW OFTEN
AGILE
PRINCIPLES
4
WORK TOGETHER
5
PROVIDE ENVIRONMENT
6
CHAT FACE-to-FACE
7
MINIMIZE WASTE
8
MAINTAIN PACE
9
10
LOVE SIMPLICITY
11
SELF-ORGANIZE TEAMS
12
28

J-CURVE
EFFECT
Performance

Desired state

Current
state

Time
Adapted from David Viney, The J-Curve Effect observed in change
29

J-CURVE
EFFECT
Performance

Desired state
What stakeholders
(mistakenly)
expect

Current
state

Time
29

J-CURVE
EFFECT
Performance

Desired state
What stakeholders
(mistakenly)
expect

Current
state
What actually
happens in most
cases

Time
29

30

Had not experienced
a failed project
31

32

33

SCRUM

33

SCRUM
DEFINITION

33

SCRUM iterative, incremental methodology
for project management often seen
DEFINITION in agile software development.

33

SCRUM iterative, incremental methodology
for project management often seen
DEFINITION in agile software development.

Daily scrum
meeting 24 hours

Shippable
Sprint product
Product backlog 2 weeks
backlog

33

GROUND
RULES
“ Change is the
only constant
Tao Principle ”
“ fail faster to
succeed sooner
”
David Kelley, CEO Ideo

34

GROUND
RULES
Scrum roles, artifacts, events
and rules are immutable

- Why should we change? The old ways were good enough

35

GROUND
RULES
Shared goals and responsibilities

Daily standup, daily communication, daily involvement

36

GROUND
RULES
All team members’ role is “team member”,
no sub-teams dedicated to speciﬁc
domains

- We have a bottle neck in the XXX phase

- How may I help you today?
37

GROUND
RULES
Full time team members

- Sorry, I can’t help you, I’m working on something else

- Make everything visible! Look at the whiteboard
38

GROUND
RULES
Avoid paralellization

- Everything is important

39

GROUND
RULES

Bueno, Bonito, Barato: Choose two of them

40

GROUND
RULES
Fixed
Scope

Traditional
Estimated
Cost Time


40

GROUND
RULES
Fixed
Scope Time Cost

Agile!
Traditional
Estimated
Cost Time Scope


40

TIME
BOX

41

TIME
BOX Traditional
Estimated

Real

41

TIME
BOX Traditional
Estimated

Real Ouch!

41

TIME
BOX Traditional
Estimated

Real Ouch!

Agile!
Estimated

Real

42

TIME
BOX Traditional
Estimated

Real Ouch!

Agile!
Estimated

Real Continuous improvement
Replan
42

TIME
BOX Traditional
Estimated

Real Ouch!

Agile!
Estimated

Working software!
Real Early & continuous
delivery
Replan R1.0
42

TIME
BOX Traditional
Estimated

Real Ouch!

Agile!
Estimated

Real

Replan R1.0 R2.0
42

SCRUM
OVERVIEW

Roles Artifacts Meetings

43

SCRUM
ROLES
1 PRODUCT OWNER
the voice of the customer

2 TEAM MEMBER
deliver the product

3 SCRUM MASTER
facilitator, mentor, coach

4 EXTERNAL EXPERTS
consultants, assessors, auditors
44

SCRUM
TEAMS
Team
Prod. Owner

#*# ?" ?"
Tech Lead Test engineers Int. designer
Visual Interface
Scrum Master designer

#" #" #" <>#
Developers Front-end dev.
?*#
QA Lead

45

AUTONOMOUS
TEAMS
Group of individuals working in concert
toward shared specific goals without
the direct influence of an outside party

They (so not their
Capaple of doing
Self- managers) decide
the work end-to-
Competent how to meet goals
end to meet goals organized

Acknowledgment Composed by
Multi-
and assumption of Accountable members from
responsibility about disciplinar multiple
goal achievement departments

46

PRODUCT OWNER
ROLE

Seats in the driver’s seat, prioritize what to do and
knows when the software should be shipped
47

PRODUCT OWNER
ROLE

47

PRODUCT OWNER
ROLE

Here be
the team

47

PRODUCT OWNER
ROLE

Here be
the team
Thousands of
clients!
Scary, aren’t they?

47

PRODUCT OWNER
ROLE

Here be Product
the team owner.

Thousands of
clients!

47

PRODUCT OWNER
ROLE

Here be Product
the team owner.
The brave
Thousands of gatekeeper.
clients!

47

PRODUCT OWNER
ROLE

Guardians of the scrum teams.
They keep orcs at the doors.

47

PRODUCT OWNER
ROLE

Guardians of the scrum teams.
They keep orcs at the doors.

✓ Responsible for delivering the maximum value to the
company.
✓ Must be up to date of the sprint status
✓ Responsible for having good user stories from the PM
on time having the client’s ok before the sprint planning
47

DEVELOPER!
Writes code *sigh*
ROLE
Designs software architecture
Don’t let the team build a Rube Goldberg machine

Co-responsible for the team’s output
"With great power there must also come -- great responsibility!"
Stan Lee - Amazing Fantasy #15 (First Spider-Man story)

"To whom much has been given, much will be expected"
Jesus - Luke 12:48

48

DEVELOPER!
ROLE

48

TECH LEAD
Focused on the output, not the process.
Helps in the process of converting ideas to
ROLE
architecture, to tasks, to code.

49

TECH LEAD
ROLE

Global project technical vision

Leading scrum meetings
Do’s

Remove technical impediments

Manage team’s technical skills

Write code. Write a lot of code

Create interactive environment

49

TECH LEAD
ROLE

Be the only responsible

Don’ts
Make the hard decisions alone
Do’s

Impose his opinion
Be the best at everything
Write code. Write a lot of code Write all the hard code

49

TECH LEAD
ROLE

Be the only responsible

Don’ts
Make the hard decisions alone
Do’s

Impose his opinion
Be the best at everything
Write code. Write a lot of code Write all the hard code
http://www.ﬂyingtomoon.com/2011/06/do-we-need-technical-leads-in-scrum.html
http://blog.franktrindade.com/2009/08/11/whats-the-tech-lead-doing-anyway/
http://www.magpiebrain.com/2006/09/12/a-tech-lead-manifesto/ 49

SCRUM MASTER
ROLE
Focused on the methodology, the
people and the team improvement,
not the output of the current sprint.

Care for all the people in team

(Train the team to) Remove impediments Have management authority

Don’ts
Do’s

Commits to work on behalf of
Make retrospective the team
enhancements happen
Need to be a developer
Have the best people skills
Be the only one concerned
about people’s feelings
Protects team against
interruptions.

50

for SCRUM MASTERS
51

The SM observes the world but trusts his inner vision. The SM allows things to happen.
He allows things to come and go He shapes events as they come.
His heart is open as the sky. (12) He steps out of the ways and let the design speak for itself. (45)

The SM doesn't talk, he acts. The SM gives himself up to whatever the moment brings.
When this is done, the team says, He knows that he is going to leave,
"Amazing: we did it, all by ourselves!" (17) he has nothing left to hold on to: no illusions, no resistance in mind.
He holds nothing back from the project, therefore is ready for
departure, as a man is ready for sleep after a good day's work. (50)
When the SM leads, the team is hardly aware that he exists.
Next best is a leader that is loved.
Next, one who is feared. The great way is easy, yet developers prefer the side paths.
The worst one who is despised. (17) Be aware when things are out of balance.
Remain centered within the design. (53)
A good traveler has no fixed plans and isn’t intent upon arriving.
A good artist lets his intuition lead him wherever it wants. The SM's power is like this.
A good scientist has freed himself of concepts He let all things come and go effortlessly, without desire.
and keeps his mind open to what is. He never expect results; thus he is never disappointed.
Thus the SM is available to everybody and doesn't reject anyone. He is never disappointed, thus his spirit never grows old. (55)
He is ready to use all situations and does not waste anything. (27)
Those who don’t have a clue are still debating about the process
Therefore the SM controls without authority. Those who know, just do it. (56)
Working, yet not taking credit.
Work is done, then forgotten.
Therefore it lasts forever. (2) SM is content to serve as an example and not to impose his will.
He is pointed, but doesn't pierce.
Straightforward, but supple.
When the process is lost, there is good practice. Radiant, but easy on the eyes. (58)
When good practice is lost, there are rules.
When rules are lost, there is ritual.
Ritual is the beginning of chaos. (38) If you want to be a great SM, stop trying to control.
Let go of fixed plans and concepts and the team will govern itself.
The more rules you have, the less disciplined the team will be.
The SM concerns himself with the depth and not the surface, The more coercion you exert, the less secure the team will be.
with the fruit and not the flower. (38) The more external help you call, the less self-reliant the team’ll be. (57)

for SCRUM MASTERS
51

TEST ENGINEER
Testing is not a phase. ROLE
Development = testing + coding

52

TEST ENGINEER

Writes automated tests
Do’s

Designs test plan

Run auto/manual tests

Co-responsible for team’s output

52

TEST ENGINEER

Writes automated tests Be the only responsible for

Don’ts
output’s quality
Do’s

Designs test plan
Run all the tests
Run auto/manual tests Makes the decision on
whether the product is “done-
Co-responsible for team’s output done” alone

52

AGILE
QA QA is not a phase, it's a state of mind

If it is not tested it is not done-done

Programmers write tests

Test driven development? (TDD)

53

SCRUM
ARTIFACTS
1 PRODUCT BACKLOG
a prioritized features list

2 SPRINT BACKLOG
a list of to-do tasks

3 BURN DOWN
a progress tracking method

54

why

Prioritized estimated stack of user stories
55

DEEP
BACKLOG
Detailed appropriately

E
stimated

E
mergent

P
rioritized

56

DETAILED
APPROPRIATELY
More estimation errors
MANY Unwanted dependencies
DETAILED False sentiment of control
SMALL Loss of overview
STORIES
Useless rework
Hardly manageable


DEEP
BACKLOG
Horizon Product Backlog Details Priority
First
sprint Detailed
US
+
AC High
Next
two
sprints Detailed
epics
Any
other
sprint Less
detailed

The
unknown Low
58

DASHBOARD
Design Code Test
-!Normal Backlog Selected Done!
On Rdy On Rdy On Rdy
-!Bug
SPRINT
-!Evolutivo

Atención
FIRE!
inmediata

PRIO
Atención
prioritaria

Sólo si hay
buffer y el ASAP
Sprint va bien

-!Ante -!Test
Burndown Burnup bloqueos,Impediments
automatizados -!Doc.
ayudar tester antes de ready
actualizada
con criterios -!Seguir
-!Max. 3 avatars por aceptación estándar de -!95% coverage
persona código

59

BURN
DOWN
Estimated effort left

Ide
al e
vol
u tio
n

Days
60

BURN
DOWN

Ide
al e
vol
u tio
n
Re
al e
vol
u tio
n

Days
60

BURN
DOWN

Days
61

BURN
DOWN

Days
62

BURN
DOWN

Days
63

BURN
DOWN

Days
64

BURN
DOWN

Days
65

BURN
DOWN

Days
66

SCRUM
MEETINGS
1 DAILY STANDUP
what I did, what I’ll do today, impediments
2 SPRINT PLANNING
creation of the sprint backlog
3 SPRINT DEMO
shows sprint’s accomplishments

4 SPRINT RETROSPECTIVE
review the way team works
5 BACKLOG GROOMING
keep the backlog DEEP
67

SPRINT
SCHEDULE
Day1 Day 2 Day 3 Day 4 Day 5

Planning (3h) Work! Work! Work! Work!
Grooming (1h)
Work! (4h)

Day 6 Day 7 Day 8 Day 9 Day 10

Work! Work! Work! Work! Work! (4h)
Demo (1h)
Retro (2h)

68

DAILY
STANDUP
Who?
When? Scrum master
Always at the same time Team members
Always at the same place
Always 15 minutes
What?
Why? What did I do yesterday?
What will I do today?
Team synchronization Any impediments found?

69

SPRINT
PLANNING Who?
When? Scrum master
Team members
4h at the beginning Product owner
of every sprint
What?
Why? What will we do? (with PO)
How will we do it?(wo PO)
Team commitment

70

SPRINT
PLANNING Who?
When? Scrum master
Team members
4h at the beginning Product owner
of every sprint
The team decide
what will they do What?
Why? What will we do? (with PO)
How will we do it?(wo PO)
Team commitment

70

ESTIMATION
GAMES
Dish washing Ironing

Dog walking Oven cleaning

Lawn mowing Monthly shopping

Plants watering Paint bedroom

Beds changing Floor cleaning

Laundry Windows cleaning

71

PLANNING
POKER Without poker planning
3

12
#

# #
24
ZZZZZ

# #

72

PLANNING
3

12
# #

# # # #
24
ZZZZZ

# # # #

72

PLANNING
3
3!
12
# #
3... 5...
# # # #
24
ZZZZZ
7... 3...
# # # #

72

PLANNING
POKER
3
13
8
#

# #
3 20

# #

73

PLANNING
POKER
3
13
8 3
# #

# # 13 8
# #
3 20

# # # 3 # 20

73

PLANNING
POKER
3
#
13 8
# #

# 3 # 20

74

PLANNING
POKER
I think it’s a 3 because...

3
#
13 8
# #

# 3 # 20

74

PLANNING
POKER

3
#
13 8
# #


# 3 # 20

74

PLANNING
POKER

3 3
# #
13 8 5 5
# # # #


# 3 # 20 # 5 # 8

74

PLANNING
POKER
Convergence!

3 3
# #
13 8 5 5
# # # #


# 3 # 20 # 5 # 8

74

PLANNING
POKER
Convergence!

3 3
# #
13 8 5 5
# # # #


# 3 # 20 # 5 # 8
Ok... not complete convergence.
But they agree that an estimate of 5 should be close enough.
Next story. 74

PLANNING
POKER

75

SPRINT
DEMO (a.k.a. sprint review)
Who?
When? Scrum master
Team members
2h at the end of Product owner
the sprint
What?
Why? Explain what’s (not) done
Show what’s done
Show work, PO validates release
PO validates

76

SPRINT
RETROSPECTIVE
Who?
When?
Scrum master
Team members
2h after the demo
And nobody else

Why? What?
Review the process
Continuous (see next slides)
improvement

77

Don’t give
opinions on
other’s work.

78

RETROSPECTIVE
PRIME DIRECTIVE

Regardless of what we discover, we
must understand and truly believe
that everyone did the best job he or
she could, given what was known at
the time, his or her skills and
abilities, the resources available, and
the situation at hand.

79

RETROSPECTIVE
WHAT DO WE TALK ABOUT?
What helped me in my work?

What hindered my performance?

What made me enjoy my work?

What made me feel bad?
80

RETROSPECTIVE
WHAT DO WE TALK ABOUT?
What helped me in my work?

What hindered my performance?
I’m talking about
me my work?
What made me enjoy

What made me feel bad?
80

RETROSPECTIVE
HOW TO SAY IT?
1 FACT DESCRIPTIONS
not evaluations of behaviors or judgements

2 POSITIVE LANGUAGE
because you know we’ll learn from your message

3 CONFIRMATION ASKING
to make sure your message has been understood

4 ACTIVE LISTENING
to learn from what others have to say
81

GROOMING
MEETING
Why?
Make backlog DEEP Who?
Help PO write stories Scrum master
Participate in early stage Team members
Product owner
When?
1 hour per sprint What?
After sprint planning?
Read/write/improve US
Estimation game


ESTIMATION
GAME 1/5
Backlog

ser

ry oryy y
U U to st r r

try
oUserrsero c
UorrI

InfoJobs Agile

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

InfoJobs Agile