≡ Menu

We’ve all been there: code that hurts your brain to look at, let alone comprehend.

Not written by you, of course. You wouldn’t write a mess like that, and you can hardly believe that somebody else did (or maybe you can…?)

Your mind wanders to who to blame for this abomination before your eyes. You start complaining to the person sitting next to you. Then to your boss. Then you decide that it’s time for a coffee and then to browse for new jobs.

Sound familiar? I bet it does!

The difference between an average programmer and a good one is in what you do next.

Do you ignore it and try to forget you ever saw it, or do you attempt to improve it?

I have a simple rule that I like to follow: I always try to leave the code in a better state than I found it.

This might involve small improvements, like improving code formatting, renaming methods or variables, or adding useful comments. Tiny improvements add up over time, especially if the whole team is doing the same thing!

Or the improvement could be larger, like refactoring or adding test coverage.

Yes, this can take time, and yes you do have that deadline to consider. But it’s amazing how quickly small improvements can be done; certainly in much less time than it took to understand that grotesque code. Which means that your improvement might make it much quicker for the next person to understand – and that next person might be you, when you revisit it in a year’s time…

The important thing is to do it, and encourage your whole team to do it. Don’t be afraid to change things. Take responsibility for that code, even if you didn’t write it: embrace collective code ownership!


I recently had the opportunity to hear Jean Tabaka, Agile Coach from Rally Software, speak in Brisbane at Yow! Nights about The 12 Failure Modes of Agile.

Jean has been consulting as an Agile coach for many years, so it was really thought-provoking to hear her top reasons of why the adoption of Agile might fail.

I thought I’d repeat the list on my blog for my readers because I think it’s a great compilation of potential pitfalls we should all work hard to avoid. Perhaps we could call them “Agile anti-patterns”!

The 12 Failure Modes of Agile (from Jean Tabaka)

1. “Checkbook commitment”

This refers to when people are saying they’re doing “Agile”, but without actually committing to it. They expect immediate results, and they use the same old organisational structure and metrics.

2. Culture that doesn’t support change

If the company culture is resistant to change, how can it adopt a methodology that embraces it? An example of this would be a culture where people are rewarded for not “rocking the boat”.

3. Ineffective use of retrospectives

Retrospectives must be done and handled effectively. The feedback gained via retrospectives must be learned from and acted upon. The whole team must be responsible for the actions from the retrospective, not just the scrum master.

4. Ignore needed infrastructure

For example, for a team to do Continuous Integration, it needs access to a build server!

5. Lack of full planning participation

The whole team needs to participate in planning and, as a team, commit to the work defined for the iteration.

6. Unavailable (or too many) product owners

Product owners are busy, but it is a warning sign when they say “we’re too busy for all this communicating”. Also, if there are too many product owners, it can be hard to get agreement.

Jean raised an intriguing question here: she asked how many people in the audience had done some form of Agile training. Many hands went up. Then she asked, how many people had worked with product owners who have been trained in Agile? I don’t think anybody raised their hand…

7. Bad scrum masters

The team needs to collaborate well within each iteration, and a poor scrum master can be harmful to the team’s morale and productivity. An example of a bad scrum master is one that plans all the work, puts it in a tool and then tells people to do it.

Jean made the point that if you take over the decisions for others you lower morale (and IQ’s!). Scrum masters should not control, they should empower.

8. Not having an onsite evangelist

This point is particularly important for distributed teams, or teams in branch offices. Without an Agile evangelist/coach onsite, the remote team can lose its way.

9. Team lacks authority/decision making ability

Agile is not about control, it is about empowerment.

10. Testing not pulled forward

Testing should be done up front, ideally, or else as soon as possible. Testing should also be automated.

11. Traditional performance appraisals

Traditionally, performance appraisals reward individual performance. In an Agile environment, the focus is on team performance, not individual heroics, and appraisals should reflect this.

Performance evaluations should also be regular, not once per year.

12. Change is hard, Agile is blamed

For example: an Agile methodology is introduced to solve a company’s problems. It fails, and Agile is blamed rather than the company’s own, deeper problems. It is often easier to look outwards and assign blame rather than to look inwards.


Recently I attended a session of the Brisbane Agile Academy Meetup Group (which I highly recommend, and not just for the free pizza!) chaired by Craig Smith, on Using Agile for Non-Development Projects.

I must admit have a special interest in this idea: ever since I began using Agile for software development I have fantasised about its potential for non-development projects. I used it to partly plan my recent round the world trip. A former colleague of mine was using it to plan his wedding. If it works for a software team, it could work elsewhere… right?

But it’s never quite that easy, is it? It can be difficult to get buy-in for an Agile process in a development team, depending on the level of management support and developer engagement. Imagine how much harder it must be to get momentum in an environment or industry that may not have even heard of Agile!

Having these doubts in mind, the session was a real eye-opener for me. I was introduced to real people working in corporate teams using Agile for non-software projects.

