Yes, we all know andYes, we all know and love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far? It could be that the promotion of the flexibility cause both teams, stakeholders and customers to expect and demand too much flexibility which causes too many and difficult to manage changes leading to project delays, quality problems and teams that had difficulty delivering value.
Yes, we all know and love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far? It could be that the promotion of the flexibility of the method is what causes both teams, stakeholders and customers to expect and demand too much flexibility. This causes too many and difficult to manage changes leading to project delays, quality problems and teams that had difficulty delivering value.
Is Agile too flexible for its own good?
In this
article by Lajos Moczar in CIO magazine, he thinks the whole method is flawed:
Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.
I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here…
In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes. Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it's an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.
From my perspective, it isn’t so much that Agile is too flexible, but rather that people are too flexible in their use of Agile. I think the real flaw is to blame the method for being flawed due to misuse, rather than one’s misuse as being the flaw that causes flawed results. For example, it’s like blaming a hammer for being a flawed tool because you tried to use it to hammer a screw into a wall, rather than admitting that your flawed use of the hammer is what cause screw to damage the wall.
I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself. What do you think?
I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself. What do you think? love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far? It could be that the promotion of the flexibility cause both teams, stakeholders and customers to expect and demand too much flexibility which causes too many and difficult to manage changes leading to project delays, quality problems and teams that had difficulty delivering value.
Is Agile too flexible for its own good?
In this article by Lajos Moczar in CIO magazine, he thinks the whole method is flawed:
Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.
I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here…
In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes. Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it's an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.
From my perspective, it isn’t so much that Agile is too flexible, but rather that people are too flexible in their use of Agile. I think the real flaw is to blame the method for being flawed due to misuse, rather than one’s misuse as being the flaw that causes flawed results. For example, it’s like blaming a hammer for being a flawed tool because you tried to use it to hammer a screw into a wall, rather than admitting that your flawed use of the hammer is what cause screw to damage the wall.
I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself. What do you think?
Posted on: August 12, 2013 11:37 PM |
Permalink