Agile Scrum

Published on February 2017 | Categories: Documents | Downloads: 43 | Comments: 0 | Views: 414
of 101
Download PDF   Embed   Report

Comments

Content

Who I am?
Name: Dipl.-Ing. Sebastian Sussmann easier, just call me: Sebi
Skype: sebastian.sussmann.home

Email: [email protected]

8/8/2012

www.axonactive.vn

1

SCRUM

8/8/2012

www.axonactive.vn

2

Agile knowledge

8/8/2012

www.axonactive.vn

3

Why are we here? Software development

8/8/2012

www.axonactive.vn

4

Key points

Idea

parameter
Scope (output)
Budget
Time

Involved person
Manager
Customer
Worker

Steps
Flow
Framework
Process
Planning
Monitoring
Quality

Satisfaction
Quality
Get what he want and more

8/8/2012

www.axonactive.vn

5

How does it work?

Create first
version

Take out of
service

Changes until
the customer
is happy

improvement

Deployment

8/8/2012

www.axonactive.vn

6

How can it work?

Just for really small things
Create first
version

Take out of
but not for projects
service

Changes until
the customer
is happy

Whenimprovement
the process is too
complicated for the
defined
approach, the
Deployment
empirical approach is the
appropriate choice.
-> AGILE Methods

8/8/2012

www.axonactive.vn

7

Software process
W a te r fa l l mode l
S p i ra l mo d e l
R a ti ona l U ni fi e d P r oc e s s (R U P )
Op e n U n i f i e d P ro c e s s
P ro t o t yp e Mo d e l
V -M ode l
W -Mo d e l (w i t h p re t e s t p h a s e )
E x tr e me P r ogr a m mi ng (X P )
C rys t a l Fa mi l y
XU P : XP + R U P + MS F
OP E N
S c r um
K a nba n I T
S t a g e -Ga t e -Mo d e l
P e rs o n a l S o f t w a re P ro c e s s
P l a s t i c I n t e rf a c e f o r C o l l a b o ra t i ve Te c h n o l o g y I n i t i a t i ve s t h ro u g h V i d e o E x p l o ra t i o n
P ro c e s s P a t t e rn s
E n t e rp ri s e U n i f i e d P ro c e s s
A g i l e U n i f i e d P ro c e s s (A U P )
Mi c ro s o f t S o l u t i o n s Fra me w o rk
C a t a l ys i s
Te a m S o f t w a re P ro c e s s
P r ototypi ng
Mo d e l D ri ve n S o f t w a re D e ve l o p me n t
Fe a t u re D ri ve n D e ve l o p me n t (FD D )
Te s t D ri ve n D e ve l o p me n t
H e rme s (E D V ) s w i s s p ro je c t mo d e l
a c t i F: A g i l e p ro je c t mo d e l
R OP E S (R a p i d Ob je c t -o ri e n t e d P ro c e s s f o r E mb e d d e d S ys t e ms )
C MMI (C a p a b i l i t y Ma t u ri t y Mo d e l I n t e g ra t i o n )
I S O 1 2 2 0 7 , S o f t w a re L i f e C yc l e P ro c e s s e s
I S O 1 3 4 0 7 , U s e r Ori e n t e t S h a p i n g I n t e ra c t i ve S ys t e m
I TI L V 3 (s e t o f b e s t -p ra c t i c e s f o r I T s e rvi c e ma n a g e me n t (I TS M))
...
Source: http://de.wikipedia.org/wiki/Liste_von_Softwareentwicklungsprozessen
8/8/2012

www.axonactive.vn

8

waterfall

Requirements

Design

Code

Test

Maintenance
8/8/2012

www.axonactive.vn

9

waterfall

-Simple framework
-Looks like simple
management effort
-looks like a visible
process

Requirements

Design

Code

Test

-Sequential steps not every time
useful or not possible to do
-No feedback
-No risk analysis
-Discover problems only at the end
-User requirement only at the
beginning
-Risk of miss understanding
-Risk to get to much documentation
-sequential oriented
-...

Maintenance
8/8/2012

www.axonactive.vn

10

Prototype model

Prototype specification

Produce the prototype

Play around
Experimentation

yes

Accepted?

no
Changes and extend

8/8/2012

www.axonactive.vn

11

Prototype model

Prototype specification

Produce the prototype

-Maybe useful
integration in other
project models
-Get a fast user
feedback
-Producing fast
“software”

Play around
Experimentation

Accepted?

no

-If thisyes
is a main model it will have
yes
a big development
effort
-No documentation
-No maintenance possible
-Risk that this prototype will be
used
-sequential oriented

Changes and extend

8/8/2012

www.axonactive.vn

12

XP (Extreme Programming)

Driven by coding
the most important question is:
how to solve the coding,
This mean produce software
With close customer relation
Light documentation,
Mostly the customer
is not able to describe what he need
It needs a big interaction between
Customer and developer
The lifecycle
Month: release plan
...
Minutes: code / test

Source: http://en.wikipedia.org/wiki/File:Xp-loop_with_time_frames.svg
8/8/2012

www.axonactive.vn

13

XP (Extreme Programming)

Driven by coding
the most important question is:
how to solve the coding,

-The risk will be
checked regularly
-Best practice
-Realize the problems
early
-close customer
contact
-Fast first result

This mean produce software
With close customer relation
Light documentation,
Mostly the customer
is not able to describe what he need
It needs a big interaction between
Customer and developer

-No Transparency
-No Reusability
-It need trust
-Risk

The lifecycle
Month: release plan
...
Minutes: code / test

Source: http://en.wikipedia.org/wiki/File:Xp-loop_with_time_frames.svg
8/8/2012

www.axonactive.vn

14

Kanban





Continuously prioritized queue
Continuously deployment
Development and maintenance, combined
Visibly and easy to use

8/8/2012

www.axonactive.vn

15

www.axonactive.vn

16

Scrum on a beer coaster

Source: http://www.it-agile.com
8/8/2012

compare
XP

Scrum

RUP

V-Model

Waterfall

Focus

Development
process

Development process

Project process

Business process

Business Process

Important
roles

- Customer
- Developer

- Product Owner
- Scrum Master
- Team

- Software
architect

-System designer
- Software
developer

Project manager

Risk
Analyses

Everybody

Product Owner
together with Team

Architect

Project manager

Project manager

Priority

Stories together
with customer

Product Owner
together with Team

Architect

-System designer
-Project manager

Project manager

Architecture

Developer

Team together with
Product Owner

Architect

Developer

Architect

Test

Developer

Team

Quality control

Quality control

Quality control

Changes

Developer

Product Owner

Architect

Configuration
manager

No changes

Documentat
ion

Everybody

Team

