Losing the Flesh

Who likes the flabby flesh now? In the age of the ultra book, every thing needs to be razor thin. That is the ‘in’ thing now. I don’t think many will have a different take on Kareena’s size zero ;)

It was thus a pleasant change for me when I was introduced to the concept of razor thin software development – Lean/Agile methodology. Now the concept itself as I am learning is nothing new. Not influenced by the pretty actresses :P but borrowed heavily from manufacturing principles. The now widespread Toyota way of manufacturing seems to have been the start of all this.

Coming from a background of traditional waterfall model, where its judiciously taught that the key to a successful software is in following a rigorous plan of design/analysis/code/test/build (one at a time in a sequential manner), I was obviously not prepared to fully accept a system which did not believe in detailed planning, worse one which seemed to advocate a policy of ‘not’ thinking too much into the future. To accept that Agile is the best way to build software, was, or perhaps is still a little difficult for me. But to acknowledge that there is some merit to the fundamental shift in focus that Agile thinking tries to evoke is easy.

The Agile manifesto is perhaps the formal starting point of it all. Ever since I got into my new organization - champions of agile, I find myself repeatedly asking one question – By laying emphasis on interactions rather than moribund documentation, Agile seems to eliminate all needs of documentation which is in stark contrast to the near religious zeal on documentation that you’ll find elsewhere in the software development world. In my previous avatars, I was told documentation is the key. If there’s a requirement, it better be documented clearly; the RTM – document it. If there’s a best practice, it needs to be documented; if there’s a learning it needs to be documented; Now obviously I didn’t know if we had any measure of the benefits of all such documentation; whether all of this chunks of paperwork (physical or electronic) really made any sense or added any business value.

As a business analyst my role usually starts with gathering requirements and documentation is a critical part of it all. The Requirement doc (whether BRD, FS or in whichever form) running into a good number of pages is considered the bible, which once signed off becomes the basis for change control.  From there to noting down requirements in tiny bits of real paper is to travel to a completely different world for me. Now, looking back I seem to concur with the thought process that if the business users have to freeze their requirements before the development begins, then they make every effort possible to cramp as many requirements as possible often leading to a long and excruciating requirement gathering and freezing process.

It is not uncommon for the requirements phase to run into few months or even for a good part of a year because of this fear psychosis that drives them to spill everything possible which to their mind is like extracting every ounce of their money’s worth from the software development company! Little surprise then that the bulk of their requirements may never bring any business value to the organization.

The idea of producing working software in an incremental fashion is indeed profound. The moment the business users see a part of what they will eventually get, everything changes. It is also to the relief of all the stakeholders that there is no need to freeze the requirements early on – quite simply coz there is no way of knowing all the requirements unless the users really get a feel of what the new system they are going to use is going to be like. I also think there won’t exist a scenario where the users know exactly what they want. Even if they say so, it is only based on their assumption of the existing system and not based on a clear and rational understanding of the new system.

In summary, I find that the concept of churning out quick workable software extremely beneficial and an idea that makes great business sense and value - especially in these times of ever changing economic realities. The idea of minimal documentation is appealing but will be interesting to see how many of the big bucket I.T clients agree to frugal paperwork. The biggest challenge however will be in getting the people out there to truly understand the philosophy - as with the case of this case study of the failure of Agile. Quick viewing of piecemeal functionality is all nice but it will be intriguing to see how they see the big picture and agree to do away with unnecessary features as time passes which is also one of the things Agile propounds.