Monday, March 27, 2006
Thoughts for the Agile Community...
Agile software development has the power to change how software is developed within corporate America, yet it hasn't been embraced in any big way. Figured I would throw out some thoughts to the agile community on how to increase its uptake and do so in a rapid manner...
1. The community has been well-served by the founding members but it is now time to find others to be the keeper of the flame. Communities grow and thrive when constraints to their growth are acknowledged and addressed. Imagine what would happen if the agile community got several folks who work for Fortune enterprises to not only passionately blog on agile (Scott Mark comes to mind) but invited these same folks to be keynote speakers at industry conferences.
2. Awhile back, I mentioned that I may consider no longer championing agile approaches which in hindsight, my perspective was more about the banner vs the practice. Reality dictates that the open source movement is also an agile method. I have always asked myself about the corporate partyline that states "we have a communications problem" whenever there are massive failures. The open source community has developed operating systems such as GNU Linux with thousands of developers who have never been in the same room, never participated in listening to the guidance of the all-wise potentate leader nor have even heard each others voice yet they continuingly deliver valuable working software. Is "communication" or lack of really a crutch for the lack of conceptual integrity? If so, emphasize better architecture over better communication.
3. Extreme Programming feels right in a coprorate setting but is it too a crutch for corporate dysfunctionalness? The notion of pair programming and encouraging developers to get feedback from another individual at one level is an incremental improvement within most environments while in another sense, wouldn't it be better for them to get feedback from the world? I think that one of the things that helped me improve as an architect is not the sterile feedback I tend to get in a corporate environment where everyone due to HR practice tends to be tempered and cordial but in the feedback by folks in the blogosphere who have taken my own thoughts and improved on them and likewise have given me brutally honest feedback whenever I slip. Isn't the real problem not about feedback from a single individual but the lack of open communication?
4. Doesn't extreme programming actually encourage tight coupling. Tight coupling of developers works at some level, but wouldn't a switch to looser coupling over email and common web sites increase productivity and increase the amount of folks who can participate resulting in better scale? I have yet to find a corporate environment at any large scale that has work environments truly suitable for pair programming. The cubicle mindset can't be easily fixed because this is not controlled by IT. Wouldn't it be better to change to approaches that IT does control?
5. The agile community at some level avoids talking about other efficiency gains that could be realized in corporate environments. For example, if I bring in my favorite consulting firm in to help with development of a new enterprise application, they may bring in new languages that help deliver it faster but what about reducing the total cost of ownership over its lifetime? What if multiple potential customers could combine forces and allow a product to be developed across corporate boundaries spreading the cost of development? The cost of lost productivity would be more than made up by the spread.
6. The agile community is savage in supporting the building of test cases first yet this seems disconnected from the contracts they sign with their customers. Would you convince more customers if payment wasn't based on either hourly constructs or fixed bid but instead payment for test success?
7. Would the agile community support the notion of developer ratings as a way to mitigate perceived risks of agile? Many enterprises are worried about working software that is unmaintainable just to get the next paycheck. What if there was a Slashdot-like moderation system where developers could be rated. If an agile developer writes unmaintainable code, their rating goes down and customers would get to see it in a more transparent manner.
| | View blog reactions1. The community has been well-served by the founding members but it is now time to find others to be the keeper of the flame. Communities grow and thrive when constraints to their growth are acknowledged and addressed. Imagine what would happen if the agile community got several folks who work for Fortune enterprises to not only passionately blog on agile (Scott Mark comes to mind) but invited these same folks to be keynote speakers at industry conferences.
2. Awhile back, I mentioned that I may consider no longer championing agile approaches which in hindsight, my perspective was more about the banner vs the practice. Reality dictates that the open source movement is also an agile method. I have always asked myself about the corporate partyline that states "we have a communications problem" whenever there are massive failures. The open source community has developed operating systems such as GNU Linux with thousands of developers who have never been in the same room, never participated in listening to the guidance of the all-wise potentate leader nor have even heard each others voice yet they continuingly deliver valuable working software. Is "communication" or lack of really a crutch for the lack of conceptual integrity? If so, emphasize better architecture over better communication.
3. Extreme Programming feels right in a coprorate setting but is it too a crutch for corporate dysfunctionalness? The notion of pair programming and encouraging developers to get feedback from another individual at one level is an incremental improvement within most environments while in another sense, wouldn't it be better for them to get feedback from the world? I think that one of the things that helped me improve as an architect is not the sterile feedback I tend to get in a corporate environment where everyone due to HR practice tends to be tempered and cordial but in the feedback by folks in the blogosphere who have taken my own thoughts and improved on them and likewise have given me brutally honest feedback whenever I slip. Isn't the real problem not about feedback from a single individual but the lack of open communication?
4. Doesn't extreme programming actually encourage tight coupling. Tight coupling of developers works at some level, but wouldn't a switch to looser coupling over email and common web sites increase productivity and increase the amount of folks who can participate resulting in better scale? I have yet to find a corporate environment at any large scale that has work environments truly suitable for pair programming. The cubicle mindset can't be easily fixed because this is not controlled by IT. Wouldn't it be better to change to approaches that IT does control?
5. The agile community at some level avoids talking about other efficiency gains that could be realized in corporate environments. For example, if I bring in my favorite consulting firm in to help with development of a new enterprise application, they may bring in new languages that help deliver it faster but what about reducing the total cost of ownership over its lifetime? What if multiple potential customers could combine forces and allow a product to be developed across corporate boundaries spreading the cost of development? The cost of lost productivity would be more than made up by the spread.
6. The agile community is savage in supporting the building of test cases first yet this seems disconnected from the contracts they sign with their customers. Would you convince more customers if payment wasn't based on either hourly constructs or fixed bid but instead payment for test success?
7. Would the agile community support the notion of developer ratings as a way to mitigate perceived risks of agile? Many enterprises are worried about working software that is unmaintainable just to get the next paycheck. What if there was a Slashdot-like moderation system where developers could be rated. If an agile developer writes unmaintainable code, their rating goes down and customers would get to see it in a more transparent manner.
