Introduction to Agile

Steve Young CVO PMO Technology Manager

Some problems are just hard, some people are just difficult.
These methods are not salvation.
- Craig Larman, Agile & Iterative Development, 2004

Takeuchi and Nonaka

Harvard Business Review - Analysis of the 10 most competitive and

innovative companies in the world

Built in instability

Team members are given the freedom to do research and creativity but at the same
time expected to produce to high standards.

Self-organizing project teams

Teams take on self organizing character where prior knowledge does not apply
Left to stew the process creates a dynamic order where team creates it own agenda,
takes risks and creates new concepts

Overlapping development phases

Multi-learning

Teams stay close to outside sources of information

Across both dimensions (individual/group and function)

Subtle control

Enhances cooperation, involvement, problem solving, initiative taking, diversifies skills

Select team members and balance team

Create open work environment
Encourage constant communication with customer
Establishing evaluation and reward system based upon group performance
Tolerating and anticipating mistakes

Transfer of learning

Seed new teams with experienced members

What Makes a Project Successful?

10 year study by the Standish Group. The Standish Group has boiled
down their research to the following list of factors that make software projects
successful. The factors, from their year 2000 study, are listed in order of
importance:
1. Executive Management Support (18)
2. Users Directly Involved (16)
3. Experienced Project Managers (14)
4. Clear Business Objectives (12)
5. Small Milestones (10)
6. Standard Software Infrastructure (8)
7. Firm Basic Requirements (6)
8. Formal Methodology (6)
9. Reliable Estimates (5)
10. Other (5)

Overview

Agile
Agile
Agile
Agile
Agile

Impetus
Background
Principles
Methods
Balance

Why should we care?

When did it all get Started?
What are they thinking?
How do we use it?
What about discipline?

Agile Impetus

People are more important than any process. Good people with a good
process will outperform good people with no process every time.
- Grady Booch Object Solutions: Managing The Object Oriented
Project, 1996
I found no interesting correlation in the projects that I studied among
process, language or tools and process success. A well functioning team
of adequate people will complete a project almost regardless of process
or technology theyre asked to use.
- Alistair Cockburn Agile Software Development, 2002

Software Development Paradigm

Industry average project rate of change: 30%

Each software project is typified by:

Newly assembled project team

Exact product has not been built by the assembled team
Incomplete statistics on schedule, cost and quality
Can only estimate the list of tasks to create the software
Changes to scope, features, design, materials and team
members should be expected

A more appropriate model for software development is often:

New Product Development

Response to Change

Loading the Boat vs. Packing Light

Predicatively planned projects typically waste time on unneeded
scope.
1998 study by The Standish Group:
45% of features built are never used
19% are rarely used
16% are sometimes used
13% are used often

Discussion

Predictive vs. Adaptive

Game of Chess
Command and Control vs. Empowered Teams

Walk to your car

ASD Background
When did it all get started?

Ours is too great and too complex a nation

for even such as I to direct and lead every
action.
- Attila the Hun

Adaptive/Predictive Scale

Agile Software Development Manifesto

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.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler

James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

http://www.agilemanifesto.org/

Key Principles

Harness change vs. Fight change

Start with teams of motivated people
Continuous open communication
Empowered teams over Command-and-control
Time-boxed iterations in weeks
Strive for sustainable pace

Deliver working software early and often.

What Agile Feels Like

Committed to DONE software early and often.

People help each other and interact face-to-face.
People dont wait a day to communicate.
Team members know to give and take.
Team members remove roadblocks that others cant or wont.
Non-team members help remove roadblocks, and avoid becoming
roadblocks.
Team members willing to wear multiple hats.
Team members pull their weight.
Team members help each other learn to pull more weight.
I know and trust that we are doing what will best move the project forward
today.

ASD Methods
How Do We Use Them?

Luck is the place where opportunity and preparation

meet.

Agile Methods

Face-to-Face Communication
Regular User/Customer Feedback
Time boxing
Daily Team Checkpoint
Deliver Highest Value First
Deliver Working Software, Early & Often

Agile Methods