Architect

Everybody

For each step

Driven by

Code

Scope

Documents

Documents

Documents

model

Small and agile

Small and agile
Time boxed

Big formal
framework

A big formal
framework

fix

8/8/2012

www.axonactive.vn

17

compare
XP

Scrum

RUP

V-Model

Waterfall

Focus

Development
process

Development process

Project process

Business process

Business Process

Important
roles

- Customer
- Developer

- Product Owner
- Scrum Master
- Team

- Software
architect

-System designer
- Software
developer

Project manager

Risk
Analyses

Everybody

Product Owner
together with Team

Architect

Project manager

Project manager

Priority

Stories together
with customer

Product Owner
together with Team

Architect

-System designer
-Project manager

Project manager

Architecture

Developer

Team together with
Product Owner

Architect

Developer

Architect

Test

Developer

Team

Quality control

Quality control

Quality control

Changes

Architect
Configuration
No changes
ItProduct
isOwner
not easy
tomanager
compare
Everybody
Team
Architect
Everybody is For each step
because
the focus
Code
Scope
Documents
Documents
different
for allDocuments
Small and agile
Small and agile
Big formal
A big formal
fix
processes...
Time boxed
framework
framework

Documentat
ion
Driven by
model
8/8/2012

Developer

www.axonactive.vn

18

Planned metrologies

Sequential

Iterative

Agile

defined process sequential

defined process iterative

iterative agile

Waterfall

Spiral

Scrum

V Model

RUP

XP

Prototype

ITIL

Kanban
Lean

Heavy weight methodologies work in some instances,
but there are HIGH COSTS, and can be HIGH RISK in
using them in DYNAMIC ENVIRONMENTS

8/8/2012

www.axonactive.vn

19

Stacey matrix

Source: http://www.derailleurconsulting.com/blog/complexity-and-noise-in-systems-development-projects
8/8/2012

www.axonactive.vn

Source: Strategic Management
and Organizational Dynamics by
Ralph Stacey in Agile Software
Development with Scrum by Ken
Schwaber and Mike Beedle.
20

Sequential vs. overlapping development

Requirements

Design

Code

Test

Rather than doing all of one
thing at a time...
...Scrum teams do a little
of everything all the time

Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
Source: Mountain Goat Software, LLC
www.axonactive.vn

21

Agile
Agile isn’t hype or a fad
It’s a process control framework for complex environments
It has always existed its not a new idea (see history)

and
Agile doesn’t work everywhere
Because Agile is not silver bullet !
Agile will not work and it will fail for example here:
- in really traditional engineering if the framework is fix
- Organizations which don’t ”accept” Agile thinking
- Very simple projects
(ok, it works, but these are simple enough to be done with any methodology)
8/8/2012

www.axonactive.vn

22

Goal and important features of Scrum

Scrum
Scrum is a Agile management framework
its used for incremental products
structure
Scrum will just mentioned about few rules
3 - ROLES (scrum team)
5 - EVENTS (meetings)
3 - ARTEFACTS (list of items)
Transparency
Inspection
Adaption
Definition of Done

8/8/2012

www.axonactive.vn

23

The goal and important features of Scrum

The process is Iterative / incremental
out put is always a potential shippable product increment.
That the customer will always get and see a result.
Time box / cycle
Everything is time boxed (all meetings)
Everything will be repeated and improved as a cycle
Documentation
the documentation is available but only the necessary documentation will be
done.
No overhead documentation

Its always better to show at least
something and the truth.
Promise a delay means nothing.
8/8/2012

www.axonactive.vn

24

Definition of Scrum
1913 Henry Ford
belt production
1948 – 1988 Taiichi Ohno
Toyota Production System (TPS) – Toyota Way - lean production (1990)
1986 Nonaka und Takeuchi
The New, New Product Development Game
to increase speed and flexibility
Its called „rugby“ approach and the whole process is perfomed by one cross functional team

1995 Ken Schwaber,
Schwaber, Jeff Sutherland
collaborated during the following years to merge the writings, their experiences, and industry best practices into what is now
now
known as SCRUM now

1999 M. Beedle, M. Devos, Y. Sharon, K. Schwaber, J. Sutherland
Scrum: A Pattern Language for Hyperproductive Software Development
2001 Ken Schwaber, Jeff Sutherland
defined the Agilen Manifest

Source images: scrum.org
8/8/2012

www.axonactive.vn

25

Who works with scrum

Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm, Nokia,
Sony Ericcson, Philips, BBC, IBM, SAIC, LMCO, Ariba, Federal
Reserve Bank, Medtronics, Motorola, Northrup Grumann, Applied
Physics Laboratory, Hewlett Packard, IDX, Siemens Medical, Gestalt,
Wildcard Systems, Primavera, Yahoo, Conchango, BMC, Lexis-Nexis,
Bentley Systems, Bose, CapitalOne, Federal Reserve Bank,
ClearChannel, Xerox, bwin, Nokia, Motorola, SAP, Ariba, Cisco,
Covad Communications, DoubleClick, Mercury Interactive,
SalesForce.com, Google, TomTom/Teleatlas, Intuit, Electronic Arts,
most game companies, teleradiology, Hangout, Air Force Advanced
Fighter heads up display, Erste Bank, AWACS, Adobe, Nominum,
Hangout, eDialogue, IDX teleradiology, NewsPage, Wildcard
Systems, F4-Networks, Engineering Innovation, Certeon, Allianz
Versicherung, AxonActive, ...

Source: collected
8/8/2012

www.axonactive.vn

26

... Scrum Artefacts

... Scrum Events

... Scrum Team
8/8/2012

www.axonactive.vn

27

... Scrum Team

Stakeholders

Product Owner
Scrum Master

Scrum Team
Team

8/8/2012

www.axonactive.vn

28

... Scrum Team

Product Owner
PO
► Defines the features of the product, decides on release date and content (based on product backlog)
► Is responsible for the profitability of the product (ROI)
► Prioritizes features according to market value
► Can change features and priority at product level
► Accepts or rejects w ork results (delivered product)
► represents the stakeholders and the business

© unbreakablepo.com
8/8/2012

www.axonactive.vn

29

Product Owner

... Scrum Team

Responsible for the ROI and the Product

© unbreakablepo.com
8/8/2012

www.axonactive.vn

30

... Scrum Team

Scrum Master
SM
► Ensures that the team is fully functional and productive
► Enables close cooperation across all roles and functions and removes barriers
► Shields the team from external interferences
► Ensures that the process is followed. Invites to daily scrum, iteration review and planning
meetings, ...
► Enforce timebox

©iStockphoto.com/ zoranmzoranm
8/8/2012

www.axonactive.vn

31

Scrum Master

