08 AgileLegacy Keynote Slides

Legacy of Agile
Software Development
2007 Construx Software Builders, Inc.
All Rights Reserved.
www.construx.com
Why Agile?
Basic Motivations
Developers
want less overhead and less

distractionspending more time doing
the real work of the project
Clients want more flexibility to correct
mistakes after the project is underway
Bottom line: for certain kinds of
software, traditional development
practices were not getting the job done
Software Development Best Practices
Value Delivery on a Traditional (Sequential)

Development Project
Value /
Functionality
Cost
Time
Waterfall Value Delivery
Value Delivery on an Incremental

Development ProjectInitial View
Value /
Functionality
Cost
Time
Iterative Value Delivery
Value Delivery on an Iterative (Agile)

Development ProjectPrioritized Iterations
Value /
Functionality
Cost
Time
Diminishing returns when functionality is
delivered in priority order
Value Delivery on an Iterative (Agile)

Development ProjectPrioritized Iterations
Value /
Functionality
Value /
Functionality
Cost
Time
Diminishing returns when functionality is
delivered in priority order
Summary of Agile Value

Methods support responding to change
creating opportunities to incorporate change
Delivers business value earlier in the
development cycle
Option to cancel at any time yet still deliver
value
Incorporate more timely feedback from the
customer
Provide better visibility to the customer
Especially useful when schedule and
resources are fixed, and mission is to provide
maximum business value within those
constraints
What, Specifically, is
Agile?
Origins of Agile
Agile Manifesto (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.
10
Common Agile Methods
Evo (Tom Gilb)

DSDM (DSDM Consortium)
Extreme Programming (Kent Beck)
Rational Unified Process (IBM/Rational)
Scrum (Ken Schwaber)
Adaptive Software Development (Jim Highsmith)
Crystal Clear (Alistair Cockburn)
Feature Driven Development (Jeff De Luca, Stephen
Palmer)
Lean (Ron Mascitelli/Mary Poppendieck)
Many additional variations are emerging (IXP, XP2,
etc.)
11
What, Specifically, is Agile?

(circa 2001)
Non-Waterfall
Non-CMM
Lightweight
Little
or no documentation
Few or no requirements up front
Code-focused
12
What, Specifically, is Agile Today?

(This is not your fathers Agile!)
Non-Waterfall
Always incremental
Usually iterative (non-sequential)
Primary focus on flexibility
Reduced emphasis on long-range
predictability of featuresespecially of the
combination of cost, schedule, and features
Specific "Families of Practices
Incremental and iterative practices

More code-focused than document-focused
Minimal up-front requirements work
Modern practices that work!

13
The Most Fundamental

Contribution of Agile:
Different Lifecycles
Activities & Phases

Software
development consists of wellidentified activities:

Requirements
Architectural design
Detailed design
Construction
Developer test/integration test
System Test
These
activities may or may not be

performed in phases
15
Lifecycle Modeling
How the activities are sequenced and
partitioned makes up the lifecycle
The lifecycle model is the dominant attribute
of any method, whether Agile or traditional
Most variation among development
approaches can be explained by variation in
the lifecycle models
Additional variation can be explained by
specific techniques favored by different
methods
16
The Two End Points:

100% Sequential vs. 100% Iterative
100% Sequential (e.g., Waterfall Development)
100%
100%
100%
100%
Requirements
Architecture
Construction
System
Test
100% Iterative (e.g., Extreme Programming)
17
The Most Significant Differences Among

Development Methods
1.
2.
3.
4.
The most significant variations among

methods can be explained in terms of
balance between work done up front and the
number of iterations
Percent of requirements done up front vs. in
each iteration
Percent of design done up front vs. in each
iteration (partially dependent on #1)
Number of iterations
Percent of testing done in each iteration vs.
at end of project
18
Common Lifecycle Features of All

Credible Methodologies
In-phase
defect removal goal is always
100%
Wide variety of techniques are used in
pursuit of the goal
Effectiveness of the techniques used to
accomplish the defect-removal goal
varies widely
19
Code and Fix

0% of requirements done up front
0% of design done up front
Many development increments
50-100% of testing left to the end
In-phase defect-removal goal
is not 100%
20
Waterfall
1 development increment
100% of testing left to the end
Approach falls far short of achieving
100% in-phase defect removal
21
Benefit of More Iteration (e.g.,

Evolutionary Delivery)
Many development increments
0-25% of testing left to the end
22
This Framework Also Explains Some of the Most

Significant Attributes of Other Development Methods
XP
Scrum
Code and Fix
Pure Waterfall
Staged Delivery
Design to Schedule
Evolutionary
Prototyping
Evolutionary
Delivery
Spiral
Design-to-Tools
23
Industry Experiences
with Packaged Agile
Methods
XP
Scrum
XP as a Whole
Based on evolutionary prototyping lifecycle
model (which explains many of its strengths
and weaknesses)
Primarily developer focused
Includes 12 key practices including pair
programming, test-driven development, onsite customer (and additional practices have
been added in version 2)
Includes 4 values (plus 1 more in version 2)
We see XP fail more often than it succeeds
(i.e., organizations abandon use of XP)
25
Scrum as a Whole
Based
on time box development

(evolutionary delivery)
Primarily workflow/management focused
Key practices include 30-day sprints,
product backlog, daily standup meeting,
multi-level planning, end-of-sprint review
We see Scrum succeed more often than
it fails (i.e., organizations continue to
use Scrum)
26
Our Evaluation of Packaged Methods

Few projects actually use all the practices in a
packaged method
Difficult to determine which practices in the
package produce which benefits
Claim of synergy among a predefined set of
practices is not valid (although certainly some
practices do affect each other)
Ultimately, benefit comes from picking
practices appropriate to the team, business,
and kind of work
27
Industry Experience
with Specific Agile
Practices
Industry Experience
Experience
comes from Construxs

consulting and training clients
(approximately 1000 companies in the
past 5 years)
Also comes from published industry
reports
29
Roadmap
Agile
practices that are usually valuable

Agile practices that have been hit or
miss
Agile practices that tend to be
problematic*
*Slides are included in this talk for reference,
but we will not discuss them
30
Agile Practices That

are Usually Valuable
Short Release Cycles

Agile Usage
30 day sprints (or shorter) (Scrum)
1-4 week iterations (XP)
Weekly releases (Evo)
Construx Assessment
Release is sometimes purely internal
Release is sometimes only to selected
customers
Release is sometimes a full, public release
Overall, a clear industry best practice,
reduces numerous common risksvirtually
always valuable
32
Highly Interactive Release

Planning
Agile Usage
Planning Game (XP)
Planning session to define product backlog,
estimate, plan (Scrum)
Construx Assessment
Practice rolling-wave planning: long-term
roadmap (2-12 months) combined with short
term, detailed planning (30-60 days)
Overall, Agile, PMI, and other roads are all
converging to the same destination
33
Timebox Development
Agile Usage
30-day sprints (Scrum)
Iterations (XP)
Timeboxes (DSDM)
Construx Assessment
Keeps progress visible, supports high morale,
minimizes in-flow requirements changes as
long as timeboxes are short (~30 days)
Overall, a series of sprints seems to be more
sustainable for many teams than 40-hour
work week
34
Empowered, Small, Cross-Functional

Teams
Agile Usage
Team includes Dev, QA, Management/
Coach, and customer (XP, Scrum)
Construx Assessment
Similar to Feature Team idea originally
popularized by Microsoft
Allows for streamlined decision making
Allows for excellent execution because of high
buy-in to decisions
Overall, its hard to beat the efficiency and
buy-in of a team in which the people who
carry out a decision are the same people who
made the decision
35
Involvement of Active Management

Agile Usage
Coach (XP)
Scrum Master (Scrum)
Construx Assessment
High discipline methods benefit from the external
accountability provided by a coach or manager
The Agile roles are essentially Theory-Y style
management
Theory-Y: The belief that most workers are ambitious, selfmotivated, responsible, want to be self-directed, and are
motivated by the opportunity to do good work. Theory Y
managers try to remove barriers that prevent workers from
fully actualizing themselves and ensures they dont get
bogged down by rules.
Overall, illustrates the benefit that engaged

management can have
36
Coding Standards
Agile Usage
Coding standard (XP)
Construx Assessment
Overall, a longstanding industry best
practice
37
Frequent Integration and Test

Agile Usage
Continuous integration (XP and others)
Construx Assessment
Logical extension of smoke test and daily
build, given sufficient processing power
Must include testing as well as integration or it
wont be meaningful
Can be a chore to instill the frequent build
ethic in project teams
Overall, worth the effort to build at least daily,
even if start-up is burdensome
38
Automated Regression Tests

Agile Usage
Use of unit test frameworks (XP and others)
Construx Assessment
Virtually always a good practice with new
development
Use with legacy systems presents challenges
Benefits from both developers and test
specialists contributing test cases
Overall, an invaluable practice when used in
an appropriate context
39
Retrospectives at End of Each

Release
Agile Usage
Heartbeat retrospective at end of each
sprint (Scrum)
Iteration and quarterly reflections (XP)
Construx Assessment
Provides frequent opportunities to
sharpen the saw
Provides periodic opportunity to
reassess business value of the project
Overall, another clear best practice
40
Agile Practices that

Have Been Hit or Miss
Customer-Provided Acceptance
Tests
Agile Usage
Onsite customer creates acceptance tests
(XP)
Construx Assessment
Requires a level of ongoing customer
participation that is hard to obtain
Customers often dont know even generally
how to define meaningful test cases
Overall, a good, supplemental test practice
but not a substitute for independent testing or
developer testing
42
Daily Stand-up Meetings

Agile Usage
15 minute daily stand up meeting (Scrum)
Construx Assessment
Public peer accountability is useful
Meeting can be shorter
Meetings can be less frequent (2-3/week)
Watch for meeting for the sake of meeting
Overall, a good idea that can be taken too far
43
Simple Design
Agile Usage
Focus on the simplest thing that will work (XP)
Construx Assessment
A good design emphasis as long as team
doesnt oversimplify
Focus on the simplest design that fully satisfies the

known requirements
In the extreme case, YAGNI is problematic

Sometimes used as a cover for code and fix
Overall, a valuable design emphasis that is
prone to abuse
44
Test-First Development
Agile Usage
Test-first coding style (XP)
Construx Assessment
Minimizes time to defect detection
Democratizes creation of test cases
Requires culture shift among developers,
which can be problematic
High Discipline--often dropped or
compromised
Overall, an important step forward in SQA,
and worth the effort
45
40-Hour Work Week

Agile Usage
40-Hour Work Week (XP)
Construx Assessment
The real issue is sustainability; 40 hour
work week is a crude approximation of
that
Recent Agile writing has moved this
direction, too
Overall, focus on sustainability, not 40
hours
46
Agile Practices That

Tend to be Problematic
System Metaphor
Agile Usage
System metaphor (XP)
Construx Assessment
Probably the least understood aspect of
XP; XP experts dont even agree about
what it means
Tends to lead to time spent arguing
about metaphors
Overall, best to ignore this practice
48
On-Site Customer
Agile Usage
On-site Customer / Project Community (XP, Scrum)
Construx Assessment
Obtaining a full-time onsite customer is great, but its rarely
possible
If an onsite customer can be obtained, that customer isnt
necessarily representative
Role is frequently delegate to a business analyst or even
developer
Involving the customer is an important concept (goes back
to original Standish Group CHAOS report in 1994, or
earlier)
Within Agile, the concept has evolved toward embracing
the whole team or project community (aka project
stakeholders)
Overall, the original idea is migrating toward Boehms
Theory-W management, a good development
49
Collective Code Ownership

Agile Usage
Any programmer can work on any section of
code at any time (XP)
Construx Assessment
Quality of code changes can be uneven
Can lead to coding style wars
Can lead to unclear responsibility for
maintenance
Overall, intuitively appealing but, outside the
context of XP, seems to be problematic in
practice
50
Pair Programming
Agile Usage
Strongly associated with XP
Construx Assessment
Sweet spot is pairing of junior and senior
programmers
Many programmers prefer not to work this
way
Very few organizations stay with the full-scale
practice on a sustained basis
Overall, lots of value when used selectively
51
Refactoring
Agile Usage
Organized approach to improving code quality
in the face of changes
Construx Assessment
Refactoring is often used as a cover for code
and fix
Large-scale refactoring projects are usually
disastrous, unfocused time wasters
Used by the book, refactoring adds useful
discipline to code changes
Overall, a good practice in whose name many
abuses are committed
52
Agile's Legacy
Agile's Legacy--Negatives
Latest in a long line of genuine advances that
have been hyped beyond their real
capabilities (structured, 4GLs, object oriented,
CASE, reuse, etc.)
Agile isnt the best solution for every
company, though it is for many
The Agile name has lost much of its meaning
due to excessive buzzword usage
Agile literature has sometimes thrown out the
baby with the bathwaterthere are still cases
where sequential practices are the best fit
54
Agile's LegacyPositives
Clear #1:
Heightened awareness of importance of short,
iterative and/or incremental development cycles
Pounded the final nail in Waterfalls coffin

Provided a helpful check and balance against
overly bureaucratic CMM implementations
Provided an important reality check on the limits
of omniscient requirements practices, design
practices, and planning practices
continued.
55
Agile's LegacyPositives
Legitimized code-focused practices that became

popular in the 1990s
Some good reminders about fundamentals
including active project management, detailed
short-term planning, frequent builds, and coding
standards
Opens doors to a new set of very powerful
possibilities, e.g., short iterations support highly
accurate estimation based on project data
Provided deep development of a family of
practices focused on providing maximum value
when schedule and resources are fixed
56
In Other Words,
The Pendulum has Swung
CMM /
Waterfall
Agile
57
And it has Started to Swing Back
CMM /
Waterfall
Agile
58
The Pendulum Swinging Back
A lot has happened in 6 years

40-Hour Work Week Sustainable Pace
Agile doesnt provide predictability Increasing usage of
project-data to support longer-range predictability (Burn down
charts)
No design up front Focus on design simplicity
Onsite customer Project community
Customer-supplied tests Collaborative test approach
100% usage of pair programming Selective usage of pair
programming
Package methods Blended packages (e.g., elements of
XP within Scrum)
Agile as standalone process Agile practices used within
stage-gate process
Etc.
Lots of specific methods emerging that embody these ideas
(XP2, IXP, etc.)
59
Seminars &
Professional Development
Consulting
Tools
sales@construx.com
www.construx.com
+1 (425) 636-0100

08 AgileLegacy Keynote Slides

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

08 AgileLegacy Keynote Slides

Uploaded by

Copyright:

Available Formats

Legacy of Agile

want less overhead and less

Value Delivery on a Traditional (Sequential)

Value Delivery on an Incremental

Software Development Best Practices

Value Delivery on an Iterative (Agile)

Value Delivery on an Iterative (Agile)

Summary of Agile Value

Software Development Best Practices

Individuals and interactions over processes and

That is, while there is value in the items on

Common Agile Methods

Evo (Tom Gilb)

What, Specifically, is Agile?

Software Development Best Practices

What, Specifically, is Agile Today?

Incremental and iterative practices

Modern practices that work!

The Most Fundamental

Activities & Phases

development consists of wellidentified activities:

activities may or may not be

Software Development Best Practices

The Two End Points:

100% Iterative (e.g., Extreme Programming)

Software Development Best Practices

The Most Significant Differences Among

The most significant variations among

Common Lifecycle Features of All

defect removal goal is always

Code and Fix

Software Development Best Practices

Software Development Best Practices

Benefit of More Iteration (e.g.,

Software Development Best Practices

This Framework Also Explains Some of the Most

Software Development Best Practices

Software Development Best Practices

on time box development

Our Evaluation of Packaged Methods

Software Development Best Practices

comes from Construxs

Software Development Best Practices

practices that are usually valuable

Agile Practices That

Short Release Cycles

Highly Interactive Release

Empowered, Small, Cross-Functional

Involvement of Active Management

Overall, illustrates the benefit that engaged

Software Development Best Practices

Frequent Integration and Test

Automated Regression Tests

Retrospectives at End of Each

Agile Practices that

Daily Stand-up Meetings

Focus on the simplest design that fully satisfies the

In the extreme case, YAGNI is problematic

Software Development Best Practices

40-Hour Work Week

Agile Practices That

Collective Code Ownership

Software Development Best Practices

Pounded the final nail in Waterfalls coffin