Agile Scrum Scrum... · Agile Scrum Foundation training IMPROVEMENT BV ©2016 21 Agile Scrum...

Agile Scrum Foundation training

IMPROVEMENT BV ©2016 www.improvement-services.nl 1

©IMPROVEMENT BV www.improvement-services.nl

Erik Philippus

IMPROVEMENT BV [email protected]

Agile Scrum

Foundation Training

Planning Board

To Be Done In Progress Done

0

Burn-down chart

Stor

y Po

ints

10 20 30 40 50 60 70

The Essence of Agile

12

Welcome

& Introduction

2

Agile

Contracting

3

Questions Wrap-up

2

Backlog

Break

8

SCRUM basics

22

Agile

Project Planning

17 0 1 2 3 4 5 6 7 8

70 Unplanned

Work

4

68



Nice To Meet You!

Erik Philippus (1951) IMPROVEMENT BV

35 years of experience in industrial automation Foxboro, ESA, Philips, Assembléon, Vanderlande, Vitatron, ASMI, Agilent, ASML, Imtech, NXP, …

Agile Development •  Training, Certification & Workshops •  Agile Architecting •  Agile Implementation

www.improvement-services.nl Archive login: ImprovemenT/Wachtw00rd

Planning Board


0

Burn-down chart

Stor

y Po

ints

10 20 30 40 50 60 70


12

Welcome

& Introduction

2

Agile

Contracting

3

Questions Wrap-up

2

Backlog

Break

8

SCRUM basics

22

Agile

Project Planning

17 0 1 2 3 4 5 6 7 8

70 Unplanned

Work

4

68

56



What is Agile?

•  English phrase:

in Dutch: ‘beweeglijk’, ‘wendbaar’, ‘gezwind’

•  Italian musical espression: fast, trills, embellishments •  Project Management: the flexible and fast response of organizations to unpredictable changes and customer demands

Agility

Agile: The Art of Dealing with Uncertainty

I thought I was interested in

uncertainty, but now I’m not so

sure …



The Era of Predictability

The Horizon of Predictability



The Ghost of Uncertainty

Uncertainty is part of every innovative and creative development process.

The Agile Paradigm embraces change, unpredictability and

unforeseen complexity as inescapable constants

in all product development.

Requirements

Design

Development

Testing & Validation

Deployment & Maintenance

-

The Waterfall Approach

lacking (customer) feedback loops

loss of information at transition moments

Managing The Development of Large Software Systems



Tangible Deliverables The Primary Measure of progress

Requirements

Design

Development


50% done

50% done

Traditional Agile

Requirements

Design

Development


A Paradigm Shift

Traditional •  Customer knows what he wants •  Engineers knows how to build it •  Nothing changes along the way

Agile •  Customer discovers what he wants •  Engineer discovers how to build it •  Things change along the way

Predictive Adaptive



Mindsets

Ability Static Can Grow Goal To look good To learn Challenge Avoid Embrace Failure Defines your identity Provides information Effort For those without talent Path to mastery Misfortune Helplessness Resilience

Agile Mindset Fixed Mindset

ImprovemenT Blog: Agile Mindset

Virtual Cattle-Grid



Response to Unpredictability

Agile Waterfall

Plan-Driven Heavy-weight

Value-Driven Light-weight

Decide late Deliver fast

Decide early Deliver slow

Incremental

Spiral Model

value value value

resilience

Predictive Adaptive

Historical Roots of Agile Methods

Individuals and interactions over processes and tools Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

The Agile Alliance Utah, Februari 2001

Agile Manifesto Core Agile Values

Agile methods are people-oriented rather then process-oriented

That is, while there is value in the items on the right, we value the items on the left more.



•  Our highest priority is to satisfy the customer through early and frequent delivery of high-quality software.

•  Welcome changing requirements, even late in development.

•  Business people and developers must work together daily throughout the project.

•  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

•  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

•  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

•  Agile processes promote sustainable development by maintaining a constant pace.

Agile Principles

Agile Myths Popular Misconceptions

Agile is anti-planning

Agile is

undisciplined

Agile requires a lot of rework

Agile is

anti-architecture

Agile doesn’t scale

Agile is a silver bullet

Agile is anti-documentation

Agile is only for software development



•  Extreme Programming (XP) •  Crystal Family •  Dynamic Systems Development Method (DSDM Atern) •  Test-driven Development (TDD) •  Essential Unified Process •  Agile Unified Process •  Scrum •  Kanban

AGILE The Agile Family

Incremental Delivery: don’t bite off more than you can chew



Visual Management You Can’t Manage What You Can’t See

Communication by using visual signals instead of texts or other written instructions.

information radiators

Tasks are broken down into small increments (2-4 weeks), in which the team works through

a full development lifecycle

•  Planning is more realistic with frequent releases •  Allows project to adapt to changes quickly

Time-Boxed Activities

Creation of a rhythm

Minimizes the overall project risk



Tangible Deliverables

Early and relevant feedback is a vital element of Agile!

Tolerance for Change

BDUF Big Design Up Front BPUF Big Planning Up Front



Collaboration

Every Agile Team has collective ownership

with respect to challenges as well

as victories!

Agile = Teamwork



Continuous Learning

Step outside your comfort zone to find new or better ways to

improve what it is you’re doing

Creativity

F.A.I.L = First Attempt In Learning



One of the aims of traditional methodologies is to develop a

process where the people involved are replaceable parts (resources)

Coder

Tester

Designer

?

Analyst

Agile Teams are Small (6 ± 3),

Cross-functional & Self-Organizing

