Tuesday, October 23, 2007

Successful Project

It has now been about ten months since my main client hired a new boss to sort them out. He seems to have made great improvements. The downside, personally, is that he now feels that the project in which I have been lead developer is sufficiently complete that they can do without me. I have agreed to work with them for a couple more months helping them become independent. Personally, I believe that the project still has much to do, but at the same time it is good that the client sees the project as a success, and that they are now confident they can proceed with it on their own.

This has been, perhaps, my most successful project to date - and certainly the one of which I am most proud. Several things worked well: we followed an agile approach with Crystal as its philosophy, and Extreme Programming as its practice, and this delivered on its promises. Having said that, we didn't do much pair programming - and that was perhaps a serious omission, since each developer became an expert in only one area of the system. Perhaps more importantly, we only has an on-site customer for about twenty percent of the whole time. This meant that we guessed requirements far too often. Furthermore, we released frequently: at least once per month, but received nowhere near enough feedback along the way. If I could change one thing, then, it would have been far more involvement by the customer's decision makers and business experts - rather than just their technical staff.

Comparing this project to earlier ones, I see that upper management can (and did) make a great difference to a project. If a team is just left to "get on with it" then it is highly unlikely they will magically materialise something that adds business value. Upper management needs to help everybody stay focused on delivering clearly articulated business value, communicative on progress and plans, and collaborative in steering towards them. Collaboration, I have learned, is not just about sticking people in the same room and telling them to work together, but about ensuring that people really care about and are committed to the success of the project, and put in personal effort to ensure that one another is as effective as possible. "Team players", then, are not hired or born, but cultivated.

The end of this particular project has actually caused me to reflect on a few of the project's successes:

Unlike just about every other project I have worked on over the past 20 years, this is one I am actually quite proud of. There have been ups and downs along the way, but overall I sense that the project has moved forward with a regular heartbeat, has resulted in a very happy client, and has taught me a tremendous amount both technically and professionally.

In fact, the project has been so inspiring, that I am going to take the core concepts from the project, and rework them over the coming months into a product with much wider appeal. As a sneak preview, I will be developing in the first instance several technologies that will simplify considerably the construction of CRUD applications. Although many developers look down at CRUD applications, I have found that non-trivial ones are very challenging, and very valuable to businesses.

It won't be until the end of the year that I start full time on this, since I am deep in the process of complete hand-over of my current client work. Starting in the new year, though, I will be developing pretty rapidly and full-time, and then releasing my output as open source software.

One vital point is that this is not intended to be a technology that can be thrown at any project to make it successful. Rather, the intent is to help reduce the technical burdens that plague many projects, so that developers and business experts can spend more time on communication and collaboration in working out business-value-laden requirements. The developers will still have to be technical, but should become more productive, freeing them to spend more time on systems analysis with customers. Furthermore, the technology will, I hope, match well with the agile principles of beings able to keep pace with requirements change, so that the collaborations between developers and business experts can remain ongoing and fruitful. That is, as well as eliminate big-up-front-design, we can let go of big-up-front-requirements-analysis.

The ultimate aim is then to establish a reputation as an effective collaborator in the development of practical software, which helps companies focus on delivering business value rather than being held back with technical distractions. From this, I hope to establish a new direction in my consultancy career - helping people to use the technologies I have released, in conjunction with several others that bring clear benefit. The focus will be always be on understanding evolving business value and how that maps to changing requirements in the software systems supporting that business value. It will be, for me, a fresh challenge, and I hope, for future clients, a rewarding experience.

No comments: