An analyst firm has published a report it says highlights the confusion the agile software development method can cause in businesses, and the lack of kwowledge about its long-term costs. It also wrote a shorter report featuring models of how much rework could be needed.
The report by Voke Inc., titled Market Snapshot Report: Agile Realities, was based on a survey of 200 different companies using agile methods. Participants in the survey were asked how much they knew about the costs of reworking code, what benefits agile provided them and even what the definition of agile was.
Many companies using agile development methods don’t have a clear picture of the long-term rework costs, says Theresa Lanowitz, a Voke analyst who worked on the report. Forty-four per cent were unable to give a dollar figure. Another 35 per cent couldn’t identify a single benefit of agile, yet were able to name 35 challenges they encountered with the method.
Not only was there confusion about how to apply agile concepts, but there were 100 definitions of what the term even meant, she added.
Not only was there confusion about how to apply agile concepts, but there were 100 definitions of what the term even meant, she added.
Many companies using agile don’t realize that it leads to “the fundamental realignment of software engineering to a primary focus on software devevelopment,” Lanowitz says. The ownership of requirements is transferred from the business side to software developers through frequent code changes, she adds.
The findings, says Lanowtiz, suggest there is an “agile dilemma,” which is “the inherent risk and confusion created by the business desire for speed and flexibility, customer responsiveness and so on.”
“We believe that that’s really being misinterpreted as a mandate to participate in the developer-centric movement called agile,” she adds.
But Israel Gat, practice director for the Cutter Consortium’s agile product and project management service, says the report demonstrates a “fundamental misunderstanding” of how agile projects are managed.
He rejects the claim that agile is a “developer-centric” movement, stressing that it’s up to business executives to stay engaged in software projects, regardless of what method they use. Handing over ownership of projects to developers would indicate a lack of commitment on the part of business executives. Business integration into the development process, he added, is a “keystone of agile for the simple reason that without it we cannot succeed.”
He also took issue with the contention that agile is difficult to scale. In the report, the authors gave an example of a team of 40 distributed around the world trying to hold a scrum meeting.
Gat dismissed the example as irrelevant, given that agile recommends forming teams of seven at the most (plus or minus two). “I certainly would strongly advise any of my clients not to go in scrum with 40, with a single team of 40.”
Instead, he says, they would form six teams of roughly seven people each. He points to a client he’s currently working with that has 22 of teams this size spread between San Francisco, Hyderabad and locations in Europe. Synchronization, he says, is “essential to our success and has got absolutely nothing to do with the software method in use.”
“So yes, scrum scales. And no, if you’re going to scale it into a single team of 40 you would be in deep trouble before you can say scrum.”
As far as the lack of knowledge about what agile means among those surveyed, Gat says he doesn’t think it’s because its precepts are difficult to assimilate, but rather that some businesses aren’t committing themselves to learning and applying it. Agile has “levels of maturity,” and some companies are simply further along than others, he says.