Empowered Teams

How Cross-Functional should my team be?

ability to work outside the core area

deep skills in a functional area

Always 7%

Never 45% Rarely

19%

Often 13%

Sometimes 16%

Source: Standish Group Study Report

Focus on Customer & End-User

If you don’t have

the actual customer

involved, you’re

just guessing

at requirements

Hearing the voice of customers and end-users is fundamental for Agile



Prioritization

Don’t waste time working on things that do not add immediate value.

Work on the most important items first. These are the things that add the most business value.

Prioritizing is more important than time planning!

Richness of Communication

Com

mu

nic

atio

n E

ffec

tivi

nes

s

whiteboard

telephone

email paper

2 people communicating through:

Increasing communication temperature is an important goal of the Agile approach

face-to-face

Communication



Communication

Alignment Golden Rule: “Try to understand before

you want to be understood”

Source: Steven Covey - The Habits of Highly Successfull People

Agile Manager: Servant Leadership

•  Shared Vision Distilling the customer’s grand vision into a meaningful plan for everyone involved in the project Layout a common set of understandings from which emergence, adaptation and collaboration can occur

•  Environment Enhancing team productivity by doing whatever possible to minimize obstacles and optimization of the environment Battling organizational dysfunctionality

•  Politics Using the various agile mechanisms to minimize politics and keep everything visible and obvious

•  Continuous Improvement Promotion of an organizational culture of continuous learning (from mistakes)

Don’t confuse

‘Servant Leadership’ with

‘No Leadership’



Agility: Creating Value in an Unpredictable World

•  Productivity •  Effectiveness •  Product Quality •  Reponse Times •  Time-to-market •  Customer Satisfaction •  Employee Motivation •  Continuous Learning

Agility is about staying successful in complex, dynamic and

unpredictable environments

Agile Adoption The Crucial Role of Management

Team level impediments, if any, will dominate in the short run,

while management level impediments dominate in the long run.

Transformation impediments are in most cases

management level related

Paragraph on Agile Adoption



Agile Adoption Common Obstacles

Ability to change organizational

culture

52%

General resistance to change

41%

Availability of personal

with the right skills

33%

Management support

31%

Trying to fit Agile elements into a non-agile

environment

35%

Project complexity

26%

Customer collaboration

26%

Budget constraints

14%

Confidence in ability to scale

22%

Perceived time to

transition

14%

None

13%

Agile Adoption Success Rate

Challenged Success Failed

Traditional Agile

9%

42% 49% 29%

14% 57%

Source: The CHAOS Manifesto, Standish Group 2012



Agile is an iterative and adaptive approach to system development,

performed in a highly collaborative manner

by self-organizing teams,

with just enough ceremony that produces high quality systems in a cost effective

and timely manner,

which meets the changing needs of its stakeholders.

Agile System Development ‘the return of common sense’

Planning Board


0

Burn-down chart

Stor

y Po

ints

10 20 30 40 50 60 70


12

Welcome

& Introduction

2

Agile

Contracting

3

Questions Wrap-up

2

Backlog

Break

8

SCRUM basics

22

Agile

Project Planning

17 0 1 2 3 4 5 6 7 8

70 Unplanned

Work

4

68

56

34



Agile Scrum Essentials

Paragraph on Agile Scrum Topics

•  is a empirical process framework for developing and maintaining complex products •  delivers products of the highest possible business value •  is simple to understand, but very challenging to master •  has a history of success on a wide variety of projects •  makes clear the relative efficacy of product management and development practices •  will surface (organizational) issues quickly, offering possibilities for significant improvement •  is not a silver bullet

Scrum is a Framework For Agile Project

Management

What is Scrum?

Scrum and XP From the Trenches



Scrum Basics

Scrum facilitates an incremental, feature-driven & time-boxed product realisation process

product owner

scrum master

development team

Scrum in a Nutshell

2-4 week



Software Requirements

Problem with IEEE-830 style software requirements: •  Tedious to read, so readers skim or skip sections •  Multi-interpretable, error-prone •  Assumes everything is knowable in advance

If detailed requirements are written down

The user will get what he/she wants

At best, the user will get what was written

then

You built what I asked for, but it’s not what I need

Requirements Specification the formal way

1. The product shall have a gas engine

2. The product shall have four wheels

2.1 The product shall have a rubber tire mounted to each wheel

3. The product shall have a steering wheel

4. The product shall have a steel body



As a user, I want to mow my lawn quickly and easy

As a user, I want to be comfortable while mowing my lawn.

Define Motivations, Don’t Define Implementations

Agile Requirements Specification where the formal meets the informal

A user story is one or more sentences in understandable language that captures what the user wants to achieve. General Format:

As a [user role] I want [goal], so that I can achieve [value]

What is a User Story ?

WHO WHAT WHY

Understanding the why facilitates creative and original ways to solve the problem.



Als een deelnemer aan deze training, wil ik ……..

What is a User Story ? exercise

Job Stories alternative for/addition to User Stories

As a regular customer, when I purchase more than € 10.000 in goods, I become a preferred customer so that I will receive a 10% discount on all prices.

Persona Action Rationale

User Story

When a customer purchases more than € 10.000 in goods, he becomes a preferred customer so that he will receive a 10% discount on all prices.

Situation Motivation Expected Outcome

Job Story



51

Why User Stories ?

•  User stories bring the customer perspective into the project, providing a concise ‘hook’ for business goals and user expectations

•  User stories are a medium for discussion and prioritization of requirements with (non-technical) stakeholders

•  User stories promote participatory design and supports cross-functionality in the team

