lyckas med scrum och agile omfattning: 2 dagar, 9-17 · agila metoder en genomgång av vad de agila...

Succeed with Scrum and Agile

Henrik Berglund – Cedur Datakonsult AB

– 15+ years of working as a consultant with software engineering

– 10 years as Software Lead for a family of Bluetooth software products

– 10+ years of experience with Agile methods

[email protected]

+46 709 400864

Getting the most from

Scrum & Agile

2013-01-08

Henrik Berglund

Twitter: @henrikber

Welcome!

After you have read this:

- Take a seat

- Take one minute to fill out the warm-up

questions

- Find someone to compare and discuss

your answers with

(Yes, right now…)

What problem have you seen?

Form teams

Create a poster on a wall

Summarize in 10 minutes

1980Basic, 6502, 68k asm

1993

Agile/EmbeddedTeams

XP, Scrum

1999

Scrum/agile coach

2008

2010

ADA

LiTH LISP, Prolog,Pascal

C, C++,Flex, yacc

Perl, VBA, C#,Tcl, bash

Henrik Berglund

SS7, TCP

Topics

Basic principles

Agile

Scrum

Requirements

Release Planning, tracking, controlling

Sprint Planning, tracking, controlling

Roles

Scaling

Teams

Change, making sustainable progress

Scrum simulation

The technical piece of the agile puzzle

Tell the person next to you what you think is the best way to learn something in a

course like this.

1 min

Basic principles

very simple

very important

What are we trying to do?

In your team, on the wall, create a summary that defines what a successful project is.

Success?

12 months

requirements

Great job!

management

funding

customersowners

teams

individuals

ValueLearning

Job satisfaction

Profit

Traditional success definition

according to initial specification on time on budget

Great ideas (speculation)About new product /project

”requirements”

We predict these things will be valuable

Waste Value

Source: Chaos report, Standish

35% of requirements change

60% of features rarely or never used

Lousy predictions, why?

At 7:50, specify plan for the day:

Problem to be solved: Keep room temperature 21 C(There is no thermometer in the room)

8:00 Element on, level 38:30 AC on, medium cold….…..

Exercise: List all variables we need to consider. (e.g. number of persons in room)

The solution

– empirical process control

Transparency

Inspect

Adapt

Don’t try to predict all variables, work with feedback

Plan things before starting?

Best approach depends on problem!

How can we choose?

Use empirical approach(Adapt to what we know)

© 1993-2011 Scrum.org, All Rights Reserved Slide 1627 March 2011

Think about the products you develop.Rate complexity of requirements from 1-10

Well known in detail,Everyone agrees, no misunderstandings, no unclarities, stable, never changes

Unknown, people have different interpretations, difficult to get consensus/clarity, unstable, changes frequently

110


Think about the products you develop.Rate complexity of technology used from 1-10

We know everythingabout the technologies used in solutions. Nothingnew. It is very stable. No surprises. No changes

A lot of new unknown things. Things are new and unknown to us. Many things are changing. Many things are unstable.

110


Think about the products you develop.Rate complexity of people issues from 1-10

Human issues never addcomplexity. It is so easy towork together! Everyoneagrees, we quickly and correctly understand eachother. No politics. Everyone behavestransparently and predictable

110

Having people involvedadds significant complexity. There are different (sometimes hidden) agendas, different opinions, communicationproblems, unexpextedchanges and misunderstandings.

Technology

Far from Certainty

Close to Certainty

Requirements

Wel

l kno

wn,

stab

leU

nkno

wn,

unst

able

Simple

Complicated

Complex

Chaos

Recepies

Empirical(Scrum)

What process is effective?

Source: Ralph Stacey, University of Herfordshire

People

Three legs of empirical process control

1. Transparency

2. Inspect

3. Adapt

Empirical process control in, Agile/Scrum/XP

Feedback cycles!

Pairing

Developer tests

Continuous integration

Daily Scrum

Sprint review

seconds

minutes

hours

days

weeks

What is agile?

Why does your organizationwant to be agile?

Agile Manifesto, Snowbird Utah Feb 11-13, 2001 www.agilemanifesto.org

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

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

Exercise: What do each ofthese have to do with empiricprocess control?

12 principles behind the agile

manifesto• Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

• Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.

• Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.

• 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.

• Working software is the primary measure of

progress.

• Agile processes promote sustainable development.

The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.

• Continuous attention to technical excellence

and good design enhances agility.

• Simplicity--the art of maximizing the amount

of work not done--is essential.

• The best architectures, requirements, and designs

emerge from self-organizing teams.

• At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts

its behavior accordingly.

Goal of agile development

Deliver according

to initial specification,

on time, on budget

Adapt to actual

conditions, deliver

maximum value

Agile, what is being used

VERSIONONE, 3rd Annual Survey,

”The State of Agile Development” 2008

Scrum49%

Scrum & XP 22%

XP8%

Other, Unknown

21%

Exercise: Communicating

requirements

3 straight line elements

