Skip to content

Is Agile software development like a bad movie?

June 11, 2012

Movies reflect their times.  1930’s gangster films always had the final scene where the condemned to die’s mother tells the judge “he’s a good boy deep down inside”.  Makes sense – we had that national crime issue, back then.  Today, Sci-Fi movies are about technology out of control, taking over the Earth, being brought over by spaceship or developed in a laboratory (some say even a dorm room). In Corporate America, tech going amuck is more likely to be an out of control software project.  We’re seeing a recent spate of multi-million dollar system development, or licensed software implementation, project budget overages, or under-deliveries, all tied to one word – ‘agile’.

Many organizations have adopted Agile as a preferred methodology, and with good reason.  Traditional waterfall (sequential) systems development methodologies were taking too long, being logical extensions of slower Industrial Age business and assembly cycles.  Often, by the time a system was launched, the underlying need had long since changed before anything workable could be delivered.  The response was Agile, a methodology permitting many iterative deliverables, based on a supposedly faster cycle time closely aligned to an Information Age economy.  We overreacted, throwing out everything that came before.

The Agile Manifesto was introduced in 2001, and almost immediately found broad acceptance from the developer community as it relieved them of having to work with end-users on extensively documenting specific sets of desired functions prior to coding.  It de-emphasized functional specifications and applications design over speed, assuming end-users have little knowledge of exactly what they wanted, except in very wide ranges of functionality.  Therefore, design was a non-issue. It made being a developer heroic just by developing.

End-users liked Agile as it gave them a feeling of incremental progress, as opposed to more traditional ‘big bang’ delivery cycles, freeing them from having to invest time up-front in thoroughly thinking through what they wanted, or at least, dimension the bare set of minimum requirements (and it’s hard to get blamed if it’s not in writing).   Since no one was really sure exactly what they were building in any great detail, project estimation, and resource allocations plus budgeting became a SWAG, at best, hurting all parties. Most project management methodologies and related tools still have trouble coping with the Agile method’s unique need for discipline, making up-front risk mitigation and standards adherence very difficult. Soon, while developers and their business end-user counterparts loved the freedom from documenting, deeply understanding and designing, business and IT leaders began to fear the very word ‘Agile’.

Besides initial disappointment at longer and more costly than expected development cycles, business users began to get angry over sequentially less accurate estimates for new features and enhancements over the application lifecycle.  For example, if an application has a 5 year+ lifecycle, subject to enhancements, and does not have a firm architecture/design underneath, the probably of having to pay an increasingly expensive technical debt is virtually 100%.  IT leadership, always running under tight budgets, didn’t appreciate having staff tied up way beyond scheduled release dates, impacting other projects.

As business leaders, how can we control and ideally prevent a runaway train?  First, we have to state what we want this application to do to the user, i.e., what will be our best-case take-away emotion.  Not what set of functions do they require, but how will they feel while using the product and how will they feel the next time they have to use this system?  You can call it the ‘iPhone fallout affect’, if you like; the bar has been raised so high due to the way we use smartphone apps – we enjoy using them because we assume they do the job in a way that makes us happy.  Rarely do we dread using our apps.  By focusing on the emotion, we can rapidly understand the full range of required functionality to be designed into the application, as our assumption is only a fully functional and easy to use system will provide a great experience.  No matter how cool a user interface may be if the system doesn’t get the job done, the take-way experience will be negative, much like craving a junk food burger and then leaving the store disappointed.  Conversely, I have seen highly functional applications so hard to use, the company had trouble hiring or retaining new users.

Emotion forces discipline as it is domain related and therefore developers have to understand what they are creating as a totality, which is a lot more than code in response to a series of User Stories (the predominant method in Agile to say what you need, feeding the detached iterative development machine). What experiences drive emotion?  Examples are:

  • How many times do I have to login?
  • Can I change a quantity just before or immediately following checkout without almost starting over?
  • Can I resolve disputes readily without having to navigate across multiple applications and screens? Can I feel good that someone has thought through this type of dispute before and the system can help me resolve it?
  • Does the application allow me to do my job, handling the daily reoccurring items while permitting me to handle the 1-offs, all the while helping me stay in control?  Do I have to trick the system?
  • Has the application been designed from a business process point of view, end to end, with complete data integration or do I have to massage the data across various systems to get my process done?

Once we have fully described the take-away user emotion, and all the building blocks required to achieve that feeling, will we be able to accurately dimension, resource and plan development.  Let’s call it E-Parallel, the merging of emotion fulfillment with parallel, iterative development to rapidly deliver the functionality and stability required to delight the user.  Now that is worth budgeting.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, and is one of their senior turnaround leaders/CROs, Program Rescue and Interim Executives with over 25 years’ experience reshaping companies, Operations, IT/Systems Integration and key initiatives. Return on Efficiency, LLC specializes in those companies and initiatives where technology is the primary means of service delivery and revenue creation.  He can be reached at

One Comment
  1. In Corporate America, tech going amuck is more likely to be an out of control software project. We’re seeing a recent spate of multi-million dollar system development, or licensed software implementation,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: