Author, coach, and founding father of the Agile Manifesto, Ron Jeffries, shares his wisdom.
If you’ve ever heard Ron Jeffries talk to an audience, you know how good he is at presenting his case. He uses simple and clear explanations, easy-to-follow logic, and amusing phrases and anecdotes that culminate in a fun and informative experience. His talk for the XP West Michigan user group in September, 2004 was no exception to this enjoyable style.
In the first half of his talk, “Shipping Software Early and Often,” Mr. Jeffries pointed out that frequent releases is really the “magic” of XP.
Using comparisons with the waterfall method and simple graphs, he showed how shipping early and often means:
- learning more about the assigned requirements and necessary design
- adapting to requirement changes during the project
- accurately measuring and predicting project progress
- providing a quicker ROI
That’s a big ticket for any process, and he proceeded to explain how it all works.
Waterfall vs. XP
Ron characterized the traditional approach to software development as months of building infrastructure followed by a hopefully rapid rate of feature completion. Graphed as features delivered versus time, this looks like a relatively flat line from the beginning to the middle of a project, then a line rising to the point where all features are complete at the project deadline.The unfortunate reality of the traditional approach, according to Ron’s nearly 40 years of experience, is infrastructure that takes longer to build than expected, and a rate of feature completion that is slower than anticipated. The results are missed deadlines, no early indication that the project is behind schedule, and delayed return on investment.
Delivering features per customer priorities as early as possible in the project changes this dynamic. The graph of delivered features over time begins rising much sooner, albeit at a slower rate. With a project velocity (features delivered per unit of time) established early, a project manager has much better visibility into the true state of the project, and can extrapolate better to see how the project is tracking with respect to deadlines. Additional benefits of this approach are better feedback from users, higher morale on the development team, and earlier return on investment.
The ROI Snowball Affect
Using a simple economic model of value delivered during a project, Ron showed how the “early and often” approach increases the return on investment for a project. With the traditional approach, return isn’t started until some time after the product is released and it is not as great long term. With XP, return begins almost immediately after the first release, and with subsequent releases it tends to snowball, especially if the releases start early and continue on a frequent basis.
Graphing the accrued value of both approaches shows that delivering fewer features earlier and more consistently during a project starts the return earlier, and that the accrued value remains higher for well after the deadline compared to the traditional approach. From the perspective of the company, the optimum case involved delivering the most important two thirds of the feature set as soon as possible, then switching development resources to another project. This ties into the observation that typical applications are used 80% of the time in a relatively small set of the application’s total functionality. Providing the users of the application with the essential functionality early may eliminate the need of ever building the final one third of the initially envisioned features.
Ron stressed the importance of planning, estimating, minimizing up-front efforts, choosing only the most important features, and continuous customer feedback to make the best of each release. He also reviewed XP skills: creating stories, planning, test-driven development, and code refactoring. By the end of the first half of his talk, the audience seemed mesmerized by the wisdom of this man and how well he presented his case.
A Hilarious Pair Programming Demo
The second talk included not only Ron Jeffries, but also another well-known XP’er in the U.S., Chet Hendrickson. The two demonstrated test-driven development by creating a bowling scoring program using Visual Studio .NET with C#, and NUnit as a testing framework. With their programming hats on, these two became a crowd-pleasing duo. Their instruction and demonstration combined with ad-lib jokes and attitude made everyone in the audience wonder if all pair programming couldn’t be that much fun.
“The programmer should be very conscious not to write any code that cannot be broken by a test,” according to Ron. “You can do less than you think: Build a rythm – build, test, run.”
The two illustrated the importance of test-driven development and the audience could clearly see how infectious it can be. The green bar indicating a test passed can be addicting to the point that a programmer sometimes runs tests that she knows will work just to see that green bar.
The traditional time to close the XP West Michigan user group meeting is 8 pm, and a few attendees did leave at that time. Others wandered out throughout the extended demo, with the final attendees staying until 10 pm. Even then, they left reluctantly.
An Interview with the XPert
Since the group wasn’t able to get enough of Ron Jeffries, Atomic Object pursued a discussion with him about XP’s current status and his predictions for its future. Here, in full, is the interview between Ron Jeffries and Atomic Object.
Q:You have been practicing XP in some form for about 6 years now—since 1996. Some companies adopt XP and love it, while other companies just refuse to change their existing, ineffective development process. Why do you think companies resist the change, despite a proven, better software development method?
A: First of all, XP is not proven to be better. Second, people almost always resist change. Third, not all companies recognize that they have a problem. Fourth, some companies have different theories about what software development is, and how it should be done. Fifth, many people do not know what XP and agile methods are. Sixth …
Q: Do you think agile development processes will follow a typical marketing curve, with early adopters first, then a lot more adopters, and finally the laggards coming on board?
A: That’s the current running theory in the community. We see no reason to expect XP to be different from other adoption curves.
Q: Many industries adhere to strict development standards, for example defense avionics (DO-178B), automotive (QF), and manufacturing (ISO, CMM). Do you see XP practices becoming a part of these standards so they can work together peacefully?
A: I see no reason why not. XP is clearly ISO compatible, and one CMM assessor told me that an XP team would assess at level 3 in his opinion. The question of how to adhere to this or that development standard comes up from time to time. When you dig in to what the standard really says, it seems you never find anything that would preclude XP practices.
Q: What was the most challenging XP project you ever worked on and what would you have done differently to make it go more smoothly?
A: I don’t usually get long-term continuity with projects. My fate is to go in at the beginning, or from time to time, get things started or give them a little tuneup, but not to be present throughout.
C3 [Daimler-Chrysler’s payroll project, and the first documented XP project] was the only XP project that I’ve been on essentially from beginning to end. The things I would do differently now are two: first, I would make sure that everyone in the chain of command knew the truth of what was going on. Second, I would have put the project into production incrementally, not just at major 1- or 2-year milestones.
Q: Are there specific cases where you think XP doesn’t work?
A: When the culture, or some part of the team, doesn’t want to work that way.
Q: What do you feel is the single most indispensable agile development principle? (Eg, test driven development, pair programming, planning, standards, etc.) In other words, if resource limitations are high, what should be the last to go?
A: XP and agile principles do not increase costs in my opinion, they reduce overall project cost, unless you really are willing to ship software that doesn’t work and cannot be maintained. So resource limitations are a really bad reason not to be agile.
The most important principle is to ship running tested software every iteration. Everything else follows from that.
Q: We’ve noticed some developers treating XP as just another thing managers want them to do…sort of like a trend that will be tossed away when management’s “next big idea” comes along. Are you seeing this as well and do you have any suggestions on how XP might be seen more seriously as a real and lasting process change?
A: I have seen it. I think that if people actually learn how to do the XP practices, they are wise enough to decide when to use them. I think that if they do not take the trouble to learn how to do them, they are not likely to be qualified to make that decision.
Q: Would you like to see XP taught in universities?
A: Yes. And several educators are setting up courses and programs right now. I’m just getting my feet wet in that area myself.