The S-Curve Explained
By David J. Anderson, May 2004
Introduction
In my previous Coad Letter [Anderson 2004], I
described how a plot of Features completing - an earned value plot of an agile
project - typically displays an S-curve shape. With this edition I'd like to
provide some more insight as to what causes the S-curve effect and how managers
can minimize the effect it has on the overall project delivery by paying
attention to just a few areas at the beginning and end of a project.
The S-Curve
Figure 1 shows the ideal maximum production rate -
the natural limit for the development group. There are good reasons why this
optimal productivity can't be achieved immediately and why it drops off towards
the end of the project. Let's look at the bottom and top of the s-curve
separately. This material also appears in Chapter 9 of "Agile Management for
Software Engineering" [Anderson 2003].
Figure 1. S-Curve for Features Complete
Bottom of the S-Curve
It is very difficult to sprint right out of the gate. It
is probably impossible to achieve optimum throughput in the software production
system at the start of a project. There are several reasons why this should be:
feature inventory blocked due to ambiguous requirements; training of personnel;
lack of understanding of the project domain; poor team working; changing
designs; availability of tools; availability of environments; facilities; lack
of technical infrastructure; minimal domain specific tools; and staffing
levels. Some can be eliminated through better planning, others appear to be
endemic. They represent the nature of the beast - software development.
Team Formation
When a new team is formed for a
project, there will be an impact on velocity. This is endemic to the business.
The team must work through its "forming" and "storming" [Tuckman 1965, Weaver 1997]
phases before settling into its new normal habits. As the team gets to know each
other's strengths and weaknesses, there will be some friction. This friction
will reduce the production rate of the team.
Team Dysfunction
Occasionally, a team is
dysfunctional. This will manifest itself as a low production rate and a flat
curve. Dysfunction may result in poorly executed design or peer reviews, or
petty arguments which block development. Monitoring the cumulative flow diagram
[Anderson 2004] arms the manager with a lot of information which can indicate a
dysfunctional team, but only the manager can actually investigate and discover
dysfunctional behavior. It is important to understand that a dysfunctional dispute
between two individuals hurts the performance of the whole team.
Knowledge Sharing
Knowledge sharing is important
to performance. A team which works well together will share knowledge. A team
which is dysfunctional and poor at sharing will under perform. Encouraging
openness and knowledge sharing and creating a means for communicating the
knowledge, such as a news server, or intranet knowledge base, will improve
performance of the team.
Tools & Environments
If a development team is ready
to start a project but they don't have all the tools and environments needed to
make progress then the production rate will suffer badly. Capacity constrained
development resources must be exploited to the full. They must not be idle
because tools or environments are not available. Hence, it is important that
the project manager ensure tools and environments are in place early. A flat
line at the start of a project may be a strong indication that the team doesn't
have the tools or environments that it needs.
Ambiguity in Requirements
Design changes will hurt at any
time in a project. When someone discovers a requirement which necessitates the
modification of a widely used interface, the regression effect across the
system, causes velocity to drop dramatically. This problem is endemic. There
will always be a little unforeseen uncertainty related to analysis and design.
Top of the S-Curve
There are three reasons why the production rate tends to
drop off in projects regardless of software development method employed:
increased integration effort; bug fixes; inventory blocked due to unresolved
issues; and refactoring.
Integration
Increased integration effort is
almost unavoidable. As a project becomes large, code from a new iteration must
be integrated with the large existing code base. The number of problems found
during build-integration and integration testing is likely to increase. The
only way to avoid this is to never work on a large project or system. Hence,
large projects, even those built in smaller iterations, should anticipate this
effect and allow for it in the planning of the project buffer. [More about
project buffers in a future Coad Letter]
The effect of increased
problems due to build-integration can be measured by measuring the time from
the start of the build until the build is declared successful. This is the
local lead time through Integration Test. The manager can then assess what the
overall downtime for the development team might be. In extreme cases, all
development stops until the build is declared successful. The effect on the
production rate can be calculated. The trend in the build-integration time can
be used to predict the future impact of build-integration on velocity. Hence,
the contribution of build-integration to the cumulative flow diagram can be
predicted.
Bugs
As a project matures and more
code is available for system and product test, the number of bugs reported
rises. As the bug database rises, there is a tendency to increase the mix of
bugs to new client-valued functions being coded. The result is that the overall
speed of the team is maintained but an increasing percentage of the effort is
devoted toward fixing bugs. Bug fixes are related to feature inventory which is
already shown as code complete and hence no additional value is earned on the
cumulative flow diagram by working on them.
To minimize the effect of bugs
on the code complete slope and to maintain velocity, it is vital to maintain
high quality standards. Fewer bugs have a direct positive affect on the
production rate of the system. The s-curve clearly shows how and why high
quality makes a project go faster.
Unresolved Issues
As a project nears completion,
inventory which has been blocked due to unresolved issues raised during
analysis or design, re-enter the critical path. Eventually all client-valued
functionality must be coded, or the client must agree to remove them from the
scope. If they remain in scope, the issues must be resolved. Issues which
remain open near the end of a project, reduce the number of client-valued
functions which can be progressed to completion. The result is that the speed
of the team slows. Some developers may become idle, or more and more effort is
concentrated on bug fixes, because other inventory is blocked.
To avoid a tail off in velocity
it is vital to resolve issues before the client-valued functions re-enter the
critical path. Hence, the project manager should be focused on fast and
effective issue resolution. This maintains the overall throughput of the
system. A flattening in the curve is a good visual indicator that the project
manager needs to work harder to resolve open issues.
Restructuring (a.k.a major refactoring)
Restructuring (or major refactoring) will also impact velocity,
if it involves features already shown as complete. When working code already
completed is being re-worked then it is not being shown as new productivity.
For every client-valued function being re-worked, the system is losing the
possibility of a unit of new production. For this reason, I prefer to plot
restructuring as new "dark matter" features which are added to the total
inventory on the cumulative flow diagram.
Where restructuring is
unavoidable due to a change in market conditions which force new architectural
requirements upon the system or through sloppy coding which has limited the
ability of the team to deliver the full iteration, then it is vital to convey
to senior management, the true cost of the restructuring. The true cost can be
calculated from the reduction in production rate, the increase in lead time,
the increase in WIP inventory and the lost opportunity for throughput. If the
benefit from restructuring financially outweighs the cost then it should happen.
Summary
Cumulative Flow Diagrams provide a method for
tracking progress of agile projects in a "burn up" fashion. The plot of
features, stories, use cases or function points complete, can be expected to
follow an s-curve. The severity of the s-curve effect is dependent on many
factors. Managers can minimize the effect and maximize the productivity of
their team by paying attention to the contributing factors which limit
productivity in the early and late stages of a project. The s-curve effect must
be accounted for in the project plan. Velocity at the beginning and end of a
project, release or iteration will be slower than the maximum possible rate.
Given knowledge of the team, the tools environment, the requirements ambiguity,
the amount of integration needed or likely, the code quality, the ability of
project managers to communicate successfully and close issues quickly and any
likely refactoring, a good manager can guesstimate the s-curve effect and plan
for it such that the delivery date on a project will not be missed.
For additional insight on the s-curve, you may also like
to check out "Tracking Software Process" by Betsy Clark [Yourdon 2002]. She
calls small pieces of client-valued functionality - work units - and she also
observes that they plot as an s-curve.
About the author
David J. Anderson is the author of the recent
book, "Agile Management for Software Engineering - Applying the Theory of
Constraints for Business Results" published in Peter Coad's series by Prentice
Hall PTR in September 2003. He is Principal Consultant with VA Systems
Professional Services. David was one of the team which created the popular
agile development method, Feature Driven Development. He has introduced FDD at
two Fortune 100 companies Sprint (a telecommunications operator in the United
States) and Motorola. He writes the regular Agile Management
column at the Borland Developer Network website and publishes the his weblog at
agilemanagement.net. He holds a
degree in Computer Science and Electronics from the University of Strathclyde.
Email: fddmanager@yahoo.com
References
[Anderson 2003] Anderson, David J., Agile Management for Software
Engineering - Applying the Theory of Constraints for Business Results
, Prentice Hall, Upper Saddle River NJ, 2003
[Anderson 2004] Anderson, David J., Using Cumulative Flow Diagrams
, The Coad Letter, Borland Developer Network, Scott's Valley CA, 2004
[Tuckman 1965] Tuckman, Bruce W., Development Sequence in Small Groups, Psychological
Bulletin, 63(6)
[Yourdon 2002] International Function Point User Group, IT Measurement
- Practical Advice from the Experts, Foreword by Ed Yourdon, Addison
Wesley, New York, NY, 2002
[Weaver 1997] Weaver, Richard G. and John D. Farrell, Managers as Facilitators
- a Practical Guide to Getting Work Done in a Changing Workplace, Berrett &
Koehler, San Francisco, CA, 1997