Just-in-Time Stories
Relative Estimation & Story Points
Measure Velocity
Team Empowerment
Parallel Development and Testing
Daily Builds, Frequent Integration
Empirical Method (Iterate, Inspect, Adapt)

ASD Criteria
When is it right for us?

I have not failed. Ive just found 10,000 ways that wont
work.
- Thomas Edison

A Case for Predictive/Waterfall Methods

Projects/Organizations that should look to Predictive:

Loss-of-Life critical projects (FDA, some military)

Extremely low tolerance for variances
CMM 4+ organizations
ISO9000+ orgs., invested in predictive process
SOX orgs., invested in predictive process

Rigid SLDC Potential Results

Project manger: I did what the methodology said. The

developers must not have done what the methodology told
them to. Maybe they didnt report their accuracy properly.
Maybe they didnt follow the methodologies directions. They
had failed to complete a well described process that a
methodology vendor had told me would lead to predictable
results. Those developers are to blame!!!

A Case for Agile

Organizations that need ASD may:

Need to get something released early

Does not value comprehensive up-front planning
Need an on-site team to work-out-the-design
Need to implement a package, with high-user touch
Largest project risk identified as time duration or complexity
Attempting to utilize new or unproven tools
Need fixed budget, but willing to flex on scope

Risk Reduction

Risk of not pleasing the customer

Customers see product on a regular basis

Risk of not completing all functionality

Develop functionality in a prioritized manor

Risk of poor estimating and planning

Provide small estimates that are tracked daily

Scrum tolerates that not all goals may be completed
Allows Mgmt to be involved and adjusts in planning and review

Risk of not resolving issues promptly

Puts the burden of proof on Management.

Management reports back to the team on road block resolution

Risk of not being able to complete development cycle

Delivers working software every sprint

Irons out testing, release management by forcing working release
Even if impeded by these issues the team addresses them and adjusts

Risk of taking too much work and changing expectations

Disallows changes to the Sprint backlog

Agile Balance

Agility and Discipline are not mutually exclusive

Agile project can have elements of deep discipline
The key is as needed or just enough

Deeply disciplined projects are sometimes necessary

Loss-of-Life critical projects (FDA, some military)
Extremely low tolerance for variances

Break

Scrum Essentials Overview

Scrum
Scrum
Scrum
Scrum
Scrum

Overview
Planning
Roles
Artifacts
Meetings

How does it all work?

How do we plan the project?
Whos responsible?
What documents are needed?
What meetings drive Scrum?

Scrum Overview

Developed in 1993
Scrum is one of several Agile Methodologies
Scrum is part of the Agile Alliance
Has been used on thousands of projects
Used internally by various Microsoft teams
Can manage projects of 2 - 3000 team members

Scrum Cycles

Program

2-n months

Project

2-n months

Release
2-6 months

Sprint
30 days

Daily Scrum
daily

Project Success Declines Over Time

This graph indicates the sharp decline in project success the longer a
project runs without shipping a release.
1-6 months seems to be the sweet spot.

Working vs. Released Software

Sprint 1
(Normal)

Sprint 2
(Normal)

Sprint 3
(Normal)

Sprint 4
(Release)

Sprint 5
(Normal)

Sprint 6
(Release)

Sprint 7
(Normal)

Sprint 8
(Release)

During normal sprints, working software is DONE but might not be

released.
During release sprints, working software is deployed.

Scrum Planning

A Scrum project is planned up front & as we go.

Up front?

Set expectations based on initial scope.

Develop a prioritized product backlog.
Assign order of magnitude estimates. (+75%/-25%)
Define desired timing for production releases.
Estimate resources needed.
Estimate sprint count

As we go!
At the start of each sprint, plan 30 days of scope.
Refine estimates, priorities and product backlog.

Scrum Roles

Product Owner

Establish vision
Set Sprint Goals
Set Priorities
Owns the Product Backlog

ScrumMaster

Teach / Coach Scrum

Manage Process
Protect Team
Enforce Rules
Remove Blocks
Facilitate Meetings

Stakeholder

Team

Observe
Advise

Organize work
Develop product
Communicate issues & progress

Scrum Artifacts

Product Backlog

Sprint Backlog

List of requirements
Owned by Product Owner
Anybody can add to it
Prioritized by business value
Can change without affecting the
active Sprint

