Traditional waterfall or Agile Project Management?

Are we going to ‘scrum’ or do a rather ‘traditional’ waterfall? What fits within your organization and what fits the project?

When starting a new project, in our case when creating a new online platform or website, it is essential to maintain grip and control over the project and its output. But how do you keep such projects in control? Well, there are several project management methods!

How do you decide which method fits best? This depends strongly on the organization and the project. In order to make the right choice, it is important to know which method matches the situation.

Which method fits best?

There are numerous project management methods. In our business there are primarily two directions to define. The more traditional waterfall methods such as Prince2 and the agile methods such as the Scrum Framework. 

Read more about the background of the different methods in this article. 

Both methods have pros and cons, but differ fundamentally. We work with different types of projects and clients. Each time we agree on what fits best. The organization, the type and size of the project, the working method and culture of the client influence our choice whether traditional or Agile/Scrum is the right approach for the project. 

But how do you know which method suits your project best? And how do we decide which method we’re going to use? We pay close attention to:

• Project type: Simple or small project versus large or complex project.
• Culture of the client: Flexible output versus (fake) certainty.

1. Project type: Compact or small project versus large or complex project

Large and complex?

The advantages of Scrum only flourish in innovative and more complex projects. With Agile methods you quickly bring out a first version of a product. Then you test, develop and expand that version.

Small and compact?

The Scrum Framework puts a lot of emphasis on communication and continuous adjusting and testing. In a project that is simple and easy to define, with concrete output and that can be carried out within a few weeks with a small team, Scrum generates too much overhead. In that case, it’s better to use the standard phasing of waterfall methods. 

Size

Scrum and working with self-managing teams also need some start-up time. Before you can hit the ground running with the sprints, the multidisciplinary team and members of the client and contractor have to ‘get used to each other’. It is essential that the team is given room to organise itself. This means that members must have the time to focus on the project, but it also means that there must be room for this in terms of lead time and budget. The guidelines recommend a minimum of approximately 700 hours.  

At Level Level we have also partly solved this by setting up a permanent Scrum team. This means the team is perfectly adjusted to each other. This team works together on multiple Scrum projects.

2. Culture client: Flexible output versus (fake) certainty

Scrum’s greatest advantage is the intensive collaboration between the client (Product Owner) and the team. There is a short feedback loop and all stakeholders involved see immediate results in short cycles. This intensive collaboration ensures better quality of the results and faster acceptance by the target group. But this also requires commitment and flexibility from your client. This only works if it really suits the organisation.

It is extremely important that all stakeholders involved, including those on the client’s side, know and really understand the foundations of Scrum. Scrum is a mindset of the team and therefore also of the customer and client.

Intensive role of the client

With Scrum, the role of Product Owner is crucial. This role is often fulfilled by the person who traditionally fills in the role of ‘client’ or ‘customer’. The Product Owner must have a lot of knowledge (he has to decide on the specifications), must be able to make many quick decisions and must always be available. Why is that? Because the development team must not stand still! If the client is not able to make the right decisions quickly and doesn’t have the right content available, it is better not to work with Scrum. The time advantage will be lost.

You also want to work on location with the team as much as possible. Of course, it is possible to set up all tooling online, but then a big advantage of Scrum is lost: being able to interact directly with each other without any loss of time.

A self-managing team

Some companies have a hierarchical culture. If this is the case, then working with a self-managing team is inconvenient. If the client wants to remain in control and finds it difficult to fully rely on the team, then Scrum is not a good idea either. With Scrum, the client should be fully at the service of the production process and not the other way around.

Flexibele scope

The term Agile says it all. It can be a strength not to be fixated on a predefined output, but in that case all those involved must be open to flexibility. If this flexibility is not available from within the client in terms of output, lead time or budget, we have to ask ourselves whether we need to Scrum. Of course, a number of factors are fixed in Scrum as well, but Scrum is all about leaving the strength in the part that is open and translating the new insights into an even better result. For this, trust is essential.

You don’t sell fake certainty with Scrum. You buy a team with expertise that you have to trust as a Product Owner. The customer really is responsible, that’s why it can be experienced as scary. Doesn’t this suit the organisation? Then a traditional method fits better, which means that as much as possible has to be defined in advance. This gives the client the feeling of more certainty, but because of this we can’t guarantee that this will give the best results. You deliver what you agree upon, but you don’t know in advance whether that will actually ensure the achievement of the defined goal.