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 :)


  1. This was also a concern at my last company and I had extended discussions with product managment about release cylces, how much change our customers could take, how to package that change etc.

    A real concern for agile development, packaging sprints into releases.


  2. As you know, I am a firm believer in managing the balance between rapid system/solution delivery and subjecting the business to which you aptly call "change fatigue".

    But, if rapid change in the business is actually needed to remain competitive, it is time to re-frame the problem. This need for rapid change in the business becomes a requirement for information systems to support, so systems need to be able to support change, rather than having to be changed themselves.

    There is already a segment of the IT industry ready to help meet this need, the combination of Business Process Management, Business Rules Management, and Decision Management.

    So, given the need for business change is faster than the ability to change the systems supporting that business, I suggest that trying to catch up is not the answer. The business needs systems that support change, not systems that need to be changed.

  3. Good point David. Although, I can see some software changing itself in supporting business changes.

    But its interesting that Craig made the comparison to Mobile Phones. That's exactly what was going on in my mind.

    I want the latest handset. With the touchscreens and music players and bluetooth and WiFi. And I know when I switch handsets, things will change. I'll have to get used to new stuff (UI, nagivation, etc). Will it be better to have these extra features without a change to the UI? Sure. But do I really care so much about changing UI v/s new features? Not really.

    My dad on the other hand will probably stick to his old battered handset with Call and Text features for many more years.

    But we can't really say that the handset manufacturers should slow down because people might have "change fatigue"

    I think its just a decision we make as users, whether we want something cool and nifty or not. Of course, how much of cool and nifty is just vanity... is a separate discussion.

  4. Regarding "Large enterprises aren't known for their restraint when it comes to change." That depends on the industry and it is certainly not true of the insurance, banking, and retail industries. Here business continuity trumps new software/features by a long shot.

    There is a big wall between development and qa+delivery. When implementing enterpise ALM systems, I'm often fighting to prevent the business' tendencies to choke development (which would only lead to a backlash later on).

    Fortunately, (plug) my company, OpenMake Software, helps developers punch through the wall with our scriptless build tool that allows developers to deliver a build that the business can perform in a controlled and auditable way for delivery to QA and Production.

  5. Thanks for your comments guys.

    Do any of you have experience dealing whith this issue?

    It will be coming up for me later in the year.

    on the on hand we can just keep rolling out features and wait for business users to pick them up. On the other we can save them up in UAT and roll them out in clusters.

    There's been plenty of talk on the topic about prnciples, but what about examples?

  6. Anonymous9:39 pm

    It depends much on your audience (users). When people care more about having new features every two weeks than keeping everything in good old order, well, you should deliver what they expect. I think that's true for example in all kinds of online games. New features keep people interested in a product.

    On the other hand there are many scenarios (especially in software addressed to business) where consistency and continuity are far more important than rapid deployment of new features. I think project management software falls into this category. You don't want to teach all your team how to do some basic thing another way because old one doesn't work any more.

    Between this black and white there's a lot of gray where some changes doesn't hurt but they should be done at reasonable level. Many of desktop applications we use for our personal purposes are like that. Gimp is one of good examples - each time I download a new version it's changed and some options are moved somewhere else. However number of changes is limited so I don't feel lost after upgrading software.

  7. Anonymous6:50 am

    I tend to like the both/and perspective on this. The old code will not stop working just because there is now a new and better way of accomplishing the same thing.

    So, often, you can selectively transition folks to the new way as they find it compelling.

    Forward improvements to the old exposure should stop at some point, and folks will move to the new approach voluntarily as it acquires its own merits.

    At some point, the remaining holdouts will get cut off, to reduce the products overall complexity.

  8. Anonymous11:58 pm

    This seems more like a web design problem than a development problem to me. A product can be designed from the outset so that you can add to it without disrupting the work flows users have established. A top level menu system whose categories are general enough that you can fit almost any new feature under them, for example, allows you to release new features iteratively and allow users to discover what they need as the need arises. The problem may lie in treating each new feature as a "release" by shifting features around and making big front page announcements ala "Now with extra cleaning power!!!!" Constant improvement is not a series of events, and every addition doesn't need to be celebrated. Most of the time, it's enough to blog the new feature and move on. This is better than saving up features and doing a faux release. Why would you make an innovative new process mimic an obsolete process? Better to adapt how you think about the product instead.

  9. I come from two different backgrounds, I am an application developer in a small shop but I'm also a consumer of applications so I've been on both sides of software releases.

    As a consumer
    I cannot stand frequent software releases. I reviewed and purchased a component package for software development and they released new upgrades every month. Their goal was to put new functionality into the developers' hands and to have an attractive product to sell.

    However, this required a lot of time to upgrade and learn the new enhancements and eventually, I gave up on updating. Furthermore, their frequent releases also allowed many bugs to slip through. So it was a dichotomy, do I take the time to upgrade and fix the bug or can I hold off? Likewise, the software vendor didn't have time to offer usable documentation which created other issues.

    Marketing departments are the true pushers of frequent releases because they're trying to increase market share. So, that doesn't really help the guy who's currently using the software. I would've rather had a well thought out and tested product that would work for six months instead of having to upgrade every month.

    As a Developer
    As a developer, I do not like frequent releases. To explain, I'll start by stating that I'm not a fan of Agile development. The term agile is just new jargon used to describe old problems.

    For example, it wouldn't be politically correct to state that my unorganized boss has over-promised functionality to be completed in a ridiculous amount of time by his understaffed team and with project specifications that were written on a paper napkin. Instead, it sounds better to say he expects us to be Agile.

    Less sarcastically though, releasing software every month or two only releases more bugs. No matter how good your team, the shorter time to test is directly proportional to the quantity of bugs induced. What I've found after 10 years of experience is that you actually don't get any more accomplished because the next cycle involves fixing more issues. You end up becoming a fire fighter.

    Likewise, you end up tailoring every release to the squeaky wheel. As the saying goes, "the squeaky wheel gets the grease." So, this frequently changes priorities and you then have to begin taking people off of projects in mid-sentence only for them to go back to it later which can add more bugs even if that is not your intention.

    When I was fresh out of college, I was assigned the task of creating an ordering package that would allow our customers to order our products electronically. I planned it, coded it, created the install, and finished it in three months. There were bug fixes but they were minor so future releases had minimal impact. Had the releases been sooner, part of the time would've been eaten up by support.

    As a senior developer with years of experience, I have been assigned the task of creating functionality that will allow our company to send pricing updates to our customers. This involves exporting data to end-users and giving them their client software the functionality to import that data. A much smaller task than the three month project described above.

    Do to frequent releases, I've been taken off of this project at least five times. Primarily to help complete promised functionality, to test, and to a lesser extent to fix bugs. Because of this, it has taken a year to complete my project and there's still functionality that needs added to it.

    I apologize for the long post but I wanted to give a solid answer.

    Thank You.