Archive for September, 2007

How educating your business can improve IT’s efficiency

September 23, 2007

The basis of an agile transformation has to be trust. Building trust is the first job of an agile leader. We started by setting up regular meetings between IT and the business to share each other’s pain. The aim was to build relationships at all levels.

it was out of these initial meetings we realised that the idea that this was a transformation of just IT was very wrong: this was a transformation of the partnership between the business and IT. As such, a good deal of work was spent on educating the business on existing systems. This paid back in different ways.

Firstly, IT received less questions about internal systems and so were able to dedicate more time to getting client-valued software features running in production. Secondly, the business requested less and less unnecessary features — i.e. so-called feature bloat. As the trust built up, we also so less dark feature bloat from IT — so-called gold-plating. This used to occur when IT felt that the business had no real idea about what it was asking for and would not take kindly to hearing IT’s views, so they simply expanding the time needed to implement work and added the features they felt were needed.

I don’t want to give the impression that all this change happened overnight. They are significantly rarer than before but I still see gold-plating and feature bloat. However, the causes of these issues are removed as trust builds, and gradually they go away too.

Large releases mean less useful features in production

September 22, 2007

I remember at an old employer that we would parcel a number of features into large releases. At the time we thought it was more efficient to do this. We did not have a modular architecture, so everything seemed to be interconnected (often in illogical ways). For this reason, we needed to do a huge amount of analysis to check that we weren’t going to wreck something in the release. Similarly, the regression testing was huge. This had a nasty impact on our lead times, i.e. it took a long time before we could turn an idea into software working in production.

What we did not realise though was that these large releases hit us in yet another place, causing more pain and misery. The long list of features that was waiting on other features all had some kind of documentation, be it a line in an Excel sheet, a fully dressed change request document, or more analysis documentation. This is sometimes called software ‘work in progress’ or WIP. This derives from the name given to inventory in a factory that is neither raw materials nor finished product, but something in between. All work in progress perishes over time. Simply put, it gets out of date. Either business requirements change, or technical systems change, or both. So, someone needs to invest time to get the WIP uptodate. This time is time that is not used to get software working in production.

So, even though we thought these large releases were helping us to increase efficiencies, they were actually slowing us down. Per business-valued working feature delivered to production, we were investing more time than we would have done with small releases.

Large releases can be tricky to resolve, since they often have two or three root causes. Firstly, refactoring to get towards a modular architecture can help. Secondly, regular builds — i.e. more frequent than once every six weeks — will push you in the right way. This is often supported by regular regression tests and some simple configuration management best practices. Lastly, learning to define features as small increments that add value to clients is also vital to reducing release sizes.

In order to achieve this triumvirate of best practices, there is often a tendency to reduce value-added work, e.g. focus on refactoring to the exclusion of client-valued features. Avoid this like the plague — it pushes you into a vicious circle, where the business trusts IT less and less, and as a result, IT trusts the business less and less. Trust is the platform on which agile change is built.

Technorati Tags: ,