2 curved line elements

Sample product vision

Requirementsteam

Artistvision

Research by McCarthy and Monk, 1994

Effective

Communicationeffectiveness

Ineffective

Cold HotRichness (“temperature”) ofcommunication channel

Document

Audiorecording

2 peopleon email

Videorecording

2 people atwhiteboard

Communication Effectiveness

As unemployed I can search As unemployed I can search As unemployed I can search As unemployed I can search

for jobs, so that I can find jobsfor jobs, so that I can find jobsfor jobs, so that I can find jobsfor jobs, so that I can find jobs

that I would like to apply forthat I would like to apply forthat I would like to apply forthat I would like to apply forAs a user As a user As a user As a user I can pay with credit card, I can pay with credit card, I can pay with credit card, I can pay with credit card, so that it is easy to buy thingsso that it is easy to buy thingsso that it is easy to buy thingsso that it is easy to buy things

User Stories – examples

User Stories – the card

Short description used as reminder and for planning

A promise about a future conversation

Template: Readable by users

Describes things of value to users

As <role> As <role> As <role> As <role>

I can <action>,I can <action>,I can <action>,I can <action>,

so that, <value of action>so that, <value of action>so that, <value of action>so that, <value of action>

Card Conversation Confirmation

As a user As a user As a user As a user I can pay with credit card, I can pay with credit card, I can pay with credit card, I can pay with credit card, so that it is easy to buy so that it is easy to buy so that it is easy to buy so that it is easy to buy

thingsthingsthingsthings

Source: http://cukes.info/

Confirmation - ”Gherkin” - ATDD

Source: http://www.manning.com/free/green_adzic.html

Confirmation – FitNesse - ATDD

I have a problem

What happened in the F16 case?

real teams

We can design a solutions for that

stakeholder

Exercise: How does your organizationuse documents/text?

Stories - size

• Keep high priority stories small, e.g. 2-3 days

• Epics – large stories

• Themes – grouping of stories to ease planning

and prioritizing

• Backlog maintenance

INVEST Guidelines- Bill Wake

• Independent

• Negotiable

• Valuable

• Estimatable

• Small

• Testable

Details: Stories - Advantages

• Encourages verbal rather than written communication

• Understandable by both customers and developers

• Right size for planning

• Works with iterative development

– Focus on user value

– Easy to split up as backlog order changes

• Encourages deferring detail until maximum knowledge is

available

Estimating

What value do we get from estimating? (Why do we do it?)

What techniques do you use?Who estimates?When?Why?

Estimating in story points

1 2 3 5 8 …(13, 20, 40, 100)

Relative estimates

Planning Poker

Details: Planning Poker

1. Each team member is dealt a set of cards.

2. The meeting moderator picks a feature to estimate.

3. The person who knows the feature best describes it.

4. The team asks questions to clarify the feature.

5. Every team member silently makes an estimate and picks a card.

6. Everyone turns their card over at the same time. If the estimates differ significantly, the highest and the lowest bidder explain their selection.

7. Repeat the previous two steps until estimates converge.

Scrum Master

Product Owner

Development Team

”Scrum Team”

Assign roles for Scrum simulation

Development Team , plans and performs work, optimizes process

Scrum Master , works in team also, checks rules, leads retrospective

Product Owner , orders backlog, determines acceptance criteria, accepts/rejects stories

Special instructions in envelope…

Rules for Scrum simulation

1. Only one requirement in progress in a team, including PO check/review

2. No re-work

DONE!

1111

First pick baseline card

Estimate 21 cards

in 30 minutes

Planning Poker

Discuss requirement

Show cards at same time

Discuss differences

Individually estimate

Release planning of three sprints, each 5 minutes

1111

(cards marked iteration1)

(cards markediteration1 or 2)

Try to pick cards to optimizebusiness value

(cards markedIteration1, 2 or 3)

Release planning, II

1111

RELEASE BURNDOWNMake two forecasts:

Forecast: business value : 3800

total storypointsdone in three sprints

34

business value done in three sprints

Flow in Scrum

dailyscrum

sprint review

retrospective

productbacklog

sprintbacklog

increment

24h

sprint1-4 weeks

sprintplanning

Did you ever work on a project...

- Where everything was fine until end of the

project, then problem after problem was

discovered and actually it was quite delayed.

Whistle if you did!

Transparency


- Where everyone was trying to hide the fact that they were probably not on schedule. Everyone hoped that someone else would have to cave in first and admit that they were late

Transparency

Clap your hands if you did!


- That was delivered on schedule, but then there were a lot of trouble reports. For months the team did not have time to do anything but fixing reported defects.

Transparency

Stomp your feet if you did!

dailyscrum

sprint review

retrospective

productbacklog

sprintbacklog

increment

24h

sprint1-4 weeks

sprintplanning

Definition of doneincrement

What has been done to the increment (and thus also, what has not yet been done)

Example of things to include:- coded- unit tested- design documentation created- …

incrementIf no work is remaining, this is the most transparent

Definition of doneincrement

Who owns it?

Who can change it?

As an amazon customer I get

recommentations for books,

so that I easily can buy

books I will enjoy but

did not know about

Splitting big features

sprint 3

sprint1

sprint2Logic

DB

UI

Requirements breakdown

Traditional

Emergent architecture

93 things todo

3 monthsNo progress

Shipped in 7 months61 things done

Next iteration did not use any of these 32!

Scrum

Example: Primavera & iManage

Requirements breakdown

sprint 3

sprint1

sprint2Logic

DB

UI

Traditional ”Sashimi”

Spr

int 1

Spr

int 2

Spr

int 3

backloggrooming

sprintplanning

dailyscrum

sprint review

retrospective

releaseburndown

productbacklog

sprintbacklog

sprintburndown

24h

increment

Backlog grooming

Everyone spends 5-10% of each sprint

Prepare for coming sprints

Backlog grooming

So that we know just enough about requirementswhen sprints start

study

research

discuss

mockups

spikes

Backlog grooming

To keep product backlog transparent and in goodshape.

estimate

break down

reformulate

Product Backlog - todo list for product

Development TeamProduct Owner

Estimate5

It shall be possible to pay using

MasterCard

Order in backlog

#2Estimate13

Product Backlog

Ordered by Product Owner – Usually at Theme level

Do first

Do last

What are some advantages of keeping an ordered backlog?

Product Backlog,

how much details do you need?

Get enough accuracy for release estimates

Note, more effort yields very little beyond a certain point

Fine grained

Larger chunks

Just enough so that work flows smoothly during iterations

Minimize work spent on low-priority stories

Release planningExercise

Release planning

Velocity =

# of Story points Team can get to Done per sprint

Iteration 1

Iteration 4

Iteration 3

Iteration 2

Iteration 5

Iteration 6

Iteration 7

…

Release 1

Release 2

Example, what velocity to use

Latest 3 average

Story points

1 5 12

Lowest

Highest

Tracking status - release burndown

Work remaining

Story points

Sprints

1 5 1512

20

100

200

21Changed Scope

Managing fixed date, fixed scope

Work remaining

Story points

Sprints1 5 1512

20

100

200

21

Time buffer

Feature

buffer

Promise this

Promisethis

Good velocity

Innovation or stable velocity ?

What about value?

Sprint planning

sprintplanning

dailyscrum

sprint review

retrospective

releaseburndown

productbacklog

sprintbacklog

sprintburndown

24h

increment

Sprint planning, part1

Development Team

Product owner

We select this much

Perform backlog maintenance as needed (5 min – several hours)

Define a sprint goal

-Motivate!

-Give wiggle room regarding functionality

Timebox for 30 day sprints: 4h

Why can the team decide how much

work to take on?

20

18

15

10

Dead core

Because pushing workin makes developmentgo slow and will destroyone of the companiesMost valueable assets

Key to agility: Definition of done

Teams pull as muchwork they can get toDone in a sprint

Sprint planning, part2

– Team plans out sprint

– Creates Sprint Backlog

– Team makes a forecast

As a User, I…8 points


Code the

4h

Test the

2h

Test the

2h Code the..

8h

Code the..

4h

Code the..

8h

Story TODO

Selected Product Backlog (tasks,

smaller than 1 day)

Timebox for 30 day sprints: 4h

Exercise, sprint backlog, 5 min

• Select, plan, break down and estimate story 5

and 18 from XP game, iteration 1

Find card

Make additions

C

Story TODOSort deck in four piles

10s

What if we can’t find a sprint goal?

Running the Sprint

Daily Scrum

sprintplanning

dailyscrum

sprint review

retrospective

releaseburndown

productbacklog

sprintbacklog

sprintburndown

24h

increment

Daily Scrum - purpose

Tactical planning meeting for Development Team:



Code the

4h

Test the

2h

Test the

2hCode the..

8h

Code the..

4h

Code the..

8h

Test the...

2h

Code the..

8h

Code the..

4h

Story TODOInprocess Done

Impediments

Bumdown

- Are we on track?- What is our plan

for today?- What is our plan

for the sprint?- What can be

improved?

Details: Daily Scrum

• Daily standup meeting for Development Team to inspect/adapt

• ScrumMaster and Product Owner can optionally attend

• Time boxed to 15 min

• Same time, same place every day

• Update task board

• Three questions:– What did you do yesterday?

– What will you do today?

– Are there any impediments in your way?

• Team commit to each other!

Status tracking – work remaining



Code the

4h

Test the

2h

Test the

2hCode the..

8h

Code the..

4h

Code the..

8h

Test the...

2h

Code the..

8h

Code the..

4h


Impediments

Bumdown

Code the GUI

Work remaining ,updated every day by Team

Total work remaining ,updated every day by Team

8h

Tracking time spent is NOT part of Scrum and may cay cause lowered development speed, lowered quality and loss in predictability!

Impediments

• Think outside of the box!

– What if this would be the ideal work environment.

What would be different?

– What could help us to be more productive, both

as individuals and as a team?

– Try changing the question: “With what could

someone assist me today?”

Typical Impediments

• The department VP has asked me to work on something else "for a day or two."

• I don’t have time to work since I am required to perform <non value adding activity>

• I need help debugging/learning ______

• My ____ broke and I need a new one today.

• I can't get the ____ group to give me any time and I need to meet with them.

• I still haven't got the software I ordered a month ago.

• Required to attend various meetings not needed to meet sprint goal

What if Daily Scrums are useless?

Management involvement

• Manager assigns two slots

for impediments

• Slots are filled by team

• Team decides if

impediment is solved

• After 2-3 months…free

slots start top appear…

Idea by Mattias Skarin, Crisp AB, 2009

Tracking status during the sprint

Visual tools



Code the

4h

Test the

2h

Test the

2hCode the..

8h

Code the..

4h

Code the..

8h

Test the...

2h

Code the..

8h

Code the..

4h


Impediments

Burndown

If the sprint proves to be non viable

Business conditions change so that sprint will be of no value

Technology proves unworkable

Team is interfered with

Abnormal sprint termination

sprintplanning

dailyscrum

sprint review

retrospective

releaseburndown

productbacklog

sprintbacklog

sprintburndown

24h

backloggrooming

abnormalsprint termination

increment

What if the CEO walks in

…and asks a team member to just do a few

weeks of work for an important demo

Discuss with your team, 5 min

This is clearly within the power of the CEO isn’t it?

How does Scrum handle this? What happens with

the team and the sprint goal?

Sprint review

sprintplanning

dailyscrum

sprint review

retrospective

releaseburndown

productbacklog

sprintbacklog

sprintburndown

24h

backloggrooming

increment

productbacklog

increment

Sprint review

How far have we come? What is done and what is not?What are some future scenarios/possibilities?

Transparency

Collaboration

What if there is nothing to review?

Retrospective

sprintplanning

dailyscrum

sprint review

retrospective

releaseburndown

productbacklog

sprintbacklog

sprintburndown

24h

backloggrooming

increment

Details: Retrospective

• Time-boxed to 3-hours

• Attended by Team, Scrum Master and

optionally Product Owner

• What went well?

• What can be improved in the next sprint?

What if retrospectives are waste?

Retrospectives: Getting started

www.cedur.se/agile-blog

“PST favorites”

Timeline

Fishbowl

Remember the future

The race car and the abyss

Happyness metric

Perfection game

Starfish

See/hear/feel

Problem tree

Root cause analysis

Appreciation game

Sailboat

Like/Learn/Lack/Long for

World café

Design thinking

A word of praise

Team radar

Circles and soup

Open space

Solve problems, not symptoms

Problem: Smoke in my bedroom

Bad solution: Open window and go back to sleep

Good solution:

- Find source of smoke

- Oops there is a fire in the basement…

- ?

- ?

Cause-effect diagrams

Source: http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf

Defects release to production

Angry customersProblem

Teams demotivated

Loss of team members

Problem

Teams disrupted

Stress

Releases not properly tested

Lack of test automation

Not enough time to write test scripts

Scope of sprint not reduced

Root cause

Lack of tools & training in test automation

Root cause

Hotfixesrequired

A3 Problem Solving

Who does what in Scrum?

Product Owner

Product Owner

Stakeholders

Product Backlog

R1

R2…

ReleasePlan

ReleaseBurndown

what’s missing…?

Development Team

Backlog Grooming, 5-10%

6 +/-3 persons

Potentially Shippable Product Increment

Product Backlog

Sprint Backlog

Self managing

Self optimizing

Scrum Master

• Responsible for Scrum process

• Teaches Scrum to everyone

involved in project

• Facilitates teamwork

• Coaches team and individuals

• Removes impediments outside

team reachScrum

Mixing roles

• PO can be on the Development Team (part

time developer)

• SM can also be on Development Team (part

time developer)

• PO should not be same person as SM

– What to do, How to do it, conflicts of interest

Scaling Scrum

Customer

PO ”proxy PO”

productbackog

PO ”proxy PO”

delaysmisunderstandings

PO

Exercise: How can onePO do all this?

I have a problem

Remember the F16 case?

real teams

We can design a solutions for that

stakeholder

PO

Real teams

productbackog

ideasstrategiesproblems

ideassolutionsdecisions

Coordinating work of 15 teams…

The bigger pattern

Complexity, self organization

Containers

Differences

Exchanges

When more is unknown than known (complexproblems) - best addressed with self organization

Source: G Eoyang

Release planning for <= 15 teams

Sprints (2w)

Releases2-3 months

Release planning 2d

Release planning meeting

Release business goals

Architectural goals

Iterative team planning, 1 h

What have we plannedWhat will we plan nextProblems

Synchronizing teams – Continuous

integration

User Interface

Service layer

Components

Persistence Layer

Scrum Team