... Scrum Team

Responsible for increasing
i
Productivity
and for using the scrum framework

©iStockphoto.com/ zoranmzoranm
8/8/2012

www.axonactive.vn

32

... Scrum Team

Team
T
► Cross-functional, seven plus/minus two members (full-time membership; Team based not Project based)
► Selects the iteration goal and specifies w ork results (based on order)
► Has the right to do everything within the boundaries of the project guidelines to reach the
iteration goal
► Organizes itself and the work
► Demos work results to the Product Owner

©iStockphoto.com/mikedabell
8/8/2012

www.axonactive.vn

33

Team
Responsible for delivering the product of each sprint

... Scrum Team

7 +/+/ - 2 member

©iStockphoto.com/mikedabell
8/8/2012

www.axonactive.vn

34

... Scrum Team

Stakeholder, Business Owner, ...
Steakholder
► The Product Owner works with the Stakeholders , represents their interests to the Team
► group of people who have an interest in your product that aren’t directly involved with its creation
► mostly also the customer
► sometimes who defined the business idea
► it can be everybody who is not part of the SCRUM TEAM

8/8/2012

www.axonactive.vn

35

Stakeholder, Business Owner, ...

... Scrum Team

Can support the Scrum team (as a Chicken)

8/8/2012

www.axonactive.vn

36

... Scrum Artefacts

... Scrum Events

... Scrum Team
8/8/2012

www.axonactive.vn

37

www.axonactive.vn

38

... Scrum Events

CYCLE - process SCRUM

8/8/2012

CYCLE steps and cycle
habit and stability

... Scrum Events

To get a potential shippable product increment

8/8/2012

www.axonactive.vn

39

CYCLE steps and cycle
NO changes during the sprint

... Scrum Events

The sprint is save and locked after commitment!

8/8/2012

www.axonactive.vn

40

... Scrum Events

CYCLE scrum artefacts

8/8/2012

www.axonactive.vn

41

... Scrum Events

ARTEFACTS Planning 1 WHAT

Attendees: ScrumMaster, Team, PO
Preparation: PO must prepare the backlog prior to meeting
Goal: Analyze the Product Backlog, Clarification on Backlog item (RISK, VALUE)
Goal: Select potential backblock Items for next sprint based on SIZE
Timebox : max. 4 hours (for a 4 week sprint)
Team / PO: will define SPRINT GOAL
Team: Make suggestions for items
PO: Final decision on what items to work on (will prove the goal again)
Team: Final decision on how much items to work on
8/8/2012

www.axonactive.vn

42

... Scrum Events

ARTEFACTS Planning 2 HOW

Attendees: ScrumMaster, Team
Must be available for answering question: ProductOwner
Goal: define the real issues and order for this sprint
(identifies TASKS, ESTIMATE)
Timebox: max. 4 hours (for a 4 week sprint)
Output: Sprint backlog
Output: Final commitment (proved by PO)

8/8/2012

www.axonactive.vn

43

... Scrum Events

ARTEFACTS Daily Meeting
Attendees: ScrumMaster, Team

RULES

Goal: Synchronize work

Discussion after the daily Scrum

Timebox: 15 minutes

Penalty for being late

Questions:

Same place and time every day

• What have you done since last meeting?
• What will you do before next meeting?
• What is in your way?

8/8/2012

Chickens (listen) and pigs (listen / talk)
Collect Impediments

www.axonactive.vn

44

ARTEFACTS Review Meeting
Attendees: ScrumMaster, Team, PO, Stakeholders

... Scrum Events

Preparation: No more than 1 hour (to be sure that everything is available and run)
Goal: Present the functionality and review it, adjust the requirements
Timebox: 4 hours (for a 4 week sprint)
• Team presents “DONE” functionality and discusses with PO and stakeholders
• Team cannot present functionality that is not “done”
• Product Owner prioritizes backlog accordingly
• LIVE Demonstration

8/8/2012

www.axonactive.vn

45

... Scrum Events

ARTEFACTS Retrospective Meeting

Attendees: Team, ScrumMaster.
(PO should be not for the Team Retrospective)
Timebox: 3 hours (for a 4 week sprint)

Actions
• Do we only have a few actions?
• Are they considered useful?
• Are they implemented?

Goal: Reflect and create actions for improvements
Is “done” extended?
Questions:
• What went well during last sprint
Updating our working agreements?
• What could be improved during last spint
• ScrumMaster facilitates
Do we require:
• Improvements needing action will be added to next sprint • Tasks in the Sprint backlog?
choose always 3 new issues and this three needs to be• improved
Items in the Product backlog?
8/8/2012

www.axonactive.vn

46

Best practice - unofficial ... Scrum Events

ARTEFACTS Releaseplanning Meeting

Release Planning

Whole Backlog

Several
Sprint backlogs
Attendees: PO, the Team and ScrumMaster
will support

Several
Sprints

Meeting timebox: as needed
date
Release cycle: release date time boxed based on fixed date with flexible scope OR fix scope flexible
Release

Goal: get a commitment for a release schedule, see release Burn down and Product Backlog

Best practice - unofficial ... Scrum Events

8/8/2012

www.axonactive.vn

47

ARTEFACTS Releaseplanning Meeting

Release Planning

Whole Backlog

Several
backlogs
Attendees: PO as needed, TeamSprint
and ScrumMaster

Several
Sprints

(PO should be not for the Team Sprint)
Meeting timebox: as needed
Release cycle: release date time boxed based on fixed date with flexible scope OR fix scope flexible
date
Release
Goal: get a commitment for a release schedule, see release Burn down and Product Backlog
8/8/2012

www.axonactive.vn

48

The backlog evolves, and its contents change frequently.
New items are discovered and added to the backlog based on customer and user
feedback.
Existing items are modified, reprioritized, refined, or removed on an ongoing basis.
It will be never fixed.
Grooming is Teamwork

Attendees: PO, the Team and ScrumMaster will support

D etailed
E stimated
E mergent
P rioritised

Meeting timebox: as needed
1. Analyse the customer and user feedback
2. Integrate the learning
3. Decide what to do next sprint
4. Create small stories
5. Get the stories ready (check acceptance criteria)
www.axonactive.vn

... Scrum Team

... Scrum Events

8/8/2012

8/8/2012

Output:

49

... Scrum Artefacts

Best practice - unofficial ... Scrum Events

Backlog Grooming

www.axonactive.vn

50

Best practice - unofficial ... Scrum Artefacts

ARTEFACTS Userstory
High-Level
Initial Story for sprint planning (Formal)

Front side: story

Best practice - unofficial ... Scrum Artefacts

8/8/2012

Back side: acceptance criteria

www.axonactive.vn

51

