Wednesday, January 14, 2009
Agile has the potential of becoming an IT worst practice...
The Agile Manifesto is filled with wisdom that is not understood by many who claim agility...
Another architect I know, recently commented that in 1999, if he presented a suboptimal (aka half-assed) architecture, he would have gotten it handed to him. In 2009, he can present suboptimal architectures with relative ease but if he violates the "process" he will get it handed to him. Is this true in your shop?
Seeing things through the lens of process encourages folks to focus on things such as CMMi and Scrum while ignoring practices such as extreme programming which has the potential of increasing quality.
My theory on it is that there's an increasing lack of architectural competency, which leads to the inability of an architectural governance group to form an educated opinion regarding the technical quality of any particular architecture.
When you factor in the political power that many architectural governance boards have, you end up with power brokering just to be in the group. All of that leads to a lack of technical knowledge. So, how does a non-technical group make evaluations of technical solutions? They rely on something they can understand and measure, like whether the solution follows the process.
It doesn't take long for the governance group, often driven by politics and power brokering, to start claiming success based their metrics for "process following". Reported success leads to more power, ad infinitum.
On the other hand, there's more than one way to skin this cat. You could argue that there's a "minimum" technical solution which meets the business case at hand, and some range of solutions from there up to the "optimal" technical solution. It would then be a matter of cost/benefit analysis in determining the best solution overall for the business. Of course, in this model, you would still need the technical expertise in order to identify whether the solution at hand is "minimum" or better; a process, by itself, will not suffice.
| | View blog reactionsAnother architect I know, recently commented that in 1999, if he presented a suboptimal (aka half-assed) architecture, he would have gotten it handed to him. In 2009, he can present suboptimal architectures with relative ease but if he violates the "process" he will get it handed to him. Is this true in your shop?
Seeing things through the lens of process encourages folks to focus on things such as CMMi and Scrum while ignoring practices such as extreme programming which has the potential of increasing quality.
My theory on it is that there's an increasing lack of architectural competency, which leads to the inability of an architectural governance group to form an educated opinion regarding the technical quality of any particular architecture.
When you factor in the political power that many architectural governance boards have, you end up with power brokering just to be in the group. All of that leads to a lack of technical knowledge. So, how does a non-technical group make evaluations of technical solutions? They rely on something they can understand and measure, like whether the solution follows the process.
It doesn't take long for the governance group, often driven by politics and power brokering, to start claiming success based their metrics for "process following". Reported success leads to more power, ad infinitum.
On the other hand, there's more than one way to skin this cat. You could argue that there's a "minimum" technical solution which meets the business case at hand, and some range of solutions from there up to the "optimal" technical solution. It would then be a matter of cost/benefit analysis in determining the best solution overall for the business. Of course, in this model, you would still need the technical expertise in order to identify whether the solution at hand is "minimum" or better; a process, by itself, will not suffice.
