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.
"Make sure the customer sees progress in action"
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.
<< Back to Lifecycle
<< Back to Software Reality