There is no doubt that we live in a society dominated by marketing. There are terms and concepts that sell. They are like hallmarks of distinction that many try to put on their business card, even if the similarity with reality is, in many cases, only partial.
Today we are going to talk about Scrum, a framework that is all the rage. It is agile and modern (though not new). And it is clear that agile and modern sounds better than slow and old-fashioned. But the truth is that, although Scrum has advantages, it has disadvantages and cannot be used in every type of “project”.
In fact, Scrum is not a framework suitable for projects, but rather for products. Nevertheless, many developers believe (or at least claim) that they are applying Scrum. Why? Because the word Scrum is sexier than more realistic alternatives. But we will see that later. Let’s take it one step at a time.
Where we come from: Cascading development
First of all, it is interesting to remember where we come from. Traditional software development was done using the waterfall methodology. In a nutshell, it can be summarised as follows: Development is divided into several phases that are implemented one after the other in a specific order:
- Requirements analysis
- System design
- Implementation
- Testing
- Deployment
This methodology has a major drawback: it is one-way. The main problem is that once implementation has started, the requirements cannot be changed. Unfortunately, in the software world, requirements are not entirely clear from the beginning, or they may want to be modified during development, either because the customer changes his mind or because the needs have changed. This is especially true for long projects.
So, is waterfall development a bad methodology? Not at all. It is simply a working methodology that works effectively for projects where all the information is defined from the beginning. There are many sectors where waterfall development is successfully applied. It simply has limitations of flexibility, which can be a problem for the development of a software project.
Introduction to Scrum
Scrum is an Agile framework that is based on delivering increments in work cycles called Sprints. In each Sprint, a fully functional part of the product is delivered. Each Sprint has a phase of Requirements Analysis, System Design, Implementation, Testing, Deployment. One of the advantages of this framework is that requirements are defined (or at least discussed) before each sprint. Therefore, the team defines in each Sprint what is going to be implemented next. This allows to react to possible changes in the market, or simply to benefit the interests of the end users of the product.
Project vs. Product
You may have noticed that in waterfall development I have spoken of project while in Scrum I have spoken of product. This was not by chance.
The waterfall methodology is a project management model. A project has a budget and a fixed duration. In other words, when a project is implemented, it must be known how much it will cost and when it will be complete.
With the Scrum framework, the development of a product is managed and therefore there is no end date. Scrum is used for iterative product development over an indefinite period of time. At the start of development, the final result is not known, as the functionalities to be implemented are defined as the product is developed and according to the decisions that are made to meet market demands. That is why it is flexible.
Can I use Scrum in my project?
If we read carefully, the answer is simple: no. Scrum can be used for product development, not for a project (although Scrum approaches have been developed for projects in recent years). And in consultative software development there are plenty of projects.
For this reason, projects developed under the Scrum framework often fail or these projects are actually developed using a methodology reminiscent of Scrum but which is not really Scrum, as the framework is not applied correctly (in fact, in a project it cannot be applied at all). Consequently, the principles that make Scrum work cannot be fulfilled either, among other reasons
Pseudo-Scrum is an approach to waterfall development and Scrum, with the advantages of both. The prefix Pseudo may convey the idea that it is a less valid methodology than Scrum, but this is not true. Sometimes the term hybrid is also used, which sounds better. But what matters is not what we call it, but the methodology itself. It is important to choose the working method that best suits the needs and not to go by what is fashionable or sounds good at the moment. The ultimate goal is to ensure the success of the project or product and the satisfaction of both the client and the team working internally.
In summary, we call a framework that appears to use Scrum features but is not pure Scrum a Pseudo-Scrum framework. In the following, we will explain how we do it at WATA Factory.
Pseudo-Scrum at WATA Factory
First of all, it is worth mentioning that at WATA Factory we apply the way of working that best suits each project. We use Scrum in the development of some products, but this framework is usually not adapted to the requirements of our customers. In the vast majority of cases, customers need to know what they are going to receive, how much their development is going to cost and when it is going to be delivered. This is, by definition, incompatible with Scrum.
Our Pseudo-Scrum is a hybrid between waterfall development and Scrum, taking the advantages of each.
First of all, we have a phase of requirements gathering and analysis. Subsequently, we make an interactive prototype, so that the client can see what the resulting product will be. Additionally, we make an offer that includes development cost and delivery date, unless, together with the client, we can work based on hourly budgets for the continuous improvement of the product in question, in which case we would apply pure Scrum.
Using waterfall development, the technical team would have no further contact with the customer until the delivery date, as everything would be pre-defined. However, this is where Scrum comes in.
The implementation is done in product iterations by means of fully functional deliveries. That is, the customer could use the delivered functionality. This has two advantages. The first is that the customer can make use of his product before the final delivery. The second is that the customer can see and test the functionality. Once implemented, the customer sometimes notices improvements in the developed part of the product. An implementation with Pseudo-Scrum allows the customer to redefine those functionalities that he considers appropriate during the development.
Of course changes must be of the same magnitude as the original implementation in order to maintain the delivery date and development cost. Alternatively, it is compensated by discarding or simplifying other functionality. For this, we work with a prioritised backlog, in which the client decides the order of implementation of the functionalities.
Use Pseudo-Scrum proudly
There is frequent criticism of ways of working that are reminiscent of Scrum or claim to be Scrum, but in reality do not follow the framework faithfully. In part, this is understandable. If you are not using Scrum, you should not preach that you are using it. What is not correct is to say that pure implementation is the right one and any other option is just an attempt to imitate. Nothing could be further from the truth
Use the methodology that best suits the situation, and defend it with your head held high.
