Legacy of Agile

Software Development
2007 Construx Software Builders, Inc.
All Rights Reserved.
www.construx.com
Why Agile?
Software Development Best Practices
3
Basic Motivations
Developers want less overhead and less
distractionspending more time doing
the real workof 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
4
Value Delivery on a Traditional (Sequential)
Development Project
Waterfall Value Delivery
Cost
Time
Value /
Functionality
Software Development Best Practices
5
Value Delivery on an Incremental
Development ProjectInitial View
Iterative Value Delivery
Cost
Value /
Functionality
Time
Software Development Best Practices
6
Value Delivery on an Iterative (Agile)
Development ProjectPrioritized Iterations
Diminishing returns when functionality is
delivered in priority order
Time
Value /
Functionality
Cost
Software Development Best Practices
7
Value /
Functionality
Cost
Value Delivery on an Iterative (Agile)
Development ProjectPrioritized Iterations
Diminishing returns when functionality is
delivered in priority order
Value /
Functionality
Time
Software Development Best Practices
8
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?
Software Development Best Practices
10
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.
Software Development Best Practices
11
Common Agile Methods
Evo (Tom Gilb)
DSDM (DSDM Consortium)
Extreme Programming (Kent Beck)
Rational Unified Process (IBM/Rational)
Scrum (Ken Schwaber)
Adaptive Software Development (J im Highsmith)
Crystal Clear (Alistair Cockburn)
Feature Driven Development (J eff De Luca, Stephen
Palmer)
Lean (Ron Mascitelli/Mary Poppendieck)
Many additional variations are emerging (IXP, XP2,
etc.)
Software Development Best Practices
12
What, Specifically, is Agile?
(circa 2001)
Non-Waterfall
Non-CMM
Lightweight
Little or no documentation
Few or no requirements up front
Code-focused
Software Development Best Practices
13
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!
The Most Fundamental
Contribution of Agile:
Different Lifecycles
Software Development Best Practices
15
Activities & Phases
Software development consists of well-
identified activities:
Requirements
Architectural design
Detailed design
Construction
Developer test/integration test
System Test
These activities may or may not be
performed in phases
Software Development Best Practices
16
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
Software Development Best Practices
17
The Two End Points:
100% Sequential vs. 100% Iterative
100% Sequential (e.g., Waterfall Development)
Require-
ments
Archi-
tecture
Construction System
Test
100% 100% 100% 100%
100% Iterative (e.g., Extreme Programming)
Software Development Best Practices
18
The most significant variations among
methods can be explained in terms of
balance between work done up front and the
number of iterations
1. Percent of requirements done up front vs. in
each iteration
2. Percent of design done up front vs. in each
iteration (partially dependent on #1)
3. Number of iterations
4. Percent of testing done in each iteration vs.
at end of project
The Most Significant Differences Among
Development Methods
Software Development Best Practices
19
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
Software Development Best Practices
20
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%
Software Development Best Practices
21
Waterfall
100% of requirements done up front
100% of design done up front
1 development increment
100% of testing left to the end
Approach falls far short of achieving
100% in-phase defect removal
Software Development Best Practices
22
Benefit of More Iteration (e.g.,
Evolutionary Delivery)
25% of requirements done up front
25% of design done up front
Many development increments
0-25% of testing left to the end
Software Development Best Practices
23
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
Industry Experiences
with Packaged Agile
Methods
XP
Scrum
Software Development Best Practices
25
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, on-
site 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)
Software Development Best Practices
26
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)
Software Development Best Practices
27
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 synergyamong 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
Industry Experience
with Specific Agile
Practices
Software Development Best Practices
29
Industry Experience
Experience comes from Construxs
consulting and training clients
(approximately 1000 companies in the
past 5 years)
Also comes from published industry
reports
Software Development Best Practices
30
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
Agile Practices That
are Usually Valuable
Software Development Best Practices
32
Short Release Cycles
Agile Usage
30 day sprints (or shorter) (Scrum)
1-4 week iterations (XP)
Weekly releases (Evo)
Construx Assessment
Releaseis sometimes purely internal
Releaseis sometimes only to selected
customers
Releaseis sometimes a full, public release
Overall, a clear industry best practice,
reduces numerous common risksvirtually
always valuable
Software Development Best Practices
33
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
Software Development Best Practices
34
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
Software Development Best Practices
35
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
Software Development Best Practices
36
Involvement of Active Management
Agile Usage
Coach (XP)
Scrum Master (Scrum)
Construx Assessment
High disciplinemethods 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, self-
motivated, 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
Software Development Best Practices
37
Coding Standards
Agile Usage
Coding standard (XP)
Construx Assessment
Overall, a longstanding industry best
practice
Software Development Best Practices
38
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
Software Development Best Practices
39
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
Software Development Best Practices
40
Retrospectives at End of Each
Release
Agile Usage
Heartbeat retrospectiveat 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
Agile Practices that
Have Been Hit or Miss
Software Development Best Practices
42
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
Software Development Best Practices
43
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
Software Development Best Practices
44
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
Software Development Best Practices
45
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
Software Development Best Practices
46
40-Hour Work Week
Agile Usage
40-Hour Work Week (XP)
Construx Assessment
The real issue is sustainability; 40 hour
work weekis a crude approximation of
that
Recent Agile writing has moved this
direction, too
Overall, focus on sustainability, not 40
hours
Agile Practices That
Tend to be Problematic
Software Development Best Practices
48
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
Software Development Best Practices
49
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 teamor project community(aka project
stakeholders)
Overall, the original idea is migrating toward Boehms
Theory-Wmanagement, a good development
Software Development Best Practices
50
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
Software Development Best Practices
51
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
Software Development Best Practices
52
Refactoring
Agile Usage
Organized approach to improving code quality
in the face of changes
Construx Assessment
Refactoringis often used as a cover for code
and fix
Large-scale refactoring projectsare 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
Agile's Legacy
Software Development Best Practices
54
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
Software Development Best Practices
55
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 balanceagainst
overly bureaucratic CMM implementations
Provided an important reality check on the limits
of omniscient requirements practices, design
practices, and planning practices
continued.
Software Development Best Practices
56
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
Software Development Best Practices
57
CMM /
Waterfall
In Other Words,
The Pendulum has Swung
Agile
Software Development Best Practices
58
CMM /
Waterfall
And it has Started to Swing Back
Agile
Software Development Best Practices
59
The Pendulum Swinging Back
A lot has happened in 6 years
40-Hour Work Week Sustainable Pace
Agile doesnt provide predictabilityIncreasing 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.)
Seminars &
Professional Development
Consulting
Tools
sales@construx.com
www.construx.com
+1 (425) 636-0100