Scrum Team

Scrum Team

• All teams use same code base

• Integrates several times a day

• Test automation and modern CM tools needed

• Moving (an extremely difficult) synch problem to code level makes problem easy!

Synchronizing teams –

“Scrum of Scrums” meeting• What has my team

done that may affect others?

• What will my team do that may affect others?

• What problems are my team having that with whitch it could use help from other teams?

Scrum Team

Scrum Team

Scrum Team

Team representatives

Scrum of Scrums, a problem solving meeting,often > 15 min

Source: “Succeeding with Agile”, Mike Cohn

“Office”

Integration team

“Word” team

“Excel” team

“Powerpoint” team

Needed in big/complex projects

Looks for unknown or unattended interfaces between teams.

Develops facilities to integrate, build and test work of feature teams

Working with non-agile teams

Stub out their interfaces and simulate them

ScrumD

one

Don

e

Don

e

Don

e

Don

e

Don

e

Don

e

Don

e

Hardware/waterfall

Work with them to improve definition of done

Scrum Simulation

Think about how this feels

Exercise: Scrum Simulation

Three Iterations- Sprint Planning, 5 min- Sprint, 5 min- Review 2 min- Retrospective, 5 min

Goal: Maximize business value

Rules:- Only one story in progress at a time,

including PO check/review- No rework! 1111

sprint PO can choose stories

from sprint

1 1

2 1, 2

3 1, 2, 3

Release planning

1111

RELEASE BURNDOWN

& Make a forecast: -storypoints done in three sprints (each 5 min)-business value done in three sprints

Forecast: business value

Sprint planning 5 min

PO orders requirementsto maximize business value

Team plans how toperform work

11111111

1111

Sprint 5 min

GO!

Sprint Review

1111

RELEASE BURNDOWN

What was done?

Update release plan & burndown

Update forecasts: - of storypoints remaining- of total business value

Sprint retrospective 5 min

Scrum Master leads team in analysis:

• What worked well?

• What could have workedbetter?

• Pick a few improvemensfor next sprint

Write result from sprint on score-board:• Story points• Business value

Slack

creativity, learning, cross team collaboration

Exercise: 60 Steps

• Goal: Walk 60, real, big steps in 60 seconds

• 1) Managers: Command workers:

– Start/Stop

– Left/Right

– Faster/Slower

• 2) Workers, manage your own work

What do you think about forming

teams

Fill out the handout: 2

minutes

Form pairs, discuss results:

5 minutes

Bottleneck of software development

Team formation model Bruce Tuckman, 1965

Forming

Storming

Norming

Performing

Team start activities

Projects: assign work to individuals

AProduct

Project a1

Project a2

B Project b1 Project b2

Persons (previously knownas ”resources”)

Product

Product development using persons

working in teams

AProduct

BProduct

Backlog ”A”Backlog ”B”

”Tigers”

”The A-Team”

”Blueberries”

Experts/generalists

- Low speed, low value!

+ Solutions with greatproperties

I can do this

efficiently!

I can do this

efficiently!I can do this

efficiently!

value

What can you do?

+ Speed, value, learning!

Could you work

with me on this?

I can do this

efficiently!I’ll try!

value

R&D Team performance

Performance

Time together

Months Years

Switch a member every one or two years to keep improving…

Work with enabling conditions & team building to maximise probability this will happen Most groups

A few tips on how to get good results

with teams

Whistle if you ever has held your opinion

back to avoid conflict or to avoid hurting

a co-workers feelings

Trust

Open (positive) conflict

Innovationsynergy

• History, what do everyone bring

• Goals for individuals, the team and the

organization

• Work process

• Development practices

• Team rules

• Conflict management

Teamstartups, use 1-2 days to work through:

After this effort I want to have ….

We are curious, courageous and take the lead in our organization on exploring how to

develop great innovative teams. Each of us take responsibility for this.

We will increase our market share by developing a product with best

performance in market

“Journey lines”, what do everyone bring

Idea first found in “Coaching Agile teams”

Make decisions by consensus

Yes

Yes Yes

Yes

Yes

No

Faster to consensus with fist-to-five

It’s a great idea and I will be one of the leaders in implementing it.

I’m not in total agreement but feel comfortable to let this decision or a proposal pass without further discussion.

I think it’s a good idea/decision and will work for it.

I need to talk more on the proposal and require changes for it to pass.

I still need to discuss certain issues and suggest changes that should be made.

I am more comfortable with the proposal but would like to discuss some minor issues

Blueberries – team agreements

Definition of done

Meetings, length, time

How to develop sw, design, test, collaboration etc

ways of working together…

Everyone will attend our working meetings. It is not ok to schedule other conflicting work/personal activities

No headphones in team area

We value differences in opinion/experience. Everyone will make their opinion known

When we get into conflict, each of us will takeresponsibility to work through it

When team agreements is not kept, each of uswill call on this behaviour

Blueberries, agreements continued

New to Scrum? – Clarify responsibilities

Line

