4 questions to ask yourself before doing agility

A few weeks ago, I got interested in the agile method.

Not to agile methods in general, but rather to the essence of the agile method: the agile manifesto.

As a developer, here are 4 questions I asked myself before I started to get interested in “the agile method”. 👇

Who created the agile manifesto?

The manifesto was drawn up in 2001 by 17 IT specialists in order to respond to a problem that we all know:

“Why do IT projects fail?”

And especially because this question leads to many others:

• Why can’t we deliver on time to production,
• Why do we throw code in the trash,
• Why does our soft not work,
• Why does it bug all the time…

And so much more.

As a developer, can we really succeed in delivering correct code in a given time?

This is what the manifesto tries to do, describe the foundations of successful project management. 👌

In the agile manifesto, there are therefore 4 values ​​on which are based 12 principles whose goal is quite clear: to deliver a quality project to the client as quickly as possible.

As this article is relatively short, I invite you to read my full analysis which details the values ​​and principles of the agile manifesto (in pictures).

The manifesto is therefore intended to be a guide for developers to best succeed in their work.

Are agile methods still relevant?

Since their development 20 years ago, agile methods have been widely criticized.

Not the agile method as such (the manifesto, although sometimes questioned, is not the target of attacks).

It is the implementations of agile methods, these frameworks like Scrum, Kanban, Extreme Programming etc that are being criticized today.

For the record, at least 2 original signatories of the manifesto, Ron Jeffries and Andy Hunt, withdrew a few years ago.

For them, agile methods are badly implemented, badly used…

We fall back into the failings of old managerial methods.

That’s all we wanted to avoid at the start.

It is also often said that agile methods are not always easy to use.

And that’s true.

Project management in general is a profession in its own right, you have to train and gain experience to fully master this domain.

For me, agile methods are not dead, far from it.

In recent years, there has been a significant increase in “benevolent managers”, trying to make the life of workers (in this case developers) more pleasant at work.

“It’s over to produce only code, managers have now realized that coders can think.”

We must not forget that agile methods were created by and for developers.

Also, these tools are always adapted to our current way of working. And best of all, they are often synonymous with project success.

When to use agile methods?

I often advise starting with an agile approach when the scope evolves as the tool is developed.

Sometimes we have to start development when the specifications have not yet been fully set.

👉 The customer needs us to start developing the tool quickly and sync meetings are scheduled every week in order to move forward on the functional specifications.

These changes of direction involve being flexible and receptive to changes in general (and that’s good because that’s exactly what the manifesto was written about!).

It’s a go for agility!

👉 Conversely, if the client has a tight deadline, a specific scope that requires actors to commit to a date and a budget, a more traditional project management method, such as the V-cycle, will be more suitable.

It will be without agility!

As often, it’s a matter of the situation.

Is the schedule likely to move? Do you need to start using the product quickly? Does the customer need a commitment of means or result?

So many questions to ask yourself before choosing to adopt an agile approach.

Which “agile method” to choose?

There are several quite popular agile methods (in the framework sense of the term).

We can mention Scrum for example, which you have already I think heard about or that you practice perhaps?

There is also XP which is considered “THE” agile method for developers.

Or Kanban which is very popular among those who like to have something visual.

But suddenly… Which framework to use?

Good news: they are all different enough that it can match with different teams and different projects.

 

The second good news is that you can only use certain agile methods tools without being locked into a framework!

Project management doesn’t have to be about adopting one particular method, it can also be done by taking the best from each world.

“Composition over inheritance!”

A framework like XP will have a set of tools at its disposal: Pair Programming, TDD, BDD, where Scrum prefers Sprints, Daily Meetings, Poker Planning…

Why not choose the tools that are right for us?

Agile methods must adapt to the team and not the other way around.

Forcing your team to do TDD would be stupid if the team did not want to…

The important thing is that the processes are clearly defined upstream and that everyone is in agreement with this.

A happy developer is a productive developer.

My advice would therefore be to discuss it in advance with your teams. Then choose the method and the tools that best match the needs of the client and the desires of the team.☀️

Alex has been a developer and blogger for almost 10 years. Every month he gives exclusive tips via email on how to become a better developer. Do not hesitate to subscribe to its newsletter!