Foundations Mechanics Agile Software Development Planning

Agile Software Development

www.agilecrossing.com

1

Agile Software Development Instructor – Roger Brown CST, CSC

Training Transition

Transformation

All slides © 2014 Roger W. Brown www.AgileCrossing.com

Topics

Foundations

Mechanics

Planning

Scrum Roles

Agile Success Factors

Agile Transition

Extreme Programming

Kanban

2

Agile Foundations

History Values

Principles Brands

3

Empirical Process

• Agile success relies on “Empirical

Process”

• Improvement comes from a continuous

learning cycle we call “Inspect and

Adapt”.

4

Continuous Improvement

Plan

Do Check

Act

Deming Cycle

Empirical Process Transparency,

Inspect and

Adapt

5

notes

6



2

Agile Basics

• Agile software development implements

Lean principles and dynamics.

• Scrum is one form of Agile, designed

initially for software development but

applicable to other kinds of work.

7

Manifesto for Agile Software Development 2001

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

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

www.agilemanifesto.org

Agile Manifesto

8

What is Agile Software Development?

Team Based Incremental Iterative Frequent Delivery Fully Visible Production Quality Value Driven

9

Product Development Value Stream

Product Discovery

Product Definition

Product Development

Product Delivery

Product Operation

Support

Scrum/XP

Lean Startup

Lean UX

DevOps Kanban

Several complementary frameworks are available to increase organizational agility

Business success comes from maximizing value/time.

10

notes

11

Agile Mechanics

Scrum Framework and

Execution

12



3

Scrum Framework

• Scrum has 4 meetings and 3 artifacts

• Scrum has 3 roles that share the

responsibility of creating value in small

increments

• The roles complement each other to

create a balanced team

13

Scrum Framework

Potentially Shippable Product

Increment

Sprint Backlog

Product Backlog

Release

Planning

Sprint

Planning

Sprint

Review Sprint

Retrospective

Daily

Scrum

1-4

weeks

Story Time

14

The Scrum Team

Desired Features

Product Owner

Development Team

Product

ScrumMaster

15

Product Owner

Maximizes the value of the work done

o Sets Vision o Manages Backlog o Elaborates Features o Reviews Work o Decides Release Dates

16

Development Team Member

o 7 ± 2 o Cross functional o Full-time o Self-organizing o Empowered

Develops the product with high quality

17

ScrumMaster

o Facilitator o Mentor o Coach o Leader o Change Agent

Helps the team improve flow

and throughput The ScrumMaster is the

Heart of Collaboration

18



4

notes

19

Scrum Execution

• Scrum organizes work into 1-4 week time

boxes called Sprints

• Each Sprint has 4 primary meetings

• The bulk of the time is spent creating

value in the form of a product

20

Sprint Planning Meeting

Product Backlog

Sprint Backlog

Pri

ori

ty

Goal 1: What? • Which PBIs can will comprise our forecast? • What is our Sprint Goal? Ex. Build the shopping cart

Goal 2: How? • Design an implementation plan, often by decomposing into tasks • Double check our forecast

Attended by • Product Owner,

Development Team, ScrumMaster

• Other interested stakeholders

Time-box to 1 hour per week

of Sprint

Sprint Time Box

S1

1-4 weeks

Steady cadence, fixed length Abnormal Termination If the Sprint Goal cannot or should not be reached for

unexpected reasons, stop and plan a new Sprint

Focus No one can change the Sprint plan except the Scrum Team to add or

remove a PBI

S2 S3 S4

22

Daily Scrum

15 Min

The Three Questions What did you do yesterday? What do you plan to do today? Is anything blocking you?

23

Task Board

Sprint Burndown

Information Radiators

Item

24



5

Sprint Review

• Purpose • Get feedback from the Stakeholders

• Demonstrate the completed stories

• Review progress and adjust future

• Identify new/changed features

• Attendees • Product Owner, Development Team, ScrumMaster

• Any other stakeholders

Preparation • Who will show what? • Deploy to a preview server • Any documentation needed? • Update and show release burnup chart

2 Hours

Show actual running

code!

Sprint Retrospective

• Scrum Team meets privately

• Goal is process improvement

• Format

• Review results of previous experiments

• Gather Data

Reflect on what worked well, what didn’t

• Generate Insights

Discuss results and new ideas

• Decide Action Items

Consider adopting new practices

Stop doing things that are not working

1.5 Hours

Stop Start Continue

