...every problem looks like a nail.

Date: 21-10-2010 12:58 | Author: Derek Glen | Category: Change management | Tags: change, agile, scrum, process, improvement, tools

In yesterday's post, I explored how people may (unintentionally) limit themselves when it comes to tackling problems, based on what they know and what they can do. It's interesting to note that we've come across a few telling examples of this over the past year whilst developing our 'Agile Framework'.

The company, for example, which has invested heavily in its agile environment, building state-of-the-art 'pods' which are geared up to support small, integrated Scrum teams. They major on communication, with interactive whiteboards and a communal, touch-of-a-button video-conference system which can instantly link the team to their counterparts at any of half a dozen other sites. All of this technology focus is home territory for a company at the cutting edge of communications technology.

But is it working? Well no, not yet. The technology is lovely, but the teams (and the individuals within them) have not yet adopted the right behaviours to get the most out of them. Savings have been made, of course, through lower travel costs, but have the benefits of Scrum been realised? No.

An internet company with a 'difficult' supplier (which develops much of their core platform) has plans to adopt Scrum as the heart of its agile development approach. The benefits case, however, is incomplete, as contractual constraints make it too difficult to bring the supplier along on the transformational journey.

So Scrum may be used in a small way, by some peripheral teams, whilst the real value proposition - changing the development of the main product to agile - remains untapped and on the 'too hard' pile.

Then take a third case - an organisation with a robust and well-established development methodology, has invested heavily in agile techniques over the last couple of years, trying to introduce elements of agile into its existing lifecycle. However, certain parts of the lifecycle, such as a structured, but inflexible test and release cycle, have prevented even those teams which have whole-heartedly adopted agile from reaping the benefits of early success.

The consequence in this particular company? Well it seems their interest in agile is waning, with fewer teams adopting it, and management interest has started to move on to other ways of 'doing things differently'. Some are still using it in places, but the benefits are hard to find. Yet across industry in general, agile methods are very much in vogue, with more and more companies embracing them.

More evidence that in order to identify and embrace opportunities for improving efficiency, you must look at the problem through a variety of lenses, not just the familiar ones closest to hand.