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 them 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.
Re: The Advantage of Being Non-Agile
Re: The Advantage of Being Non-Agile
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 is true. However, it creates the misleading impression that:
1. Agile is not formal. (False: agility is orthogonal to formality.)
2. Maintenance cost is reduced or controlled by spending more on up-front design. (False: maintenance costs average out at about 50% of the project's cost, regardless of design effort.)
In fact, a properly constituted agile project will attempt to enter the maintenance phase of the software lifecycle as quickly as possible; it might be viewed as the purpose of agile.
Agile is not properly viewed as the omission of design. Instead, it's a different approach to design.
An agile project will inevitably have some junk features in it. A non-agile project will also inevitably have some junk features in it. Thinking about the features won't stop them from being junk; creating an exhaustive review process will stop only a small number of the more obvious ones. Trying the system out in situ will stop far more; this is where agile methods are supposed to shine.
Of course, "traditional" (non-agile) methods shine in other areas. Agile methods are counterindicated, for example, where there are no system experts, so that _only_ exhaustive study can possibly reveal what's truly needed. Most agile methods are, of course, informal, and so will not work unaltered in a problem area where formality is one of the requirements; but enough agile methods have been formally documented that for any formal project where exhaustive study is NOT a requirement, there should be precedent for using a (formal) agile method.
Re: The Advantage of Being Non-Agile
I like the idea of a formal agile process that might fit somewhere between informal agile and traditional approaches.
The implementations of agile processes I've encountered so far have been very informal and denied that it's sometimes important to pass ideas through a stage of design and architectural examination. They also refused to accept that stability (i.e. resistance to change) might be a non-functional requirement for some systems.