Hardly any agile left in Agile

This is something has been nagging at my mind in the last couple of years. When I started getting interested in eXtreme Programming in 1998 it represented a step up from some of things I was already doing with software development teams. We were using techniques best classified as Rapid Application Development. First eXtreme Programming and then the Agile manifesto represented lightweight methods to get software shipped.
There are two important parts of that last statement:
1. lightweight methods
2. software shipped

The concept of doing the simplest thing to achieve a goal, is an important part of eXtreme Programming. Traveling light (or not carrying baggage from previous experiences) is an important part of being agile. One of the aspects of agile that I always found attractive was the objective of enabling the development team to deal with change in short time frames.
While it may not be fully apparent, from the behaviour of many software development teams, the objective of developing software is to ship a product, a finished piece of working software. This desire to find better ways to get software shipped is clearly not something everyone in the industry shares. that is why we have collections of rules that appear to do nothing than keep people in jobs. Don't get me wrong, I appreciate that in certain situations we need 5 people analyzing the business rules in order to determine how to build software that manages a complex business process. The reality I often see is that the business process is not that complex and the reason the team has 5 business analysts is because the career path for developers in that company is to be promoted to a business analyst role.
I digress...
The reason for this post is to try and make you think about how the actions you are taking are really making you more agile (small 'a'). If your objective is to be able to handle change with as little pain as possible then following a hard set of inflexible rules is not going to help you too much.
Shipping software is a art that is not easy to teach by laying down a set of rules, in many ways it is much more like a creative activity than an engineering activity. Decisions have to be made that are not pure engineering decisions, they are not pure business decisions, nor are the decisions purely design oriented. It is a combination of all of these things and more.
Questions that need to be answered include; is the software aesthetically pleasing to the user, is the software functional, is the time right to release this to the market, etc..
There seems to be this constant flow of software with rules designed to help people become Agile, there are also more and more people professing to have the ultimate rule book for Agile software development.
In my opinion this is 90% bogus, the number of people that have a career telling other people how to ship software and have not actually shipped software in years (or ever!) amazes me.
If you want to be truly agile then drop as many tools as you can, learn to do more with less rules and restrictions, and most of all practice shipping software by actually shipping software!

Cloud and Client chat on CodeCast

In this episode of CodeCast, Ken Levy interviews Dr. Neil Roodyn discussion the differences and scenarios around cloud and client computing. Topics includes applications running in the cloud, documents hosted in the cloud, and rich/smart clients that use the cloud as part of the solution, with more and more of a mixture of client and cloud within applications rather than one versus the other.