Why methodologies

- [Presenter] All software development projects adopt a certain methodology such as Waterfall, Agile, Scrum or Kanban because methodologies help improve the chances of project success. Projects are defined as activities that have a definite start and end. They deliver something with tangible value and whatever they deliver is unique to their stakeholders. Let us take an example. A baker bakes a cake every day at her bakery. Every time she bakes a cake, can I call it a project? The answer is no. Now I am planning to bake a cake today. I have never baked one before but I'm going to try, can I call it a project? The answer is yes, why? Because the baker is doing something which is routine for her. She has all the checks and balances, the scale and the confidence that comes with experience whereas in my case, the chances that the cake will not come out right are quite high. Good or bad, baking a cake for me will be a unique experience whereas it is a standard part of the baker job. So these two baking activities meet the first two criteria that is a definite start and end and something of tangible value but only my baking meets the third one and that is uniqueness to its stakeholders. Another scenario could be that the baker decides to bake a new kind of cake that she has never baked before. In that case, baking this cake will be a project for her. The main idea is that projects are not routine. They deliver something that has not been delivered before and hence that makes them risky endeavors. All software development methodologies help us bring down that risk. The risk can be of various kinds, risks can be organizational. What if my customer goes bankrupt and cancels the project? Risks can be geopolitical such as a war or biological such as a pandemic. Such risks are external to projects and while the project team needs to think about these if they may occur, software development methodologies do not offer much help in such cases because these risks are beyond a project teams control. The risks that our methodologies help address are internal to a project and hence within the project teams control to a large extent. One way to look at these risks is what is called a triple constraint. Every project has three major constraints, time, scope and cost. They are connected in a way that if you try to change one, you are forced to change at least one more if not both of the remaining two. If I want to increase scope, it will cost more and may take longer. If I want to deliver something faster then I might have to cut down some features. The cost may or may not change. We define a successful project as something which manages all these three constraints. Full scope delivered on time and within budget. If I deliver something which failed on at least one of these three parameters then my project is considered as challenged and if I do not deliver anything then my project has failed. Methodologies help us manage risks by managing these triple constraints. When we start a project, we start with a big goal. Let us say the goal is to build an e-commerce website. We need to figure out what exactly is the customer looking for and also what they're not looking for. That is the scope. Now, how will we deliver it? Will we deliver in one big bang approach or will we deliver in small increments. The big bang approach has a higher risk factor because in this approach, we build the whole thing and then show it to our customer. We spend a long time and a lot of effort in building that full product. So our investment keeps increasing. It is possible that our customer may not like what we built and in the worst case may completely reject it. Now, if that happens all the time, effort and money spent goes to waste. If we invested say a million dollars in building something and if there is a 10% chance that the customer may reject it, then the risk can be quantified as 10% of a million dollars which is $100,000. But if it's delivered in short increments then you keep getting customer feedback, if they don't like it, then you have to undo only the most recent increment which will be a fraction of those million dollars and not all the way back to the beginning. So every time you deliver an increment, you deliver something that has lower risk and so your overall project risk goes down at each incremental delivery. The big bang approach is what the Waterfall methodology has. In waterfall, you start from the beginning and continue till you have built the full fledged product to be delivered. All phases of software development, analysis, design, coding, testing and deployment are done end-to-end with no opportunity to go back. That is why it is called a Waterfall because once the water starts falling, it never goes back. And that makes the project one long and risky endeavor. The results of which will be known only at the end. On the other hand, delivery in short increments is the iterative methodology. We are not only are delivering in short sprints, we also have full flexibility to go back and forth to make sure what we are delivering is something that the customer really wants and something that really works. We deliver in small steps often in just about two to four weeks we are dealing with a lesser number of uncertainties, simply because we can see a few weeks ahead better than a few months ahead. It is easier to stick to timelines that are nearer than those that are farther away into the future. And lastly, the cost. Since you are delivering something of value every few weeks, the chances that the customer will pay for the value delivered is much higher. And that brings the costs also down. Another factor that adds to the risk element in a project is its complexity. Baking a cake is less risky than building an e-commerce website, simply because a cake is simpler. As complexity grows so does the risk. Simple projects can rely on individual expertise but as complexity increases, we need methods, tools and processes to manage the risk.