manager

Scrum

Master

Scrum

Product

Owner

Development

Team

…

Line

manager

Project

manager

Product

owner

…

This

ThatAnd this

Thisalso

Make a co-located workspace available

• Co-locating teams at least doubles productivity

”How Does Radical Collocation Help a Team Succeed?”, Teasleyet al

• 30 meters apart is same as truly remote”The Organization and Architecture of Innovation”, Allen & Henn

Desks to support teamwork/pairing

Remote!?!

Team rooms/facilities – what is

needed?

Conference rooms

Light

Pairing stations

Areas for individual work/calls

Plants

WhiteboardsWalls

Personal space

Inverted U table setup

Conference rooms

Light

Pairing stations Areas for individual work/calls

Plants

WhiteboardsWalls

Personal space

Teamroom 1

Teamroom 2

Details: Co-location

• Provide facilities, let team decide when to co-locate

• Working in a well-designed co-located space must be made

feel like a privilege

• One team/room. Provide noise isolation

• Provide adjacent conference rooms for meetings and hotelling

cubicles for work/private time away from team

• Make sure tables support pairing

• Write down team rules

• Update performance evaluation systems

Details: Self organizing team– Why?

• Whats’s bad about telling people the best way

to perform their work?

– Slows down inspect/adapt cycle

– Takes responsibility away

– Lessens commitment, energy and buy in

– Hinders continuous improvements

Details: How to lead/coach self

organizing teams

• How can we lead without commanding?

– Facilitate discussions

– Ask open questions

– Help analyze thinking/problem solving

– Let team fail, learn and assume responsibility

Feedback

When you <specific action> I <…>

Really?

#&%~!

Calling broken agreements

The agreement is important

to me. How do you feel

about it?

I noticed that you did not keep the agreement, and that is not ok with me!

The boy’s got skills!

#&%~!

<Make a new agreement about how to treat your agreements>

Conflict management

• Any upset, fear, or conflict, when thoroughly

viewed, will disappear

• Upset people tend to repeat themselvesC. Avery

Conflict resolution - The listen protocol

”A” is what I think

You think ”A”, is that right?

Yes (or no)

Is there more?

Yes (or no)

I think ”B”

You think ”B”, is that right?

Sw

itch

tone

xtch

unk

Lisa Sten

…

Change

Tell the person next to you about a change you have been involved in- What happened?- Why?

1 min

Why change?

To improveto adapt

to fix problems

Why has this not yet changed?

Change something on yourself!

Change something on someone else!

What happens when problems are exposed?

Problem

Fix problem

Keep problem

Responsibility Process

Independent of part of world, age, culture, gender, education, …

RESPONSIBILITY

OBLIGATION

SHAME

JUSTIFY

LAY BLAME

The Responsibility ProcessTM

Christopher Avery & Bill McCarley

The how-to model

Three keys to responsibility

1. Intention

2. Awareness

3. Confront

Key three: confront

What can I do about this?

How did I create this?What

do I want?

What can I learn from this?

#%&!@!

I can see that you are justifying

Helping others to responsibility

Can only be self applied!

Dissapointingly, you can’t tell others to

change

But on the other hand you don’t need

to!

Problems will be fixed anyway!

What is your mindset?

Lay blame(blame someone else)

Justify(blame circumstances)

Shame(blame yourself)

Obligation(should, have to, must…)

ResponsibilityWhat do I want? What can I do?

What do you think?

Could this responsibility stuff also apply to me?

I don’t care to fix any problems

I get payedanyway

Fixing problems, what’s in it for you?

Thousands of knowledge worker diary entries reviewed

- What happened?- Good day/bad day?

Source: Teresa Amabile and Steven Kramer, Harvard Business Review: “What Really Motivates Workers,http://hbr.org/2010/01/the-hbr-list-breakthrough-ideas-for-2010/ar/1

What people dislike

#1 reason for bad days at work: Encountering roadblocks to meaningful accomplishment

What people enjoy

75% of all good days at work were linked to progressand overcoming obstacles

Thus, to enjoy work more

Download posterand hang it at your workplace:www.cedur.se/downloads/rpm.pdf

www.christopheravery.com

20+ years of focus on ”just” this…


Change PART II

If what you want involves othersWhat can you do?

The illusion of control

Random ticket numbers Picked their own ticket numbers

Asked 4x more for tickets

People do not like other people’s ideas. They like their own ideas

...4 times as much

Getting everyone to contribute

Yeah yeah, whatever. Can I go back to actuallyworking now?”

Spread of agile knowledge on an

average team

Gap is too wide, very few

can contribute to

discussions

Scrum/agile knowledge/experience

Persons

Expert

Clueless

Required for buy in and sustainable

change

Everyone cancontribute todiscussion!

Scrum agile

XP lean

teamschange

Common pool of ideas

Buy in, Sustainable changeContinous improvements

Arguments and persuasion

… and further proof thatmy idea is awesome…

Now, get started!

Blah Blah Blah

