Most of the people executing projects using Agile process consider that the requirements can be changed and incorporated anytime till the last day of release to Production/Live systems. It is very difficult to drive that Agile has a process and certain parameters are to be base-lined and fixed.
With such an interpretation of the process, the project suffers. There is no sufficient time for Design and Architecture, the implementation and for testing. The problems start surfacing when the project is released to higher environments specially commissioned live.
Teams - Development or Testing would have received very less time to do their activities and are hurried up. Result? Hardly, to anyone’s surprise, the deliverables are of poor quality and everything aftermath is a show stopper production issue.
Once the application becomes a little stable (i.e., when the showstoppers are reduced), the users will realise how slow the system is. It flows down the hierarchy and comes to the development team as though they have to cut their heads-off for blunders committed.
When the root cause analysis for the performance is done, it is the fairly obvious reasons that come out as findings. A few reasons are like:
The Architecture and Design processes are mostly ignored. Of course, tactical solutions are meant for that reason!
Development team was rushed through with no time to use common components or to check if something has been re-written nth time
No time for code reviews and even if someone dares to do it, there’s no time to fix it
The environments are not tuned and configured according to production standards. When were given the time to do it, at the first place?
I understand that we are in a short cut world. We want everything at fingertips. But it doesn’t mean that projects also will be executed at that pace, whatever new process applied. Agile is great, but only when used properly. And for that matter, it applies on any process.
Labels: Agile, performance
