In the good old world of IT development, we have the software development done as per the waterfall model. It was sort of a logical transition from the construction or mechanical world to the newly found software world. The big phases were defined as Requirements, Design, Coding, Testing and Production. It was more or less across the wall model in theory but was a big spaghetti of people and processes. Features went into production which were not part of Requirements and the intended requirements never made to the Production.
One of the major reason for the software developments to fail in waterfall model was the inability to
visualise the final product by all the stakeholders. Everyone has their own picture in their mind and it was difficult to synch it with one another. The synching required a high amount of communication going back and forth which usually was missing. Another reason of the failure was to identify the right end user of the product. For development, QA became the end user and for QA it was the marketing and sales department or the purchase department of the client. No one bothered to look at the actual end used who is going to use the product day in and day out. The big picture was usually so big that no one knew how to convert it into execution. There was also no easy way to see the shape of the product as it evolves which is common in construction or automotive or for that matter any traditional industry.
visualise the final product by all the stakeholders. Everyone has their own picture in their mind and it was difficult to synch it with one another. The synching required a high amount of communication going back and forth which usually was missing. Another reason of the failure was to identify the right end user of the product. For development, QA became the end user and for QA it was the marketing and sales department or the purchase department of the client. No one bothered to look at the actual end used who is going to use the product day in and day out. The big picture was usually so big that no one knew how to convert it into execution. There was also no easy way to see the shape of the product as it evolves which is common in construction or automotive or for that matter any traditional industry.
To solve the problem of big, people inverted the problem and started looking into small and the agile came into picture. Agile focused on the small but functional pieces of the system. The whole cycle got broken into small iterations with each iteration having a well demarcated deliverable. It has been adopted by a large number of players in the industry now and has its own fair amount of success.
The natural question that comes up is that which approach is the right approach. Is waterfall a complete failure or is Agile the panacea to all the software development problems. It's like what is more important, a forest or trees in it. When we have to cross a forest, we need to know about both the extent of forest and how to cut through it in right way for every effort put in.
In this respect, I think neither of the software development model are complete. Each has a mindset which brings certain positive and negative points and they have to be blended in the right way to come up with the right execution model. I am using the term mindset, because that is the differentiator. The waterfall model promotes a mindset of thinking in the long term and the agile mindset promotes short term. And both are important in their own way. So what is the right model? I think the right model is to inculcate the thinking of both the long term and the short term. It's about doing right things. The doing part is the agile mindset and the right is waterfall mindset. How does it translates to day to day execution? In terms of requirement, it means someone should understand how the end product is going to look like but at the same time it should be sequenced in such a way that the deliveries can be done one piece at a time.
No comments:
Post a Comment