•  User stories will make clear what the users actually need (instead of what they want)

•  User stories facilitate realistic project

monitoring and reliable release planning

ID 13 11

5

16

User Stories As a GIS administrator I want to restrict editing of the State Forest Layer to only users in the Editor's role so that this layer isn't accidently edited As an Editor I want features in the State Forest Layer to be automatically clipped by the Forest District Features so that correct topology relationships are maintained As a GIS administrator I want the system to block standard deletions from the State Forest Layer, so that Users am forced to formally dispose of the feature As an Editor I want features in the State Forest to be automatically checked so that no features overlap within the same layer

Project Backlog: Landscape Exam Tool

Sample Product Backlog

Estimation (Story Points)

5 8 4 3

Publicly Visible

Prioritised by value and risk Includes

rough estimates



ID 13 11

5

16

User Stories As a GIS administrator I want to restrict editing of the State Forest Layer to only users in the Editor's role so that this layer isn't accidently edited As an Editor I want features in the State Forest Layer to be automatically clipped by the Forest District Features so that correct topology relationships are maintained As a GIS administrator I want the system to block standard deletions from the State Forest Layer, so that Users am forced to formally dispose of the feature As an Editor I want features in the State Forest to be automatically checked so that no features overlap within the same layer

Project Backlog: Landscape Exam Tool

Sample Product Backlog

Estimation (Story Points)

5 8 4 3

Have conditions of satisfaction which can

be tested at review/delivery

Are product features described within the context

of the customer/end-user

Have no or minimal dependency on other user stories

May contain a reference to detailed specifications

Fits into a single sprint to keep the work flowing

Sprint

Release priority

The Product Backlog Pyramid

days

weeks

epic

theme

months

Refinement (Grooming)

user stories



Product Backlog Refinement An ongoing, parallel activity

Refinement

Development

increment

Continuous

Sprint

Sprint

Release priority

The Product Backlog Pyramid

days

weeks

epic

theme

As a team member , I can indicate folders not to backup, so that my backup drive isn’t filled up with things I don’t need to save

As a team member, I can specify files or folders to backup based on file size,

date created and date modified, in order to facilitate an fast and

effective backup process.

months

As department manager, I want to have the guarantee

that project data never get lost, in order to guarantee an uninterrupted workflow

As a project leader, I want to provide my team with a tool that enables them to easily backup

essential data, so that previous versions of project information can be retrieved



Refinement Toward Bit-Sized Chunks

Spike Upfront Investigation & Dealing with Epics

Sometimes the scope and content of user stories or epics can be understood

only after targeted analysis

A spike is a special type of story for activities such as:

exploration, research, analysis, design, proof of concept, prototyping, etc.

Gain knowledge necessary to:

•  Underline architectural trade-off decisions •  Reduce risk of a certain technical approach •  Better understanding of critical requirements •  Increase reliability of high-level estimations •  Disaggregate large user stories into constituent stories

Blog: Architecture Spikes Spikes.pdf



Spike Example

Epic: As a consumer, I want to see my daily energy use in a histogram so that I can quickly understand my past, current and projected energy consumption

Technical Spike: Research how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data. Functional Spike: Prototype a histogram in the web portal and get some user feedback on presentation size, style and charting

The Product Backlog: shields the team from interference

high priority

low priority

Each iteration implements the highest priority

work items

New work items are prioritized and

added to the stack

Work items may be reprioritized at any time

Work items may be removed

at any time

Modifications Defects Patches Customer Requests Market Demands …

Team



Dealing with high urgency items

high priority

low priority

Each iteration implements the highest priority

work items

New work items are prioritized and

added to the stack

Work items may be reprioritized at any time

Work items may be removed

at any time

Modifications Defects Patches Customer Requests Market Demands …

Add very urgent item to sprint backlog Team

Remove item of similar size from sprint backlog

The Product Owner: •  Owner of the Product Backlog

•  Understands the customer's needs and carries the product vision to the team

•  Defines the features of the product by writing (or authoring) user stories

•  Cares about user needs and is responsible for maximizing the business value of the product

•  Collaborates with the team as the customer representative

•  Priorizes features (user stories & epics)

•  Can change user stories and priorities for upcoming sprint(s)

•  Accepts or rejects sprint results

Role of the Product Owner responsible for product success



Role of the Product Owner A difficult and comprehensive role

The Product Owner is essential for the overall succes of Scrum

Critical Factors: •  Company-wide mandate •  Product Backlog management •  Availability •  Team involvement

•  The financial value of having the feature •  The cost of developing / supporting the new feature •  The amount and significance of learning and new knowledge created by developing the feature •  The amount of risk removed by developing the feature •  The business impact of not (yet) having the feature •  …

Guidelines for prioritizing user stories or epics:

Prioritizing Requirements



Relative Penalty Prioritisation of user stories

Golden Rule: Incorporate the relative penalty

in your prioritization for absence or late delivery

of a feature

Look at features from the perspective of how users will be affected by the presence as well

as by the absence of the feature

MoSCoW Method Evaluation of requirements

M Must Have O

S Should Have C Could Have O W Won’t have priority

minimal viable product

If everything is top-priority, you don’t have priority



The Development Team:

•  Understands the details of the (upper part of the) Product Backlog

•  Determines the relative effort needed to realize the items on the Product Backlog

•  Decides how much productive time it has available during the sprint

•  Decides how many product backlog items it can commit to complete during the sprint

•  Delivers a ‘potentially shippable product’ at the end of every sprint

•  Organizes itself and its work

•  Demos work results to the Product Owner

