In January 2010, Forrester Research published an in-depth report into how Agile development methodologies are being used. The headline finding was that the iterative, test-driven and collaborative approach to building software is now firmly in the mainstream.
Of the 1,298 professional developers surveyed, 35% said that one form of Agile or another best represented the way they create applications. That was a greater proportion than any other method: the ‘Waterfall’ approach, Agile’s polar opposite, was chosen by just 13% of respondents.
But the report also found that organisations are using Agile in all manner of different ways. Indeed, they found that more mix it with other methodologies (35%) and combine elements of the various forms of Agile (39%) than stick exclusively to one particular variant (27%).
“Agile orthodoxy is the exception, not the rule,” wrote the report’s authors, Dave West and Tom Grant. Indeed, they observed that “perhaps the clearest sign of the mainstreaming of Agile is the abandonment of orthodoxy”.
Information Age found evidence for this observation repeatedly throughout the year. Agile adopters often spoke of how they had picked the components of the methodology that suited their precise requirements, and mixed them with other approaches.
At UK broadcaster BSkyB, for example, the business intelligence team has adopted aspects of Agile to accelerate the delivery of BI projects.
Traditionally, a BI project would involve a requirements-gathering stage followed by a long period of development. After many months, a finalised BI infrastructure – that may or may not have met the business’s requirements – would be launched.
Under what Avi Marco, BSkyB’s head of business intelligence, describes as “agile BI”, a functional BI system, from the data model to the reporting layer, is delivered after every two-week sprint. As well as delivering value early, this allows the user to assess how well the system meets their needs.
Marco says, however, that the orthodox Agile methodology as it stands does not entirely suit BI projects, as there are important milestones along the way, such as integrating data sources, that do not translate to “story points” that are meaningful to the business user.
Similarly, engineering company Zühlke has for some time applied Agile, more commonly associated with web and application development, to large systems integration projects.
Applying Agile’s test-driven development approach is more complex for large integrations than it is for websites or applications, says Wolfgang Emmerich, CEO of Zühlke UK, as there are more variables involved: “You have to build a harness around the system so that you can test its behaviour from the boundaries.”
Other organisations are even adapting Agile for use outside IT. British Airways, for example, which adopted Agile for software development in 2008, has since applied elements of the methodology in developing ideas for new revenue streams.
By creating Agile-like ‘Revenue Labs’ for business staff, the airline was able to accelerate the speed with which potential revenue streams can be appraised, costed and initiated.
“Rather than a team spending three weeks on a very nice PowerPoint presentation and taking it to a steering committee, senior management comes down to the [Revenue Lab] and sees the raw materials,” BA’s head of IT delivery, Mike Croucher, told Information Age in September 2010.
Once an idea is finalised it feeds directly into the Agile software development process. “When the proposition team is done, someone from that team will form part of the Agile IT team developing the system to support that proposition, so you get that cross-over,” Croucher explained. “And sometimes you might need to feed back from the Agile IT team into the proposition team.”
According to Chris Field, president of the Project Management Institute, rather than replacing its predecessors, Agile is becoming one of a number of tools available to software development projects, with its own strengths and weaknesses.
“The way to look at these things is to think about the characteristics of the project, and use different aspects of the methodologies that are appropriate,” he told Information Age in early 2010. “Going forward, Agile will drop into the same toolkit as past approaches like Waterfall and Prince.”
It may be just one of many tools available, but Agile nevertheless presents some unique management challenges of its own. For example, because the methodology relies on frank and open communication between team members, it places an emphasis on ‘people-skills’ that some programmers may not be used to.
“In an Agile world, developers must have courage,” BA’s Croucher explained. “They need to be able to say to the business, ‘I only have this much velocity, so you can only have certain features – what do you want me to prioritise?’ And they have to be asking, ‘Are we driving the top-value items or are we driving something that is just nice to have?’”
He revealed how some of his more senior developers were reluctant to adopt Agile at first, although most have since come round to the idea.
According to Stuart Mitchell, a project manager at banking giant HSBC, Agile teams are particularly sensitive to the motivation of individual members. “If you’ve got devolved responsibility and everyone is offering to help each other out, that’s when Agile is at its best,” Mitchell told London’s Agile Business Conference in October 2010. “But if you bring someone in who doesn’t pull their weight, it can drag everyone else down.”
This explains the rigorous process that HSBC uses to recruit its Agile developers. Candidates must be approved by every level of the development team, from programmers through to the project sponsor, in order to get the job.
The project manager’s role is equally impacted by Agile. According to Forrester Research analysts West and Grant, the methodology frees project managers from being “the enforcement arm of the project plan”.
Instead, their responsibility is to “[create] the best working environment possible” and to “track and communicate project status”.
For IT executives overseeing Agile adoption, two critical tasks will be to identify project managers with the skills and propensity to fulfil this new role and to supply them with the necessarily tools.
If the experience of BA’s Croucher is at all typical, it could well prove to be a rewarding initiative. One of the principal benefits of Agile adoption, he said, has been the way that it has motivated his development staff: “Some have said it has changed their lives.”