Decomposed task list

Driven by a portion of Product
Backlog
Owned by Team
Only Team modifies it

Sprint Goal

Blocks List

One sentence summary

Defined by Product Owner
Accepted by Team

Increment

List of blocks & pending decisions

Owned by ScrumMaster
Blocks stay on list until resolved

Version of the product

Potentially shippable
Working functionality
Tested & documented according
to project definition of DONE

The Planning Cycle

Product Backlog Q&A

How is the product backlog managed?

When can the Product Backlog change?
Does the Product Backlog ever contain items other than
product features?
Do changes to the Product Backlog affect scope?

Sprint Backlog Q&A

When is the Sprint Backlog created?

How is the Sprint Backlog different from the Product Backlog?
How does the team know enough on day 1 of the Sprint to
accurately estimate tasks in the Sprint Backlog?
Can the Team add items to the Sprint Backlog during the Sprint?
Who assigns team members to tasks?
How detailed must Sprint Backlog items be?

Sample Product Backlog

Scope list
Prioritized by business
value
A, B, C feature
distinction
Rough estimates help
size the sprints

Sample Sprint Backlog

Granular tasks
(2-16 hours each)

Assigned to team members

Estimates adjusted daily

by team

Managed by the team

Sample Burndown Chart

Provides candid transparency

Printed daily
Posted publicly
May be bumpy

Scrum Meetings

Sprint Planning - A

Daily Scrum

Time-boxed: < 4 hours

Run by ScrumMaster
Declare Sprint Goal
Top of Product Backlog presented by
P.O.
Team asks questions & selects topmost
features

Sprint Planning - B

Time-boxed: < 4 hours

Run by ScrumMaster
Team decomposes features into a
Sprint Backlog
Team adjusts +/- features by task
estimates against sprint capacity

Sprint Review

Time-boxed: < 4 hours

Run by ScrumMaster
Attended by all
Team demonstrates increment
All discuss

Time-boxed: < 15 minutes

Run by ScrumMaster
Attended by all
Stakeholders do not speak
Same time/place daily
Answer 3 questions:
1) What I did yesterday
2) What Ill do today
3) Whats in my way
Sprint Backlog updated
ScrumMaster updates blocks

Sprint Retrospective

Time-boxed: 1-2 hours

Run by ScrumMaster
Attended by Team and P.O.
Discuss process improvements, wins
and losses
Adjust process

Scrum on a Page

Typical Sprint Calendar

Sprint Vision
Sprint Backlog

What did you do yesterday?

What are you going to do today?
Do you have any blocks?

Product Demo

What worked/didnt
How can next
sprint improve

Scrum Meeting Q&A

Who leads the Sprint Planning meeting?

What happens at the Sprint Review?
Who Leads the Daily SCRUM calls?

How do we get started?

1. Identify Product Owner

2. Identify Scrum Master
3. Develop a Product Backlog
4. Work with Product Owner to prioritize Product Backlog
5. Develop a vision for the first sprint
6. Schedule Sprint planning meeting with team to develop sprint backlog
7. Schedule daily scrums same time each day
8. Team should burn down hours daily
9. Schedule mini-sprint review sprint backlog reality check
10. Schedule Sprint review with Product Owner at end of Sprint
11. Schedule Sprint retrospective with entire team
12. Begin again at step 4

Further Reading

Agile Software Development with Scrum