Keep it interesting • Appreciations • Food • Variety

Sprint Timeline

Sprint 1 Sprint 2

Re

leas

e P

lan

nin

g Sp

rin

t P

lan

nin

g St

ory

Tim

e

Spri

nt

Re

vie

w\R

etr

osp

ect

ive

Continuous Elaboration of Product Backlog Items

Sprint N

Spri

nt

Pla

nn

ing

Sto

ry T

ime

Sp

rin

t R

evi

ew

\Re

tro

spe

ctiv

e

Spri

nt

Pla

nn

ing

Sto

ry T

ime

Sp

rin

t R

evi

ew

\Re

tro

spe

ctiv

e R

ele

ase

…

Daily Scrum is held every day except Review/Retrospective day.

notes

28

Agile Planning

5 Levels User Stories Prioritization

Estimation Release Planning

29

Agile Planning

• Agile planning is continuous

• Agile planning happens at 5 levels, each

with a different time horizon

• The Product Backlog is the primary

source of work to be completed and

value to be delivered

30



6

Value Driven

Estimates

Features

Schedule Cost

Plan

Driven

The Plan creates

cost/schedule estimates

Waterfall

The Vision creates

feature estimates

Schedule Cost

Features

Value / Vision

Driven

Agile

Source: Sliger and Broderick “The Software Manager’s Bridge to Agility”

Constraints

31

Product Context - 5 Levels of Planning

Strategy

Portfolio

Vision

Roadmap

Release

Sprint

Day

P1 P2 P3 P4 P5

Product Backlog

Release 1 Release 2 Release 3

s1 s2 s3 s4 … sN

Scru

m P

lan

nin

g

32

Product Vision

• The Big Picture of how the product creates value

• Aligns team and business to the same goal

What is the name? Who is the target customer? What are the key benefits? What are the differentiating features?

33

Product Backlog

• Dynamic set of items to be done

• Prioritized

• Constantly in flux as the situation changes

Story

Story

Story

Spike

Story

Refactor

Story

Defect

Process Change

items are removed

priorities change

items are added

34

notes

35

User Stories

• User Stories are simple descriptions of

desired functionality

• User Stories have two attributes that are

helpful for planning: size and priority

• Stories are elaborated just-in-time for

implementation

36



7

User Story Template

As a <user role>, I can <do something> so that <I get some value>.

37

Card – Conversation – Confirmation

Sample User Stories

As a student, I can get a degree on-line so that I do not have to move near a college campus

As an online student, I can print a copy of my transcript to show an employer

As a degree candidate, I can see which courses I still need to satisfy my major so I can plan my next term

As a professor, I can get student test summary reports so that I can assess my teaching effectiveness

38

Backlog Hierarchy

Epic User Story Task Task Task Task

User Story Task Task Task Task

User Story Task Task Task Task

Product Backlog

Sprint Backlog

Business Goal

Planning Implementation

39

Where are the details?

(front)

Story 6: Course Catalog Demo As a prospective student, I can browse the course catalog to see if the classes I am interested in are available.

(back)

Story 1 Acceptance Criteria [ ] Has full catalog browse and search controls [ ] Show available dates in summary list [ ] Item click leads to class detail page [ ] Show class star ratings only, no comments [ ] Replace “Register for Course” button with “Join Now!” that links to sign-up page

Automated Tests

Speclet • formula • UI design • screen flow • business rules

40

notes

41

Prioritization

• Priorities help the Scrum Team decide

what to do next

• Priorities help with long term planning

• Prioritization can be done in many ways,

based on many criteria

42



8

Prioritization - MoSCoW

o Business value

o New knowledge

o Risk/Complexity

o Desirability

43

Story Map

Epic

I can browse by

department

I can search by subject

I can register

I can read content

I can browse by

title

I can unregister

I can browse by professor

I can join a waitlist

I can take tests

I can search by date offered

I can search by major

I can take classes on-line

Browse Search Register Attend Reports

I can do homework

I can print my

transcript

I can see my grade for a class

I can browse by popularity

Theme

Must

Should

Could

Pri

ori

ty

Smaller stories give more options for prioritizing for max value

44

I can print my

schedule

I can print my report

card

I can chat with

classmates

notes

45

Agile Estimating

• Agile estimation is done at both the high

level and the low level

• Estimates are used for planning and for

tracking progress

• Estimates are done quickly, by the

Delivery Team

• Estimates are not commitments

46

