Feb 11

The Opposite of Agile

oppositeMost of us might have played the game of Opposite Day when we were young. The rules of the game are simple: You’re supposed to say the exact opposite of what you mean. For instance, I would tell my mom: “I hate you so much”, when I really wanted to say that I loved her. Or I would tell my sister: “I really don’t think we should be playing a game together because that’s always sooo boring.” – you catch my drift.

Today, I want to play Opposite Day once more to see what we can learn from Agile’s opposites. (And no, I’m not going to make it easy on myself and say ‘waterfall’) While exploring what the opposite is, I want to identify the benefits of these opposites to see what we might be forgetting in our Agile Enthusiasm. So let’s see where this will take us.


“Get it right the first time.”

It’s important that everything you make is perfect. You will never get another chance of getting it right. Therefore, you need to make sure that everything you do is perfect.

Even though perfectionism is most of the time referred to in a negative way, there’s also something to say for it, for it pushes you to strive for the best. However, there is a trade-off between striving for the best and spending too much time on something. Agile supports the feel of ‘just enough’ and ‘do what you can’.


“Make sure you have everything.”

You should strive for a complete plan. If there are still holes, fill them. If there are still things to think about, postpone the deadline. Most important is to be sure everything is elaborated upon before we can move on.

It is scary to work with half a plan. It doesn’t feel right to start if you don’t have all the information you need. It doesn’t feel right to decide without knowing all the consequences.

It is in our dna to want to have security and know what lies ahead. It is good to finish something, and it is good to strive for completeness in the long run, however, it doesn’t help us in a process as messy as developing an awesome product. A certain amount of flexibility and improvisation are needed to get the most creative solutions. Iteration and working with small chucks are the medicine for the slow, inert bulkiness that is the consequence of our fear of missing something important.


“The butterfly effect is evil.”

Once made, you don’t want to change it, because changing something will influence a lot of other things. This is why we have to think things up beforehand, so we don’t have to change them anymore later.

Nobody likes it if you change your mind too often. But the point here is not how often you change it, but why you change it. It is good to stick with a decision, IF that decisinos was the right one. It is also good to change your direction, if the direction is a consequence of a wrong choice.

It is good to realize what implications certain decisions have. However, the only good reason to stick with an old idea is ‘Because it won’t make a better product’ and not ‘Because otherwise we will have done all this work for nothing.’


“Management should decide that.”

I can’t possibly make that call, I’ll need to run that by my manager. I don’t bear that responsibility, so it’s not in my power to make that choice. I will get back to you in 3 weeks.

It is ok if you don’t want to carry a responsibility that isn’t yours. But who says it isn’t your responsibility? I think responsibilities should lie with the persons most suitable to make accurate assessments about something.

The important thing, in my eyes, is that decisions are made, not by individuals, but by the team. Discussions should be supported, for it brings to the surface the smart solutions. Also, decisions should be made by researching the actual end user and their context.

Decisions should not be made because someone has decided the responsibility lies with someone else, but because you think it’s the right decision to make. And if you’re sure about that, things can move much quicker, which will leave you time to change your mind later (but only if needed!).


“I want to know every detail.”

Be sure to document everything, because we need to make sure other people can understand why we did what we did. Also, the knowledge should be accessible to anyone, not just you.

Of course it is handy to document everything. Of course it is good to be able to transfer our knowledge to people outside the team. Going into detail and being precise about what is actually happening is not a bad thing. One of the biggest problem when someone leaves a company is how to keep the things in that are crucial to keep in. But there’s also a downside to it. Being precise and documenting every detail can get in the way of shipping the product.

Again, there is a trade-off between this and the time you have to spend. And I can’t imagine someone who’d rather use up precious hours to document something than build something that is new, cooler and better.


So. I hope this blogpost was not useful to you at all. By all means, if you have any comments or additions, keep them to yourself.

Permanente koppeling naar dit artikel: http://agilethings.nl/the-opposite-of-agile/