2002, Prentice Hall, Ken Schwaber, Mike Beedle.
(#1 read for anyone serious about Scrum)

Agile Project Management with Scrum

2004, Microsoft Press, Ken Schwaber.
(A bit more fluffy, but has a lot of case studies)

Agile & Iterative Development

2004, Pearson Education, Craig Larman.
(#1 read to introduce and compare Agile methods)

Agile Software Development

2002, Pearson Education, Alistair Cockburn .
(Provides the science and the whys of Agile methods)

Agile Estimating and Planning

Agile Estimating and Planning

Release Planning Overview

Defining Constraints
Build a Product Backlog
Scoping and Prioritization Techniques
Estimation Techniques
Pulling It All Together

Release Planning Overview

Seven Steps to creating a Release Plan

1. Clarify Project Objectives (ATAM Architecture Tradeoff
Analysis)
2. Define Project Constraint Profile
3. Develop a Product Backlog
4. Estimate the User Stories
5. Recommend Team Size/Structure
6. Estimate Team Velocity
7. Identify Sprint Themes and Release Sprints

Constraints

Time
Schedule

Resources
Budget
Human Resources
Infrastructure

Performance

Scope
Quality
User Acceptance / Customer Satisfaction
Maintainability / Architecture

Constraint Considerations

Constraint #1: Time

As we wait to deliver value, cost and risk rise.

Product quality does not always improve with time.
Use time-boxing to control the Time Constraint.

Constraint #2: Resources (Cost)

Increasing team size has an affect on value & performance.

Tools can have a profound effect on performance (+/-).
Investment in process will affect performance (+/-).

Constraint #3: Performance

Defining clear project success criteria is critical.

Consider team dynamics, political stewardship, continuous process
improvement.

Develop Product Backlog

Gather User Stories:

User interviews
Questionnaires (not usually a primary technique)
Observation
Story-Writing workshops

User Stories

What User Stories are not:

Requirements
User stories arent IEEE 830
4.6) The system shall allow a company to pay for books with a credit
card.
4.6.1) The system shall accept Visa, MasterCard and American
Express cards.
4.6.2) The system shall charge the credit card before the books are
shipped.
4.6.3) The system shall give the user a unique confirmation number.

User stories are not use cases

Develop Product Backlog

User Story What is it!

User stories describe functionality that will be valuable to either a
user or purchaser of software.
User stories are composed of three aspects:
Description
Conversation
Tests

Develop Product Backlog

Why change from requirements to user stories?

User stories emphasize verbal rather than written
communication
User stories are comprehensible by both customers and
developers
User stories are the right size for planning
User stories work with adaptive development
User stories encourage deferring detail
User stories support opportunistic development
User stories encourage participatory design
User stories build up tacit knowledge

Build a Product Backlog

Story
As a <role> I want <ability> so that <benefit>.
Description
Conditions of Acceptance

Scoping & Prioritization Techniques

Scoping & Prioritization Techniques

Set Stakeholder Expectations

Variable scope requires controls.

Scope must be prioritized by the business.
Defining scope that breaks Time + Cost constraints will have
consequence.
They will be asked to specify a priority for each feature:
A = Must Have
B = High Value
C = Nice to Have (or Future Consideration)

Incorporate scope priorities into product backlog and release

plans.

Consequence of Priority

If the project has too many A features:

Might not be able to deliver value incrementally.
May run out of resources before delivering value.
Team might not know what to work on first.

Stakeholders should understand that:

All A features must be delivered
As many B features will be delivered as possible
C features are unlikely to surface other than as design
considerations.

Estimation Techniques

Estimation Techniques

Tangible Estimates

You have been assigned potato peeling duty

You have 20 baskets of potatoes to peel
The baskets are of different size
How long will it take?

Tangible Estimates

Look at the baskets and estimate how many potatoes.

After one hour, see how many potatoes youve peeled.
Estimate the remaining schedule.

Relative Estimating Exercise

Form Small Teams (5-7 ea.)

Use Estimation Poker to assign dog points to:

St. Bernard
Great Dane
Dachshund
Terrier
German Shepherd
Poodle
Bull Dog
Labrador Retriever

Relative Estimating Advantages

Story Points
Forces the use of relative estimating
Studies have shown that we are better at this

Focuses us on estimating the size, not duration

We derive duration empirically by seeing how much we complete
per iteration

Puts estimates in units that we can add together

Relative estimates do not decay

Pulling It All Together

Pulling It All Together

Document the Release Plan

Seven Steps to creating a Release Plan

1) Project Objectives (in P.B. doc)
2) Define Project Constraint Profile (see sample)
3) Develop a Product Backlog (in P.B. doc)
4) Estimate the User Stories (in P.B. doc)
5) Recommend Team Size/Structure (in P.B. doc)
6) Estimate & Measure Team Velocity (in P.B. doc)
7) Identify Sprint Themes and Release Sprints
(in P.B. doc)

