Fear of Non-Progress

<< Page 3: Increase Communication

Page 4: Tackle the Problem Head-On

If your project is experiencing the real thing - if it really is suffering from slow development, and not just the illusion of slowness, then you need to tackle the problem head-on.

For example, the ICONIX Process (described in the book Use Case Driven Object Modeling With UML, A Practical Approach by Doug Rosenberg and Kendall Scott) provides many ways to identify and deal with "analysis paralysis" - the problem of getting bogged down in a particular section of the project (such as, painstakingly drawing state diagrams for every class in your static model).

A major part of communicating rapid development also ties in with our re-engineered process (which luckily gives this article some much-needed cohesion):

To the manager, code = progress. So make sure they see lots of code. You can show them lots of reports that demonstrate that the project really is on track. But what they really want to see is new software. This is, after all, the objective of the project. Paper to them is not progress, new software is.

To the person for whom we are writing this system, working functionality = progress. So make sure they see frequent small releases. This does not necessarily mean giving them actual production code to "go live" with every two to three weeks (as would be the rather tiring case in an XP project). This would drive most customers mad. Consider a blue-chip client that likes to spend six months performing their own acceptance tests for any new software. Are they going to initiate a new set of tests every three weeks? Even scaled down to a smaller project for a less quality-obsessed organisation (the cads!), this sort of rapid-fire release schedule represents a major logistical headache.

Instead, make sure the customer sees progress in action. Make sure they can push buttons and see things happen, see message queues filling and emptying and invoices being processed (even if they aren't actually doing anything, or hooked up to anything, at this early stage in the project). If it's visual, show it to them. As soon as something has been connected up to something else, and it works, show them. At the very least, regularly email them the latest screenshots (whether they ask for them or not) so they can see the project progressing, and provide feedback.

Start Producing the Front End Early

A neat trick to help convey this sense of progress, and hence ease the customer's jittery nerves, is to produce the front end early. This could be a Visual Basic or Swing GUI if it's a desktop application (once considered old-school in the face of groovy new HTML front-ends, but now making a welcome comeback). If your project isn't GUI-centric (e.g. a server product or a data processing system), you'll have to make do with whatever material you can use that still conveys a feeling of progress.

That really is the key point: you need to convey a sense of steady progress throughout the project. This means regularly releasing new sections of the user interface, which will delight the customer and keep them enthralled as they discover new areas of their burgeoning new product, as if they are exploring an adventure game. Keep rewarding them with new areas to explore.

Rapid GUI prototyping is a popular method of quickly reaching a common understanding of the customer's requirements. For example, each iteration of the ICONIX Process (mentioned above) actually starts with a GUI prototype (or in some cases even a prototype user manual), from which the use cases are identified. This initial effort may not end up being anything like the real GUI, as the use cases will be honed and modified as the analyst develops a greater understanding of the customer's requirements.

However, the GUI prototypes are a great starting point, because they help the customer to visualise what it is that they really want the system to do. As an added bonus, they can also help to convince them that things really are progressing smoothly (especially when they see more and more of the agreed-upon user interface steadily becoming "real").

It is possible to plan the entire project lifecycle around the perception of rapid development. Remember, keeping the customer happy is as important to the project's success as delivering the project for real.

Software Reality Community Why not post a message to the accompanying message forum...

<< Back to Lifecycle

<< Back to Software Reality