The What , The Why , and The How of Agile / Iterative Development

SDM Team:
Michelle Tilley Manny Sullano Stephen Chueh

Objectives of AGILE AD
Agile

Drive faster time to market and more rapid realization of business value. Build a global delivery team that delivers solutions on-time, on-budget with quality. Enable business innovation through rapid ideation and prototyping, new technology solutions, and leading-edge solutions. Target energy to the creation of value for our customers and focus on elimination of waste. A culture that rewards people to deliver, create and innovate together.

Global

Innovative

Lean

Empowered
Agile Development Simulation 2 5/25/2011

The Agile Manifesto

Reference: http://agilemanifesto.org/
Agile Development Simulation 3 5/25/2011

Agile Practices
Product Owner Product Owner
$$$

Collocation Collocation

Backlog Backlog

Continuous Continuous Integration Integration

Refactoring Refactoring

Short Iterations Short Iterations

Daily Standup Daily Standup

User Stories User Stories

As a <persona> As a <persona> II want want <behavior> <behavior>

One Piece Flow One Piece Flow

Whole Teams Whole Teams

Iteration Review Iteration Review

Unit Tests Unit Tests

Retrospectives Retrospectives

?
Agile Development Simulation 4

The List goes on

Source: Damon Poole (dpoole@accurev.com) 5/25/2011

Unified Process + Agile Practices

USDM Process Kernel
Whole Teams Whole Teams

s es in us B

s is k R s isk lR n ti o cu xe E sk Ri s ks

Backlog Backlog

c Te
Continuous Continuous Integration Integration

a nic h

Measurement Measurement

Ro

is tR u llo

Agile Practice Plug-Ins

Agile Development Simulation

5/25/2011

An Agile Approach steadily advances the solution in small but deliberate steps

Iterative project profile

Traditional project profile

Agile Development Simulation

5/25/2011

Risk and Progress Trends on an Agile Project

LCO LCA IOC

Requirements Verified

High

100%

Total Risk Exposure

Low

Project Schedule / Iterations Improve Predictability Increase Effectiveness over Time Improve Quality Deliver Business Value More Predictably

Agile Development Simulation

(Dotted Line) 0%
5/25/2011

(Red Line)

Iterative vs. Waterfall

Goal-directed Deliver maximum value within time and expense budget Adapt and steer Exact path is not 100% predictable Plan in short increments Weeks not months or years Revisit and refine every iteration Adjust plans based on Progress and Risk Results-oriented Progress measured by successfully tested scenarios, not task completion
Agile Development Simulation 8

versus

5/25/2011

Why is Iteration Useful?

Shows partial results faster, building support for the solution Through real demonstration of progress Customers actually see something of value sooner Improves the probability of success Through an explicit focus on reducing risks early in the project Provides accurate feedback on progress Through working software Motivates the team Through real achievement Makes planning easier and more accurate By not trying to plan the entire project all at once

Agile Development Simulation

5/25/2011

The Backlog
Backlog (n): an accumulation of tasks unperformed or materials not processed Composed of: Requirements (e.g., use case scenarios, supplementary requirements) Change requests Defects Refactoring work Regression tests User documentation Training material Tasks (only in iteration backlog)

Agile Development Simulation

10

5/25/2011

Establishing the Project Backlog

Define Backlog Items

Agree to Backlog Item Business Priority Estimate Backlog Item Effort Assess Backlog Item Risk Establish Prioritized Project Backlog

+ Priority + Effort + Risk (Project) Backlog

+ Order

Agile Development Simulation

11

5/25/2011

Step 1:Define Backlog Items

BF of UC1 Create booking UC1: Manage Booking(s) Basic Flow Create Booking 1. AF1 of UC1 For existing Cust AF2 of UC1 View booking 2. 3. 4. Authentication Choose to create a booking Select adventure type Select the specific adventure based on the selected adventure type ..

Supplementary Specification SUPL1 Availability The system will be available 24 x 7 with the exception of the regular maintenance time of Sunday, 8:00pm to 11:30pm EST. SUPL 2 Throughput The system should handle 1000 transactions per hour (200 create/update transactions, 800 read transactions) SUPL 3 Capacity The system should handle 100 concurrent users with an expected 1000 daily users. SUPL 4 Response Time All screens will respond to user requests in under 5 seconds.

5.

AF1 Create Booking for Existing Customer AF2 View Booking(s) AF3 Update Booking UC2: View Booking(s) Basic Flow View Booking 1. Authentication Display Booking Detail 2.

