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:

1. Requirements analysis
2. System design
3. Implementation
4. Testing
5. 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.

The post Pseudo-Scrum, our own adapted framework in WATA Factory appeared first on WATA Factory.

This may seem obvious, but unfortunately in the world of software development there are always discrepancies between what the customer asked for and what was finally implemented. This problem occurs especially in projects with complete solutions, so here we explain our best practices for this type of project, which are also known as turnkey projects.

Starting a new project by taking the time to understand the customer’s real needs is an investment that more than pays for itself during implementation, not only saving development costs for the customer, but also ensuring customer satisfaction.

A satisfied customer is the best business strategy of all.

Michael Leboeuf

At WATA Factory, we have identified three key phases that help us to determine what needs to be developed, and which go beyond simply recording requirements.

1. Understanding the real needs of the client

In most cases, software development companies only read the specifications and then hold a meeting with the contact person to clarify any doubts. In the best case, and if everything is done correctly, the provider then knows in detail what the customer wants to implement.

But in some cases this is not enough. Often the customer is not even aware of the full potential of today’s technology. As experts it is our duty to thoroughly analyse the possibilities that the final software could offer the customer.

Therefore we examine the different parts of the customer’s management or manufacturing process. We also talk to the various parties involved and try to identify processes where time or resources are wasted. Not all customers use this opportunity, especially in complex organisations with different departments involved.

2. Concept development

As soon as we are aware of all the client’s real needs, we apply various creative methods to generate ideas for the creation of a concept that will provide a remarkable added value for the client, which can even sometimes go beyond what the client originally imagined.

Depending on the type of project, we apply techniques ranging from Design Thinking to Lateral Thinking. This phase distinguishes us significantly from other companies in this sector.

At this point we make a special effort to involve experts from various fields in order to achieve a result that meets the high expectations of our customers.

3. Presentation of the concept

Having made sure at the beginning of the project that we understand the customer’s requirements (by avoiding misunderstandings that could jeopardise the success of the project), we make sure at this stage that the customer understands the concept we have developed for them in the previous step.

For this we use various visual templates that clearly convey the concept we have devised. Depending on the project we use wireframes, mockups or interactive proof on concepts.

Although some software providers work on an hourly rate, we guarantee the customer a result and a delivery date. So the customer has the certainty of what he gets and when.

In addition, we attach particular importance to communication with the customer. We do not only revise the concept regularly, until a satisfactory solution has been reached, but also ensure during the implementation, by continuous delivery to the customer, that we go in the desired direction. Customers can visit us whenever they want and, if desired, they can even work with us in our modern offices.

Our main goal is not the software itself, but the satisfaction of our customers. The software is the way to achieve this satisfaction.

The post How to get a new software project off to a good start appeared first on WATA Factory.