To be or not to be... Agile!

In my career I’ve seen a lot of misconceptions about Agile. And I’d like to do a step back and explain what being Agile means to me.

We ‘do’ Agile

This is the biggest misconception of all, and the main reason for my blogpost. Again and again I’m hearing people/companies say: “We do agile”. And this is just wrong… Agile isn’t some system you ‘do’. It isn’t a selection of things you can learn from a book. It is just a mindset and all the other stuff are consequences, let me explain that!

The meaning of ‘Agile’

If you look up the word Agile in the dictionary this is what it comes up with:

Agile means you’ll move quickly and easily. That is it basically, everything you do when you are agile boils down to:
Start quickly, get something done quickly, expect changes in movement and go with it easily.

For example, in software, expect every bit of code to change (more than once). This will automatically make your code easy to read, extend and refactor. Not only code will change, the requirements will change. Nobody knows what a system will look like in two/three years (those who say they do are wrong), we might have a good idea what to make at this movement, but once you get started people will want other things… this always happens. Stay open to these changes in your movement, be agile!

Agile, Scrum, we need to do stand ups!

Ah, the stand ups, you’ve been reading a book and it told you that you need stand ups? This is a requirement to be ‘agile’? WRONG. Like I said before, it is all just a consequence. Why do we do these stand ups? Because you need to know what everybody around you is doing at this moment. In waterfall projects you already know what people would be doing weeks (even months) in advance. But if you embrace the agile mindset and accept all these changes you might not even know what you’re doing tomorrow. The more you are open to changes and quickly move between tasks, the more often you’ll need to update your colleagues. That is why some projects do stand ups, a consequence of being open for changes.

We use whiteboards and post-its, we do agile!

If your design and the requirements don’t change, write everything down with a pen, or maybe put it in some Software Architect solution (Rational anybody?) or just inscribe it in a stone tablet. Instead, if you are agile and move quickly, designs and requirements change. You don’t want to go into a meeting with a printed piece of paper which has tasks or designs etc, you’d rather want to have the design on a whiteboard. This will allow you to change it during the meeting instead of re-printing. Whiteboards are perfect to erase and redraw shapes and lines! It is just the best tool for somebody who is agile. Except for one problem, if you write down text and you have to move it… rewriting takes a long time. To counter this we use post-its: write once, stick everywhere! It complements the whiteboard very well.

So do we need to use a whiteboard and post-its to ‘be agile’? NO… Whiteboard and post-its are a consequence of being agile, it is the best tool for the job as far as I know.

Retrospective!

If you don’t try new things and you don’t want to change the way you are working (being not agile) you don’t need to evaluate and come up with changes, obviously. But if you are agile, open for change, you need to have meetings on how you can change. As a consequence the retrospective arrives. This meeting is one of the most important meetings if you are agile; you talk about what can be improved in your process: What can make us more agile? What is holding us back?

No agile rules…

I don’t think agile needs a set of rules, you just need people to explain the basic concept of the mindset. The other things most organizations treat as ‘agile rules’ can be considered best practices because they make sense if you are agile; but please don’t just follow these rules.

Learn from others, embrace the agile mindset and come up with your own system… that works for you!