Agile Management - June 2004 - The S-Curve Explained by David J. Anderson

By: David J. Anderson

Abstract: This article provides 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 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


Server Response from: ETNASC01