Dias nummer 1 - SIUEFlexible! AGILE First Impressions 3 × "Agile teams don't plan." × "Agile is a...

AGILE Realities

Presenters:Chris Koo (Edward Jones)Blake Moyer (Edward Jones)Joan Romine (Boeing)

1

AGILE Gaining Momentum

2

Fast!

Flexible!

AGILE First Impressions

3

× "Agile teams don't plan."× "Agile is a silver bullet."× "Agile teams don't need requirements."× "Agile teams can deliver an end product faster

than waterfall."

AGILE Development Myths

4

Is iterative and incremental

• Is about useful working software quicker and better through better internal team and customer collaboration.

• Is a mindset and discipline, NOT a template or tool.

AGILE Development

5

You may think that IID and Agile

work together like this…

IID Agile

A better representation of IID and

Agile would be as follows…

IID Agile

Manifesto for AGILE Development

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 toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

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

6

AGILE Project Returns

100%

11%

10%4% 125%

Benefits

Realized Using

Traditional PM

Approaches

Expected Benefits

Using

Agile/Iterative

Approaches

End-User

Adoption

Improved

scope, less

unused,

unneeded

functionality

Quality

Improvements

Lower cost due

to less work

Time to Value

Benefits

realization

pulled from

iterative

releases rather

than one single

release at the

project’s end

7Source: Corporate Executive Board

SPRINT ARTIFACTS

PREPARATION(Iteration -1 & 0)

SPRINT PROCESS(Construction)

AGILE Process

ROLESProduct Owner

Scrum Master

SprintTeam

StakeholdersUsers

• Vision / Business case • Agile eligibility / approval• Epic requirements• Initial product backlog• Initial release plan• Team assembly

Sprint Planning

Daily Cycle

Sprint Review

Sprint Retrospective

Update Product Backlog

RELEASEProduct Increment

Product Backlog

Sprint Backlog

Impediment List

• Daily Scrum• Daily Work

8

Test Cases

Design Models

RequirementsUse Case

Prototype

• Vision / Business case • Agile eligibility / approval• EPIC requirements• Initial product backlog• Initial release plan• Team assembly

AGILE – Preparation

9SPRINT

ARTIFACTS



AGILE Process

ROLESProduct Owner

Scrum Master

SprintTeam

StakeholdersUsers


Sprint Planning

Daily Cycle

Sprint Review




Product Backlog

Sprint Backlog

Impediment List


Test Cases

Design Models


Prototype

Mindset Shift - Scope

Re

sou

rce

s

CustomerSatisfaction

Cost

Waterfall AGILE

Res

ou

rce

s

CustomerSatisfaction

Cost

FOCUS:Scope / Function

FOCUS:Priority / Value

Flexible Constraint

Fixed Constraint

10

Mindset Shift - Requirements

Waterfall

"Pay now…"

AGILE

"…or pay later"

EPICRequirements

Project Plan

Testing

TestingImplement

Design

Development

Implement

DetailedRequirements

Detailed Requirements

Business Need Business Need

Project Plan

Sprint 1

Development

Design

Testing

Design

Development

Implement


Sprint 2

Testing

Design

Development

Implement


Sprint 3

Project Approval

11

Mindset Shift – Product Backlog

Story ID Story Name / Description Status

Business Priority Story Points Sprint

1 View Orders (INQ Summary) Planned A 1

2 INQ Summary Screen (Branch users only) Planned A.0 1

3 View Orders by Name / Account- Includes creation of View file

Planned A.1 7 1

4 View Orders by FA Planned A.7 3 1

5 View Orders by Symbol Planned A.2 2 1

6 View Orders by Product Planned A.3 3 1

Business-defined

story or use case

describing a function.

Highest priority

stories are

developed first;

others queued

up as "Planned."

Business defines

story priorities,

and may change

them at any time

Sprint team sizes

stories using a relative

measure; at the end of

each sprint, # story pts

delivered is measured.

12

SPRINT PROCESS

(Construction)

Sprint Planning

Daily Cycle

Sprint Review


UpdateProductBacklog

Product Increment

AGILE – Sprint Process

13

RELEASE

SPRINT ARTIFACTS



AGILE Process

ROLESProduct Owner

Scrum Master

SprintTeam

StakeholdersUsers


Sprint Planning

Daily Cycle

Sprint Review




Product Backlog

Sprint Backlog

Impediment List


Test Cases

Design Models


Prototype

AGILE - Sprint Artifacts

14

SPRINT ARTIFACTS

Product Backlog

Sprint Backlog

Impediment List