ARTEFACTS Userstory
High-Level
Initial Story for sprint planning (Formal)

Front side: story

I ndependent
N egotiable (until sprint)
V aluable (for customer)
E stimable
S mall
T estable
8/8/2012

Back side: acceptance criteria

As a <user role>,
I want <goal>
so that <reason>
Can I <acceptance criteria>
www.axonactive.vn

52

Or BDD

Story

Example 1: New lists are empty
Given a new list
Then the list should be empty.
Example 2: Lists with things in them are not empty.
Given a new list
When we add an object
Then the list should not be empty.

Based on Stories
Its also possible
To start

Code

BEHAVIOR DRIVEN
based

Source: http://en.wikipedia.org/wiki/Behavior_Driven_Development
8/8/2012

www.axonactive.vn

53

Userstory why

Main dish
comes with
soup or
salad
and bread.

...
8/8/2012

www.axonactive.vn

...
54

Requirenments

Functional
requirements

Non Functional
requirements

"A requirement specifies a function that a system
or component must be able to perform."
• Business Rules
• Transaction corrections, adjustments, cancellations
• Administrative functions
• Authentication
• Authorization –functions user is delegated to perform
• Audit Tracking
• External Interfaces
• Certification Requirements
• Reporting Requirements
• Historical Data
• Legal or Regulatory Requirements
...
8/8/2012

• Performance –
Response Time, Throughput, Utilization, Static Volumetric
• Scalability
• Capacity
• Availability
"A non-functional
• Reliability
• Recoverability
requirement is a
• Maintainability
statement of how a
• Serviceability
system must behave,
• Security
• Regulatory
it is a constraint upon
• Manageability
the systems
• Environmental
behaviour."
• Data Integrity
• Usability
• Interoperability
...

www.axonactive.vn

55

www.axonactive.vn

56

... Scrum Artefacts

Product Backlog

8/8/2012

... Scrum Artefacts

Product Backlog (concept)

Items at top are more granular than items at the bottom

8/8/2012

www.axonactive.vn

57

www.axonactive.vn

58

... Scrum Artefacts

Product Backlog (concept)

D etailed
E stimated
E mergent
P rioritised
8/8/2012

... Scrum Artefacts

Product Backlog (concept)

8/8/2012

www.axonactive.vn

59

... Scrum Artefacts

Product Backlog (concept)

• One list per product, one product backlog for one team
• List of functionality, technology, issues
• Emergent, prioritized, estimated
• More detail on higher priority items
• One list for multiple teams (this request area product backlogs)
• Product Owner responsible for priority
• Anyone can contribute
• Driven by Business and Vision
• the list is maintained and public posted
8/8/2012

www.axonactive.vn

60

... Scrum Artefacts

Sprint Backlog (concept)

• Issues / Stories with more than 1 or 2 days should be put in smaller tasks
• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)

Best practice - unofficial ... Scrum Artefacts

8/8/2012

www.axonactive.vn

61

Sprint Backlog (concept)

Stories are the commitment -> estimation POINTS
Each story can have several Tasks -> estimation in Points / Hours
the task should be not bigger than one day
this tasks are initial tasks
this tasks will discover the work to meet the fix scope of the story commitment
Every estimation is always based on Remaining Time
8/8/2012

www.axonactive.vn

62

... Scrum Artefacts

Sprint Backlog | Kanban

8/8/2012

www.axonactive.vn

63

... Scrum Artefacts

Impediment Backlog

©iStockphoto.com/jalalajalala

Organize and collect the impediments which can not solved during the sprint in one backlog
It is management’s job to remove provide an impediment removal service to the teams
so that they optimize value delivery.
choose always 3 new issues and this three needs to be improved

This is very hard work for Scrum Master
8/8/2012

www.axonactive.vn

64

responsibility

PO (T)
T (PO)
T (PO)

T

T
T
PO / T
8/8/2012

www.axonactive.vn

65

HELPFUL TOOLS
Helps us to stay on track

8/8/2012

www.axonactive.vn

66

adjustments value | The iron triangle
Scope is driven by budget and time in WATERFALL
Scope drives budget and time in TRADITIONAL METHODS

Budget

AGILE

Waterfall

Scope

Scope

Quality

Quality

Time

Budget

Overtime
8/8/2012

www.axonactive.vn

Time

Not on Time
67

adjustments units | time boxed
► ALL Meetings
► Development time (Sprints)
► Release

©iStockphoto.com/RBFried
8/8/2012

www.axonactive.vn

68

adjustments units; long-term productivity





no regularly overtime
higher long term productivity
planning of workload with team velocity and points instead of hours
the best team productivity is with around 85% load

Maxw ell Curve

8/8/2012

www.axonactive.vn

69

Plan-Do-Check-Act (PDCA) cycle

Act

Plan

Check

Do

W. Edwards Deming

8/8/2012

www.axonactive.vn

70

... Scrum Theory

three legs of scrum | adapt

8/8/2012

www.axonactive.vn

71

Sprint abnormal Termination
A sprint can be cancelled
by the Product Owner
if the sprint make no sense because of external
influences

by the Team if there is no way to fulfil anything
in the current Sprint
(should be approved by PO)

Start with a new
planning
and review the reasons of the termination

©iStockphoto.com/ Milos Jokic
8/8/2012

www.axonactive.vn

72

ScrumMaster

ScrumMaster

Project manager

Team

Team

Team
Team

ScrumMaster
facilitates

project manager
coordinates
8/8/2012

www.axonactive.vn

73

Best practice - Planning Meeting

The whole sprint

Order, schedule ...
How does a sprint work
Your time is limited at this meetings ...
You will need always a efficient process ...
©iStockphoto.com/ Kriss Russell;
8/8/2012

www.axonactive.vn

74

Best practice - Planning Meeting

PlanningMeeting

8/8/2012

www.axonactive.vn

75

www.axonactive.vn

76

Best practice - Planning Meeting

PlanningMeeting

Best practice - Planning Meeting

Size

8/8/2012

www.axonactive.vn

77

Best practice - Planning Meeting

Size

< 1 or max 2 days

8/8/2012

www.axonactive.vn

78

Best practice - Planning Meeting

MoSCoW

© Wikimedia: Рудаков Владимир
8/8/2012

www.axonactive.vn

79

www.axonactive.vn

80

Best practice - Planning Meeting

MoSCoW

© Wikimedia: Рудаков Владимир
8/8/2012

Must have
Order of one timebox

Best practice - Planning Meeting

MoSCoW

The requirement is essential, key stakeholder needs will not be satisfied if this requirement
is not delivered and the timebox will be considered to have failed. MUST can be
considered a backronum from M inimum U sable S ubse T
Should have
This is an important requirement but if it is not delivered within the current timebox, there is
an acceptable workaround until it is delivered during a subsequent timebox
Could have
This is a nice to have requirement; we have estimated that it is possible to deliver this in
the given time but will be one of the requirements de-scoped if we have underestimated
Won't have
The full name of this category is ‘Would like to have but Won’t Have during this timebox’;
requirements in this category will not be delivered within the timebox that the prioritisation
applies to

Source: www.daily-scrum.com/features/moscow-prioritization
8/8/2012

www.axonactive.vn

81

www.axonactive.vn

82

Best practice - Planning Meeting

customer value

8/8/2012

Best practice - Planning Meeting

Risk

For Risk and Customer Value
The PO should get the double
number as each team member

© Logan Ingalls from South Boston, MA, USA
8/8/2012

www.axonactive.vn

83

www.axonactive.vn

84

Best practice - Planning Meeting

kanban | planning board

8/8/2012

Best practice - Planning Meeting

risk value matrix

8/8/2012

www.axonactive.vn

85

www.axonactive.vn

86

Best practice - Planning Meeting

risk value matrix

8/8/2012

Best practice - Planning Meeting

risk value matrix | get priority

8/8/2012

www.axonactive.vn

87

Best practice - Planning Meeting

Order

Count with steps of 10

You can easy
reorder and
put some
stories
in-between

8/8/2012

www.axonactive.vn

88

Best practice - Planning Meeting

kanban | planning board

8/8/2012

www.axonactive.vn

89

www.axonactive.vn

90

Best practice - Planning Meeting

kanban | planning board

8/8/2012

Best practice - Planning Meeting

get order, check the acceptance criteria

8/8/2012

www.axonactive.vn

91

www.axonactive.vn

92

CYCLE scrum artefacts

Best practice - Planning Meeting

HOW TO ESTIMATE
At the planning meeting

8/8/2012

www.axonactive.vn

93

www.axonactive.vn

94

Best practice - Planning Meeting

estimation

• Quick
• Reliable
• Fun
• Fibonacci – Less argument
• Clarification on the difference
Not on the agreements
• Everybody is involved
Not only dictated by
most-knowledgeable person

8/8/2012

Best practice - Planning Meeting

estimation

Show a picture of planning poker set!

© Wikimedia: Borb (FibonacciBlocks.svg)
8/8/2012

www.axonactive.vn

95

www.axonactive.vn

96

Best practice - Planning Meeting

estimation

~75%

8/8/2012

Best practice - Planning Meeting

estimation | relation

> Relative estimation!
> Reference Story
(everybody should know it and should have the full understanding of this story)

> Points NOT hours! NO UNIT! For a Story item
www.axonactive.vn

8/8/2012

97

(planning meeting)
estimation | relation

2?

Okay, how long does
this story take?

...

8
Zzzzzzh

?????

Idea from: www.crisp.se/planningpoker
8/8/2012

www.axonactive.vn

98

(planning meeting)
estimation | relation

Hmm 2?

...

13 ?
Zzzzzzh

Maybe 40 ?

8/8/2012

www.axonactive.vn

99

(planning meeting)
estimation | relation

?

...

13 ?
Zzzzzzh

?

8/8/2012

www.axonactive.vn

100

(planning meeting)
estimation | relation

Hmm ... 2?

10

? 13

13 !
? 13

8

Okay 13 !

Maybe 40 ?

8/8/2012

www.axonactive.vn

PLANNING POKER

101

®

At the planning meeting

Planning Poker® is a reg. trademark of Mountain Goat Software, LLC.
Sequence of values is (C) Mountain Goat Software, LLC.
8/8/2012

www.axonactive.vn

102

(planning meeting)
estimation | relation

2

8?

Okay, how long does
this story take?

13?

5?

40?

8/8/2012

www.axonactive.vn

103

(planning meeting)
estimation | relation
I thought ... And because
of..... I know that...
Okay, thanks, big
divergence, why?

I done this and ... I got
... My experience... If
I do ..... Because ...

8/8/2012

www.axonactive.vn

104

(planning meeting)
estimation | relation
Ah, yes, i see.... hmmm

Okay, lets play again?

Ah, yes, i see.... hmmm

8/8/2012

www.axonactive.vn

105

www.axonactive.vn

106

(planning meeting)
estimation | relation

8/8/2012

(planning meeting)
estimation | relation
Yes

Yes

Okay, between 5 and 8 Not
such a big convergence.
everybody feel confident with
8?

Yes
Yes

Yes

8/8/2012

www.axonactive.vn

107

www.axonactive.vn

108

(planning meeting)
estimation | relation

Okay, how do you
think about the next
story?

8/8/2012

(planning meeting)
estimation | relation
I have no Idea.
I'm lost with this
story

I need a
break!

I see, there are some
questions, this story is
not clear and we
need a break.
Okay, lets have 5
minutes break
8/8/2012

www.axonactive.vn

109

(planning meeting)
estimation | relation |countries

1

2

3

5

big

Source: www.docondev.com/2010/08/roshambo-estimating.html
8/8/2012

www.axonactive.vn

110

Best practice - Planning Meeting

Sprint Backlog

8/8/2012

www.axonactive.vn

111

Sprint Backlog
Story

Task

If u need you can
create initial TASKS
Can be estimated in
hours

• Tasks / Stories with more than 1 or 2 days should be put in smaller tasks
• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)
8/8/2012

www.axonactive.vn

112

Sprint Backlog

Just for getting a higher
responsibility for quality and
testing we make sometimes a
estimation for D evelopment
and one for

T est.

the total points for the first

• Tasks / Stories with more than 1 or 2 days should be put
in smaller
tasks
Story
are 35 points
• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)
8/8/2012

113

www.axonactive.vn

Sprint Backlog

This list should be updated
everyday with the remaining
points ...
For each story!
You can do the update at
theindaily
meeting
• Tasks / Stories with more than 1 or 2 days should be put
smaller
tasks

• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)
8/8/2012

www.axonactive.vn

114

Best practice - Planning Meeting

COMMITMENT
last step at planning meeting

8/8/2012

www.axonactive.vn

115

www.axonactive.vn

116

Best practice - Planning Meeting

Velocity

8/8/2012

Velocity
One easy guesstimate rule

just 5 minutes for getting the available
working time for the following sprint

8/8/2012

www.axonactive.vn

117

Velocity
e.g three weeks sprint, starting by Wednesday
and a team size of 6 member

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

15 Days
0.5 Review
0.5 Retrospective
1
Planning I/II
0
Boxed days
---------------------------------13 Days left
===================
Don’t forget to count the
Scheduled holidays of
each team member
during this sprint
e.g.
one member takes 1 day
a other member 2 days
Calculate minus 3 days
--------------------------------13 days x 6 member = 78
78 - 3 holidays
= 75
===