Role of the Team

Development Team The Heart of Scrum

•  Significantly increased responsibility •  Communication is key •  Openness with respect to activities •  Pro-active attitude •  Team interest first

Critical Factors:



Definition of Done Upfront Transparancy

The Development Team will start the work only when the Definition of Done is crystal clear!

70

Single-Project Teams team focus on one project

Each project has its own

Product Backlog

Each team works on a single project during the sprint



71

Capability Teams team focus on field of expertise

Each team works on multiple projects during the sprint in line with their field of expertise

72

Single-Project Teams Working on a single project in parallel

Single Project represented by a single

Product Backlog

Each team working on the same

Product Backlog during the sprint



73

Multi-Project Team working on several projects in parallel

One team, working on multiple projects

during the sprint

Multi-Project Teams The True Cost of Context Switching

Adding a single project to your workload will drop productivity by 20%

Source: Gerald Weinberg on Quality Software Management : Systems Thinking



0 1 2 3 4 5 6 7 context switching

project C

project B

project A

single tasking

multi tasking

0 1 2 3 4 5 6 7 8 9 10 11 12

single tasking

multi tasking

Multi-Project Teams

Multi-Project Teams Avoid Superfluous Project Context Switching



Multi-Project Teams Prevent Overload and Excessive Multi-tasking!

Context Switching

is a considerable,

(and often hidden)

source of waste

How to organize individuals into Scrum teams

scrum team A scrum team B scrum team C

'meta' scrum team system/platform architect product manager integration & test engineer delegate team A delegate team B delegate team C

’System Backlog’

Backlog Backlog Backlog

Scrum of Scrums scaling Agile & synchronizing teams

Paragraph on Scaling Agile



The Scrum Master: •  Is the servant-leader of the Scrum team

•  Is the moderator for Scrum meetings

•  Takes care that the Agile/Scrum principles are understood and enacted

•  Shields the Development Team from external interferences

•  Removes obstacles that impede team members

•  Enables close co-operation between all Scrum roles and functions

•  Facilitates everybody the organization in their understanding & adoption of Scrum

Role of the Scrum Master

Scrum Master Partner & Supporter of the Scrum Team

Foster an environment that enables the team grow toward high-performance

•  Empower and encourage the team to make decisions •  Remove barriers and develop a high level of trust •  Resolving conflicts

Capable to:

Desirable Attributes of a Good Scrum Master



Scrum Master Promotion of Self-Empowerment

Team Formation

Bruce Tuckman’s Team Formation Model

Every Scrum team will go through the steps of forming, storming, norming and performing



Ideal Sprint Length

•  How often can stakeholders provide

feedback and guidance

•  Scrum familiarity in the organization

•  Level of experience and maturity within the team

•  Required co-ordination with other teams

•  Technical capabilities (e.g. automated acceptance testing)

•  Ability to decompose work

•  …

Sprint Length & Team Size

Team Size

Sprint Length



Sprint Zero

Focus on team’s environment •  setting up computers •  creating team room •  development environment •  tooling •  … Preparation for first sprint •  make high-level architecture overview •  produce project charter •  gather all relevant features •  produce first version of product backlog •  define ‘minimal viable product’ •  agree on default definition of done •  …

Release Sprint Hardening Sprint:

•  Performing time-consuming regression testing •  Deploying the code from the Sandbox to Production Environment •  Production data population •  Setting up operational systems and processes •  Training and handover for support staff

potentially shippable

shippable

Not a dumping ground for sloppy work!



•  Product Owner presents updated Product Backlog •  Product Owner describes features to be realized •  Product Owner indicates associated priorities •  Development Team presents total number of available hours for the next sprint •  Scrum Team agrees upon the Sprint Goal

WHAT - What is the goal of the next sprint?

Sprint Planning Meeting

•  Product Owner clarifies Product Backlog items if needed •  Team decides how to build the selected functionality into a product increment •  Team breaks Product Backlog items (features) into tasks •  Team may invite other people to provide technical or domain advice •  Team presents a concise plan for realizing the Sprint Goal: the Sprint Backlog

HOW - How will the chosen work get done?

88

Estimation of Productive Time

Team member A: 40 hours Team member B: 20 hours Team member C: 30 hours Team member D: 10 hours Available: 100 hours

Rule of thumb: 6 effective hours per 8-hour working day No contingency planning!



89

Task Breakdown

4

3

5

user stories tasks

6

7

10

5 8

36h

100 h

5

4

6

9 10 4 8 27h

12 7 6

7 5

37h

The team forecasts the functionality it will deliver in the upcoming Sprint

Management trusts the team and commits to leave priorities alone during the sprint

Bi-directional Commitment



Each team member answers the following 3 questions: •  What did you do yesterday? •  What will you do today? •  What is in your way?

task board = 'information radiator'

timeboxed: 15 minutes!

no more 'submarine behavior'

stand-up meeting

Daily Scrum visible communication

Commitment and understanding between peers,

not a management status meeting!

while standing up, people are

more creative and less individualistic

Scrum Task Board

Story To Do In Progress 8

Done

code

code

code

doc

doc

doc

doc test

test test

test design

design doc

code

prep

prep design

code test

As a user, I …. 6

As a user, I …. 4

As a user, I …. 8

6

6 8

4

4

4

4 8

8 12

12

7 5 5 3

12

3

3

Hours

Story points

Minimize WIP (work in progress)

11



Scrum Task Board Identify Type of Work

Story To Do In Progress 8

Done

prep

prep As a user, I …. 6

As a user, I …. 4

