Pattern 4: Timeboxes ***
AKA:

You have completed a BUSINESS PROCESS MODEL (2), a use case model and begun to extract a type model. Now you have to ensure timely delivery of a site that meets current requirements as closely as possible. But...

Time pressure fights against both robustness and the need to respond to changing business requirements during the project. However, timely delivery is nearly always a critical success factor.

Therefore

Divide the use cases into coherent groups, taking into account technical constraints (e.g. client server dependencies, supplier lead times, etc.) and business issues (e.g. unitary business offering). There are three possibilities.

1. Tackle the easiest area first to boost developers’ confidence.
2. Tackle the area that solves 80% of the business need first.
3. Tackle the area with the greatest technical challenge first.

The first approach is seldom the right one, because there can be some nasty shocks awaiting the team downstream and because it is not a good way to impress users with the team’s skills. A combination of the other two approaches is ideal. The focus too is on the essential requirements early on, rather than those features that the business (or the developers) would like the system to have ideally.

Set definite delivery dates for the software and content that implement each such group of use cases. When deadlines seem endangered, cut functionality instead. But don’t expect to get all the requirements right first time. If stakeholders request new of changed functionality, rate its importance against the prioritized business objectives. Negotiate on what must be deferred to the next timebox if the new features are to be included. Drop use case functionality corresponding to the lowest priority objectives. Never deliver late. Don’t compromise on quality unless there is an argument to do so based on the objectives. Don’t allow anyone to change the objectives or their priorities.

Now begin to develop the site using GRADUAL STIFFENING (5). AUTOMATE TESTING (6) wherever possible. Start USABILITY TESTING (7) early on. Use GET-IT? (8) tests as soon as possible too.

This is another process pattern of great generality sometimes ignored by web developers.

Rapid Application Development or RAD, as a development approach, began to be popular in the late 1980s but its origins remain obscure. The Joint Application Development (JAD) workshop technique used at IBM was certainly an influential component. Rapid prototyping had been used for years and also penetrated the RAD approach. James Martin is sometimes accused of first coining the phrase but the earliest formal declaration seems to be the Ripp (Rapid Iterative Production Prototyping) method developed at El du Pont de Nemours and sold later under the catchy slogan: ‘Your system in 128 days – or your money back’. Ripp was followed by many proprietary imitations and soon every consultancy had its own version and name. What they all had in common is the use of workshops and timeboxes. A timebox sets a rigid limit to prototype iterations to ensure management control over prototyping. A small team is mandatory and the tested prototype is both end-point and deliverable. RAD methods vary in the extent to which users participate in the prototyping process and the kind of tools used. This pattern emphasizes building a bridge between the understanding of the business people and the developers, and integrating their effort.

The time-box technique offers the following benefits. It imposes management control over ripple effects and uncontrolled iteration. Control is achieved by setting a rigid elapsed time limit on the iterations and using a small project team. Furthermore, it has a usable system as both the end-point of the process and its deliverable. There is no distinction between production, evolution and maintenance as with conventional approaches, which usually ignore maintenance costs during project justification.
Time-boxes tackle the following management issues:

• Wants versus needs – by forcing requirements to be prioritized by negotiation between users and developers. Users and the project team are forced to concentrate on the real needs of the business.
• Creeping functionality – in the traditional life cycle the long delay between specification and delivery can lead to users requesting extra features. The use of a time limit reduces this tendency.
• Project team motivation – the developers can see a tangible result of their efforts emerging.
• The involvement of stakeholders at every stage reduces implementation shock.

The approach reduces time-to-market, not by a magic trick that makes hard things easy but by delivering an important usable subset of the entire system in no more than a few weeks.

It is absolutely critical to maintain credibility; build on success and manage expectations during the process. This is achieved by several means. Customers should be warned that a quickly developed prototype may conceal much complexity. A working site will take time in proportion to the complexity of the tasks it assists with. You will know what these are because you ESTABLISHed THE USE CASES (3). Equally, customers should be stimulated by many small, incremental deliveries. We have ESTABLISHED THE OBJECTIVES (1) and prioritized them so that developers can show that corners that are cut to keep within time limits are low priority corners. Developers can thus afford to accept reasonable changes to requirements, provided that existing, low priority requirements can be eliminated by mutual agreement based on the priorities. This expectation management is a key task for the project manager. If it is neglected the project will usually fail.
This technique prevents paralysis by analysis, errors due to delay, spurious requirements and implementation shock. It usually motivates teams better than the waterfall approach.

The Dynamic Systems Development Method (DSDM) is a ‘framework of controls for rapid application development’ (Stapleton, 1997). There are no prescribed techniques. DSDM has a rudimentary and high-level process model that can be tailored for individual organizations’ requirements. It was developed as a potentially standard approach by a consortium of 17 British user organizations in 1994 that now has over 1,000 members world-wide. DSDM has nine fundamental principles; all of which the process described below adheres to totally. They are:

1. Active user involvement is imperative.
2. Teams are empowered to make decisions.
3. The focus is on the frequent delivery of products.
4. Fitness for business purpose is the essential criterion for acceptance of deliverables.
5. Iterative development and incremental delivery are necessary to converge on an accurate business solution.
6. All changes during development are reversible.
7. Requirements are defined at a high level.
8. Testing is integrated throughout the life cycle.
9. A collaborative and co-operative approach between all stakeholders is essential.

These principles enable an organization to determine whether a particular project is suitable for the approach. For example, if you know perfectly well that under no circumstances will a sample of (at least surrogate) users be available, then forget it.
What DSDM does give is a framework that can be informed with the concrete political and organizational characteristics of a project. The commitment to time-boxing (principle 3) means that milestones are equated with deliverables, making the approach very product oriented. Testing is performed throughout the life cycle, rather than as an end-stage activity, and this leads to far higher quality and far fewer implementation surprises. Very importantly, the products and documentation mandated by DSDM are as minimal as possible, while still ensuring adequate quality and progress towards delivery and maintenance.
One useful contribution from DSDM (suggested first by Dai Clegg of Oracle, I understand) parallels the prioritization of objectives in SOMA workshops. DSDM classifies requirements into: Must have, Should have, Could have and Want to have (but not in this release). This categorization is referred to by the contraction: MoSCoW. However, several recent experiences have shown that there is a tendency for every stakeholder to insist that their pet requirement is a Must. To counter this we recommend a numerical prioritization based on consensus if possible. The voting technique described in ESTABLISH THE BUSINESS OBJECTIVES (1) is one way to achieve this. If (much) more time is available, pairwise ranking may be a more ‘scientific’ approach.

The prioritized use cases provide perhaps the only rational basis for negotiation with stakeholders when deadlines slip or requirements evolve. Fix the business objectives and priorities for the duration of each project but allow the requirements to evolve. Drop the use cases and types corresponding to the lowest priority objectives where technically possible.

Look for quick wins. For example, when testing your site there will be instance when a tester hits a problem that surprises the developers but for which the solution is obvious. In a similar category are fixes that require little or no effort or those where a small effort will have a big impact. It is important to give such fixes a high priority and de-scope other features accordingly.

Browse the language	What is Wu?	Look at an example pattern sequence	Structure of the patterns
Comment on Wu	Contributors	Return to TriReme home page	Links to related sites