2%

14%

34%34%

16%

Innovators: New things

Early adopters: Reasons

Early majority: SuccessLate majority: SafetySome pressure

Laggards: Extreme pressure, Fool proof

What people need to change

Have patience

Take it step by step

Don’t take resistance personal

Why do people not cooperate?

What’s in it for me?

Do you know?

Summary

Scrumagile

XP lean

teamschange


RESPONSIBILITY

OBLIGATION

SHAME

JUSTIFY

LAY BLAME

persuasion

Problem exposed

keep

fix

What’s in it for me?

Take it step by step

Tell someone you did not talk to so far which ideas about change you foundinteresting or useful.

1 min

Think of a really small problem you arehaving One that you can fix yourselftomorrow, before lunch, without involvinganyone else. Write down what you aregoing to do to fix it

1 min

The technical piece of the agile puzzle

FlexibilitySpeedQualityPredictabilityProduct lifetime ROI

Exercise: Done I

• Work in pairs. Do

the math on your

handout. 3

minutes

• Report: What did

you get?

Discussion

Perhaps developers are perfectionists that try to

produce beautiful code just to please their

ego’s?

Would we be able to decrease lifetime cost of

software if developers just learned what ”good

enough” quality is?

Conclusion

• Stop adding defects…

• Just about anything you do to increase quality

will increase product ROI

• Increasing quality increases development

speed,it is NOT a tradeoff!

So we have 0 defects when we are

done

Surely nobody can compete with us now?

When you are programming, what share of your

time do you think you spend reading existing

code, trying to understand how it works so that

you can make some changes…?

50%?

90%?

Readability pays off

• ”Code that works” is a very weak definition of

done

• How can we create readable code?

– When it works (every 10 minutes if you do TDD),

refactor for simplicity and readability

– Pairing/collective code ownership, you cannot

determine what code looks like to someone that

does not know what you know

This is not a problem, we have very

good developers

• Yes, I’m sure you have. Most companies do!

• AND, most of them did not yet have the

opportunity to practice their agile skill-set. It

takes months and years to learn…

• Learning curve for developers learning agile

practices is quite steep, but the technical part

is what makes the rest work, so you just need

to learn.

What do developers need to learn?

• Writing Clean Code

• Test Driven Development

• Simple Design

• Pairing

• Refactoring

• Working with legacy code

How can we learn all this…

• Get an onsite developent coach to pair with team

for several months

• Run some inhouse coding Dojos with an expert

• Attend a hands-on TDD/agile development course

• Watch out TDD videos/Katas on the net

• Books, create a study group

• Practice…, pair

People writing about/teaching this:

• Bob Martin

• Michael Feathers

• Ron Jeffries

• Roy Osherove

• Kent Beck

• James Shore

• …

Except from making us extremely fast and removing all defects

Are there any additional advantages?

Yes – the technical piece of the puzzle actually is what makes

iterative incremental development possible

EXtreme Programming, XP

• Flattening cost of change curve

• Embrace change

Cos

t of C

hang

e

Traditional

Requirements Analysis andDesign

Coding Testing in theLarge

Production

Time

XP, Most changes

Cos

t of C

hang

e

Time

Extreme Programming (XP), practices

CustomerCustomerCustomerCustomer

TestsTestsTestsTestsPlanningPlanningPlanningPlanning

GameGameGameGame

WholeWholeWholeWhole

TeamTeamTeamTeam

SmallSmallSmallSmall

ReleasesReleasesReleasesReleases

TestTestTestTest----DrivenDrivenDrivenDriven

DevelopmentDevelopmentDevelopmentDevelopment

SimpleSimpleSimpleSimple

DesignDesignDesignDesign

PairPairPairPair

ProgrammingProgrammingProgrammingProgrammingRefactoringRefactoringRefactoringRefactoring

ContinuousContinuousContinuousContinuous

IntegrationIntegrationIntegrationIntegration

CodingCodingCodingCoding

StandardStandardStandardStandard

CollectiveCollectiveCollectiveCollective

OwnershipOwnershipOwnershipOwnership

SustainableSustainableSustainableSustainable

PacePacePacePace

MetaphorMetaphorMetaphorMetaphor

XP Practices

COLLECTIVE OWNERSHIP

CONTINUOUS INTEGRATION

SHORT RELEASES

PLANNING GAME

ON-SITE CUSTOMER

40 HOUR WEEK

METAPHOR

REFACTORING

PAIR PROGRAMMING

CODING STANDARDS

SIMPLE DESIGN

TESTING

Possible Uses of Automated Tests

• Finding defects early

• Safety net for regression testing

• Communicating with customer

– Executable requirements

• Design method – safely growing systems

– TDD

Test Automation Pyramid

Unit Tests / Component Tests

Acceptance Tests(API/Service Layer)

GUITests

Manual Tests

Biggest ROIby far!

TDD Cycles, Outside - In

Write a failingacceptance test

Write a failingunit test

Make the testpass

Refactor

