The anti-agile: which practices move you away from Agile

In the software development market, a lot is said about agility and its principles. We also have roles within the organization becoming more common, such as: agilist, agile coach, agile master, among other derivatives of "agility".

Well, here I'd like to talk about what it means to not be agile. Controversial, right? Well, the idea here is to comment on what I've experienced in practice. I will share situations in which people thought they fit into agile, but in fact did not.

Continuous delivery: you need to focus on where you want to go

One of the principles of agility talks about continuous delivery. Have you ever come across a situation where only the process of how the delivery would happen was imagined, and not the end of the project?

Yes, I know, sometimes we can fall into the trap of forgetting that part of the journey is the end, as our dear Iron Man would say, and we only think about the next delivery. We forget the purpose behind that whole solution being built. We learn from Alice in Wonderland that we need to be clear about what the mission is and where we want to go, otherwise any path will do.

Requirements: details can't be too much, nor too little

Small word, yet powerful… What I'm about to say may sound a bit cliché, but whenever I look at a requirement, I think: "Balance".

In day-to-day work, the team will mostly want to know in detail what needs to be done. The client, on the other hand, will most often think that a simple document they have, or even a meeting with them, may be enough to estimate and start developing. Well, so now what? What do we do?

Well, what worked for me in practice was seeking the balance of detailing, at a minimum, what is expected, what needs to be done, and how the application will behave, grouping by module and thinking about avoiding rework as much as possible.

Excess detail or lacking pertinent information won't help your agility, since one will become slow and overloaded with information, and the other will likely generate rework for you.

Whenever I see the word requirement, I guide myself by a phrase from the late General Patton, who served in World War II: "A good plan violently executed now is better than a perfect plan executed next week".

Change: it always comes, so how do we ease it?

Talking about change can always cause discomfort, because in practice we usually face rework, strain during negotiation, or a search for who's to blame or who made a mistake in the process…which, in my view, would not be agile.

Involve the team and ask: how do we solve this? The one thing you can be sure of in a project, no matter how detailed it is, is that something will indeed change. Be it scope, the people assigned to a given task, or the estimated time being longer or shorter. Otherwise, my dear friend, something is very wrong with your process, and it might in fact be anti-agile.

"Ok, so what would being agile mean in your view when it comes to change?"

Well, first, focus on the mission and see change as a great opportunity to hit the brakes and reflect, to review the concepts and paths we had thought of before starting, because change for the sake of change wouldn't make sense either.

Conclusion

Being agile, in my opinion, is:

• Having clarity and focus on the mission, that is, where do we want to go?
• Trust the team and build synergy, the how is up to them to define!
• Having a simple way to measure whether I'm on the right track.
• Well-defined rules of the game.

It may not be easy, but it is simple to avoid anti-agile actions.