Why Estimate?

Story Points • High Level

• Compare one story to another

• Forecast Releases and Sprints

Task Hours • Low Level

• 1-8 hours for a Story element

• Refine Sprint plan

• Track Sprint progress

1 2 3 5 8 13

47

Estimation Basics

Quick

Story 1: Home Page As a prospective student, I can view the college services so that I can decide if I want to apply.

2 Story 17: Major Progress

As a degree candidate, I can see which courses I still need to satisfy my major so I can plan my next term

5

Quick

Relative

Guess

Done by Team

More than 2x effort required

48



9

Affinity Estimating

Groups of 2-3 people choose some stories

Put in column with similar sized stories

Team members

can move stories

Visual grouping for quick comparisons

1 2 3 5 8 13 20

49

Start with numbers

or arrange by size

first

Velocity

5

12

27

32

36 38

40 37 38

40

0

5

10

15

20

25

30

35

40

45

1 2 3 4 5 6 7 8 9 10

Sto

ry P

oin

ts C

om

ple

ted

Sprint

Team Velocity

How many story points can the Team complete in a Sprint?

Varies by circumstance, increases with

experience

Aggregates Team dynamics and organizational

factors

Is measured, not “managed”

50

Velocity is sum of estimates of

stories completed

notes

51

Long Term Planning

• Scrum-built products may have

Roadmaps and Release Plans

• Team velocity is a measure used in long

term planning

52

Product Roadmap

First sub-setting of Product Backlog for a long product development time frame

• How many releases?

• When?

• What is included in each?

Tim

e

Continuing Education for Professionals

Undergraduate Degrees

Graduate Degrees

The roadmap will be reviewed and updated as things

change

Product Backlog

Releases

53

Velocity

5

12

27

32

36 38

40 37 38

40

0

5

10

15

20

25

30

35

40

45

1 2 3 4 5 6 7 8 9 10

Sto

ry P

oin

ts C

om

ple

ted

Sprint

Team Velocity

How many story points can the Team complete in a Sprint?

Varies by circumstance, increases with

experience

Aggregates Team dynamics and organizational

factors

Is measured, not “managed”

Velocity is sum of estimates of

stories completed

Measurement is more reliable

than estimation



10

The Elements of Agile Planning

Product Backlog

Must

Should

Could

Won’t in this

Release

s1

s2

s3

…

sN

Release as often as possible

Newsworthy Release Event

Tim

e

Sprints

Priorities Which items are most valuable?

Velocity How much can the team complete in a Sprint?

Estimates How much effort is expected for each item?

Product Backlog What functionality Is needed for financial success?

Release Forecast (volume):

1. How long will it take? Number of Sprints = Total Backlog/Average Velocity 2. How much can we do? Percent of Backlog = Total Backlog/(Average Velocity * Number of Sprints)

Release = a series of Sprints resulting in a marketable delivery of value.

Release Planning Meeting

Share the Vision

Create Prioritized Backlog

Forecast Team Velocity

Forecast Release

1-2 days

Release = a series of Sprints resulting in a marketable release of value.

Visual Progress

Release Backlog

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Q1 Release

Q2 Release

Q3 Release

How much will we complete?

How much is done so far?

Progress is reported in units of actual product ready for

delivery

57

notes

58

Scrum Roles

Product Owner Development Team

ScrumMaster

59

Product Owner

• The Product Owner navigates the product to maximum business value

60



11

Define the Product

Build the Product

Plan the Product

It’s a Big Job

Corporate Strategy Portfolio Alignment Customer Needs Corporate Needs Competition Stakeholders

Product Vision Revenue Target

Product Backlog Priorities

Funding UX

Dev Team Collaboration Scrum Framework

Product Details Product Review

Release Plan

What else?

61

Product Owner Attributes

• Domain knowledge

• Empowered to

• Spend budget

• Define vision

• Make release decisions

• Understand what customers want

• Available to the team

• Actively manage stakeholders

• Familiarity with product development

• Team protector

62

Managing Value

Return on Investment =

Benefits – Costs

Costs

Cost is easy with a fixed team size and

Sprint length

Benefit is not so easy to

determine Elements of Business Value • Increased sales • Accelerated sales • Decreased expenses • Customer satisfaction/retention • External compliance • Market differentiation

63

Agile Goals for Business

Faster Time to Market

Quicker ROI

Lower Total Cost

Respond to Change

Reduced Risk

Stakeholder Relations

