No paperwork, no promises, not even any chairs.  Sounds crazy?  Sounds Agile discovers Carl Hancock…

Computers now populate nearly every aspect of our lives from our schools and business, through into hospitals and up into the highest echelons of central government.  The Geospatial industry is no different.  The way that the software run on those machines has been produced has remained fairly static ever since the days when a computer was the size of a small house, yet since the turn of the century a minor revolution in software development has been taking place.  Carl Hancock talks to Project Manager Dinesh Thanigasalam about the changes that are taking place…

(To read the published article click here)

Carl Hancock:  Firstly, thank you for taking the time to talk with us.  Before we move on to talking about the Agile Method of Software Development, you could give us an overview of the history of software development?

Dinesh Thanigasalam:  Well originally software development was a process in which the customer would list their requirements, the software developers would then go away and build that software, it would be tested and then put into use by the customer and though this process sounds simple enough for as long as there has been software development, there have been failings in the system.

This became known as the Waterfall method, which was a name attributed to this model by a man called Winston Royce in his 1970 paper, ‘Managing the Development of Large Software Systems’.   Ironically, rather than introduce the name to promote it, Royce’s intention was to criticise it and though his criticisms were largely ignored, the model itself received considerable interest.

CH:  Can you describe to us the failings of the waterfall model?

DT:  Well one of the key failings with the Waterfall model was the level of documentation required, which often stretched to several hundred pages.  These documents were intended to lay out exactly what is was the customer wanted so that the software developers could go away and precisely build to those specifications.  Unfortunately though such documents were reliant on good understanding and communication, and unfortunately what was happening was that the customer, though able to have a vision of what they wanted, without being IT experts were unable to clarify exactly what that vision was.  Naturally therefore, the software developer was liable to misinterpret that and so the documents from day one would be inaccurate. 

Put simply, no matter how good or competent you are from the customer side or the software development side, you will never be in a position where you fully articulate what the system should be.  By the very nature of the waterfall model, these problems would not become apparent until the very end of the process when the customer would turn around, often after months and months of development and say, “This isn’t what I asked for.”  This led to the painful practice of project overrun and increased expense but through the frequency of such occurrences it ended up becoming the accepted norm.

CH:  So how did the change come about?

Momentum had been building for a while but it was really in 2001 when a group of software developers decided, ‘this is just not a good way of working’ when the Agile Model of Software Development was born.  One of the key concepts to it was to dramatically reduce the amount of documentation.  It was thought, there is no need to spend a huge amount of time documenting because that documentation everyone knows will be inaccurate.  You can spend months doing it and at the end it’s a document that doesn’t do what it’s supposed to do.

In addition to reducing the level of documentation, something that Agile not only accepts but embraces is the fact that the customer will invariably change they mind, whether through a new influence on the business, a change of priorities or indeed any number of reasons.  To accommodate this, the agile process has removed the concept of delivering the software right at the end of the process; rather than months of arduous work before presenting the software, the Agile model actively encourages customer participation throughout the process, allowing them to visualise and see what they’re getting right from the start so at the end of the project there will be absolutely no surprises.

Within this the customer is able to prioritise their needs and have the software built with this in mind.  Therefore a complete package that might take six months from start to finish could allow the customer to have the most important part complete and running in a month, the second most important after two months etc.  From the developers perspective Agile then is a very test-driven approach because of the need to be frequently delivering production quality software. In Agile you no longer build a whole load of software then do some testing at the end; you build a little bit, you test it, make sure it works as it should do and then you deliver it to the customer.

CH:  With regards Agile, how did you first come across it?

DT:  I’m from a formal software development background having started as a support engineer for a company called Borland, moving into software development with Independent Computer Solutions working with both Oracle and SQL servers.  From there it was a natural evolution in Customer Relationship Management (CRM), progressing through from an analyst into project management, eventually running the CRM department at Touchstone.

One of my first objectives at Touchstone was to develop our client based and aim for bigger and more complex projects.    Now as we did that the small projects that had 50-100 man days of development started to become frayed at the edges and we realised that as soon as you get to the 200, 500, 1000 day projects that the old processes were really found wanting.

It was when I took up a job at Conchango, who were very much at the cutting edge of technology that I was introduced to the Agile method.  One of my first Agile projects was for a leading High Street Bank that wanted a new commerce system, developed from scratch, completely bespoke with a backend customer services system.  This involved for us 1400 days of work crammed into seven months.

Not only did we do it on the dot and went live in seven months, much to the astonishment and general excitement of the people within the organisation but the company then went on to hit its objective of selling an additional 1000 loans per month, within a month.  The comment was, if all our projects did this it would be amazing and for me this was proof that you could actually develop a huge amount and have it delivered a lot quicker and without all the documentation, all though the use of Agile.

CH:  And what about your current company, Aligned Assets?

DT:  Well I’d known Carl Nunn, the Managing Director at Aligned Assets for probably 12 years having hired him as a MapInfo expert at my first company when we were moving into the GIS industry.  We kept in touch so I’d always had a knowledge about Aligned Assets.  The last time I heard though it wasn’t just the two or three people from its original formation, it was over 30 people, which to me is a good sign of success, drive and energy.  From talking with the directors it was apparent that the whole GIS market place from a software development perspective was still lagging behind in terms of the old ways.  So that was my attraction to the company – not only Aligned Assets’ reputation but also the scope that we could then start marking good things in a different way as well.

CH:  Aligned Assets are known for their gazetteer management solutions within the public sector.  How different was it to adapt Agile methodology from the private to the public sector?

DT:  In one sense the public sector customer is no different to one from the private sector in that their needs from a software development perspective are the same – they want the software to do what they want it to do for a set amount of money and delivered in a set period of time.

We are currently working with some local authority clients whoa re willing to adopt the Agile process and I believe that once we show the success from this work then the momentum will build up and it will filter through the local government community.  My perception is that it won’t be long until they are saying, ‘hang on, perhaps this is really a good way of doing things.

With regards our work with the emergency services there does tend to be a higher degree of documentation control but as the term Agile implies, you don’t have to follow absolutely everything to the letter of the law.  Agile fundamentally is a pragmatic, customer-centred model that is adaptable enough to says, ‘ok, let’s use Agile for this part, but a more conventional approach when required.

Whilst the waterfall model was very much just about producing software to a specification, with Agile the projects are so bound up with the customer that one for local government it delivers specific local government functionality and the same is true throughout the public sector.

CH:  Finally, could you sum up for us the benefits that a company using Agile software developers can expect over those that use a more traditional approach?

DT:  The benefit is that the end user, the customer, will have influence, can see what they are getting right up front so always know what they’re getting, and they get it quicker and faster.  Safer, quicker and monetarily a more efficient process in terms of getting what’s required.

To read the published article click here