Agile’s enterprise evolution?
As we know, Agile’s methodology for the creative process anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Although it has plenty of critics (what? developer cynicism – no really, it’s there), Agile focuses on keeping code simple, testing often and delivering functional “bits” of the application as soon as they're ready.
The goal for Agile is to build upon small client-approved elements of the total solution as the project progresses, as opposed to delivering one large chunky application at the end of the project. To use a cooking analogy, being fair, I do recognise that to some, chunky style if far preferable to a puree.
But is Agile on a large scale feasible? Seeking a higher level of enlightenment here, I spoke to Borland following their keynote speech with BT at London’s Agile conference this week. To appease my curiosity, they told me that they have been working on a large-scale Agile project, with BT no less. It is widely believed that Agile is predominantly more suitable for smaller scale projects. But Borland’s Pete Derry gave me an insight into the scale of the their workings with BT in a bid to convince me that Agile can indeed work to a much larger scale.
Going back a few years, BT realised that the traditional method of using Agile was becoming outdated. Too often the original model was unable to change as requirements changed, often combining to create many of the industry’s typical project failure scenarios such as overruns, functional problems and busted budgets - issues that we read about all too regularly.
BT recognised that all their suppliers also needed to use Agile and so set about working on a fresh implementation of Agile with Borland. One of the key reasons for the success of this project (or so I’m told) was recognition of the key requirements the customer wanted and communicating closely with them. Well, you would hope so wouldn’t you? But it is of special importance here because for Agile to work properly, a very close relationship is needed between development teams and the business they serve. Vague requirements can only add to problems further down the line.
Throughout the project, Borland needed to keep a variety of stakeholders happy every step of the way. Using workshops, Borland was able to get every single stakeholder to agree on priorities of the project thereby circumventing the classic problem where each customer thinks their priority is the most important.
Fans of Agile will argue that it is largely common sense and that it is faster, more efficient, involves less capital risk, is more business friendly and creates a better working environment than traditional software development methods. Equally, critics of this methodology will mock its lack of design structure and piecemeal approach to overly granular level detail arguing that it fails to encompass a longer-term holistic view of the total project.
As for me – the jury is still out on this I’m afraid. Probably because of the fact that being a software application development journalist I get bombarded from every side all the time. I’ll leave it up to you to place Agile somewhere on the evolutionary scale. However, it’s interesting to see an Agile approach delivering benefits on such a large scale.