What are the differences when you implement a project using the traditional approach vs an empirical way of working? During a scrum workshop, which I attended recently, this question has been answered in a very descriptive and visualized way, which I want to share with you.
But before we start, let´s answer the question: What is the traditional approach and what is an empirical approach?
The traditional approach is basically the waterfall model. Wikipedia says the waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.
In the waterfall model your project is split up in 5 phases, “Requirements gathering”, “Design”, “Implementation”, “Verification” and “Maintenance”. Thus, you move through each of these phases in a sequential process and you jump to the next phase only if the preceding phase has been finished.
On the other side there is the empirical approach. Scrum is based on an empirical approach, as you can read in the scrum guide: Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Ok, now we know what traditional (waterfall) and empirical (scrum) approaches are. Let´s have a look at how those two approaches have an impact on 4 different categories: visibility, adaptability, business value and risk. And as I love graphs, I even created a diagram for each of the categories:
Visibility
The visibility in the traditional approach is very high at the beginning. You have your plan and you can show that to your stakeholders. The plan contains exactly what you want to implement and how you want to implement your software. During the project visibility goes down, because your stakeholders don´t get anything. They don´t know if the development team is really implementing the thing right – and even more importantly – the right thing. At the end of the project, when the software is delivered, stakeholders can see and use what you created, therefore visibility goes up again.
In the empirical approach the shape of the curve is the same. The big difference though is, that you deliver working software much more often – actually after each sprint. Therefore the stakeholders are able to see the progress of the development much more often and the visibility stays at a very high level.
Adaptability
Adaptability in the waterfall model goes down drastically the further you are in the process. At the beginning you can easily make changes to your plans, in case a requirement changes. But when the project is in a late stage of the process, changes of requirements are very costly. For instance, if the team is finished with coding the whole project and they are currently in the testing phase, then a requirement change basically forces the team to start with phase 1 again.
In scrum though, changes are actually expected and even welcome. The fourth item in the agile manifesto even states: “Responding to change” over “Following a plan”. Of course, if requirements change, then this should preferably happen at the very start of the project, because at that stage it is still the easiest to adapt. Adaptability goes down the later you are in the project – this is similar for the empirical as well as the traditional approach. The big difference though is, that adaptability still stays at a very high level in the scrum approach compared to the waterfall one.
Business value
If a team has finished coding and even tested their product, but the software is not deployed, then the customer cannot benefit from it. Thus, software brings value to the business only when it is delivered and used by the customer.
In the waterfall model the software is delivered to the customer at a very late stage in the process. Therefore the business value is low at the beginning and only raises notably when the software is deployed, which is – as I already mentioned – at a very late stage in the process.
In scrum the goal is to deliver working software each sprint. So the scrum team delivers business value in each sprint. At the beginning of the project the team usually focuses on the most important features, which bring the highest business value. After some time the most crucial features have been delivered and the team works on features, which are nice-to-have, but not mandatory for the software to work. Therefore its added business value gets smaller and smaller and at a certain time you decide to focus on a different project.
Risk
The risk is highest at the start of a project, because that´s the point where uncertainty is highest. For example, you don´t know if the product, what you gonna build, will be usable for customers, or if the team will have problems with the new technology you plan to use, etc.
At the end of the project, when the software has been delivered successfully to the customers and everybody is happy, the risk is zero (or at least very low). So, no matter what approach you use – risk is high at the start and low at the end. But how risk decreases over the lifetime of a project is different to the approach.
In a traditional model the risk stays very high throughout the whole project until the software is successfully delivered to the customer.
On the other hand, in the scrum approach you can focus on the tasks with high uncertainty at the start of the project. Especially when you have a project with a very high risk factor, you can actively work on uncertain tasks right at the beginning. For instance, you can create a prototype using the new technology to make sure this technology is the correct choice for this project.
Wrap up
As you have seen, there are quite some differences between the traditional and the empirical approach, which we have seen in the 4 models. If you want to introduce scrum in your company, then these 4 models might help you to convince management that agile is really helpful. The agile way of working improves visibility for stakeholders, welcomes changes in requirements, helps to increase the business value very early and finally it also reduces the risk for projects.
Awesome, he? Let me know what you think and leave me a comment. HabbediEhre and until next week.
