As it was confirmed by a recent Methods & Tools survey, the adoption of agile approaches has been increasing recently. Following these results, I asked software practitioners on different discussion forums to share their opinion about the substance of agile adoption. As agility is now becoming “trendy”, we could see a number of organizations that will qualify now themselves as “agile”, without implementing the essence of the agile software development practices.
The fact that everyone could have its own definition of “Agile” is not upsetting. After all, agile groups different approaches like extreme programming, scrum, test driven development, feature driven development etc. The problem is that people will now adopt the “agile” badge as they could have been doing “RUP” before, just because it is the “right” answer. Besides this, the main obstacle to true agile adoption is the organizational context existing in large companies or governments agencies. As a participant cleverly says, it is difficult to transition from a “Command & Control to a Collaborate & Communicate structure”
Lack of documentation and control are the weaknesses the more often associated to the agile approaches. The truth is that agile recommends “just enough” documentation which could be different if you are developing a web site or medical device software. Short iteration could be considered as a very good tool to control project evolution and fight the “99% complete” syndrome that reveals many project failures. Practices are therefore not obstacles to agile adoption, but it is rather the environment where its culture should be living that makes successful implementation difficult.
The main issue faced by agile approaches is the traditional management vision of the software development projects. Drawing from the engineering perspective, many organizations wants to specify a solution and then estimate the time and budget needed to realize it. I suppose that you would not commit to build a new house without a detailed plan and a budget. Many managers don’t act differently when they have to invest in a new software system. The agile approach requires relinquishing the (illusion of) long-term control to accommodate changes during the project. We have a long history of organizations signing off projects knowing that the probability of getting the initial requirements for the budgeted price is very low, and this is also true for other domains than software development. People don’t ignore this situation, but the buyer mainly uses the project “contract” as a protection mechanism against criticism. On the other side, many sellers use the proposal only to get the contract signed, hopping to bargain about price and functions after the project has begun. We are sadly often more dealing with organizational politic than honest human relationships. This has caused often a situation of distrust between users and developers and transition open collaborative development is difficult. Users are reluctant to abandon the situation when they think they should know at the beginning of the project the answer to the question: “how much will I pay for what”. If things started to go wrong, managers don’t want to find themselves explaining to their boss that they started a project with a lot of (assumed) uncertainty.
The final question is: should we adapt organization to approach or adapt approach to organization and people? I support the agile trend to change the user-developer relationships, but I doubt that this will be a quick and easy goal to achieve, moreover in large organizations where the political aspect is more important. We should therefore keep in our toolbox different approaches to suit diverse organizational contexts.