The Advantage of Being Non-Agile
Sometimes being not so agile prevents you from adding crap to your system
Agile software development has been en vogue in this decade. It started with the popularity of Extreme Programming (XP) and Kent Beck's series of books on the topic.
One of the values stated in the Agile Manifesto is "Responding to change over following a plan" and is accompanied by the principle
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
While I generally consider most agile practices as common sense, some of they may also cause trouble.
Being agile encourages customers to feed the development team with ideas on the spur of the moment while non-agile processes enforce proper planning. As a result of the slower time to market more formal processes prevent short-run ideas from being implemented and consuming resources that were better spent working on future-proof core requirements. Besides this those short-run requirements clutter the system if not properly removed once they are no longer needed.
A nice solution is to use differnt processes for differnt systems. Agile processes are best deployed for systems with a short lifetime and requirements that are not fully understood upfront. Examples for this kind of systems are public facing web applications like web stores. More formal processes are well suited for core systems with a long lifetime where maintenance cost is an important factor and stability is key.
This separation allows new ideas to be tested in an agile environment and move them to core systems once they become mature and turn out to be important features in the long run. When they will finally reach the core system the requirements are well understood and can easily be specified in a formal way - so the formal process is not a burden but a line of defense for feature creep.
Which systems belong to which category depends on the type of your business. If you are a bank your accounting systems will probably fit the "core" category as will the systems needed for compliance and trading. The public facing systems and systems mainly used for sales could benefit from an agile process.
The following questions may help you when you classify your own systems:
- How long do you expect the system to live?
- How stable are the requirements for the system?
- Will your system undergo frequent changes?
- How important is the system for your company in the long run?
If you are planning new systems you can also use this classification to define your system boundaries.