AF3 of UC1 Update booking

BF of UC2 Cust view booking

. . .

AF1 Authentication Fails AF2 Data Unavailable

Agile Development Simulation

12

5/25/2011

Step 2: Establish Business Priority

BF of UC1 BF of UC1 Create booking Create booking

MoSCoW
Must Should Could Want (wont)

M
AF1 of UC1 For existing Cust S AF2 of UC1 View booking

M
AF3 of UC1 Update booking

M
BF of UC2 Cust Cust view booking S

Business Partner
Jan 6, 2011 Agile Development Simulation 13 5/25/2011

Step 3: Estimating Effort

BF of UC1 Create booking

Must
AF2 of UC1

20

View booking

8 20
5

Must
AF3 of UC1

Update booking

Must

13 20

13 20

Planning Poker is a way to build consensus. It allows, or forces people to voice their opinions, thoughts and concerns.

BF of UC2 Cust view booking

Should

40 20 20

20

AF1 of UC1 For existing Cust

Should

Free online tool: http://planningpoker.com/

Agile Development Simulation 14 5/25/2011

Step 4: Associate Risks with Backlog Items

Risk Score R1 1000 concurrent user R2 Response time < 3 sec R3 integrate w/ legacy R4

10
BF of UC1 Create booking

100

10

50

10

10

50

25

5 Impact

Probability

Must
AF3 of UC1

20

Update booking

Must
AF2 of UC1 View booking

Must
AF1 of UC1 For existing Cust

Should

BF of UC2 Cust view booking

Should

Agile Development Simulation

15

5/25/2011

Establish Prioritized Project Backlog

Risk Score R1 1000 concurrent user R2 Response time < 3 sec R3 integrate w/ legacy R4

10
BF of UC1 Create booking

100

10

50

10

10

50

25

5 Impact

Probability

Must
AF3 of UC1

20

BF of UC1 AF2 of UC1

1st iteration of Elaboration

Update booking

Must
AF2 of UC1 View booking

Must
AF1 of UC1 For existing Cust

Should

BF of UC2 Cust view booking

Should

Agile Development Simulation

16

5/25/2011

Business-Driven or Risk-Driven? Both!

The backlog is prioritized based on a combination of business priority and risk mitigation
Quick Wins Tough but Necessary

Business Value

Low Priority Risk

Agile Development Simulation 17

Why bother?

5/25/2011

Iteration Backlog
BF of UC1 Browse Products Must 20 Detail Requirements 2 hours

Design Interfaces 4 hours

Write Test Cases 2 hours

?? hours

Agile Development Simulation

18

5/25/2011

Execute 1st Elaboration Iteration

Project Backlog
BF of UC1 Create booking

Iteration Backlog

Tasks
Detail Requirements 2 hours Design Interfaces 4 hours Write Test Cases

Completed Tasks

Done

Must
AF2 of UC1 View booking

20

Must
AF3 of UC1 Update booking

2 hours
. . .

Tasks involved in implementing BF of UC1

Execute Test Cases 2 hours Detail Requirements 2 hours Design Interfaces 4 hours Write Test Cases 2 hours
. . .

Must

AF1 of UC1 For existing Cust

Should

BF of UC2 Cust view booking

Tasks involved in implementing AF2 of UC1

Should

5
2 hours

Execute Test Cases

Agile Development Simulation

19

5/25/2011

Summary: Agile / Iterative Development

Tasks in Progress Tasks Blocked

Project Backlog New work items are prioritized estimated and added to the stack. Work items can be re-prioritized or removed at any time. High priority items should be welldefined

Tasks to Do

Burn down / up chart

Completed Tasks

Project Backlog Highest priority items form objectives for the iteration

Iteration Backlog

4-6 Weeks Iteration

Working Software

Tasks are defined (from the selected project backlog items) and prioritized to be undertaken during the iteration
5/25/2011

Agile Development Simulation

20

Assessing: Three Simple Measures

These measures provide the means for project teams to understand: Where they are relative to where they need to be When they are in trouble Where they should be focusing their attention The measures are simple enough that any team can capture them with minimal effort
X X X X X X X
5/25/2011

Risk

Progress

X X

X X X X

Quality
X X X

X X X

Perhaps more importantly, the measures provide an objective view of project status

Agile Development Simulation

21

Extra Slides

10/19/2010 Agile Development Simulation

