"It's really semantics," says Dinakar Vasanthakumar, Group CIO at the Logikal Group. "Agile, Waterfall, ASAP, SDLC, free-form, extreme development and so on. With over a dozen years in the IT and consulting world, let me clarify that there's no way any piece of code, logic or functionality can ever be brought out into this world without a reality check every so often. What does a proof of concept or a prototype attempt to do? What does the solution manager in SAP attempt to provide? It really offers a glimpse of what will be the end state of a product."
Patrick O'Reilly, CIO at MIP, holds a similar view. "A key differentiator between Agile and other methods is that Agile understands that the customer doesn't really know what they truly need until after they see that it's missing from the solution. We've always called it ‘scope creep', but it was really ‘depth of scope'. Agile enforces an iterative cycle of develop-test-show-feedback-repeat. This means we're exploring the depth of scope continuously, not only at the end of the project, which is way too late."
Guy Saville, director of IT and Credit Systems at SA Homeloans, believes Agile methodologies, when knowingly applied from the outset, are actually a better approach to risk management and value or ROI management than traditional methods.
"The key to Agile is the iterative and incremental approach to delivering business value," he says. "You invest only in planned, predictable increments, and you get quick and meaningful feedback and early value delivery, and you only continue investing for as long as the incremental value being added by the project team continues to exceed the incremental costs."
But given sufficient time, he would focus on the business benefits: "How to be customer- and value-focused – Agile is as much about ‘doing the right things' as about ‘doing things right', how to enable the innovation needed to continue to delight our ever-more-demanding clients, how to accelerate time-to-market for products and services, how to reduce non-value-adding waste in the organisation."
Agile depends on the team, and on every individual in the team managing themselves maturely.
He also says that the concern over the apparent flexibility of budgets and timelines in Agile projects is an example of a lack of understanding of Agile's methodologies, as well as of denying the inherent limitations and failings of traditional project management.
"There's a mountain of factual evidence that traditional project and system development methodologies don't work well in managing time and budgets in software development," he says. "In fact, they don't even work well for delivering something that the business actually wants and can use."
"Clearly explain to the business heads that Agile development methodology isn't time-consuming, as any other methodology really does the same, but in the guise of something else. Secondly, embrace the spirit of iterative development rather than the terminologies," he says.
As far as he's concerned, everyone is already using the Agile approach, and the only difference is in the nomenclature. "This is because, as a project manager or a vendor or a developer delivering commitment to a customer, I want to control and ensure that the end state is what the customer wanted and is true to what I incrementally discovered was the real requirement, designed and tested."
While the process of traditional project management and Agile development may end up being the same, accepting this from the outset requires a huge change in mindset from management, according to O' Reilly.
"In Agile, the focus is on the correct solution, not on meeting a deadline. Agile depends on the team, and on every individual in the team managing themselves maturely. To the traditional business, and traditional managers, this is frightening. In many cases, it's simply too much to ask."
As a result, he says many teams have continued with traditional methods, but started having daily meetings that they've labelled 'scrums', and claimed to be 'doing Agile'.
"Clearly then, successful implementation of Agile requires strong leadership – as opposed to strict management – of the Agile team, maturity from the developers, serious commitment from the customer, and trust from senior business management," he says. "This doesn't happen overnight. When these qualities come together, it allows the Agile team to focus on delivering the solution, rather than on meeting deadlines. The result will be solutions that really work and meet customer requirements. And yet, this does not necessarily mean that Agile will take longer."
First published in the September 2013 issue of ITWeb Brainstorm magazine
Our comments policy does not allow anonymous postings. Read the policy here