Friday, December 09, 2005
What's wrong with Agile, SCRUM, XP and other methodologies...
Several of my peers over the last couple of weeks have been noodling how to bring agile to the enterprise at large. We have had great success in small pockets but never took the big jump to incorporate it into our fabric. Anyway, figured I would share a central theme in our discussions...
One common theme that seems to hold true whenever I talk with architects at other Fortune enterprises is that their internal methodology always seems to feel waterfall. With the word agile being plastered in magazines such as CIO, SD Times and others, CIOs who practice management by magazine are sure to consider agile software development as something to explore in 2006. While I am a big fan of agile, I wonder if anyone has ever put serious thought into thinking about open source as a software development methodology? Would enterprises be better served if they were to not adopt agile and head straight towards open source?
Let me give you an example. In Extreme Programming, the notion of pair programming where two individuals work together to ensure quality is a good behavior to encourage in corporate environments. Many corporate cultures are disgustingly polite when it comes to the ability of one developer to provide feedback to another. By making two people work together solves for the HR issues surrounding agility but isn't it really a crutch?
The amount of effort required to change corporate culture towards agile approaches just to make two folks talk with each other is simply encouraging and perpetuating dysfunctionalism. Maybe if you IT folks figured out how to not be disgustingly polite to each other and focused on adding value to the business, our jobs wouldn't be headed offshore. Maybe corporate America would be in for a rude awakening if you took the code of developers whom you believe to be stars and had it reviewed by the public, your perceptions may change.
Don't get me wrong, agile is something that I am an advocate of. I also believe that agile isn't the only impediment to developing working software and that enterprise architecture plays a critical role in the success of agile software development. Maybe, the real problem I have been noodling is that the way we are generally expected to build software is just plain wrong. It's not just "Agile" vs. "Waterfall", but it's the entire context and methods around construction.
We need to kidnap all the analogies to engineering, or architecture, or physical construction that are pontificated by IT executives and architecture teams. Of course the agile community has adopted the notion of gardening which I like better. Would love to see this aspect talked about more as it represents the principles of incubation, stewardship and yield.
One notion of architecture and the infamous equation of city planning is corrupt. Analogies are OK but analogies are just models. Models of facets of software or other aspects of IT lifecycle such as operations, infrastructure, etc that do not encompass or define the entire activity.
Software is messy at best. A big steaming pile of bleep comes to mind whenever I think of software. Unlike buildings, software is not governed by the laws of gravity nor do most other physical laws apply. Simply, there are little or no real world constraints. One person's thing of beauty is another's nasty pile of bleep. It can't be codified into a few simple rules (managers know this as best practices) that anyone can follow.
Software development is a unique activity, a combination of creativity, problem solving, communication, iterative learning and most importantly comprimise that the world has not seen before. Enterprise architects need to acknowledge this fact and stop attempting to equate software development with engineering or building construction...
I leave you with several blogs that are worthwhile reading on agile software development:
Crossing the Agile Chasm
Agile Business Methodology
Estimating Frustrations on Agile Project
Hackers and Painters
Agile Process Smells
Evidence
| | View blog reactionsOne common theme that seems to hold true whenever I talk with architects at other Fortune enterprises is that their internal methodology always seems to feel waterfall. With the word agile being plastered in magazines such as CIO, SD Times and others, CIOs who practice management by magazine are sure to consider agile software development as something to explore in 2006. While I am a big fan of agile, I wonder if anyone has ever put serious thought into thinking about open source as a software development methodology? Would enterprises be better served if they were to not adopt agile and head straight towards open source?
Let me give you an example. In Extreme Programming, the notion of pair programming where two individuals work together to ensure quality is a good behavior to encourage in corporate environments. Many corporate cultures are disgustingly polite when it comes to the ability of one developer to provide feedback to another. By making two people work together solves for the HR issues surrounding agility but isn't it really a crutch?
The amount of effort required to change corporate culture towards agile approaches just to make two folks talk with each other is simply encouraging and perpetuating dysfunctionalism. Maybe if you IT folks figured out how to not be disgustingly polite to each other and focused on adding value to the business, our jobs wouldn't be headed offshore. Maybe corporate America would be in for a rude awakening if you took the code of developers whom you believe to be stars and had it reviewed by the public, your perceptions may change.
Don't get me wrong, agile is something that I am an advocate of. I also believe that agile isn't the only impediment to developing working software and that enterprise architecture plays a critical role in the success of agile software development. Maybe, the real problem I have been noodling is that the way we are generally expected to build software is just plain wrong. It's not just "Agile" vs. "Waterfall", but it's the entire context and methods around construction.
We need to kidnap all the analogies to engineering, or architecture, or physical construction that are pontificated by IT executives and architecture teams. Of course the agile community has adopted the notion of gardening which I like better. Would love to see this aspect talked about more as it represents the principles of incubation, stewardship and yield.
One notion of architecture and the infamous equation of city planning is corrupt. Analogies are OK but analogies are just models. Models of facets of software or other aspects of IT lifecycle such as operations, infrastructure, etc that do not encompass or define the entire activity.
Software is messy at best. A big steaming pile of bleep comes to mind whenever I think of software. Unlike buildings, software is not governed by the laws of gravity nor do most other physical laws apply. Simply, there are little or no real world constraints. One person's thing of beauty is another's nasty pile of bleep. It can't be codified into a few simple rules (managers know this as best practices) that anyone can follow.
Software development is a unique activity, a combination of creativity, problem solving, communication, iterative learning and most importantly comprimise that the world has not seen before. Enterprise architects need to acknowledge this fact and stop attempting to equate software development with engineering or building construction...
I leave you with several blogs that are worthwhile reading on agile software development:
Crossing the Agile Chasm
Agile Business Methodology
Estimating Frustrations on Agile Project
Hackers and Painters
Agile Process Smells
Evidence
