We are currently working on a cool application for the Fire Protection Association (FPA) called Robust. The goal of the application is to ensure businesses are suitably prepared when an incident occurs (e.g. a Fire) Based on information gathered from the various core business activities it aims to help minimise any business impact and provide guidance on recovery options.

On a side note the technology stack used for this project is also very interesting; we are using Windows Presentation Foundation for the UI, ADO.NET Entity Framework and SQL Server Compact 3.5 SP1. I will leave one of the team to delve more into this in another post.

We have learnt some very important lessons about agile practices and their value to our customer (FPA) Any project that is undertaken will yield knowledge for the entire team (including the customer) in both the business and technical domains.
It has been an absolute pleasure to work with our customer, Jim Glockling who is the Technical Director at FPA.

Here are some of key project lessons:
1) Initial estimate of cost – Getting the initial cost of the project right and whether it can be done within a customer’s budget is really important. This is not the same as providing a “fixed price” but it is to ensure that you can deliver something of value to our customer within the assigned budget. I do not need to reiterate how difficult it is to estimate software projects.

2) Feedback – The show and tell sessions where we showed Jim what we had managed to deliver allowed him to feedback points he thought were great and places where we needed to make changes. This also gave Jim visibility that we had actually delivered valuable and working software. This feel-good factor is so very important in a project.

3) Iteration 2 nerves – I could lie and say everything had gone smoothly from the start in this project but this wasn’t the case. Our show and tell for Iteration 2 led to Jim feeling really anxious about the project as we had missed some key things. I mentioned to Jim that in the early stages of a project we are still learning about the project, the business domain and that he should trust my team. Whilst mulling over this “bad” iteration I concluded that the team had missed these key points early in the project and learnt from the experience. This incident was picked up because of the simple “inspect and adapt” process baked into our agile process.

4) Delivering working software – Jim has been able to show people a working application. This has allowed him to secure extra budget for more features and has attracted the interest of large insurers. We are gleaning business value early!

5) No change requests - Scrum advocates that Jim is able to change the features that are being developed at the start of each iteration. He has been able to push in features that were relevant to the large insurers without incurring any cost for straying from an originally agreed set of features (usually outlined in a functional specification)

6) Customer commitment – If a company really wants a project to be successful it should be committed to ensure its success. This means a company should give our team as much access as required to an individual who can drive the project from a business perspective so we can get decisions made quickly. Jim has ensured he has been available to make sure we get information and feedback quickly.

Software development using any chosen methodology is not easy; having an open and honest approach coupled with aiming to maximise business value are some of the principles in our process that lead to project success.