As a user, I …. 8

12

code 4

code 4

code 3

code 5

code 8

design

12

design

11

design

12

test

8

test

4 test

4

test

3

test

3

doc 6

doc 7

doc 5

doc 6

doc 6

Scrum Task Board Visualizing Tasks On Hold

Story To Do In Progress 8 Done

code

code

code

doc

doc

doc

doc test

test test

test design

doc

code

prep

prep design

code test

As a user, I …. 6

As a user, I …. 4

As a user, I …. 8

6

6 8

4

4

4

4 8

8 12

7

5

5 3

12

3

3

11

Impediments

waiting for spec

1 1

tool not available

2

doc

6

2



day

1

day

2

day

3

day

4

day

5

day

6

day

7

day

8

day

9

day

10

day

11

day

12 0

20

40

60

80

100

hour

s wor

k re

mai

ning

Sprint Burndown Chart

Tackle a disappointing

burndown chart by

adjusting the scope.

Going for extra time

is not a good idea,

and is hardly ever a

sustainable solution

Sprint Burndown Chart Daily Actualized Status

Story To Do In Progress 8 Done

code

code

code

doc

doc

doc

doc test

test test

test design

design doc

code

prep

prep design

code test

As a user, I …. 6

As a user, I …. 4

As a user, I …. 8

6

6 8

4

4

4

4 8

8 12

12

7 5 5 3

12

3

3

11 4

6

total number of hours = new point on burndown chart



Sprint Burndown Chart example

Monitoring Progress

Sprint Burndown Chart Release Burndown Chart

Burn down charts promote: •  Transparancy: visibility of time spent on not-agreed upon work •  Alignment: absence of last-minute surprises •  Adaptivity: facilitate timely corrective actions •  Co-Creation: tracking is at the team-level, no blame-game

velocity

Burndown Chart Template



Scrum Review

Sprint Review Meeting: •  The Team demonstrates what is accomplished

•  Product Owner accepts or rejects the delivered product increment

•  Anyone can attend

•  Attendees collaborate on the next things that could be done

•  All the feedback is gathered

Sprint Review The Issue of Quality

Demoing ‘Working Software’ is important, but not enough



Quality Saves

Quality

Time Money

Devil’s Triangle ?

Quality Costs More

relevant product quality requirements must be

part of the ‘definition of done’ of selected tasks.

Requested Quality: Part of the ‘Definition of Done’

‘Better than requested’

is the enemy of ‘Done’

“What is Working Software?” – www.improvement-services.nl/blog/?p=344

Agile Testing towards an integrated test process

•  Testing is not a distinct phase Testing should be a continuous activity of any Agile team Testing activities are integrated with the development process

•  Testing is not an exclusive activity All team members must be prepared to perform test activities Testing is not the sole responsibility of the designated tester

•  Testing when possible Early testing, starting in phases of gathering requirements and design, is highly recommended. •  Test tools are indispensible

Advanced test tools and test automation are needed

•  Testing is part of the ‘definition of done’ A release or iteration is done when it is fully tested, test results are processed, and problems are resolved

paragraph on Agile Testing



Test-driven Development rapid cycle of testing, coding, and refactoring

a test will drive the code to the next increment.

Test-driven Development.pdf

Retrospective Continuous Learning

•  What is going well? •  Where do we have a challenge? •  What will we improve the next sprint?

Sprint Retrospective:

•  The Team inspects itself: people, relationships, process and tools

•  The Team identifies the major items that went well

•  The Team identifies the potential improvements

•  The Team creates a strategy for implementing improvements



Starfish Retrospective

The Retrospective Starfish

Circles & Soup

Circles & Soup



ScrumBut attempt to make a dysfunction invisible

Examples: “[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 use Scrum, but] [we can't build a piece of functionality in a month,] [so our Sprints are 6 weeks long.]" “[We use Scrum, but] [sometimes our managers give us special tasks,] [so we don't always have time to meet our definition of done]"

syntax: [ScrumBut][Reason][Workaround]

Beware of Dogmatism

ImprovemenT Blog: ‘Beware of the Scrum Police!’



Scrum under Siege

Change of Scope

Change of Team Composition

Stretching ‘definition of done’

Interference & Unplanned Work

insufficient elaborated

User Stories

resistance & lack of

co-operation

Ineffective handling of

Impediments

Scrum Health Checks

Contra-indications for Scrum

•  Company management is not committed or works against Agile principles no understanding of Agile and Scrum matrix numerous people into numerous projects fixed time, fixed scope and fixed budget projects

•  Product Owner there is not product owner at all product owner is not available product owner has no mandate of the organization product owner has no access to real users or stakeholders user stories not available or not suitable/ready for implementation

•  Development Team team composition changes all the time no cross-functionality possible due to missing expertise daily interference and context switching massive stream of unplanned work no project focus: most team members are not dedicated

•  Product full predictability/no innovation: all requirements are known upfront work cannot be divided into smaller chunks



Agility & OTAP

Ontwikkeling

Test

Acceptatie

Productie

Sprint review

Stand-up

Release

scrum

Sprint planning

Scrum in een OTAP omgeving

Continuous Integration


is a development practice that requires developers to integrate their code into a shared respository

or mainline at least once a day.




Continuous Delivery & Deployment

Continuous Delivery

is a series of practices designed to ensure that code can be rapidly and safely deployed to production

by delivering every change to a production-like environment

Continuous Deployment

every change goes through the deployment pipeline and is automatically deployed to production,

thereby ensuring business applications and services function as expected through rigorous automated testing.

