I recently discovered that ‘agile’ (small A, big a, I don’t care.) is more than just another bullet in your sales guy’s buzzword bullshit bingo armoury. I always had my suspicions that there was something good there, now I’ve had a go and I get it. So here’s a few things that I have learned. (If you’re already doing this, none of this will be new to you but I wanted to get them written down.)

You don’t do agile.

Without sounding like the aformentioned sales guy, you can’t do agile. You can be agile. Duh.

In other words, you can’t follow a strict regiment of pre-planned rules and be agile. Obviously. You can, however, quickly react to change. Identify issues and solve them before they become a big problem.

Scrum is a set of pre-planned rules that facilitate being more agile. But it’s not the be all and end all. Your team will probably outgrow Scrum as they find what makes them more productive. I’ve heard it described as “agile with training wheels”. I agree.

People are really bad at estimating

Utterly, utterly awful. Story points are by no means a silver bullet, but they’re better than estimating in hours. Try out different relative estimation techniques such as affinity estimation or planning poker.

Protip: Don’t give up. It’s hard. As my next point explains…

Being agile is difficult

To properly implement Scrum (which is not the only way of being agile, but it’s a good start), you may have to do things you’d be otherwise uncomfortable with in any other social situation.

• Aggressively timeboxing meetings can make a Scrum Master look rude but can greatly improve the efficiency of meetings.
• Explaining to a client that interrupting a sprint for a ‘critical’ (not really critical) task can have repercussions for productivity. (Programmers are not units of work.)
• (Developers) Being empowered to get on and do your job.
• (Managers) Trusting your developers to do their job.
• Being ‘that guy’ who says “this isn’t going to work, we should stop.”
• Not planning months/years in advance. You may feel better, but that won’t matter when you overshoot your deadline by 6 months. Also, your client will be annoyed when you spent all that time estimating and you were wrong anyway!

These are all things that traditional common sense say are bad. Rudeness, managers not managing, admitting defeat early on, not planning well. You shouldn’t do these things! Except that actually they’re fine.

• Rudeness isn’t as rude when its for the good of a development team. Even if you feel uncomfortable at the time.
• Telling clients how things are done may seem like biting the hand that feeds you. But setting expectations is equally as important.
• Developers are smart. They don’t need to be babysat.
• Managers are natural risk-mitigators. But there is a clear dividing line between manager and Scrum Master.
• Being ‘that guy’ can save your company months of wasted effort and money.
• Planning in short bursts promotes focus and accepts the fact that estimates more than 2 weeks(?) in the future are essentially useless.

Being agile is fun

When your team is settled in to the agile flow, it becomes fun quickly.

Gone are the semi-awkward “I don’t think we should talk about that here” moments in the daily stand-up. It becomes a game as to which team can get their stand-up finished most efficiently.

Gone are the awkward messages from clients explaining that they want that feature right now.

Gone are micromanagers and in come Scrum Masters looking out for their development teams.

Gone are ‘code-monkey’ developers who wait patiently for orders before dutifully producing code in a caffeine-fuelled stupor.

Gone are the 2 year development cycles that inevitably end in failure.

But it’s hard.

Yeah. Nothing I can do about that. You’ll have to decide if its worth it for you. These are based on my experiences and they are by no means representative of the rest of developer-kind.