19 March 2009

A downside of agile development?

I use a few online services, and you can tell which ones have adopted the philosopy of incremental product roll-out.

Just about every time you log in, there is another feature being promoted and presented to you for consideration.  Sometimes things you were used to have moved or disappeared.

This constant change makes some products less appealing than something that is more reliable.

Yes, it''s the internet age and kids these days are disappointed they have to wait four hours until a new feature is released, but I think many of us still like the tools we use to have some semblance of stability.

Large enterprises aren't known for their restraint when it comes to change.  Frontline workers are used to constant process tweaking and product modifications.  (Think mobile phone and internet plans.)

I remember managing a team which was the communications focal point for all system, process and product changes for a particular organisation.  At the end of my first year we looked back at how much change had been funnelled through our team and discoverred it was about 3000 initiatives.  That added up to about one change initiative per staff member in a year!

At another job I talked about our project change management plan in the context of an organisation that had just gone through a series of large and significant changes.  The staff were suffering from 'change fatigue.'

Will an agile development approach amplify this problem?

As project people, how do we balance the benefit to us of frequent small delivery against the cost to our clients and users of dealing with too much change?

Have you got experience dealing with this dilemma?  What did you do and how did it work out?

Happy St Patrick's day - I'm having  guiness to celebrate :)

Search This Blog