Continuous Deployment Maximizing Reliability and Customer Resonsiveness

Every change automatically gets put into production, resulting in many production deployments every day:

Company Deployment Frequency

Deployment Lead Time

Amazon 23.000/day minutes

Google 5.500/day minutes

Netflix 500/day minutes

Facebook 1/day hours

Twitter 3/week hours

Typical Enterprise once every 9 months months or quarters

Source: The Phoenix Project, Gene Kim et. al.



DevOps Bridging Change and Stability

Development: We want to make new features and

launch new versions!

Service & Maintenance: We want to guarantee

high availability and stability!

DevOps

BiSL ASL 2

ITIL

OTAP

PRINCE 2

SCRUM

tMAP

promotion of a set of processes and methods for thinking about communication and collaboration between departments

LEAN

Paragraph on DevOps

DevOps

•  small releases

•  minimal overhead

•  pipeline standardization

•  reduced impact &

frequencey of incidents

Scrum & Prince 2

Prince 2 Agile Scrum

•  transactional

•  predict as precisely as feasible what is needed and what will happen

•  fixed scope, time & budget

•  change must be controlled tightly

•  collaborative

•  work with the business to capture as much value as possible in a given time & budget

•  fixed time & budget scope: evaluate, prioritise & decide during the project

•  change happens always, we deal with it, anyway

Stage = Sprint Senior User = Product Owner Senior Supplier = Scrum Master

Paragraph on Prince2



Scrum Tooling

www.atlassian.com/software/jira

Planning Board


0

Burn-down chart

Stor

y Po

ints

10 20 30 40 50 60 70


12

Welcome

& Introduction

2

Agile

Contracting

3

Questions Wrap-up

2

Backlog

Break

8

SCRUM basics

22

Agile

Project Planning

17 0 1 2 3 4 5 6 7 8

70

Unplanned

Work

4

68

56

34

26 22



High-Urgent Tasks

High-urgent, unplanned tasks jeopardize the Sprint Planning

Dealing with Unplanned Work

How to effectively deal with structural unplanned work ?

Part of the team is busy with bug fixing, instead of working toward the common sprint goal



Lean: Optimalization & Improvement

Kanban: work-flow optimalization •  Visualization of the Work-Flow •  Limitation of the Work in Progress (WIP) •  Measurement of the Lead Time of Work-Items •  Identification of Bottlenecks in the Process

�� visual card/board

Work In Progress

To do Ongoing Done

A B

C

D

To do Ongoing 2

Done

A B

C

D

Scrum Board Kanban Board

FLOW FLOW

Scrum limits WIP per sprint

Kanban limits WIP per workflow state



Response Time

To do Ongoing Done

A B

C

D

Scrum Board Kanban Board

Wait until work-item(s)

move to next phase

To do 2

Ongoing 2

Done

A B

C D E E

Wait until next sprint

Average Response Time = (Sprint Duration)/2

Lifecycle

To do Ongoing Done

A B

C D

Scrum Board : From start to finish

To do 2

Ongoing 2

Done

A B

C

D

Kanban Board: At any time

A B

C D

Constant Flow

Kanban board is never reset

Iterative

Scrum board is cleared

after finishing the sprint



Tracking

To do Ongoing Done

A B

C D

Scrum: Team Velocity Kanban : Cycle Time

A B

C D

Team Velocity

Performance is

measured per sprint

Cycle Time

Performance is

measured per work-item

To do 2

Ongoing 2

Done

A B

C D

A B

Status Transparency

To do Ongoing Done

Scrum: In Progress

To do 2

Ongoing Phase A

3

Done

Kanban : Tailor-made stages

‘In Progress’ subdivided

into several stages

Ongoing Phase B

2

A B

C

D

B

C D

A

E

Single

‘In Progress’ Column



Monitoring Waiting Time

To do Ongoing Done

Scrum: No Waiting Tasks

To do 2

Ongoing Phase A

3

Done

Kanban : Signalling Waiting Time

Stages subdivided into

‘in progress’ and ‘ready’

Ongoing Phase B

2

A B

C

D

B

C

D A

E

Stages without ‘Waiting’ state

F

ready

Scrum + Kanban ��

‘Dealing with urgent tasks using Scrumban.pdf’



Planning Board


0

Burn-down chart

Stor

y Po

ints

10 20 30 40 50 60 70


12

Welcome

& Introduction

2

Agile

Contracting

3

Questions Wrap-up

2

Backlog

Break

8

SCRUM basics

22

Agile

Project Planning

17 0 1 2 3 4 5 6 7 8

70 Unplanned

Work

4

68

56

34

26 22

19

Traditional Contracting

•  Burned out programmers

•  No learning or discovery on the way

•  Rigorous change control increases cost and proliferates non-value added work

•  Sacrifice of quality in case of problems

Fixed Time, Cost & Scope Contracts

Cost

Time

Quality

Scope

Recipe for death-march projects



making cooperation difficult and hinder progress

increase the chance of success for both parties

Contract Types

Which contract forms are best for agile software development projects

and at the same time commercially competitive?

Variable Scope •  Customers can change their minds •  Suppliers aren't encouraged to sacrifice quality •  Customer's and Supplier's interests are aligned Incorporate customer

responsibility

Agile Contracting: Evolutionary delivery in close co-operation with the customer

Customers have what they want at the project end, after they've learned,

instead of getting what they wanted at the project start.



Variable Scope Contract: Reversing the ‘Iron Triangle’

functionality

functionality time resources

Plan-driven Value-driven

fixed

flexible resources time

Fixed scope

Estimated cost