64 Predictability

Manage the Profit Strategy

Time

Pro

fit

competition

market penetration

customer feedback

innovation

compliance

internal stakeholders

market changes

The Product Owner balances competing demands to maximize value/time

65

notes

66



12

Development Team

• The Team is self-organizing • Teams go through a maturation process

67

Key Success Factors

• Self-organizing

• Cross-functional

• Full-time dedicated

• Work in a shared space

• Empowered to make decisions

• Team Working Agreement

• Definition of Done

• Automated Testing

• Right Skills and Tools

68

Tuckman's Team Development Model

Storming

Forming

Norming

Performing

• Teams go through four stages

• Teams can regress when membership changes

Time

Effe

ctiv

en

ess

69

Motivation

• Financial rewards often give poor results • Intrinsic vs. extrinsic motivation • People are motivated by

• autonomy • mastery • purpose

See Dan Pink, TED.com and Drive

70

Create

Validate Improve

Agile Goals for Developers

Cadence

A Sense of Done

0

20

40

60

M T W T F M T W T F

Wo

rk R

emai

nin

g (h

rs)

Visible Progress

Quality Work

Feedback

Teaming

71

notes

72



13

ScrumMaster

• The ScrumMaster is responsible for the health and growth of the Scrum Team

• The ScrumMaster is a facilitator, mentor, negotiator, protector, coach and servant leader

73

Facilitator

• Keep meetings productive and short

• Mediate disputes

• Grease the wheels

74

Coach

• Lead people to their own solutions

• Aware of the bigger picture

• Able to mentor individuals

• Knows when • to be prescriptive • to nudge • to keep distance

It’s better to be paying attention than to have all

the answers - Ward Cunningham

75

Servant Leader

• Lead vs. Manage

• Lead to make others better

• Increase teamwork and personal involvement

• Lead by example

76

Day in the Life of a ScrumMaster

Manage impediments Facilitate meetings Mediate and negotiate Teach Scrum Manage the process Assist the Product Owner

Observe and coach Team Encourage excellence Protect Team from distractions Build relationships Promote Organizational Agility Administer

ScrumMaster 7 Team Members Productivity

77

notes

78



14

Agile Success Factors

Focus and Flow Scrum Enhancers

Managing Technical Debt

79

Focus and Flow

• Scrum works best when the Team

achieves a smooth flow of work

• Scrum dynamics are based on the

mathematics of queuing theory that we

use to manage the Internet

80

Pull Systems

Push systems overwhelm capacity, creating turbulence, rework, waste and delay

Pull systems have a steady flow that provides predictability

Push

♫

81

Small Batches

Small batches move through

a system quicker

Single-piece-flow reduces the wait time

and moves risk to the

margin

Minimize work in progress

82

notes

83

Scrum Enhancers

• A 1-sprint look-ahead on stories will help

the flow

• Defining Ready and Done will

dramatically reduce time waste

84



15

Backlog Grooming

Product Owner spends 30% of their time working on the Product Backlog

• Identify new stories

• Splitting epics and stories

• Updating Release Plan with current velocity data

• Adjusting priorities

• Preparing next stories

• Designing user experience

85

Story Time

Development Team spends 5-10% of Sprint with the Product Owner preparing for the next Sprint

• Reviewing candidate stories

• Getting details and acceptance criteria

• Some technical design

• Estimate new stories

• Considering new ideas

Often a regular meeting 1 hour/week

or 2-3 hours mid-sprint

86

Definition of Ready

Negotiate with your Team - What they need for each story - When they need it

87

Sample Right size Screen sketches Acceptance criteria Dependent stories? Speclets

Definition of Done

Unit tested to 90% code coverage Code reviewed Acceptance tests pass UI Tested User Help updated Deployment scripts updated

• When estimating size, consider all the work needed to complete the story

• The Definition of Done may evolve over time

Sample

May also have one

for sprints and

releases

88

Sprint Flow

Sprint N Sprint N+1

Candidate Stories for N+1 (1.5 x velocity)

Definition of Ready

Screen Designs for N+1 (LoFi)

Continuous Product Backlog Grooming

Story Time Sprint Planning

89

Definition of Done

notes

90



16


• Technical Debt is poorly designed code

written to save time

• Technical Debt compounds over time

• Regular payments on Technical Debt will

enhance agility

91

Sources of Technical Debt

• Known defects left for later

• Stories not finished

• Overly complex code

• Unreadable code

