A couple of days ago while at QCon San Francisco, I had a series of conversations with a person involved in software development at a major financial institution. He really wants to start using Agile techniques, but isn't sure of the best approach to take to convince others internally. I gave him some pointers including my recent article "Software Developers Can Learn a Lot from Salespeople." As I was thinking about this I realized that Agile is actually a perfect fit for financial institutions!
Software projects are highly unpredictable. More often than not they are either late, over budget, missing originally planned contents, much lower in quality than originally planned or a mix of all of the above. Another area of the business that has similar problems with predictability is sales.
When was the last time that salespeople were expected to tell you exactly what their financial performance would be? Sales people can't predict exactly which deals will come in during a quarter, nor exactly what the amount of any particular deal will be, but they are expected to hit their quotas and they are expected to show results on a regular basis and CFOs are perfectly happy with how their salesforce goes about their process. They may not be happy with the actual results sometimes, but they approve of their process.
What sales does and what Agile teams do are exactly the same! They are both working with unpredictable quantities. Developers in an Agile team may not be able to predict exactly what will be the result of any particular release and sometimes not even the result of an iteration, but they can be held accountable to produce a regular flow of high business value software on a regular basis and to be able to demonstrate that the software is actually done on a regular basis as well.
So, if the organization is comfortable with the sales process, they should be equally comfortable with Agile development. In fact, anybody involved in the business side of software development should be very uncomfortable with anything other than Agile development and be actively working to figure out how to get their development process to be more like sales.
This post has only briefly touched on the comparison of software development and sales. If you are interested in a full comparison, please take a look at "Software Developers Can Learn a Lot from Salespeople."
I was talking to Ron Morsicato of Agile Rules at dinner at last weekend's Deep Lean conference and he was saying how he thought that Agile was a good idea for mission critical applications. That struck me as an interesting thing, and I've been thinking about that all week. I think he's right and here's why I think so.
Let's say you provide mission critical software and there is a problem reported in the field which requires a fix. Well, if you are doing traditional software development, you can't exactly ask the customer to wait until you finish your current release. And if you were to put out a fix for them using your main development path, that would probably take too long too. So, you have to have a critical-fix development path. By definition, this is a development process which is not used for regular development and it is not used very often (so one would hope).
As a result, you have one process for regular development and one process for critical fixes because your regular development process takes just too darn long. That means that when you most need for things to go smoothly you are going to use the process which is the least practiced and probably also something that only a handful of folks know or are allowed to do. Doesn't that strike you as just plain wrong? Imagine trying to explain that to the media!
Part of the idea with Agile, Lean, and especially Hyper Agile is that the path from deciding to make a change and being able to deliver that same change is as short as reasonably possible. If the "overhead" from start to finish for a critical fix is 4 hours, then any task should take you no more than 4 hours plus however long it takes you to write the code and the associated tests. Once you have this capability, then you really only need one development process which you use for both regular development and critical fixes! Thus, everybody is practiced in your critical fix process and everybody has experience with doing it. This will reduce risk and increase confidence in the results.