Estimated time

Quality

Plan-driven approach

creates cost/time estimates

Fixed cost

Fixed time

Quality

Estimated scope Value-driven

approach creates feature

estimates

Risk declines as project progresses Subject to cost, time & quality risks

Acc

umul

ated

Bus

ines

s Va

lue

Time

the customer can swap items not yet done

for an item of equal size

Variable Scope



Time

the customer can replace items not yet done for

a new item of equal size Need this one too!

Dump this one!

Acc

umul

ated

Bus

ines

s Va

lue

Variable Scope

Agile Contracting

quotation, contract

fixed time fixed budget fixed scope

in-depth analysis, detailed customer demands,

project plan

design build

analysis test bug fixing

product delivery

quotation, contract

fixed time fixed budget

variable scope

product backlog

with epics, agile

estimation & planning

realization

analysis& design

test, bugfixing

product increment

realization

test, bugfixing

product increment

realization

test, bugfixing

product increment

realization

test, bugfixing

product increment

wat

erfa

ll ag

ile

realization

test, bugfixing

product release

Reduction of the Probability of Mismatch

time

possible mismatch

possible mismatch

analysis& design

analysis& design

analysis& design

analysis& design



Variable Scope: Share the Pain and the Gain

It takes two to tango

look your client in

the eye and say:

‘I may provide

flexible scope, but

I will allways deliver

value for money’.

Paragraph on Agile Contracting

Planning Board


0

Burn-down chart

Stor

y Po

ints

10 20 30 40 50 60 70


12

Welcome

& Introduction

2

Agile

Contracting

3

Questions Wrap-up

2

Backlog

Break

8

SCRUM basics

22

Agile

Project Planning

17

0 1 2 3 4 5 6 7 8

70 Unplanned

Work

4

68

56

34

26 22

19

2



Much work remains to be done before we can announce our failure to make progress

Traditional Planning A Joyless Track Record

•  Planning is by activity rather than feature - Parkinson's Law

•  Lateness is passed down the schedule - Pattern: Anti-gravity Module

•  Multitasking causes further delays - assigning work to individuals rather than to groups - focus on high level of utilization of all individuals

•  Features are not developed by priority - dropped features may be of greater value than those that are delivered

•  Uncertainty is not acknowledged - product specifications are generally imperfect or incomplete - assignment of precise estimates to imprecise work - estimates become commitments (or even deadlines)

Traditional Planning Causes of Planning Failure



Parkinson’s Law Task-based planning

Work expands so as to fill the time available for its completion.

Between 1935 and 1954 the staff of the Colonial office increased from 372 to 1661, over 400% - while the responsibility of the Colonial Office was declining. By the time of the end of the British Empire, the Department had its highest number of staff ever.

Colonial Office, London

Activity Planning A common pitfall

A critical problem with traditional planning is that they focus on the completion of activities

rather than on the delivery of features.

Activity-based planning doesn’t guarantee that customers get value from the completion of activities.

Features are the unit of customer value.

Planning should be at the level of features, not activities.



Risky components are scheduled to be completed last.

“The launch module is 98% built - all we need is the antigravity module.”

Anti-Gravity Module

Risky components are scheduled to be completed last.

“The launch module is 98% built - all we need is the antigravity module.”

Anti-Gravity Module

avoid do first

do second do last

high

risk

value low

low high



anticipation

adaptation response to

changing business conditions

strict conformance

to original plans

Agile Planning Dealing with Uncertainty

day iteration release

focus of agile team

2 - 3 months 2 - 4 weeks

Agile Planning Principle #1: Apply Multiple Levels of Planning

features tasks Daily

Planning

Iteration

Release

Roadmap

Product Vision 1 day

(sub-)system



traditional

absolute measure of size

function points lines of code

lead time ….

agile

relative measure of size

story points

Agile Planning Principle #2:

Use a Relative Measure of Size

Absolute Measure of Size

?

?

?

?

?

?

?

?

?

?



Relative Measure of Size

?

?

?

?

?

?

?

?

?

?

10

Story Points

A relative measure of size requires a unit-less coefficient

Story Point

A Story Point is a unit of measure for expressing the overall size of a piece of work using relative values



What are Story Points?

2 Story Points

Assign

‘Animal Points'

to the following

breeds:

Assignment of Story Points exercise



Breed Animal Points

Lion Kangaroo Rhinocerus Bear Giraffe Gorilla Hippopotamus Tiger

Assignment of Story Points exercise

Country Points

Assign

‘Country Points'

to Europian

countries



Country Points T-Shirt Sizes

Germany Denmark Estland United Kingdom Belgium Spain Poland Netherlands Cyprus Finland

Country Inhabitants XL

L

M

S

XS

M

•  Forces the use of relative estimating studies have shown that we're better at relative estimating (over one order of magnitude) rather than absolute estimating

•  Focuses us on the size, not the duration story points are independent of the time needed for realization, therefore, estimating in story points is typically faster

•  Puts estimates in units we can add together time-based estimates are in most cases not additive, (and may require obscure correction factors)

Why Story Points?

Story Points are a more usefull measure for project velocity and release schedule

than using hours and days.



Sizing versus Work

Velocity is a measure of a team's rate of progress

Velocity is calculated by summing the number of story points assigned to the user stories that

a team completed during one iteration

Velocity

158



Velocity Example

Team A : velocity = 25 Team B : velocity = 16 Team C : velocity = 2 Team D : velocity = 100

Project: Pile of Sand Total amount of effort: 100 story points Iteration length: 30 minutes

= 2 story points

Velocity is a team-bound characteristic