Some examples I have discovered:

  • The bank, Suncorp is using Agile for finance and procurement teams, with an Agile coach from software development background, and by mapping Agile onto standard processes
  • The telecommunications company Telstra is applying Agile while providing external services to Suncorp, integrating with Suncorp’s preferred business service methodology
  • Lonely Planet’s team of in-house lawyers is now using Agile to plan their work load and ensure priority items are done on time (Beverley Head in Agile Today, May 2011)
  • AccuRev trained their whole sales team in Certified Scrum Training and adopted a quarterly iteration period, aligning with their sales cycle

I am looking forward to watching this trend continue.

Perhaps it might become the silver bullet to unlock the next wave of productivity growth for teams of knowledge workers. Or maybe lots of story boards will just end up getting thrown off rooftops!

What do you think? Do you know of any other examples of Agile being used in non development environments?


I like to see the process of managing email as a little like gardening. You need to prune the plants and keep on top of the weeds. If you get it right, you end up with a beautifully manicured garden. If you don’t, you just end up with an overgrown backyard full of weeds!

Japanese garden

Japanese garden (Randy Robertson)

With this thought in mind (perhaps I’m a little too enthusiastic about spring?), today I took the challenge of greatly simplifying my Inbox, based on one simple principle: does this item need my immediate attention?

To do this, I used the advanced features that Gmail offers to handle a lot of the ’email gardening’ for us!

I started with the low-hanging fruit: the Priority Inbox feature.

Turn on the Priority Inbox feature

The Priority Inbox feature is brilliant. It means that Gmail will automatically determine which items it thinks are important and which ones aren’t, and then shows you the priority ones at the top of the page. You can train it to teach it what you view as important and what isn’t.

You may ask, what about the items that the Priority Inbox feature doesn’t deem as “important”? I’m talking about dozens of emails every day: newsletters, notifications, bookings; as well anything important that Priority Inbox might have missed (it’s not perfect, after all!)

It would be helpful to be able to categorise all these emails, wouldn’t it? I did this by using Gmail labels.

Create labels

Labels are a very powerful Gmail feature: they allow you to classify and thereby group your emails. Think of it as an array of virtual flower boxes, organised by type of flower.

For example, I have a label called Newsletter, in which I like to group any subscriptions that I don’t need to read straight away. Later, I can read them by clicking on the Newsletter folder that Gmail creates for me the left-hand side of the Inbox.

Gmail Label

Gmail Label

I created more labels, for example, one called Facebook, for Facebook notifications. Some people have said “just stop forwarding the notifications to your email account!“. But it’s often quicker to read them as email. It also means that I don’t need to log into Facebook, which as many of us might know, can be very distracting!

Create filters

I took the label idea one step further: I used Gmail filters to let it do the work for me. Filters are another powerful feature and are used to automatically process your emails for you as soon as they arrive. It’s like having a gardener to tend to your plants for you while you’re out shopping.

So I created the filter “all emails from Facebook should be removed from the Inbox and assigned a label of Facebook“. (Another example of a filter would be, “all emails from Brendan should automatically deleted.“)

Creating a filter in Gmail

Creating a filter in Gmail

I applied a similar process for labels and filters for notifications from Twitter, LinkedIn and so on.

Process remaining emails

At this stage the groundwork has been done for an automated email-management process. The flower boxes (labels) had been set up and the Gmail gardeners (filters) had been told what to do.

I then took my Everything Else folder and went through the remaining emails, the ones that were not classified as Priority. (At this stage I had around a thousand items in this folder!)

For each email, I applied a simple process:

  1. Is this item spam?
    If yes, click on the Gmail Mark as Spam button. I find that with this feature I very rarely receive spam in my Gmail account.
  2. Is this an email one that I DO NOT want to receive ever again?
    If yes, unsubscribe and/or create a filter to automatically delete items from that address in future. (For example, a mass marketing email.)
  3. Is this an important item which needs to be read/processed?
    If so, click on the Mark as Important button to tell Gmail to mark emails like this one as important in future. Also click the Star icon to mark the item for later processing. (For example, an email from my Dad.)
  4. Is this email one that could be archived automatically in future?
    If yes, create a filter such that any emails in the future from this address are removed from the inbox and assigned a label. (For example, all hostel booking notifications from HostelBooker can be archived and assigned the TravelBooking label.)
  5. Anything else, either click on Archive or Delete as required.

The Result


What does that really mean? It means I have no emails in my Inbox that are unprocessed. Every email is in its logical place: either assigned a label for reference, or marked with star so I can deal with it later. I also have a large set of new filters to automatically process items in the future.

Is there more work to do?

Yes. I still have to go through and process the starred items. But now I know exactly how many of those there are, and as a constant reminder, I will see them every time I log in at the top of the page.

Was it worth it?

Overall, the process probably took me couple of hours to do. It was a profitable investment of my time: in future I will spend more time responding to important email and less time managing unimportant email.

In a slightly geeky way I also kind of like the feeling that my inbox is being constantly monitored by a robot that will filter the emails for me. That means less work for me.

On the other hand, I also know that I will need to be vigilant in applying this process regularly. I will need to keep creating new filters/labels to keep those pesky weeds under control.

Ok, enough about email. Now it’s time to go and have a cold drink in that garden!


“What we can or cannot do, what we consider possible or impossible, is rarely a function of our true capability. It is more likely a function of our beliefs about who we are.” Tony Robbins