scaling software agility - wordpress.com · priorities and objectives driven by product owners 33....

Copyright 2008 Dean Leffingwell

Scaling Software Agility:

Best Practices for Large

Enterprises

Agile 201 – Seven Agile Team

Practices that Scale

1


Seven Agile Team

Practices That Scale

2


1. Define/Build/Test Team

3


Conway’s Law

“Organizations which design systems are

constrained to produce designs which are

copies of the communication structures of

these organizations.”

Mel Conway (1968)

4


Agile Fractal – a team pattern, repeated at larger scales to produce optimum outcomes

Fractal Teams can be based on

– Features

– Components, subsystems

– Interfaces

– Products

– Infrastructure

D/B/T Team – Agile Fractal

Team

1

Team

100

5


D/B/T Teams Have the Necessary Skills

6

Define

Build

Test

Define

Build

Test

Define

Build

Test

Define

Build

Test


Agile Team Rationale

Communication is optimized across disciplines

Teams have all disciplines necessary

– Define → build → test

– Bid, elaborate, execute

– Adjust scope and reprioritize

– Integrate, test, accept

The functional and social network optimized for

one purpose

– To define, design, build and test a potentially shippable

increment of software

7


High Performing Teams

Have the right people on the team

Are led and challenged, not managed

Understand their mission

Communicate and collaborate

continuously

Are accountable for their results

8


Open Environment, Constant

Communication

9


First Level of Scale

Functions/Roles:

Release manager

Product owner

System Integration/QA

Architect?

10


2. Mastering the Iteration

The iteration is the heartbeat of agility.

Master that, and most other things agile

tend to naturally fall into place.

11


Iteration Pattern

Story A

Story B

Story C

Story D

Story E

Story F

Story …

Story A

Story B

Story C

Story D

Story E

Story F

Story …

DefineDefine

Pla

nP

lan

Fix

ed

Re

so

urc

es

Fixed Time (Iteration)

12


Short Iterations

Systems are build as increments in short iterations

Each iteration is a “potentially shippable increment of

code”

Literature counsels lengths of 1 week to 4 weeks

Experience has shown that an optimum iteration length

is often two weeks

– More than one week to build real functionality

– Short enough to limit procrastination

– Natural calendar cadence

13


Iteration Cadence Calendar

Iteration planning Daily standup Daily standup

Define, design,

develop, test,

accept

Demo

Iteration

commitment

Retrospective

Prioritize and

elaborate

backlog

Routine meeting schedules simplify planning,

management, and assessment

14


Login portal

Display minutes

Support ticket call

Remote login help

Update profile

Buy more time

Single sign-on

Log rotation

Timer display

Automatic logout

Usage warning

Iteration Planning

From product backlog to iteration backlog

15

Courtesy Trailridge Consulting, LLC


Starts with a Goal

A short “theme” or “objective” for the iteration often

increases clarity and commitment

Provided by Product Owner

Finalize new UE to match designFinalize new UE to match design

Validate across all browsersValidate across all browsers

Prepare for drop to Alpha customerPrepare for drop to Alpha customer

16


Iteration Planning Meeting

Goal: Create a committed iteration plan

Objectives defined and stories backlog prioritized prior

to meeting

Process:

– Take the highest priority story

– Identify all tasks - take responsibility, team decides

– Estimate each task

– Repeat until full

Guidelines

– The whole team < 4 hours

– Estimate tasks collaboratively in hours

17


Iteration Planning

18


If you ask a team to choose items from a (prioritized) list what

the members believe they can do in a short time-box, the team

will probably choose and commit to a reasonable set of features

Once the team members have committed to a set of features

that they think they can complete, they will probably figure out

how to get those features done within the time-box

Mary Poppendiek – Lean Software Development

Team Commitment

But commitments are reciprocal

Team commits to delivering functionality

Business commits to leave priorities alone for THAT iteration

19


Delivering on the Commitment

Team self-manages completion, interdependencies,

issues

Team can add, delete or change tasks as necessary

– But stories generally unchanged

Teams “swarm” where necessary to complete higher

priority stories

Team re-estimates work remaining daily

20


Track Iterations at the Story Level

Simple Visual Status Kanban

21


Iteration Status with “Burndown Charts”


22


With Tooling Automation

23


Visibility with Daily Standups

15 minute meeting - same time and place every day; the

team decides when

ALL team members participate

Everyone stands up; no problem solving

15-minute time box; 1 to 2 minutes per report, start and

stop on time

Three comments:

– What I did yesterday

– What I plan to do today

– What blocks or impediments I face

It is peer commitments and

THIS IS NOT SCRUM

MASTER STATUS

It is peer commitments and

communication

“Meet After” – keep only needed participants for design and

problem solving

– Attendance and length varies daily

24


End of Iteration Review and Demo

Demonstration of all stories

to key stakeholders

– (in and outside team)

Occurs each and every

iteration

Acceptance (or not)

of each story

Acceptance (or not) of

the entire iteration

25


Iteration Retrospective

What is it?

– Review of the team & process

– Review of impediments

Guidelines

– 30-60 minutes

– After every iteration

– Whole team participates

Three Questions

– What should we stop doing?

– What should we start doing?

– What should we continue doing?

26


3. Two-Level Planning and Tracking

“There have been countless ambitious but doomed attempts to plan

large software projects from start to finish in minute detail, as you would

plan the construction of a skyscraper. . . . In an iterative process, we

recommend that the development be based on two kinds of plans.

– A coarse-grained plan: the phase (release) plan

– A series of fine-grained plans: the iteration plans

So, in agile methods, the investment in long-range (longer than one or

two iterations), speculative plans is reduced, and the lack of precision

and accuracy in such plans is acknowledged. Release plans, therefore,

are intentionally coarse-grained, less comprehensive, and less precise”

Kruchten, 2004

27


Two Level Planning and Tracking

Iteration Cycle

Drives

Feedback

- Adjust

Product & Release Cycle

ReleaseVision

Release Planning

Release Scopeand Boundaries

28

Iteration Planning

Develop & TestReview &

Adapt


Two Levels of Planning

Plan Releases at the System Level

– Three to six months planning horizon

– Release theme sets overall objective

– Prioritized feature sets define proposed/estimated content

– High visibility and confidence near term (Release “next” and

“next+1”). Lower visibility longer term

Plan Iterations at the Component/module/feature Level

– 4-6 weeks planning horizon

– Define story cards and tasks for next 1-2 iterations

– Adapt and adjust at each iteration

29


Planning at Scale

stories

System

Release plan at system level

R1 R2

Requirements pyramid

Fea1

Fea2

Fea3

Fea4

|1|1 | 2| 2 | 3| 3 | 4| 4 | 5| 5 | 6| 6 | 7| 7 | 8| 8

|1|1 | 2| 2 | 3| 3 | 4| 4 | 5| 5 | 6| 6 | 7| 7 | 8| 8

|1|1 | 2| 2 | 3| 3 | 4| 4 | 5| 5 | 6| 6 | 7| 7 | 8| 8

30


Iteration Pattern

Story A

Story B

Story C

Story D

Story E

Story F

Story …

Story A

Story B

Story C

Story D

Story E

Story F

Story …P

lan

Pla

n

Fix

ed

Re

so

urc

es

Fixed Time (Iteration)

31


Release Pattern

Stories

Release timebox

32


Iteration Planning is a “Routine Event”

Happens at iteration cadence boundary (2 weeks)

Can be done under local authority of team

– Subject to collaboration with other component teams

Consumes ½ to 1 day of every iteration cycle

Priorities and objectives driven by Product Owners

33


Release Planning is a “Big Event”

A full day (or two for larger teams) for every

release

Most everyone attends in person if at all possible

Product Manager owns the feature priorities

Development team owns story planning and high-level

estimates

Architects work as intermediaries for governance,

interfaces and dependencies

Adequate logistics and facilitation

– Big room with lots of whiteboard space

– Break-out rooms for multiple teams

Preview- Agile at Scale

Preview- Agile at Scale

34


Track Releases at the Feature Level

35


4. Smaller, More Frequent Releases

Shorter release dates

– 60-120 days

Releases defined by

– Date, theme, planned

feature set, quality

Scope is the variable

– Release date and

quality are fixed

36


Benefits

Rapid customer feedback reduces waste

Earlier value delivery against customer’s highest needs

Frequent, forced system integration

improves quality and lowers risk

Low cost to change

– Accepts new, important customer features

Reprioritize backlog at every iteration & release

– Reduced patching headaches

“It’s only X days the next release, that feature can wait”

Or easy, high-confidence patching

Smaller increments for higher productivity

– Leaner flow through the entire organization to customer

37


Fix the Dates - Float the Features

Teams learn that dates MATTER

Product owners learn that priorities MATTER

Agile teams MEET their commitments

10/1/2007 11/1/2007 12/1/2006 1/1/2008 2/1/2008 3/1/2008

3/25/20089/24/2007

38


Organizing Release Backlog

TimeCourtesy BMC Software, Inc.

39


Communicating Expectations

40


Courtesy BMC Software, Inc.

Delivering Customer Agility

New requirements can

be added in real-time

Do not get “stuck” in the

backlog

Certain features get demoted

to backlog

Customer gets the release in

3-4 months max

41


5. Concurrent Testing

All code is tested code. Teams get no credit for

delivering functionality that has been coded, but

not tested

Tests are written before, or concurrently with, the

code itself