Test Cases

DesignModels

JIT RequirementsUse Case

Prototype

SPRINT ARTIFACTS



AGILE Process

ROLESProduct Owner

Scrum Master

SprintTeam

StakeholdersUsers


Sprint Planning

Daily Cycle

Sprint Review




Product Backlog

Sprint Backlog

Impediment List


Test Cases

Design Models


Prototype

Mindset Shift – Sprint Backlog

Day 1 Day 2 Day 3 Day 30

SPRINT-1 WHO?Hours of Effort

Remaining

---> 362 354 342 332

322

Story A

Task 1 RM 40 40 32 20 10

Task 2 JY 26 26 26 26 26

Task 3 SG 45 45 45 45 45

Task 4 MM 40 40 40 40 40

Task 5 RM 40 40 40 40 40

Task 6 JY 17 17 17 17 17

Task 7 JY 4 4 4 4 4

Task 8 RM 16 16 16 16 16

Task 9 SG 2 2 2 2 2

Story B

Task 1 RM 32 32 32 32 32

Task 2 RM 50 50 50 50 50

Task 3 JY 50 50 50 50 50

Tasks supporting

a story are defined

by the sprint team.

Tasks are

assigned to

sprint team

members

Remaining hours

are tracked to

show "burn-down"

progress.

Every day is

tracked through 30

business days;

scrums should

highlight tasks and

issues to be worked

for that day.

15

30 DAYS

24 HOURS

SCRUM - 15 min. Daily MeetingSprint Team discusses:A. What did you yesterday?B. What will you do today? C. Are their impediments in your way?

WorkingCode

SprintBacklogTasksexpanded by team

Sprint StoriesFeatures assigned to sprint

Product BacklogPrioritized product features desired by client

AGILE – Daily Scrum

16

AGILE - Roles

ROLES

Product Owner

Scrum Master

SprintTeam

StakeholdersUsers

17

SPRINT ARTIFACTS



AGILE Process

ROLESProduct Owner

Scrum Master

SprintTeam

StakeholdersUsers


Sprint Planning

Daily Cycle

Sprint Review




Product Backlog

Sprint Backlog

Impediment List


Test Cases

Design Models


Prototype

30 DAYS

24 HOURS

Sprint Backlog• Features assigned to

sprint• Estimated by team• Team Commitment

Product Backlog• Features

prioritized by client

Retrospective

Review

AGILE Process - Review & Retrospective

Sprint Retrospective• What worked?• What didn't work?• What are actions for improving

the next sprint?

18

Sprint Review• Demo / Sign-off – FEEDBACK• Review quality• Foster TRANSPARENT

communication

AGILE Metrics

Sprint Burn-Down Chart• Sprint Velocity (hrs / sprint)• # hrs / Story• # hrs Planned / Completed• # hrs Leading / Lagging / Remaining

Product Backlog Burn-Down• # Stories in Scope• # Stories / Sprint• Story Points / Sprint• # Stories Planned / Completed

SPRINT BURNDOWN CHART

0

200

400

600

800

1000

1200

1400

8/26

/09

8/28

/09

8/30

/09

9/1/

09

9/3/

09

9/5/

09

9/7/

09

9/9/

09

9/11

/09

9/13

/09

9/15

/09

9/17

/09

9/19

/09

9/21

/09

9/23

/09

9/25

/09

9/27

/09

9/29

/09

10/1/0

9

10/3/0

9

10/5/0

9

10/7/0

9

Ho

urs

Story Burn-Up

0

20

40

60

80

100

120

140

160

180

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sprints

Sto

ries

Completed Stories Projected Stories

Total Stories Defined Maximum Stories Allow ed

Story Burn-Up Chart• # Sprints Remaining• Total Stories Defined (Scope)• Max Stories Allowed (Budget)

Development Velocity

982 hrs / sprint

0

200

400

600

800

1000

1200

1400

1 2 3 4 5 6 7 8

Sprints

Velo

cit

y

Planned Speed Realized Speed Average Realized

Velocity• Ave. Velocity across Sprints• Planned vs. Actual Velocity

Story

ID

Story Name / Description

(BOLD = Major Deliverables) Status

Business

Priority

Story

Points

(Ideal

Days) Sprint

1 View Trades Planned A 15 1

2 View Orders by Name / Account Planned A.1 7 1

3 View Orders by Broker Planned A.2 3 1

4 View Orders by Symbol Planned A.3 2 1

5 View Orders by Product Planned A.4 3 1

19

Case Studies:

Successes

X Challenges

Recommendations

20

AGILE Realities

Case Study:

Background

• 1,200+ IT employees (infrastructure & software)

• Project types

– Business software development for branches / clients / HQ

– Regulatory

– Infrastructure (facilities, hardware, network)

• Matrix organization (project staffed by functional teams)

• Highly integrated web and legacy applications

• Began deploying Scrum-based Agile in 2009; waterfall methodology deeply engrained into culture

21

SPRINT BURNDOWN CHART

0

200

400

600

800

1000

1200

1400

8/26

/09

8/28

/09

8/30

/09

9/1/

09

9/3/

09

9/5/

09

9/7/

09

9/9/

09

9/11

/09

9/13

/09

9/15

/09

9/17

/09

9/19

/09

9/21

/09

9/23

/09

9/25

/09

9/27

/09

9/29

/09

10/1/0

9

10/3/0

9

10/5/0

9

10/7/0

9

Ho

urs

Critical point in which recovery

is no longer possible without

moving stories to next sprint

Projected

Actual

Max Possible

Target 22

Case Study: Edward Jones

Success: Developers are focused, efficient, and self-disciplined

Recommendation: Reinforce expectations that estimates

are NOT commitments

Week 1 Week 2 Week 4 Week 5 Week 6Week 3

Sprint

Start

Sprint

EndDefine stories

for next sprint.

Schedule

design

sessions.

Create design

deliverables for

next sprint.

Review / sign-

off on design

deliverables,

and acceptance

criteria for next

sprint

Create Sprint

Backlog for

next sprint.

23


X Challenge: PL workload is a planning roller coaster.

Recommendation: Plan, and stay true to, planning activities

Planning Design Development Verification Implementation

Unit Testing

Integration

Testing

Functional /

Performance

Testing

Release

Regression

Testing

Te

sti

ng

Eff

ort

Waterfall

Test Strategy

Iteration -1 Iteration 0 Construction

Sprint 2

Release

Sprint 1

Unit

Integration

Functional

Performance

Testing

Release

Regression

Testing

Te

sti

ng

Eff

ort

Agile

Sprint 1 Sprint 3 Sprint 4 Sprint 5

Test Strategy

Sprint 2

Unit

Integration

Functional

Performance

Testing

Sprint 3

Unit

Integration

Functional

Performance

Testing

Sprint 4

Unit

Integration

Functional

Performance

Testing

Sprint 5

Unit

Integration

Functional

Performance

Testing

24


Success: Final push to implementation is less "intense."

X Challenge: Agile testing cycles rely on stakeholder patience.

Recommendation: Set clear testing environment expectations

Story Burn-Up

0

20

40

60

80

100

120

140

160

180

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sprints

Sto

ries

Completed Stories Projected Stories

Total Stories Defined Maximum Stories Allow ed

Remaining

stories allowed

until project

budget is

depleted

# sprints

required to

meet current

story scope

25


Success: Stakeholders understand the impact of scope changes.

X Challenge: However, expectations must be set early and often.

Recommendation:

Sprint 7

Sprint 1

Deliverable #1

Sept Oct Nov Dec

2009

Jan

2010

Sprint 2 Sprint 3

Bundle

10.1

Deliverable #2

Feb Mar MayApril June

Deliverable #3Bundle

10.6

Bundle

10.4

July OctSeptAug

Bundle

10.2

Bundle

10.5

Nov

Pilot

Pilot

Pilot

GA

GA

GA

Value Assessment

Sprint 4 Sprint 5 Sprint 6

Bundle

10.3

Sprint 8 Sprint 9 Sprint 10

Dec

Sprint 3

Sprints

Sprint 7Sprint 6


X Challenge: 30 day production deliverables often do not fit

business model.

Recommendation: Clearly define a release strategy

26

AGILE Eligibility Criteria

I can commit resources that are focused on Agile development, and are available on-site (100% if needed) to communicate with sprint team members.

I accept scope NOT being guaranteed, as long as I know my most important priorities are being delivered first. I realize that the approved cost will be fixed; when exhausted, a new phase should be submitted for approval. I realize that lower priority work will be "left on the table".

I understand the importance of, and am ready to create, test cases to help drive out requirements, even before any code is written.

I'm comfortable working face-to-face and daily with developers to flush out requirements, knowing that new requirements will be addressed in a next sprint.

I understand the importance of the Product Backlog being the "Business" plan, and am committed to creating/updating this plan with all sprint team members on a daily basis.

I understand that vendor contracts must align with Agile development processes.27


X Challenge: Culture deeply entrenched in waterfall methodology;

