Friday, November 25, 2005
Agile Software Development for Fortune 100 Enterprises
Several months ago, I went on a quest to identify individuals who are currently employed in a full-time capacity (read, no insultants) that have hands-on experience with agile development. Sadly, my quest resulted in failure. Of course it was easy to find agilists in large shops such as IBM, Motorola, Yahoo and other technology oriented places but couldn't identify much in the way of corporations whose primary business wasn't in technology.
CIO magazine recently did a feature on Capital One. Finally, the notion of being agile is starting to make it into the mainstream. I was previously of the belief that my peers were the only ones in a large corporation doing it. Glad to see that we are not alone in this world. Only if we could start getting those industry analyst types to start talking about agile methods, corporations could start addressing their real problems with aligning IT with the business and stop sending our jobs offshore.
Over the past several months and wise architect and Marine with the same initials as mines assembled a team to explore our own beliefs on being agile. Of course these types of discussions need to be tempered with political correctness and certain things simply can't be said, at least publicly.
Since the CIO magazine article has been released, pretty much every other CIO who practices Management by Magazine will start taking interest. Figured this is an opportunity, not to talk about an overview on agile but things that enterprises need to seriously consider to making agile work.
The iterative nature of agile software development requires strong project management and even stronger technical leadership. Many enterprises are filled with project managers who have never written a single line of code in their life! There is a possibility that some of these folks can bring other skills to the table that are useful but for the most part, the vast majority of this demographic may need to be moved other roles.
Likewise, enterprise architecture is vital to the long term success of agile methods because one needs to take a wider perspective. Both business folk and technologists nowadays understand the value of building enterprise service oriented architectures. Both of these audiences will appreciate the need to drive specific value through rapid deployments and take advantage of opportunistic moments. The danger though is that the business may develop something so fragmented and limited in scope (albeit adding short term business value) that over time the kinds of confusion you're going to see in the future may not yet be apparent.
It is my personal recommendation that EA's embrace agile software development approaches minimally for the following reasons:
Many EA initiatives tend to limit their thinking on agile software development to just methodology (aka process). Good EA understands that people, process and tools in that order guarantee success. Ignore the order and you will get burnt. Success is in the mix.
In order to have the right mix, you need to first have the right people on the team. A good process will only take you so far. Teams need to include experienced (folks with at least ten years of experience not folks with one years of experience ten times) and highly talented developers, as well as architects who can ensure that a coherent underlying architecture is built.
The most important element is the relationship with business managers. Getting the right balance between tactical objectives and strategic overview is just as important for executive decision-makers as it is for developers.
Here are several blog entries that provide a perspective that you should seriously consider:
| | View blog reactionsCIO magazine recently did a feature on Capital One. Finally, the notion of being agile is starting to make it into the mainstream. I was previously of the belief that my peers were the only ones in a large corporation doing it. Glad to see that we are not alone in this world. Only if we could start getting those industry analyst types to start talking about agile methods, corporations could start addressing their real problems with aligning IT with the business and stop sending our jobs offshore.
Over the past several months and wise architect and Marine with the same initials as mines assembled a team to explore our own beliefs on being agile. Of course these types of discussions need to be tempered with political correctness and certain things simply can't be said, at least publicly.
Since the CIO magazine article has been released, pretty much every other CIO who practices Management by Magazine will start taking interest. Figured this is an opportunity, not to talk about an overview on agile but things that enterprises need to seriously consider to making agile work.
The iterative nature of agile software development requires strong project management and even stronger technical leadership. Many enterprises are filled with project managers who have never written a single line of code in their life! There is a possibility that some of these folks can bring other skills to the table that are useful but for the most part, the vast majority of this demographic may need to be moved other roles.
Likewise, enterprise architecture is vital to the long term success of agile methods because one needs to take a wider perspective. Both business folk and technologists nowadays understand the value of building enterprise service oriented architectures. Both of these audiences will appreciate the need to drive specific value through rapid deployments and take advantage of opportunistic moments. The danger though is that the business may develop something so fragmented and limited in scope (albeit adding short term business value) that over time the kinds of confusion you're going to see in the future may not yet be apparent.
It is my personal recommendation that EA's embrace agile software development approaches minimally for the following reasons:
- Early, frequent delivery of valuable working software
- The opportunity to actually integrate closer with business drivers
- Increased visibility into projects
- Greater ability to adapt to changing requirements
Many EA initiatives tend to limit their thinking on agile software development to just methodology (aka process). Good EA understands that people, process and tools in that order guarantee success. Ignore the order and you will get burnt. Success is in the mix.
In order to have the right mix, you need to first have the right people on the team. A good process will only take you so far. Teams need to include experienced (folks with at least ten years of experience not folks with one years of experience ten times) and highly talented developers, as well as architects who can ensure that a coherent underlying architecture is built.
The most important element is the relationship with business managers. Getting the right balance between tactical objectives and strategic overview is just as important for executive decision-makers as it is for developers.
Here are several blog entries that provide a perspective that you should seriously consider:
- Requirements Gathering : Why Context Matters
- Facilitative Leadership: the alternative to command and control
- Cynicism, Apathy and Agile
- Experience is King
- Hacking and Refactoring
- The Catch Blog
- Carnival of Agilists
- Agile methods and fixed bids
- James Higg's Blog
- Quality without a name
- What Project Management is Not
It is becoming apparent that I haven't updated my blogroll in awhile. Need to get these folks onto it. Anyway, over the next week, I hope to post additional thoughts on agile software development here...
