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.
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:
- 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.
- 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?
- 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…