22

5/25/2011

Agile what?
1. marked by ready ability to move with quick easy grace 2. having a quick resourceful and adaptable character -- Webster dictionary pment software develo group of nd ment refers to a requirements a evelop d nt, where Agile software tive developme on itera anizing dologies based etween self-org metho ration b through collabo e solutions evolv s. -functional team cross -- Wikipedia Agile Software Development A team-oriented, iterative approach to software development that: Relies on skilled people working in collaboration Relies on accountability and transparency Relies on iteratively developing working software Enables teams to adapt and respond to change more quickly Is dependent on active customer participation -- Kurt Bittner, Ivar Jacobson International (IJI)
Agile Development Simulation 23 5/25/2011

Unified Process Lifecycle

Origination
Proposal is approved as a project

Inception
Iteration *
1.2....n

Elaboration
Iteration *
1.2....n

Construction
Iteration *
1.2....3.n

Transition
Iteration *
1..n

GATE A

GATE B

GATE C

GATE D

GATE E

* The number of iterations depicted above is for illustrative purposes only, the actual number will vary by project size and complexity

Inception
Project Viability Agreed Business Risk Mitigated
Definition and prototype of vision and business case Scope understood primarily thru business scenarios (Use Case Model) Candidate Architecture identified viable solution understood Credible Plan Understood Team formed and working Business approves plan & candidate architecture

Elaboration
Project Approach Proven Architectural Risk Mitigated
Synthesis, demonstration, and assessment of architectural baseline

Construction
Useable Solution Available Execution Risk Mitigated
Development, demonstration, and assessment of useful increments

Transition
Release Successfully Rollout Risk Mitigated
Usability assessment, production deployment Solution is deployed and business implemented Business customer is happy User Community is happy Production Support is happy

All Use Case Scenarios are Architecturally significant Use executable and tested Case Scenarios are executable and tested Plan is executed Executable Architecture proven Expanded Team is working (skinny system available) effectively Plan is refined Business likes what it sees as scenarios are demonstrated Team is working effectively Business likes what it sees as executable scenarios are demonstrated

Agile Development Simulation

24

5/25/2011

Enablers of Agile / Iterative Development

Dev / QA Environment Readiness Shared-Service Engagement Model Dedicated Cross-Functional Team Empowered Business Partners
Whole Teams Whole Teams

Work queue Working Software - Min (WIP), Max (Throughput) Just-enough, Just-in-time requirements Prioritize (Effort, Risk, Value)
Backlog Backlog

Global Optimization vs. Local Optimization Automation

Continuous Continuous Integration Integration Measurement Measurement

How to Divide and Conquer Right Metrics Drive Right Behavior

Configuration Management Automatic Test Frequent Automated Build

Risk Progress Quality

Agile Development Simulation

25

5/25/2011

Traditional versus Agile Lifecycles

Traditional Progress measured by completed activities
Primarily schedule driven Encourages separation of silos Information about project status based on adherence to schedule Milestones focus on production of documents and artifacts

Agile Progress measured by completed and tested scenarios

Primarily risk-driven Encourages collaboration across silos Information about project status based on working software Milestones focus on assessing progress and risk mitigation

Agile Development Simulation

26

5/25/2011

Phase and Iteration Patterns in Development Plans

1. Evolutionary - Lots of technical challenges
Resources
Conceptual Prototype Architectural Release Baseline Delivery LCO and LCA Passed

2. Immediate Construction - low technical challenge, but a lot to do

Resources
First Release Delivery

Inception

Elaboration

Constn

Transition

Time

Construction

Transition

Time

3. Incremental some technical challenges

Resources
Conceptual Architectural Prototype Baseline Release Delivery

4. Incremental delivery - need for fast time to market, but low technical challenge
Resources
Conceptual Architectural Delivery Prototype Baseline Delivery Delivery Delivery Delivery Delivery

Inception Elaboration

Construction

Transition

Time

Inception Elaboration Constn

Transition

Time

The choice of Phases and Iterations reflects risk mitigation strategies

Agile Development Simulation 27 5/25/2011

Iterative vs. Waterfall Things are not always what they seem, we all make mistakes in our execution
Environmental noises, imperfect communication Lack of full knowledge and foreknowledge Dealing with moving target

Iterative
Spend less time on wrong paths Learn from previous experience

Start

Finish

Reference: Joe Marasco, IBM developerWorks

Agile Development Simulation 28 5/25/2011