Snap your fingers if you have

experienced solving your own problem

just by explaining it to someone…

Pair Programming

Why?

• The Costs and Benefits of Pair Programming

– Alistair Cockburn, Laurie Williams– Takes 15% more time

– Improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable

– Extra investment paid back 15-60 times by reduced test costs

• Pair helps each other to stay on the agile path…

• Long term effects of stimulating a learning organization

• ”Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience”– Arlo Belshee study

How

• Driver

– Focuses on how to implement current method

• Partner

– Thinking more strategically

– Is this whole approach going to work?

– What are some more tests that may not work yet?

– Can the system be simplified so that the current problem disappears?

• ”May I drive?”

• Pair switching, how often?

– Consider “Ping Pong TDD”

• How to get started?

Agile Testing TDD, Test Driven Development

“Developers reach deadlines faster if they skip TDD in the same way that skydivers reach the ground faster if they skip parachutes“, Joakim Karlsson, Blueplane 2007

Unit tests

• Protects against regression failures

• Enables refactoring and emergent design

• Pass quickly (< 10 minutes)Goal: Test complete system,

4000 tests, in < 10 minutes

Unit Tests

Acceptance Tests

GUITests

End-to-end (system) tests

• Measure of demonstrable progress

–Take a while to make pass

–Hard to setup and keep working

–Optionally readable/defined by customer

Unit Tests

Acceptance Tests

GUITests

Conclusions

The warmup questions

Re-visit your warp up questions from day 1.

Check each question, did you change your mind

about anything or get new insights?

What problems have you seen

Re-visit your team poster from day 1.

For each problem, do you think anything we

covered during these days could be worth trying

to improve the situation? What?

Thank you!

Henrik Berglund – Cedur [email protected]

twitter: @henrikber

I offer life time support on this class. Feel free to give me a call and talk about scrum, agile, lean and teams!

Also take a look at our agile blogs, recommended books, videos, sites and articles at http://www.cedur.se

Bonus slides

Lean software development

Exercise: Pass the pennies

About Toyota

• What is the source of their greatness?

– Toyota Saying: Making things is about making

peopleIsao Kato, student of Taichii Ohno, Father of TPS

• Respect People

• Continuous improvements

– Faster – Better - Cheaper

Seven principles of Lean Software

Development

• Eliminate waste

• Build quality in

• Create knowledge

• Defer commitment

• Deliver fast

• Respect people

• Optimize the whole

Value stream mapping

Lower the water to expose the rocks

Queue theory –

The utilization paradox

10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Cyc

le t

ime

(hou

rs)

Load

Large batches

Medium batches

Small batches

High performance Thrashing!

Cyc

le t

ime

(hou

rs)

The seven wastes

• Partially done work, WIP

• Extra features

• Relearning

• Handoffs

• Task switching

• Delays

• Defects

Gaining a competitive edge using agile with

contracts and partners

Fixed price contracts

• Trying to limit scope

– Makes scope grow…

• Transfer risk to seller

– But who owns the risk really…

• Controlling scope and managing change

– But these costs dominate most vendor-supplier relationships

• Often awarded to lowest bidder

– So winner need to create profit by charging for change…does not align

interests of seller buyer

Turning fixed price contracts in to win-win

• We will deliver this project iteratively and incrementally

• Every iteration we will show you what we have build and ask for your

feedback

• Before every iteration you can change the priorities any way you like

• If you want to add new stuff that is no problem as long as you remove

something else of similar size

• Whenever you like you can stop the project and put it in production.

• When you do that we will charge you 20% of the remaining project cost as

compensation for loss of income

Lean contracts and cooperation

• T5 story

• Toyota philosophy

– Contract types to align interests

• For more info:

– Take a look at our three part newsletter about

contracts and cooperation at

www.cedur.se/Newsletter.html

Details: Retrospectives

Retrospective

- brainstorm, prioritize

Week2 Week3Week1

Good Can get betterTheme3 Theme 4

We want to work on this the most!

Theme 2

Theme 1

Retrospective

- cause-effect diagrams

Source: http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf

Defects release to production

Angry customersProblem

Teams demotivated

Loss of team members

Problem

Teams disrupted

Stress

Releases not properly tested

Lack of test automation

Not enough time to write test scripts

Scope of sprint not reduced

Root cause

Lack of tools & training in test automation

Root cause

Hotfixesrequired

Retrospective

- countermeasures

Root cause!

Root cause!

Suggested countermeasures

What do we expect?

Who will do what, when?

Details: Two hour retrospective example

• Check In 5 minutes

• Timeline 10 minutes

• What went well 10 minutes

• What could be better 10 minutes

• Sort/prioritize, select a

few issues to work on 5 minutes

• Root cause analysis 45 minutes

– 5 why

• Design experiments to

address root cause(s) of

problems 20 minutes

• Switch time 15 minutes

lyckas med scrum och agile omfattning: 2 dagar, 9-17 · agila metoder en genomgång av vad de agila...

Documents