Video

Video for the presentation is now available on Google Video

“Making the Date” and Q&A

Ron Jeffries

When:March 28th, 2006, 6:00 pm – 8:00 pm

Where: Atomic Object, 941 Wealthy Street SE, Grand Rapids, MI 49506

The March meeting of XPwm features Ron Jeffries. The first half will be a presentation from Ron on the confused dynamics of project dates. The second half will be an open question session. Bring your thorny problems, your myths in need of debunking, your agile adoption stories, your test-driven dilemmas or your complaints about the weather. Ron promises to tackle them all.

Never shy of making provocative statements, Ron Jeffries recently wrote this on the subject of projects and deadlines:

“In my opinion, every project should begin with high goals and a short deadline. And, with rare exceptions, every project should deliver its product by the deadline. Really. Every single project.”

But who works to make the date?

“It seems like every development project begins with the date, and we’re held responsible for ‘making the date’. Making the date is not a development responsibility.”

In this talk Ron considers the distinct and essential roles of management, customers and developers with respect to projects dates.

Ron Jeffries

Biography of Ron Jeffries
Independent Consultant

Ron Jeffries is a prolific author, industry leader and practitioner in the Extreme Programming (XP) movement. A true XP pioneer, Mr. Jeffries began practicing this agile development process in 1996. He was one of the original authors of the Manifesto for Agile Software Development (http://agilemanifesto.org), and was the on-site coach for the first XP project at Chrysler in 1998 (http://www.xprogramming.com/publications/dc9810cs.pdf). Now an independent consultant, he has presented numerous talks and published several papers on the topic. He and his teams have built operating systems, compilers, relational database systems, and a wide range of applications.

In addition to his consulting work, Ron Jeffries is author or co-author of several articles and books including Extreme Programming Installed and his most recent book, Extreme Programming Adventures in C# (DV-Microsoft Professional). Ron is editor of the website XProgramming.com, and is, by far, the most prolific on-line author in Extreme Programming and related topics.

Meeting Summary and Comments

Shawn Crowley, Atomic Object

The advantages of an agile approach: Traditional development methods (many requirements up front) often miss the deadline because they don’t give a good indication of development velocity.

The customer has no idea of what the real development velocity of the project is going to be until development starts.

Because of the lengthy requirements phase in traditional project schedules, the customer may not realize they are going to blow a deadline until they have already invested a significant amount of money.

Agile processes give the customer more decision making power . A project’s development velocity can be seen right away, giving the customer a better indicator if they are going to hit their date. This timely information call allow the customer to take controlled actions like:

• Reduce scope
• Extend schedule

Usually hitting the date is the most important because being on time is what most people will remember.

Importance of tests:

One of the most important things to the customer is for the development effort to be predictable. The best way to be predictable is to have running tested features. It is import to look at a burn down chart as running, tested, features. Without tests you may be putting defects (negative features) into the software. Your curve may not be where you think it is if there are defects lurking in the software. A possible remedy for a lack of tests is putting a block of time for testing into the schedule after development. The trouble with adding a testing phase is that no one has a real indicator of how long the testing phase will take.

It is important to have to layers of testing. Unit tests provide a way for the developer to know that their code is doing what they think it is doing. Units tests are not enough though because they do not assert what the customer wants as features (that is the job of system tests).

System tests (automated customer tests) need to be part of the feedback loop between the customer and the developer. These tests will tell that a feature is done. When a feature is too large, try to reduce the scope of the story to a minimal thing that the customer can recognize as progress. Bugs are easier to identify when the scope of a feature is smaller.

Refactoring:

The software’s design should follow the growth of the features. No frameworks up front. If a design is good enough for today, is good enough to add one more feature. After a feature is put into the software, see if it adds an ugly blob to the software and refactor it if it does.

A design that is inadequate for tomorrow is inadequate for today. Don’t sit with bad design when adding features (refactor as necessary).

Most important development skills:

• Small features
• Short iterations
• Testing
  • Test driven development
  • Customer acceptance testing
• Refactoring