Review

Release Planning Overview

Defining Constraints
Build a Product Backlog
Scoping & Prioritization Techniques
Estimation Techniques
Pulling It All Together

Agile Engineering Practices

Presented by Steve Young CVO PMO Technology Manager

Common Challenges w/ Emergent Processes

Highly detailed requirements are not gathered ahead of time

Instead we gather business centric User Stories
Important to be well worded and defined

Defined Conditions of Acceptance

COAs should be (and will be) refined along the way

Testing must happen early and often, not at the end

Slightly blurred roles (BA, Developer, QA)
Many meetings require multiple role involvement for successful understanding of the expected results

Product Owner/Business involvement is essential

Many small meetings are required through-out to mature the story and design as well as confirm the conditions of
acceptance.

Process + Engineering = Successful SCRUM

Key Agile Process Practices that Promote Good Engineering

Design Reviews
Test Case Reviews
Code Reviews

Engineering Prerequisites
Proper System Architecture / Hardware Environments
Application Lifecycle Management (ALM) Tools
Team Foundation Server

Key Agile Engineering Practices

Continuous Integration (Automated Builds)
Test Driven Development (TDD)
Functional Testing Automation
Expedites Regression Testing

Physical Architecture/Environment

Development and Integration

Dev

Staging

Build Process
Release

Dev

ALM
Tool

Integratio
n

(TFS)

Dev

Production

Option
al QA

Release

Staging

Productio
n

Tools for Agility

Test Driven Development

Testing debt is a threat to all Agile projects. This can be mitigated by adopting TDD practices.

Continuous Integration & Daily Deployment

Instills Discipline
Constantly Reports Health
Promotes an Ensures Quality
Automates Documentation
Consistent Deployment
Requires Less Manual CM Resource

73

Automated Functional Testing

Risk can be further mitigated by automating the functional testing as

well

Greatly reduce time to regression test previous functionality

Eliminate many human errors and oversights
Speed up delivery to environments
Some Popular Testing Tools (please consult SPARK-ITS guidelines)

HP Quality Center / QuickTest Pro (Formally Mercury)

Selenium (Open Source)
Rational Robot (IBM)
TestComplete (AutomatedQA)
Visual Studio for Test (Microsoft)

Preparation and Commitment Required

Minimum Recommended Requirements

1 - Agile experienced Scrum Master

1 - Agile experienced Lead Developer
Engaged Product Owner w/Business Support
Good Development Environments
Strong Engineering Practices
COMMITMENT and DISCIPLINE to all processes
Do not be tempted to modify the process until you have mastered
the basics

Side Effects

Applying good processes and discipline creates team spirit

Team spirit breeds accountability for success
Disciplined teams require less management
Good engineering practices set teams up for success.
Business involvement creates pride of ownership and responsibility
outside of the project team
Constant communication provides accurate delivery on expectations

CVO Development Tools

Visual Studio
Team Foundation Server
SharePoint
Rhino Mocks
Selenium

Questions

Questions?

The Nature of SCRUM

SCRUM is more human than other methodologies

It promotes team synergy through knowledge exchange and
constant interaction
It facilitates involvement and therefore ownership from developers,
management and the business as a whole.

Why do we need to have to have all these meetings?

Scrum meetings do much more for a team than just capturing

information. They dont only make everyone capture what they did,
but it makes everyone say it in front of everyone else. That way
everyone listens to what others are doing and they can offer help to
them later. They dont only make everyone say what the issues are,
but it makes everyone say it face to face with their management.
This encourages everyone to have courage and be honest, and gives
everyone a tool to put pressure on management about resolving
issues. It makes everyone promise in front of everyone else what
you will be working on next, so it puts everyones credibility and
trust to the test. Scrum is about deep social interactions that build
trust among team members Ken Schwaber

About Agile (SCRUM)

Agile is an Empirical Process

based upon observation or experience (meetings) ; capable of
being verified or disproved by observation (demo) or experiment
(test)
In Agile, complex processes are controlled by frequent
inspection and adaptive response

Noise
Unpredictable behavior that obscures focus and results
Is everywhere

SCRUM expects every process to be unexpected