If you take a closer look at all the instructions on agile methods, you may wonder if these are not really the return to the good old hobbyist mentality. We are going to try something and if it works – OK – if not, let’s continue.
The word agile is often used more as a decorative adornment: “see how agile, contemporary and hip we are”. In truth, nothing happens differently than in the 80s – basically only that now fewer people are employed and therefore more workload per team member is incurred. Agile should help in this situation to free-float the work in these smaller teams.
If a project is straightforward, agile methods can get you to the goal certainly faster. However, this approach is in conflict with the most common large scale projects, which are broken down into many small sub-projects. The subprojects are related to each other but are all assigned separately to different teams, some of which are scattered around the world. In such a set-up hobbyist mentality is only possible to a very limited extent, if at all.
The whole process in large scale projects follows more like a flow production of the individual project contents, but without being able to see the big picture. Inevitably, there must be rigid rules and definitions on how one subproject reacts to or has to deal with the other. What speaks against an agile project method.
Conclusion: agile methods are ideal for small projects, in which something is quickly tried to come-up with a quick result – utilizing an opportunity to act out of a rigid project framework. But for large projects the method is rather counterproductive, especially with separated global teams in work. In this case, controlling methods must be used to reach the goal.