• “Clever” solutions

• Poor designs

• Hard-to-test code

• Disabled code

92

Cost of Technical Debt

Cost to fix a defect as time passes

Impact on Team Velocity over time

Debt avoidance

Debt accumulation

Delayed debt payments

93


• Test-Driven Development

• Pair Programming

• Legacy debt payment allowances

• Boy Scout Rule

• Agile design training

• Code quality measurement tools

• Tech Debt Backlog

• Refactor stories

94

notes

95

Agile Transition

Scaling Agile Up and Out Organizational Change

Management’s Role

96



17

Scaling Agile Up and Out

• Agile can scale to many Teams

• Distributed Agile is constrained by the

laws of physics but there are patterns

that can help

97

Scaling Agile Up

Multi-Team Product • Team is the scaling unit

• Divide work across multiple small teams

• by feature

• by component

• Organize with Chief Product Owner Team and Scrum of Scrums

SoS

tactical

Team 1 Team 2 Team 3 Team 4

CPO strategic

98

Distributing Scrum Out

• How well does it work? Scrum is the best way to manage distributed Teams. Distributed Teams are not the best way to do Scrum.

• But distributed teams are a common reality so

• Prefer whole teams at each location

• Start project co-located

• Have ambassadors who travel

• Have buddies across locations

• Expect more documentation

• Don’t let anyone go dark

• Use video, IM, artifact sharing tools

99

notes

100

Organizational Change

• Agile development is simple but not easy

• Organizations are resistant to change

• Choosing the easy parts may fail to give

the desired results

101

Satir Change Model

102



18

Scrum Challenges

• Scrum is a vehicle for change • Not a process

• Scrum challenges the status quo • Reveals impediments and dysfunctions

in the organization

• Uncovers opportunities to excel in the market

• Partial Scrum will hide the dysfunctions

• Largest impediments are waterfall habits • Predictive thinking

• Command and control

• Demanding something will make it happen

• Willingness to sacrifice quality

- Ken Schwaber

Hybrid Scrum

103

Success Factors

• Involved Leadership • Emphasis on Customer Value • Empirical Process • Dedicated Cross-functional Teams • Decentralized Control • Enhanced Collaboration • Pull Systems • Modern Technology • Coaching

104

notes

105

Management’s Role

• Agile Leadership vs. Traditional

Management

• Decentralized Control

• Manager’s Value Proposition

• Leading Agile Change

106

Management or Leadership?

107

Old New

Responds to change Embraces change

Knows the answers Fosters new ideas

Bureaucratic Collaborative

Leader Decides Decentralized decisions/ownership

Authoritarian Influential

Decentralized Control

• Business set the strategy • Team is empowered to choose and

execute the tactics

108



19

Management Value Proposition

Results

Value - faster time to market - right product - higher quality - lower cost

Competitive Advantage - adaptability to changing market - risk mitigation - customer satisfaction

Productivity - transparency - reduced waste - motivated workforce

Contributions

Lead - set the strategy - champion the changes - enable an Agile workplace

Participate - guide the strategy - observe and comment - sponsor Agile management teams

Expect change - make changes as needed - socialize the changes

109

Visible Status in an Agile Enterprise

Enterprise Transition Team manages an improvement backlog

Management can view the status of any project or portfolio at any time

110

notes

111

Extreme Programming

Quality Testing

Agile Engineering

112

Quality and Testing

• Automated acceptance testing is used to ensure the right product is built

• Unit testing ensures the product is built right

113

Elements of High Quality

• Less re-work

• Fewer trouble calls

• Higher customer satisfaction

• Easier to enhance the product

• No “technical debt”

Build quality in! It’s cheaper in the long run.

114



20

The Testing Pyramid

Manual Tests through UI

Automation Suites

Unit Tests

Automated UI Tests

Automated Acceptance

Tests

Unit Tests

Traditional (find bugs)

Agile (prevent bugs)

Exploratory

testing

115

Single Piece Flow

Do This

Don’t Do This

116

notes

117

Agile Engineering Practices

Review of complimentary practices

118

Complementary Practices

• Co-location

• Pair Programming

• Refactoring

• Test-Driven Development

• Continuous Integration

• Exploratory Spikes

• Legacy System

Strategies

• Evolutionary Design

• Agile Architecture

119

Co-location

• Maximum communication

• Quicker resolutions

• Team Trust

• Learning

• Reduced overhead

• Better focus

Productivity can double!

120

