I see a common mistake made over and over by business and technical teams, and I think agile development can help.
In most of these situations, a business operations group is using a minimal software solution and wants to upgrade to something better. The software is often a Microsoft Access application that was quickly developed to address a need. I’ve also seen simple business applications developed in Lotus Notes and other scripting environments. In every case, someone stepped up and developed a quick and simple solution to a business problem.
After a while, the group decides they have outgrown the simple solution. They hold a series of meetings to determine all of the features and functions needed by the organization. The attitude being … ‘while we’re in the process of upgrading, we may as well go for all the bells and whistles we might need’.
Existing software applications used by other groups in the company are reviewed. Vendors are contacted. More meetings are scheduled. And, after much discussion and analysis, a decision is made.
The new software is purchased and customized to meet the organization’s needs or the software is designed and built as a fully custom application. Either approach is fine as they both entail a lot of work.
Finally, the new software is rolled out to the user community.
They are immediately overwhelmed by all the new features. Everything is different, even the terminology. There are more menus, more fill-in fields, more picklists, more required data entries, more security — more of everything. What took less than 5 minutes to do in the old application takes 15 minutes in the new one. This is progress?
While the new software may have far more capability than the original, the users are so overwhelmed by the complexity that they have no appreciation for the enhancements.
Why does this happen?
Be honest. We all have a tendency to over-buy. Our electronic gadgetry often has far more capability than we can use. We spend the extra money and put up with the complexity because we might need one of those obscure features some day.
That’s fine but there is more at play in the business world. IT groups have a reputation for being slow to deliver. Perhaps even worse, we have a reputation for being hard to deal with after delivery.
The end result is that people often feel that once they get IT’s attention, they need to get everything they can because it will be a long time before IT is available again.
The attitude toward IT is a side effect of the waterfall development approach.
Projects often take too long and the end results are often unexpected. The next time you are faced with an upgrade situation, try the following agile approach:
- Seek to understand the current situation. What works well? What doesn’t work at all?
- What additional functions are desperately (yes, desperately!) needed?
- Stop. That’s good enough to get started.
- Go through your discussion and analysis. Select a solution path.
- Implement or configure the bare minimum feature set required to replace the old application.
- Deploy it and move everyone over as rapidly as you can.
- Meanwhile, build out and configure the remaining desperately needed functions.
- Re-deploy.
- Finally, add any other features that have been requested and can reasonably be included.
- Roll out the extra features over one or more additional deployments.
There will almost always be time and money constraints on the above. That’s fine. Timebox and moneybox the solution. Keep the feature set flexible as described and everyone will be much happier.
If the users can justify more time and money, you’ll get additional funding and the effort can continue. If not, the old system is replaced. The major problems are addressed. The future is brighter. That’s agile.