8/8/2012

www.axonactive.vn

118

Velocity
You know already:
319 points done (average of the last sprints with same team )
78 working days for a normal sprint
4 velocity per day and person

319 / 78 = 4.09
(round off)

4 points per day and person

1

2

3

4

5

6

7

8

9

10

11

12

----------------------------------13 Days left
====================
working days
75
====================

This mean, we have
75 x 4 = 300
(round off)

13

14

15

8/8/2012

300 points can be commitment
for next sprint

www.axonactive.vn

119

Velocity
You know already:
319 points done (average of the last sprints with same team )
78 working days for a normal sprint
4 velocity per day and person

The current velocity is:
4 velocity
per day and person

8/8/2012

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

www.axonactive.vn

300 velocity
for sprint

120

Velocity

Grooming

Planning 1
Planning 2

1

2

3

4

5

6

7

8

9

10

11

12

Release

Review

13

14

Retrospective

15

Planning 1
Planning 2

Grooming

8/8/2012

www.axonactive.vn

121

www.axonactive.vn

122

Scrum Schedule

8/8/2012

Commitment

©iStockphoto.com/ pixdeluxe;
8/8/2012

www.axonactive.vn

123

www.axonactive.vn

124

The work will start

Backlog for
related teams...

Sprint backlog

8/8/2012

www.axonactive.vn

125

Best practice - Planning Meeting

Story

The story is owned
by the Team!
This only means:
who is currently
working on

5

Could be the
sign of the
verified person

Tai

S
8/8/2012

5

8
www.axonactive.vn

Must

126

Sprint Backlog | Kanban

Now you can add the
committed sprint backlog
direct to the “team board”
(Kanban)
This is the place where
you will have usually your
daily meeting.
8/8/2012

www.axonactive.vn

127

www.axonactive.vn

128

Best practice - Planning Meeting

How can I know our velocity

©iStockphoto.com/ OwnPrice;
8/8/2012

Velocity
Based on the
1.
2.
3.
4.

5.

Velocity
Number of team member
Number of stories
Commitment
1. Story points done
2. Story points remaining*
Working days

You can get a good forecast about the
speed of your team

*is a story started but not finished, must be spitted
and should be re-estimated
8/8/2012

www.axonactive.vn

129

Velocity
you will get information about
productivity and the next
sprint planning will be easier
...

8/8/2012

www.axonactive.vn

130

Velocity

8/8/2012

www.axonactive.vn

131

www.axonactive.vn

132

Daily Meeting

WHERE TO DO?
Daily Meeting

8/8/2012

www.axonactive.vn

133

www.axonactive.vn

134

In front of your team board

8/8/2012

Who is doing what ...

SM

Don’t do it like this!
8/8/2012

SM

www.axonactive.vn

135

www.axonactive.vn

136

Kanban | Team info board

8/8/2012

Kanban | Team info board

8/8/2012

www.axonactive.vn

137

www.axonactive.vn

138

Kanban | Team info board

8/8/2012

kanban | Team info board

8/8/2012

www.axonactive.vn

139

www.axonactive.vn

140

kanban | Team info board

8/8/2012

BURNDOWN
At the daily meeting

8/8/2012

www.axonactive.vn

141

Burndown

Example if you track the daily
burndown in an excel file
This is only useful for
remote

8/8/2012

www.axonactive.vn

142

Burndown

Team 1 “lazy”
10 stories
10 days
100 points commitment

8/8/2012

www.axonactive.vn

143

Burndown

Common mistake 1
We are hiding important information, if we just use one simple
burndown like only for points everyday!
Often it will look quite good but there is no way to get a successful sprint
In total 80% NOT DONE

8/8/2012

www.axonactive.vn

144

Burndown

Team 2 “no Risk”
10 stories
10 days
100 points commitment

8/8/2012

www.axonactive.vn

145

Burndown
Common mistake 2
High risk and big stories at the end....
The combined chart will discoverer this problem
It looks like only 30 points remaining but this two
stories are 50 points. They are not part of the
delivery sprint product.
This mean nearly 50% NOT DONE

8/8/2012

www.axonactive.vn

146

Burndown

Team 3 “progress”
10 stories
10 days
100 points commitment
The big burn up is now
a bit earlier ... time to act

8/8/2012

www.axonactive.vn

147

Burndown
Team 3 “progress”
High risk and big stories at the beginning,
helps to solve problems earlier
....
Even here was a burn up but enough time to act
95% Done of this Sprint

8/8/2012

www.axonactive.vn

148

BURNDOWN
BASED ON REMAINING
At the daily meeting

8/8/2012

www.axonactive.vn

149

www.axonactive.vn

150

Burndown

Important are the
remaining points,
Agile is not interested in
how many points are
already done!
We want know how many
points are left!

8/8/2012

Burndown

Daily meeting

Velocity 4 points per day and personStill not finished as
Story 1 = 8 Points
planned, I need
more time but nearly
finished....

6

4

2

0.5

0.5

0.5

Person 1

8/8/2012

www.axonactive.vn

151

Burndown

Daily meeting
Person 1
4 points per dayPerson
and person
2
Is just tracking Velocity
the
Story
1
=
8
Points
Say how much
working hour...
effort is still
remaining for this
story!

6

4

2

0.5

8

8

6

4

0.5

With this information
we can easier say
something about the
delivery time
And we can catch the
problems much earlier
and can take influence

0.5

Person 1
Person 2

8/8/2012

www.axonactive.vn

2

2

152

Review

www.axonactive.vn

153

Review
The meeting should feature a live demonstration
NOT A REPORT
T

T

ST

T

ST

T

Everybody can join,
Customer should be involved

T
T

The Team will only present FINISHED stories

PO

After demonstration the PO review the commitment made at last planning
And declare which item is DONE (and part of potential shippable)
8/8/2012

www.axonactive.vn

154

Review
The meeting should feature a live demonstration
NOT A REPORT
T

T

ST
ST
• Show Live demonstration
• AVOID PowerPoint
-> show end-user functionality
- Use acceptance test

T
T

Everybody can join,

T
T

The Team will only present FINISHED
Review, consider,
organize, decide,
inspect - Adapt

• Focus on discussion more than on demo
Customer should be involved
• Shared learning rather than reporting
• AVOID long “demo preparation”
preparation ~1hour
stories
to prepare environment
prepare data
make a own schedule
PO

It helps to discover
what the customer
really want

After demonstration the PO review the commitment made at last planning
And declare which item is DONE (and part of potential shippable)
8/8/2012

www.axonactive.vn

155

www.axonactive.vn

156

Product changes

Update backlog:
- With new requirements
- With changed requirements
- With the corrected understanding

Retrospective

www.axonactive.vn

157

Retrospective
The Team will reflect there own process
Facilitated by
ScrumMaster

What went well,
what could be
improved.

SM

Team devises
solution to most
vexing problems

T

T

Last Sprint
T
T

T
T

To solve in next sprint
Choose every sprint three impediment and
This three needs to be solved!
8/8/2012

www.axonactive.vn

158

Retrospective
The Team will reflect there own process
Facilitated by
ScrumMaster

What went well,
what could be
improved.

SM

Team devises
solution to most
vexing problems

TAKE ALWAYS CARE THIS MEETING
T
SCRUM can be only get SUCESS with this meeting.
its one of the most important meeting!
Last Sprint

T

Check previous actions first. If not done, retrospect on them!
T
Only select a couple actions and really DO them.
T
Focus on an constructive attitude.
- “What can WE do”.

T

T

To solve in next sprint

Some hints:
http://www.scrumalliance.org/articles/61-plan-of-action

Choose every sprint three impediment and
This three needs to be solved!

8/8/2012

www.axonactive.vn

159

www.axonactive.vn

160

Impediment backlog

Update backlog:
- The SM will take care this.
- but it doesn't mean that he
need to solve all items
by himself

Product Backlog



8/8/2012

www.axonactive.vn

161

Product Backlog

Maybe the product
owner like it to prepare
it in an excel file... *

But be careful, don't use to many tools,
then u will produce overhand work and
nothing is synchronized.

*the estimation need to be
updated after each sprint

paper will be the most efficient way...
Its always the remaining
estimation

8/8/2012

www.axonactive.vn

162

Product Backlog BurnDown

If we got all stories
estimated, we can keep
track about the product and
make a more realistic
release plan ...

Similar to the daily
sprint burn down we
can get based on the
planning meeting and
the velocity of your
team you can get a
product burn down

8/8/2012

www.axonactive.vn

163

Product Backlog BurnDown

if we update the backlog
careful, it will indicate us: when
we will reach the goal of the
product.
Here it will be after sprint 8

8/8/2012

www.axonactive.vn

164

RESPOSNSBILITY

8/8/2012

www.axonactive.vn

165

www.axonactive.vn

166

Chickens and Pigs

Source: www.implementingscrum.com
8/8/2012

Who is who and where? SCRUMLIES

8/8/2012

www.axonactive.vn

167

Who is who where where? SCRUMLIES

8/8/2012

www.axonactive.vn

168

NOTES / HINTS
Go / no-go

8/8/2012

www.axonactive.vn

169

“undone” work - release sprint
Avoid This!
You will hide the reality and you will not solve problems;
You will get problems!

Undone work contains: Delay & Risk

8/8/2012

www.axonactive.vn

170

“undone” work - the undone unit
Avoid This!
You will hide the reality and you will not solve problems;
You will get problems!

Undone work contains: Delay & Risk

8/8/2012

www.axonactive.vn

171

www.axonactive.vn

172

Secret developer toolbox!

Don’t do it!
Don’t use it!
©iStockphoto.com/Sean Lock
8/8/2012

Definition of Done
a story is defined to be done if we have done:
> checked in to subversion
> Deployment (place should be defined with PO)
- test case
- deployment description ready
- if needed example files
> documented
- technical documentation
- user manuals
- migration notes
- new and noteworthy
> reviewed b another team member (or paired)
code review guidelines are used
- code comments
- naming convention
> successfully build by e.g. hudson
> appropirately tested
- junit tests
- integretaion tests
- automation tests
- manual tests
- code quality, zero bugs
> ready to show a demonstration example
> quality of build release tested and
approved by another team member
- usability
- simplicity
- Function
- integration
- performance
- all exceptance criteria are full filled
8/8/2012

www.axonactive.vn

173

www.axonactive.vn

174

protected sprint

Nino Barbieri
8/8/2012

protected sprint

Source:
8/8/2012

www.axonactive.vn

175

www.axonactive.vn

176

Handmade

8/8/2012

AGILE MANIFESTO

8/8/2012

www.axonactive.vn

177

agile Manifesto

http://agilemanifesto.org/
8/8/2012

www.axonactive.vn

178

agile Manifesto

Chúng tôi phát hiện ra cách phát triển phần mềm tốt hơn bằng cách
thực hiện nó và giúp đỡ người khác làm điều đó. Qua công việc này,
chúng tôi đã đi đến việc đánh giá cao:

Các cá nhân và sự tương tác hơn là quy trình và công cụ;
Phần mềm chạy được hơn là tài liệu toàn diện;
Việc cộng tác với khách hàng hơn là việc đàm phán hợp đồng;
Sự phản hồi với các thay đổi hơn là bám sát kế hoạch.

http://HanoiScrum.net

http://agilemanifesto.org/
8/8/2012

www.axonactive.vn

179

Principles behind the Agile Manifesto
(1) Our highest priority is to satisfy the custom er through early and continuous delivery of valuable software.
(2) W elcom e changing requirem ents, even late in developm ent. Agile processes harness change for the
custom er's com petitive advantage.
(3) Deliver working software frequently, from a couple of weeks to a couple of m onths, with a preference to the
shorter tim escale.
(4) Business people and developers m ust work together daily throughout the project.
(5) Build projects around m otivated individuals. Give them the environm ent and support they need, and trust
them to get the job done.
(6) The m ost efficient and effective m ethod of conveying inform ation to and within a developm ent team is faceto-face conversation.
(7) W orking software is the prim ary m easure of progress.
(8) Agile processes prom ote sustainable developm ent. The sponsors, developers, and users should be able to
m aintain a constant pace indefinitely.
(9) Continuous attention to technical excellence and good design enhances agility.
(10) Sim plicity--the art of m axim izing the am ount of work not done--is essential.
(11) The best architectures, requirem ents, and designs em erge from self-organizing team s.
(12) At regular intervals, the team reflects on how to becom e m ore effective, then tunes and adjusts its
behavior accordingly.
Source: www.agilemanifesto.org/principles.html
8/8/2012

www.axonactive.vn

180

Pair programming

Pair programming is an agile software development technique in which two
programmers work together at one workstation.
One types in code while the other reviews each line of code as it is typed in.
The person typing is called the driver.
The person reviewing the code is called the observer (or navigator[1]). The
two programmers switch roles frequently.
http://en.wikipedia.org/wiki/Pair_programming
http://en.wikipedia.org/wiki/File:Pair_programming_1.jpg
8/8/2012

www.axonactive.vn

181

PROJECT MANAGEMENT
Hints and notes