Velocity examples

How long will it take … •  to read the latest Harry Potter book? •  to drive from Amsterdam to Maastricht ?



Velocity Example

Estimation: 80 story points 4 sprints

Observed velocity: 20

= 2 story points = 4 story points

Project: Pile of Sand

Estimation: 160 story points 4 sprints

Observed velocity: 40 Velocity depends on the applied estimation scale

Velocities can only be compared when the same estimation scale

is applied during estimations

The absolute value of estimates isn't crucial What matters is that a consistent scale is used

Agile Planning Principle #3: Apply Consistent Scale for Estimations

Dedicated estimation team ?



Velocity always measures the actual team performance.

A stable velocity incorporates all relevant

(positive and negative) factors that influence the team output (including risk)

Velocity is an empirical attribute of a Scrum team

Agile Planning Principle #4: Use Actual Team Performance

Known velocity will prevent

overloading the team

Velocity will automatically compensate the size of the work package proposed by the

Product Owner and accepted by the Development Team at Sprint Planning

Agile Planning Principle #5: Velocity is ‘the great rectifier’



Velocity & Definition of Done

The team will earn storypoints only for 100% completed user stories!

ESTIMATION OF RELATIVE SIZE

ESTIMATION OF DURATION

Stop arguing about how long it will take

Story Points +

Velocity

2 weeks 1 week

Agile Planning Principle #6:

Estimate Size, Derive Duration



•  Utilize collaborate relative estimates

•  Prefer estimations by those who will do the work

•  Use an appropriate estimation scale

•  Remove all (political) bias from the estimate

Agile Estimation in Practice

1 All the team members have a set of cards

2 Product Owner explains & clarifies the backlog item

3 Everyone selects and simultaneously shows cards

4 If estimates vary significantly, high and low estimators briefly explain their estimates

5 Repeat steps 3-4 until estimates stop converging

6 Decide estimate for backlog item

7 Move to next backlog item

Planning Poker



Planning Poker Exercise

ID User Story Story points

1 As selling car owner, I need to clean and wax my car in order to get a good price for it.

2 As a car owner, I want to have the interior of my car completely cleaned, in order to travel comfortably.

3 As a car owner, I have to purchase and tryout a set of snow-chains, in order to be safe when on winter holiday.

4 As a car owner, I need to replace the headlight bulb, since the dimmed light is not functioning anymore.

5 As a car seller, I want to make an 2-page advertisement for all the second-hand cars in my shop, to attract new customers.

6 As a lover of classic cars, I want to renovate the metalwork of my 1952 Citroen Traction Avant, since the body is rusty.

•  Combining individual estimates through group discussion leads to better overall estimates •  Emphasizes relative estimating, hence we don’t waste time in meaningless arguments •  Everyone's opinion is heard, thereby minimizing estimation bias and anchoring

•  It's quick and fun

see www.planningpoker.com for planning poker for distributed teams

Planning Poker why it works



Agile Release Planning example

Velocity: 50

Release Plan: 10 sprints Sprint duration: 2 weeks Forecasted Lead time: 20 weeks

Start of project

1 2 3 4 5 6 7 8 9 10

Sprint

500

400

300

200

100

0

Sto

rypo

ints

Product Backlog

Size = 500 Story Points

Project

Burndown Chart

Agile Release Planning example

Remaining: 350 Story Points 6 sprints Measures: •  1 sprint extra •  reduce scope •  increase velocity

After 4 sprints

1 2 3 4 5 6 7 8 9 10

Sprint

500

400

300

200

100

0

Sto

rypo

ints

Product Backlog

Velocity: 50

Project

Burndown Chart



Agile Release Planning budgeting example

Project Budget: Forecasted Lead time: 20 weeks for realization of 500 Story Points Estimated Overall Cost: 20 x 5 FTE à $ 600/week = $ 60.000 Average Cost per Story Point: $ 60.000/500 = circa $ 120

Start of project

Product Backlog Size = 500 Story Points

member 1 member 2 member 3 member 4 member 5 Member 6

1.0 FTE 0.8 FTE 0.8 FTE 0.6 FTE 1.0 FTE 0.8 FTE

Team 5.0 FTE

Multi-Product Release Planning

5



Multi-Team Release Planning

5

The only variables of interest for

Agile project Planning are:

estimations & velocities

Agile Planning Principle #7: Utilize Estimations & Velocities



Reliability of Release Planning

Estimated Product Backlogs

Observed Team Velocities

/

Pssst - Agile will make us more predictable…

=

Reliable Release Planning

# storypoints/project # storypoints/sprint # sprints

Food for Thought

Als je loslaat heb je meer grip



Resumé

Agile Certification

•  Agile Foundation Certificate Agile Consortium domain: IT | area: Benelux, UK, Danmark | cost: € 175 traditional class-room exam 1h ImprovemenT sample examination | certification guide

•  Professional Scrum Master Certificate •  Professional Scrum Product Owner Certificate

Scrum.org domain: software product development | cost: $ 150/$ 200 area: worldwide | on-line multiple-choice exam 1h ImprovemenT sample examination | certification guide

•  Agile Scrum Foundation Certificate EXIN domain: IT/Project Management | cost: € 165 class-room or on-line multiple-choice exam part of Certified Integrator Programme

Agile Scrum Scrum... · Agile Scrum Foundation training IMPROVEMENT BV ©2016 21 Agile Scrum...

Documents

Transcript of Agile Scrum Scrum... · Agile Scrum Foundation training IMPROVEMENT BV ©2016 21 Agile Scrum...