C:/Users/Roger/Documents/_AgileCrossing/Courses/CSM/videos/SPF.mov



21

Pair Programming

• Team members work side-by-side

• Better Design

• Higher Quality

• Shared Knowledge

• Continuous Learning

121

Refactoring

• Improve design without changing function

• Well known patterns

• Always leave the code better than we found it

122

TDD Rhythm

Add a test

Run test and fail

Write code to pass test

Run tests, all pass

Refactor

Remove duplication and improve

design

Compile or logical failure

Just enough to pass!

Start a task

123

TDD Screen Shot

124

Benefits of TDD

• Higher quality

• Testing is not short-changed

• Safer to refactor

• Living Specification

• Cadence and Momentum

• Confidence

125

Number of Tests

Con

fid

enc

e

Continuous Integration

126



22

Exploratory Spikes

• Time-boxed experiment with stated goals • Support feature or task estimates

• Explore unfamiliar technologies or components

• Prototype and compare major design alternatives

• Story or task-sized

127

Acceptance Test Examples

• Based on Use Case • The “sunny day scenario” is one test

• Each exception scenario can be another

• Activity description • When a user clicks on the Options screen, a modal panel of option categories opens defaulting

to the General tab

• Algorithm or formula check • Give a purchase price of $1.25 and a deposit of $5.00, the vending machine will return change

consisting of 3 dollar bills and 3 quarters

• Spread sheet

• Entitlement rule • A Supervisor can view work orders initiated by someone else but not change them

input input output output output output output

price deposit dollars? quarter? dimes? nickels? pennies?

1.25 5.00 3 3 0 0 0

1.15 2.00 0 3 1 0 4

0.85 1.00 0 0 1 1 0

128

FitNesse Screen Shot

129

Legacy System Strategies

• Legacy System == system with no tests

• Known patterns

• Write “characterization tests” to reveal current behavior

• Work in small steps

• Debug with unit tests

• Look for seams

• Break dependencies

130

Evolutionary Design

• Whiteboard vs. design document

• Constant refactoring

• YAGNI – no gold plating, minimal complexity

• Change is the norm

• Write readable code

• Write testable code

• Design to interfaces

• Use design patterns wisely

131

Agile Architecture

• Architecture == anything that is hard to change

• Design for 90%, not the last 10%

• Wire frame

• Encapsulate dependencies

• Loose coupling, high cohesion

132



23

notes

133

Kanban

134

Kanban

• Kanban is a simple Agile form based on

visual management and limiting work in

progress

• It is best for work that is highly variable

and not under control of the team

135

Kanban

Work Requests

Managed Queue

Varied items are pulled into a work stream

when someone has time to deal with them.

Irregular arrival of requests is smoothed

into to a predictable output flow.

time

136

Kanban Core Properties

• Visualize the workflow • Limit WIP • Measure and manage flow • Make process policies explicit • Improve collaboratively using models and the

scientific method • Theory of Constraints • Systems Thinking • Deming • Toyota Product System

137

Kanban Board

138

Ready Analysis Develop Code Review

Test Release

8 4 3 5 4 8

Self Assignment

Incremental Improvement

WIP Limits

Prioritization Visual Management



24

Scrum vs. Kanban

Scrum Kanban

Teams required Teams may emerge

Explicit roles No new roles

Sync input and output cadence Input and output cadence are independent

Defined artifacts, meetings, teams Start with current work flow, evolve process

Quick estimation No estimation

Measure velocity Measure throughput

Sprint-sized batches Continuous flow with WIP limits

Multiplicative increases in productivity from Team synergies

Fractionally improved productivity from incremental changes

Promotes innovation through sustained collaboration

Focused on task-sized work by silo-ed individuals

Long term predictability Near term predictability 139

notes

140

Instructor

Roger Brown

• Agile Coach

• Scrum Alliance

• Contact Web: www.agilecrossing.com

Email: [email protected]

Twitter: @rwbrown

Blog: www.agileCoachJournal.com

LinkedIn: http://www.linkedin.com/in/rogerwbrown

V 3.5

141

Agile Software Development Instructor – Roger Brown CST, CSC

Training Transition

Transformation

All slides © 2014 Roger W. Brown www.AgileCrossing.com

http://www.agilecrossing.com/

mailto:[email protected]

http://www.agilecoachjournal.com/

http://www.linkedin.com/in/rogerwbrown

http://www.linkedin.com/in/rogerwbrown