Another reason for software development to be agile.
Has this ever happened to you? You receive an email or a phone call saying something to the effect of “The software is broken!”. It is suddenly and inexplicably misbehaving. The results being observed have never happened before. What did you do?
You think “How can it be?”. No one on the team has changed anything lately. No upgrades. No bug fixes. No infrastructure changes. Not even a parameter change. What’s going on?
Oftentimes, the culprit is a business process change. The business users are doing something different and didn’t see the need to inform the software team.
They may have eliminated a process step and the corresponding data entry. When the software goes looking for the data element that has always been there and it isn’t found, strange things can happen.
Or, they may have added a step to the process. Now they want to know why the new step isn’t properly accounted for in the software. All of the steps used to appear in the reports!
I’ve also witnessed users changing the meaning of a data element. They decide to use an existing field for something else because they don’t want to request and wait for a software change. Now they don’t understand why the software doesn’t handle the new field meaning properly.
These examples demonstrate the need for good ongoing communications between software developers and end users. Business processes are constantly changing — just like the software. (Hence the need for an agile approach to software!)
Some development groups try to lock down the software. They severely restrict what people can and cannot do in the software. They enforce workflow rules that insist activities be performed in a strict order (A before B before C) or that force activities to be grouped (if A then B; if B then C).
These lock down rules work in some business environments. Generally those that are static (i.e. they don’t change much) and are fast-paced (i.e. they handle large amounts of data entry).
In the majority of business environments, the rules are too restrictive, interfering with the ability of the business team to innovate. Lack of innovation leads to bankruptcy court!
Don’t lock down the software. Keep multiple, open lines of communication between software development team and the business operations team. Be agile!