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.
