• View
• Edit
• History
• Print

CrystalisedDevelopment

There are many software development methodologies and they have been shown to be successful on many projects, however they all have their failures too. I believe that all projects which seek to create something follow the same broad model and understanding that model helps in understanding why projects succeed or fail. I also believe that this process is a fractal thing - you can look at ever smaller parts of the project and find the same process occurring. I have formed these views working on projects of all sizes, some of which succeeded and some of which failed.

The model is analogous to growing crystals from a salt solution, which is something most people do at school or with a home chemistry set. Within an organisation, at any given time, there are a lot of ideas sloshing around. Think of the ideas as being like a dissolved salt. Now either an idea gathers support and starts to crystallise or external pressure is introduced, which forces something to crystallise. Generally the first step of this crystallisation is shown by funding being approved, at which point certain aspects of the project solidify.

However most of the project is still fluid, and I believe this is now the critical stage. On projects of any significant size several parts of the project need to begin simultaneously. Therefore each of these elements also crystallise. Two things are critical at this point, firstly making the right things crystallise and secondly ensuring that the things that crystallise now will join up later.

Making the right things crystallise means concentrating on what is important right now, it may be setting standards, refining the scope or selecting technologies. But the temptation may be to dive in and start detailed analysis or procuring hardware or software. Sometimes it is very hard to get a particular element to crystallise. Once common area for this problem to occur is gathering user requirements. Frequently this area remains fluid and despite concerted efforts by the project management it refuses to crystallise. I will discuss options for bringing about crystallisation later.

Making sure the early stages are going to join up later means keeping good lines of communication between the currently isolated parts of the project (typically planning, analysis and architecture at the early stages). Remember that these early parts will grow quite rapidly and quickly lock in a lot of resource. If these things are in some way wrong then getting them to dissolve so that they can re-crystallise can be exceptionally difficult. There is a natural reluctance to completely undo all that has been done - and this might not be necessary. But there is also the fact that, even if a completely new team is brought in, tiny little seed crystals of what went before are still hanging around and hence the new work is strong biased to crystallising around these.

The premise of the model is that as a project develops various artefacts crystalise out from a saturated solution of ideas and options. Artefacts crystalise at various points in time and space and in sucessful projects the various parts must join up. The better they join up, the better the end product. Understanding this is one thing but benefit is only found if one can manipulate the solution so that the right things crystalise at the right time. Just like growing crystals from a salt, adding seed crystals is one way to make things happen. One of the best seeds is a person with the requisit skills - drop a top flight analyst into the mix at the right time and the analysis will quickly crystalise.

However we do not always have the option of manipulating the team in such a way. Consider an on-going development where a lot of code has been written but there is little to show the end users. Repeated requests to the developers for updates and demonstrations have been met with "we are working on back-end things" -you suspect that the developers are avoiding getting do to the UI and user interation. Dropping more people into the development team may have a negative effect, they will be sucked into the current team ethos and not necessarily produce more or produce visible components for end users. Another way to cause crystalisation is to increase the pressure.

In the scenario given above one way to increase the pressure is to set up a demo to the users and insist that the lead developer presents. This will force the development team to produce something visible. Ignore the whinging about how disruptive this will be. One of the enemies of the crystalisation process is time. Over time things will start to go back into solution, especially if they are in isolation. If they start to feel connected then this is less likely to happen.