Agile Development: Quack medicine or the tonic your developers need?
Relentless innovation is what makes working in the high tech industry so exciting. For many developers, working for a software vendor is where it’s at.
Being a developer for an end-user organisation is a slightly different proposition. Your customer - the business – sees technology as a tool and CIOs have the job of using the right technology for the job at hand.
Relentless innovation can therefore be a headache for others. Just helping consumers stay on top of what’s new, cool and important keeps many thousands of pundits and analysts in work. The decisions on when and how to embrace new technology, if at all, are not taken lightly.
So, where do you stand on Agile Development?
Like many development methodologies before it, Agile promises shortened delivery times for new software that is of better quality and does what the users want.
Many pundits are convinced. As are tools vendors, many of them having brought out “agile” tools or added the term to their company tagline to show their commitment to the cause.
Yet, for all the recent excitement on the subject, the principle values of agile software development were enshrined by a number of leading software engineers in the ‘Manifesto for Agile Software Development’ back in early 2001. Crucial to these values are that individuals and interactions are more important than the processes and tools being used.
Whilst this may sound like a great wheeze to keep the consultants in business, recent research doesn’t support this. Perforce Software recently sponsored research into developers with agile development experience and found that 75% of them believed that teams of around 50 developers were about as large as agile development methods could cope with. And 70% said that the most critical factor for success for large-scale projects was managing communication both within and between teams.
So, these developers support the view that the individuals and interactions are indeed more important than the processes and tools. But, the same research found that fewer than 25% of them agreed that the development metrics and measures in use were either appropriate or useful.
There is an old adage that “you get what you measure” and this research suggests that the processes and tools being used may be adversely affecting the ability of Agile Development to cope with larger projects by focusing attention on the wrong metrics.
In fairness to those doing the measuring, it’s difficult to assess the inherent value of communication amongst team members when compared to, say, the output per developer per week. But, in Agile terms, communication is the cause and relative output, the effect.
Purveyors and buyers of tools and processes take note. Agile Development success cannot be bought off-the-shelf. It requires a culture that gives developers the freedom to use the tools and techniques that are right for the job at hand, and to change them if they aren’t.
If you would like a copy of the research paper, contact Perforce Software and we’d be pleased to supply one without obligation.