clear criteria needed to cauterize an AGILE mindset.

Recommendation…

Case Study:

Background

• 5,000+ software engineers

• Wide range of project types

– Embedded flight software on aircraft

– Satellite software

– Aircraft training simulators

– Traditional web applications

• Legacy programs with millions of lines of existing code

• Software with safety critical certification requirements

• Every program has unique constraints and complications

• Deploying a customized Scrum-based Agile process

28

Case Study: Boeing

Successes

• Strong executive leadership support

• Dedicated group of experienced evangelist/champions

• Extensive support infrastructure– Training

– Coaching

– Outreach

• Synergistic, existing Lean initiative

• Rate of adoption by programs has exceeded expectations

• Adopting programs seeing significant improvements in productivity and quality (defect reduction)

29

Case Study: Boeing

X Challenges

• Every program has unique constraints.– Rare to have a pure, by-the-book Agile implementation

– Agile process must be adapted to work with program constraints (we use Lean principles to inform and guide these adaptations)

– This constrains the benefits achievable compared with a more ideal Agile team, but the benefits are still significant

• Finding cost-effective ways to train and coach multi-site, distributed teams.

• Finding effective ways to communicate our outreach message to such a large, physically dispersed enterprise.

• Implementing automated testing with legacy code bases.

30

Case Study: Boeing

Recommendations

• Don’t buy in to the conventional wisdom of which projects are appropriate for Agile and which are not.

• Agile can provide significant benefits in most situations if you can intelligently adapt to the project’s unique situation.

• The only real disqualifiers for Agile are all non-technical:– Someone on the team is actively opposed. Either get rid of them or

don’t use Agile – too easy to sabotage.

– The customer is opposed

– The contract does not allow any flexibility for incremental delivery

• For large organizations it is important to know and understand Lean principles.

31

Break-Out Session Closing

• Questions / Answers

• Thank You!

• 1-Page Take-Away Available

• "Agile Café" Roundtable (1-2:30pm)

32

Supporting Details

33

Incremental Development

Dividing the project into various independent parts and developing these sub-parts at the same/different rate and integrating them when ready. Specifically, staging and scheduling in increments!

Iterative Development

Multiple iterations help “iterate” toward a final solution.

Iteration 1: Build core registration function.

Iteration 2: Enhance the core registration function.

Iterative and Incremental Development

34

System Development Life Cycle

Initiation

Sponsor identifies a

need and defines

scope / benefits.

Design

Create system design

deliverables; focus on

how to deliver

required functionality.

Planning

Define requirements

that support scope

and develop project

management plan.

Development

Convert design into a

complete system;

install system

components into

testing environments;

prepare for testing.

Verification / Test

Test developed system

against requirements; fix

defects; prepare for

implementation.

Implementation

Implement system

into production

environment; resolve

problems.

Maintenance

Execution knowledge

transition; maintain

system in production;

conduct post-

implementation

reviews. What

Methodology?

35

Waterfall

Initiation


need and defines

scope / benefits.

Design

Create system design

deliverables; focus on

how to deliver

required functionality.

Planning

Define requirements

that support scope

and develop project

management plan.Development

Convert design into a

complete system;

install system

components into

testing environments;

prepare for testing.

Verification / Test

Test developed system

against requirements; fix

defects; prepare for

implementation.

Implementation

Implement system

into production

environment; resolve

problems.

Maintenance

Execution knowledge

transition; maintain

system in production;

conduct post-

implementation

reviews.36

Agile & IID

Initiation


need and defines

scope / benefits.

Design

Planning

Development

Verification / Test

Implementation

MaintenanceDesign

Planning

Development

Verification / Test

Implementation

Maintenance

Design

Planning

Development

Verification / Test

Implementation

MaintenanceDesign

Planning

Development

Verification / Test

Implementation

Maintenance

37

Inception Elaboration Construction Transition

I1 E1 E2 C1 C2 C3 T1 T2

Initiation

Planning

Design

Development

Testing

Implementa-tion

Maintenance

Iterative & Incremental (IID)

Time38

Agile

Time

Iteration -1 Iteration 0 Construction Release

Sprint 1 Sprint 2 Sprint 3 R1 R2

Planning

Design

Development

Testing

Implementation

Maintenance

Initiation

39

Dias nummer 1 - SIUEFlexible! AGILE First Impressions 3 × "Agile teams don't plan." × "Agile is a...

Documents

Transcript of Dias nummer 1 - SIUEFlexible! AGILE First Impressions 3 × "Agile teams don't plan." × "Agile is a...