Does Agile development work for ALL software products?

I think most people involved in developing software have a reasonable understanding of what Agile / Scrum development is all about.  The general idea is to get customer feedback early and often so that you can adjust the finished product to something that is almost guaranteed to be what the customer wants.

The Scrum project management method. Part of t...

Image via Wikipedia

This is clearly a much better idea than the traditional, or waterfall, approach where you spend months figuring out what the customer wants, more months building it, and then hope (or pray) that the customer hasn’t changed their mind or that the market hasn’t moved while you were doing all the work.

And history is full of examples of products developed using the traditional way that didn’t get close to living up to their original market expectations because they were obsolete or out of touch with their market the day they were introduced.

However, when you listen to some Agile zealots talk — you will hear things like “there never was a product that couldn’t be developed using Agile”.   Frankly, this reminds me of “one size fits all” which anyone over the age of 5 knows is simply not true — especially in today’s market where every customer wants it “their way”.

So with your help, I would like to identify products (or situations) where Agile development may not be the best approach.  The goal is to avoid trying to force-fit Agile where it clearly won’t work and to identify how to adapt Agile concepts in other cases so that we can get the best possible product in every situation.

OK — I know this is ambitious and possibly not achievable.  But a journey of many miles begins with a single step.  So let’s get started by talking about some product types where Agile will have problems:

  1. Embedded Software — The software that runs all of the “electronic” modules in your car are a good example, including the ABS system, the throttle control system, and the fuel injection system.  Obviously, you can’t ship an interim version of this software to your customers and ask for their feedback — they wouldn’t know how to test it.   And imagine if the software had a bug, the car accelerated out of control and someone was injured or killed.   How would the manufacturer explain that it was only a “test” version of the software? (Hmmm, this sounds vaguely familiar for some reason…)   Lastly, it takes a long time to ship a product like this to a customer.  So even if you could get customer feedback, it would come so long after the development had been completed as to be nearly useless to the development team.
  2. Enterprise Software that Requires Customization — This is an idea that I described previously, so I will summarize.  Imagine that you provide a customer with software that takes them 6 months (or more) to customize and deploy, how will they ever be able to provide you with timely feedback?
  3. Real Mission Critical Systems — The software that monitors and manages the nuclear reactor in a power plant is a good example.  How could any software provider explain away an interim software release that allowed a catastrophe to occur because a feature wasn’t “finished”?    I mean before they lost everything in the inevitable flood of litigation.

There are only a few examples, but they seem to have a few things in common.  Perhaps Agile / Scrum development only works with products / situations without these characteristics:

  • No Timely Feedback — It is not possible to obtain feedback from the customer / end user sufficiently fast enough for the Development team to review and incorporate it into the product.
  • No Ability to Fail — It is not possible for the product to fail, due to a feature that is incomplete, incorrectly designed, or improperly implemented, without subjecting the customer / end user to unacceptably high risks.
  • Not a Standard Product — It it not possible for customers to effectively use a “standard” version of the product.  Every version must be customized before it can be used (or tested) by a customer which makes it very difficult to detect whether a failure is in the product or a customization.

I’m sure I’ve only scratched the surface, so feel free to add your comments.

And next time, we’ll look at a few ideas for using Agile Development practices for products which have one or more of these characteristics…


7 Responses to Does Agile development work for ALL software products?

  1. paslode framing nailer…

    […]Does Agile development work for ALL software products? « Fulton's Ventures[…]…

  2. David Wright says:

    “where you spend months figuring out what the customer wants” This is not a given. Anyone doing this deserves to fail. If you want to know how to a better job, contact me through twitter.

    “more months building it,” …same thing. If your designers cannot partition software into pieces that can be delivered in succession over time, find some who can.

    • David Fulton says:

      Thank you for the comment. I would be very interested to understand the types of products that you are familiar with.
      I’ve spent a number of years with enterprise PLM (Product Lifecycle Management) software that is usually highly customized at each customer site. As a result, a single software release often takes 6 months or more for a customer to deploy to all of their employees, suppliers, and partners. And given the huge cost to make significant changes to their accompanying software and utilization procedures — customers are slow to deploy new functional releases.
      For these types of systems, new software releases usually contain a large amount of new functionality and are shipped every 12-18 months, even though the features were developed in much smaller pieces, because customers are simply unable to absorb them any faster.
      Other types of software products, especially those with a SaaS deployment model, are much easier to define, develop, test, and deploy in smaller pieces in a few weeks or more.
      Perhaps these are the types of software products that you were referring to.

  3. […] as de facto beta testers for product safety. (See David Fulton’s Tuesday post for more on the challenges to Agile posed by embedded systems.) As a frequent flier, I don’t want aircraft manufacturers to take that approach to aircraft […]

  4. […] as de facto beta testers for product safety. (See David Fulton’s Tuesday post for more on the challenges to Agile posed by embedded systems.) As a frequent flier, I don’t want aircraft manufacturers to take that approach to aircraft […]

  5. Agile can certainly be used to develop embedded software. Remember that early releases may be intended for an internal customer, e.g. internal R&D. So in your example of a braking system you would not ship that release out actual customers, but you would want early releases in the hands of internal teams to start preliminary testing and determining if a hardware/software design that looked good on paper answers questions of safety, reliability, etc. For the record, I have used agile techniques to develop embedded software with positive results.

    I think these same ideas can also be applied to mission critical systems. Early releases will used internally to evaluate performance, drive usability feedback (from internal customers). Simulation techniques and test fixtures can be used to evaluate performance and drive feature feedback in a safe manner. Mission critical systems require a higher standard for validation and verification, but your risk can be mitigated by doing that V&V incrementally as part of an agile process. I would rather know about an unforeseen issue early than late.

    I think your comment about timely feedback is a good one. If there is no mechanism in place for customer feedback in a timely manner in on an agile project you are in trouble. That customer feedback has the most value when it comes from an external customer, but internal customers can also drive product features. I am not sure any methodology is going to work well if you have an system that requires 6 months to deploy, customize, and get useful feedback.

    • David Fulton says:

      Good comment. Thanks. Could you elaborate on a couple of points?
      (1) If you are using an internal group as a customer proxy, how does this group retain their customer perspective? How do you avoid the concept of “the fox guarding the hen house”?
      (2) When using Agile for embedded systems, how do you deal with regulatory compliance or fixed schedule complications? (See Eric Krock’s post at for more info.)

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: