Thursday, 28 April 2016

Agile Gluttony

if you want to bring in Agile Software Development to your organisation because of:

  1. you want to go faster
  2. do more
  3. do better
  4. to save money
  5. any combination of or all of the above
then you and your organisation is suffering from a serious case of Agile Gluttony.

If your primary motivation is any of the above you should really consider incremental process improvement in your current processes. I have seen on a few occasions, the first attempts at agile means a complete tearing up of the current process and the cutting out of nearly everything, except coding.

Unfortunately you can't go faster or save money by cutting corners. You can't do more by diverting everyone to coding tasks. You can't do better by delivering more code. When inevitably the organisation fails to meet the expectations the customer puts on it, there is great disappointment everywhere. The valley of despair for everyone, including the engineers, management and the customer, is a deep one.

There is only one reason to adopt agile software development processes. That is to satisfy your customers needs by the frequent delivery of working software. You care that your customer gets value. When you adopt agile for that reason, in the long term you succeed and reap the benefits. However the costs of putting in the necessary infrastructure and around your application and the coaching around your development teams that enable rapid and frequent deliveries will cost you a significant sum.

When you are able to frequently deliver working software to your customer; you don't need to go faster because you are perceived as responsive to their needs. You typically actually do less, harnessing benefits the old 80:20 rule1. You will definitely do better because you deliver less change per release and your automated test suits catch bugs the customer had before. And you will save money by not doing the features the customer doesn't want or need.

1. The 80:20 rule states that 80% of the time a user will use 20% of an application features. The features in this 20% set, are the most important features and need to work well all the time. However we need to be aware they may not be the most valuable features. The most valuable features are the ones a customer is willing to pay us for.