8/8/2012

www.axonactive.vn

182

Kanomodel

8/8/2012

www.axonactive.vn

183

www.axonactive.vn

184

Project sucess slider

Source: www.mountaingoatsoftware.com/tools/project-success
8/8/2012

scalability ….
- For one customer feature u will need several teams
this will cost additional planning, coordination
handover.... (waste)
- One story is split to several teams

( )
- One customer feature can be created by one team
the dependencies between teams is sharing code
it simplify planning
require: frequent integration
- One story is only related to one team

8/8/2012

www.axonactive.vn

185

scalability ….

1st Sprint planning - together (AREA)
2nd Sprint planning - alone (TEAM)
Sprint loop alone (TEAM)
Product is coming together (everybody)
Review together (AREA)
1st Retrospective alone (TEAM)
2nd Retrospective (everybody)

8/8/2012

www.axonactive.vn

186

scalability ….

SM

SM

SM
SM

SM
SM

SM

SM

SM

SM

SM

SM

SM

SM

SM

SM
SM

SM

8/8/2012

SM

SM
SM

SM

SM

SM

SM

SM

SM

SM SM

SM

www.axonactive.vn

187

www.axonactive.vn

188

cool stuff day

8/8/2012

Self organized teams
Self-directed teams

Traditional organization

Customer-driven

Management-driven

Multi-skilled workforce

Workforce of isolated specialists

Few job descriptions

Many job descriptions

Information to everybody shared

Information limited

Few levels of management

Many levels of management

Whole-business focus

Function/department focus

Shared goals

Segregated goals

Seemingly chaotic

Seemingly organized

High worker commitment

High management commitment

Continuous improvements

Incremental improvements

Self-controlled

Management-controlled

Values/principles based

Policy/procedure based

Source: www.featureteamprimer.org
8/8/2012

www.axonactive.vn

189

organisation
Be aware: Scrum will change the Organisation

Scrum Team

Being able to deliver a product every month will have a rippleeffect through the whole organisation
Source: www.odd-e.com
8/8/2012

www.axonactive.vn

190

Organisation

Scrum will be conflicting with lots of traditional organization roles and
responsibilities:
-

Project manager will disappear?

-

Line manager will change

-

Tester will disappear?

-

Other roles will change...

... Impediment backlog ...

Always remember, this will be a personal change in some persons future and
career!
-

It will be sometimes really difficult and really painful.

Source: www.odd-e.com
8/8/2012

www.axonactive.vn

191

Organisation

Common reasons
for changing Scrum

99.99% of the changes to Scrum itself are because of
not understanding its purpose
or
to hide problems.
Avoid that.

Source: www.odd-e.com
8/8/2012

www.axonactive.vn

192

Good Scrum Smells

• Estimates are updated every day
(by remaining time)
• Everybody is there at scrum on time every day
(penalty for late)
• People offer to help others
• People ask for help
• People present the team with problems and solve them as a team
• work cross functional
(cross testing)
(help to verify other stories, e.g. By sign)
• There is lots of talking and interaction
• Lots of silly bits introduced by the team

8/8/2012

www.axonactive.vn

193

Bad Scrum Smells

• The are
Sprint
requires
a lot
more work than was planned
• Estimates
updated
every
day
Team member
(by•remaining
time) reports the same item more than two days
with
same
or greater
estimates
• Everybody
is the
there
at scrum
on time
everyand
daynobody notices or
(penaltycares
for late)

Product
not available for consultation
• People offer to Owner
help others
• Hidden
multiple backlogs
• People
ask foror
help
• Acceptance
the with
status
quo
• People
present the of
team
problems
and solve them as a team

No
interaction
outside
of
daily
scrum
• work cross functional
• Definition
(cross
testing) of Done/Acceptance Criteria missing
• Failure
to produce
potentially
shippable
software every sprint
(help
to verify
other stories,
e.g. By
sign)
Distractions
from and
outside
the team
• There• is
lots of talking
interaction
• Lots of silly bits introduced by the team

Source: Original slide - Alan Atlas
8/8/2012

www.axonactive.vn

194

where are the BUGs

© Jon Sullivan (PD-PDphoto.org)
8/8/2012

www.axonactive.vn

195

www.axonactive.vn

196

just start!

8/8/2012

ONLINE?!
This is not such easy and will produce some
overhead work
Mostly only useful for distributed teams
Online tools can not replace a
real board (Kanban) and paper
stories!

8/8/2012

www.axonactive.vn

197

www.axonactive.vn

198

Online tools

Source: www.agilezen.com; axonactive.vn (redmine, mantis)
8/8/2012

just start!

©iStockphoto.com/olm26250
8/8/2012

www.axonactive.vn

199

Starting point

Starting point in your company
1. Get at least one dedicated long-lived permanent
and cross-functional team
2. Define “Done”
3. Make sure all work flows via the Product Owner
4. Keep project managers out

Source: www.odd-e.com
8/8/2012

www.axonactive.vn

200

just start! Sprint 0

1. Setup Team (crossfunctional, Training Scrum)
2. Setup environment
-Software / hardware / Server
-Whiteboard
-Online project management needed?
3. Setup backlog
4. Get experience
5. Get first velocity
6. Negotiate and get DoD ready (approved by PO)
8/8/2012

www.axonactive.vn

201

Disclaimer
This presentation is an ongoing w ork and w ill be updated frequently and improved frequently.
1. Use
This presentation may be used:
By Sebastian Sussmann for AxonActive Vietnam and ECCI
2. Content
The author reserves the right not to be responsible for the whole correctness, completeness or quality of
the information which is provided at this document. If some body will get problems because of using some
information out from this presentation, the author will reject all claim. Because the author can not
guarantee the correct use of all provided information. The author done it with the best of one's knowledge
and belief
This presentation / document is not complete. The author can add and remove and change complete or
partly everything at every time.
3. Copyright
The author intended not to use any copyrighted material for the presentation. For the case it was clear
indicated he provide the copyright and source information at this page to indicate the copyright and the
way of use.
The copyright for any material created by the author and the company AxonActive Vietnam is reserved.
Any duplication or use of objects such as images, diagrams, sounds or texts in other electronic or printed
publications is not permitted without the author's agreement.
4. References:
http://www.s c r um al l ia nc e.o r g/
http://www.s c r um .or g/
http://www.od d- e.c om /
http://www.das s c r um team .c om /
http://www.bo r is g lo ger .c om /
http://www.s o r ec o.c h / / http://ww w.ax onac t i ve. vn
http://www.ag i l e v ietn am .or g/
http://www.to r s te n- ho r n.d e/
http://www.m ounta in goats of t war e .c om /
8/8/2012

www.axonactive.vn

202

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close