In my previous post, I discussed a number of prerequisites before considering an Agile approach in BPM. In the current post, I will go deeper into why and when one would use Agile Development.
Why use Agile Development?
We do need agility. It is the mainstay of the BPM movement. We need to get away from monolithic years-long development projects and move into a world of months or even weeks-long projects that derive significant returns.
The art here is to use the Theory of Constraints to determine the most effective target for your BPM efforts. Find the worst problems, fix them, and then find the next worst problems, etc. What this requires is careful and structured Process Design.
To do this, you need a good Process Designer or team to work with Business stakeholders to determine what can and should be done. Processes need to be designed to be modular as well, so some technical input is also required. It is a tricky procedure, and this is where the collaboration comes to the fore. It is, however, vital to let Process Designers design the Processes!
Although comprehensive documentation is not required, we need to ensure that documentation does get produced. The documentation we try to produce is more ‘wordy’ rather than technical. The purpose is to create an understanding of requirements and design concepts in a language both technical and non-technical people can understand. That is limited to words and Processes, generally. This documentation is carried forward to generate test cases and then provide technical and user documentation, so it is an effort that is reused many times to great effect. Technical documentation should also not be ignored in order to assure maintainability.
When to be very Agile
There are times, as I mentioned before, when Agile is the best of all possible ways. These are for situations when speed is of the essence, and the system may not be in use for any extensive amount of time.
The most common business area where this is appropriate is in Marketing. There may be a need to manage hundreds of thousands of new applications for a particular product, for example. This product is going out to the market in a matter of weeks to get the jump on competitors. Will we spend weeks writing requirements and documentation of the system to manage these applications? Of course not.
What we need is a system that works with a minimum of workarounds and exceptions, that will be up and running as soon as possible, and can be updated every time the Marketing department change their minds (and we now that will happen, don’t we?). It will also not require a ‘version 2’, since Marketing will have moved on and be designing some new product. If a long-term solution is eventually required, then this version can be used as the prototype, and then the traditional approach should be mixed in to ensure longevity of the system.
This is where Agile shines, and all other practices pale into insignificance. The trick is to determine when to apply it in full like this, and when to blend a mix of Agile and Traditional methods. In more common parlance: “Don’t throw out the baby with the bathwater”!
Your thoughts on Agile?
What are your thoughts off and experiences with Agile Software Development?
Follow