Testing is a team effort. Testers and developers

all write tests

Test automation is the rule, not the exception

Philosophy of Agile Testing

42


Concurrent Testing

Early and continuous testing is mandatory

– Because the system is developed in short, workable increments

of functionality:

various kinds of testing that used to be deferred until “delivery” must now

be immediate

– Forces a “test early and often” cycle which becomes integral to

the iteration process

The programmers and testers write and execute tests

as they write the code

– Learn valuable lessons sooner

– Peer review of program logic

– Risks are discovered and addressed earlier

– Quality is improved

“We can’t

accept a story

we can’t test”

“We can’t

accept a story

we can’t test”

43


Concurrent

Unit Testing

– Developer written

Acceptance Testing

– Customer, product owner, tester written

Component Testing

– Integrated BVT (Build Verification Tests) at

component/module/feature level

System, Performance and Reliability

Testing

– Systems Tester and Developer Written

– QA Involvement

44

It is unit tests that

keep our code

flexible,

maintainable, and

reusable

The test code is

important as the

production code

Test enable the

“ilities”

Robert Martin –

Clean Code


Patterns: The Practical World

The iteration goal is to have tested and accepted

software at the end of every iteration

– But automation of testing may lag by one or more iterations

Over time:

– the set of accumulated functional test cases

– + system level and performance test cases serve as full

regression tests for iteration and release

The release goal is to execute a full suite of release

level acceptance testing, full regression and system

and performance testing in less than one iteration

Often, a typical release pattern develops

45


On Test Automation

You have no choice

Manual tests bottleneck velocity

You can’t ship what you can’t test

46


Test Driven Development (TDD)

For each new story:

1. First, write the test

2. Run the test and watch it fail

a. Test the test itself and test harnesses that hold the test in place

b. See how the system will fail if the code is incorrect

3. Write the minimum amount of code that is necessary to

pass the test

4. If the test fails, refactor code & test as necessary until the

module routinely passes the test

47


6. Continuous Integration

Continuous integration is neither new nor invented by agile

It has been applied as a best practice for at least a decade

However, continuous integration is mandatory with agile

48


The Problem of Discontinuous

Integration

49


Three Steps of Continuous Integration

50

The system

always runs

Source Code Integration

Automated Build

Management

Automated

Build

Verification test


Continuous Integration Model

Kevin Lee, IBM Rational 2005

51


Teams develop locally

Code is checked in to repository

Integrate daily

System integrate at least weekly


52


Continuous Integration Success

Team can build at least once a day

– Effort is inversely proportional to time between builds!

– A broken build “stops” production and is addressed immediately

Successful builds

– Checks in all the latest source code

– Recompile every file from scratch

– Successfully execute all unit tests

– Link and deploy for execution

– Successfully execute automated Build Verification Test

Martin Fowler

53


Memo from an XP shop

“The XP environment provides us with many benefits, not the least of which is the incredible

pace of progress we are so proud of. Lately we have had a rash of build failures, some related

to infrastructure issues, but more related to carelessness. Broken builds destroy the “heartbeat”

of an XP team. Each of you has a primary responsibility to ensure that this doesn’t happen . . .

but here are a few tips to ensure that you aren’t the one who broke the build:

– Write your test cases before you write the code

– Build and test the code on your desktop BEFORE you check it in

– Make sure you run all of the cases that the build does

– Do not comment-out inconveniently failing unit tests. Find out why they are broken,

and either fix the test or fix your code

– If you are changing code that may affect another team, ASK before you check it in

– Do not leave the building until you are SURE your last check-in built successfully

and the unit tests all ran

The Build master is there to make sure that broken builds get addressed, not to address them.

The responsibility for a broken build is yours. Breaking the build will have an affect on your

standing within the team and, potentially, your review, so let’s be careful out there.”

54


7. Regular Reflection and Adaptation

At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto, Principle 12

55

Periodically, the entire team including owners/end users

– reflects on the results of the process

– learn from that examination

– adapt the process - and organization - to produce better results

The team decides what to keep doing, what to stop doing,

and what to do differently next time


Retrospective

What is it?

– Review of the team & process

– Review of impediments

Guidelines

– 30-60 minutes

– After every iteration

– Whole team participates

Three Questions

– What should we stop doing?

– What should we start doing?

– What should we continue doing?


56


Sample “take-aways”

Move the daily build to 4 PM so we know it

works before we leave for the day

Buy a bigger file server to reduce build times

We missed on the stories that were not previewed in

advance of the iteration

Our CM environment &^*#$%

Testers weren't able to start early enough –” we can’t

drop all the code on the next to the last day of the

iteration

We underestimated the technical risk of …”

Product owners need to live with us

57


END AGILE 201

58

scaling software agility - wordpress.com · priorities and objectives driven by product owners 33....

Documents