People have developed a view that using agile methodologies is always better to make products rather than traditional methods. However, this is not the case. To find out when to use Agile and when not to, plot the product on a graph basing its certainty on two parameters:
- Axis 1: Requirements, i.e., knowledge of “What needs to be made?”
- Axis 2: Technology, i.e., knowledge of “How it needs to be made?”
We can place a project in either of the four quadrants. A similar matrix was first suggested by Prof. Ralph D. Stacey to help managers determine the complexity of their company’s environment and adapt their style of decision-making. However, keeping the discussion limited to software development, this model can be used to decide if one should use agile or waterfall methodologies.
For projects falling in quadrant III, i.e., those in which know the exact requirements and the technology to be used, use of the waterfall model is advised. The reason behind this is that such projects have high levels of certainty and not a lot of changes are required to make the final product. An example could be creation of static websites (websites where the content doesn’t change with time or user) - it’s a well researched and done millions of time. The task has to be just repeated with the same processes.
For projects falling in quadrant II or IV, using Agile methodology is the best. If the requirements are clear you can go back to the client after each sprint to check if the way technology is being used is fine or needs to be changed and if the technology is clear then one can keep clarifying requirements after each sprint cycle. For example, making a software that reduces the cost of transport of material between different warehouses of a supply-chain company. Here the requirements are clear in the sense that overall cost has to be reduced but a lot of information is required for finding out the parameters and write the algorithm that would achieve it. The best approach is to keep exploring the parameters, coming up with algorithms and discussing the results with the client from time to time.
Finally, for projects falling into quadrant I have unclear requirements and unclear method of implementation. In such cases it is best to break-down the project into smaller projects which fall into quadrant II or IV and use agile to complete them thereafter. Even though such projects are hard to define, let me try to give you an example - Make a machine that can reduce the devastation caused by a tsunami. Now such a machine would require probably artificial intelligence to predict tsunami, perhaps a 3D printer to make things on a large scale that can slow down the water, or there could be other understandings of such a problem statement.
Comments
Post a Comment