eXtreme Spreadsheet Engineering

[article]
What spreadsheet modelling can learn from XP
Member Submitted
Summary:

Extreme Programming (XP) was created in response to problem domains whose requirements change. Spreadsheet development is often done in conditions of intense time pressure, for example in merger and acquisition analysis. The spreadsheet development itself is often used to develop an understanding of what is being modelled, and therefore change is constant.

Extreme Programming (XP) was created in response to problem domains whose requirements change. Spreadsheet development is often done in conditions of intense time pressure, for example in merger and acquisition analysis. The spreadsheet development itself is often used to develop an understanding of what is being modelled, and therefore change is constant.

Key features of XP

  1. Customer satisfaction through frequent visibility of increments of functionality;
  2. Constant communication with customers to set and reset expectations, acceptance criteria, scope, priorities, and schedules;
  3. Risk reduction from test-first development;
  4. Defect reduction from continuous review with fellow spreadsheet developers;
  5. Maintenance reduction through simplification;
  6. Increased productivity through focus on delivery of real needs as they are needed.

It is said that a lightweight methodology has only a few rules and practices or ones which are easy to follow. In fact XP is actually a deliberate and disciplined approach to software development. In a traditional software development environment, users may be uncomfortable with the amount of availability that XP demands of them; they would rather hand everything over to the programmers and complain later. With spreadsheets, the developers are often also the users, which is a big advantage to begin with.

User-defined tasks
The customers write down what XP calls "user stories", a few sentences in their own words saying what the system needs to do for them. These high-level (that is, not at the level of detailed screen & report design) tasks are used to create the acceptance tests–that is, does the system do each of these things? The developer guesses (frankly, a more honest term than "estimating") how long each of these tasks will take to implement. If any one is more than three weeks effort, they should be decomposed into smaller tasks. The actual time chunk, of course, depends on the environment.

Release and Iteration planning
In XP, a release planning meeting is used to creating a release plan, which lays out the overall project in terms of iteration plans. The customer decides what story is the most important or has the highest priority to be completed. In spreadsheet development, this is likely to be a major shift in thought–away from building up pieces to an overall model that answers the big questions first, however crudely. Each task includes its acceptance test, without which it cannot proceed. Therefore, you are always working with a correct model; initially oversimplified, but it gets more detailed as time permits.

The other meeting style that is used is a daily "stand-up" meeting; this avoids wasting time on stultifying meetings where only a few contribute.

Project velocity
XP’s measure of progress is "project velocity"–the number of tasks that were finished during an iteration compared to the total of the estimates that these stories or tasks received. This data is then used in a release planning meeting to re-estimate and re-negotiate the release plan if project velocity changes dramatically for more than one iteration. Don't fudge estimates; that is just a flight from reality.

Another discipline is to avoid the "I'll just do this too as I'm at it" syndrome, adding any functionality before it is scheduled. In practice, these guesses at what might be needed in the future are often not justified. Just add what you need for today, anything extra will slow you down.

Moving pairs
One of the most distinguishing features of XP is "Pair programming". This has the effect of continuous peer review. Advocates [1] say "It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality."

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09