I’ve seen a number of teams who proclaim to be ‘doing agile’, with varying levels of success. For me, and especially where the team isn’t in a complex environment (i.e. a hierarchy of agile teams / scrums of scrums, etc), the major benefit of agile is that it allows the team to be as efficient as possible, delivering as much business value as possible.

I’ve also seen agile often used as a positive spin on being disorganised; simply having little or no documentation, design or process does not an agile team make! A team in this state, using agile vocabulary actually compounds the problem; both through the differences between reality and what is presented to customers, prospective team members and other stakeholders, and because of the additional process and work associated with agile (retrospectives, planning sessions) that are ineffective and waste time when not used properly.

Below are some common traits I’ve seen in good teams, and how to spot when they may not be correct, I’ve often seen the opposite of these in teams and they can be easily spotted by talking to individuals in the team; you’ll often hear complaints, moaning and general dissatisfaction around these themes.

• The team either has an empowered sponsor / business owner available at least 80% of the time, or there is a good understanding of the acceptance criteria for work items being delivered. If you regularly have situations where the sponsors expectations aren’t met, this is likely to be the issue.
• The backlog is managed sensibly, with work coming into the backlog and the team managing it through the process. Work coming in directly to individuals is a common indication this isn’t happening.
• Work item estimation is done with a good understanding of what the scope / acceptance criteria are. Estimations based on a one line description are unlikely to be accurate.
• The team has an appropriate development process for their situation. If the team is less than ten people, in one room, a simple wall board should suffice. If you have remote team members you need to think about how they interact with it.
• The team is empowered to deliver, and to modify their development process. This should be handled in the retrospective with the team optimising as appropriate.
• The team has a culture of code quality, especially tests. You often see a reluctance to refactor code when a codebase has insufficient tests.
• The team has an engaged daily standup with a small amount, but not too much, back and forth between team members. A flat, boring update with everyone giving a 15 second update to the team leader doesn’t really add value.
• The team regularly contribute to each others features, through discussion, review, pairing and testing. A group of people working in isolation does not equal a team.
• The team ships regularly, whether this is to a UAT environment, or live features are being deployed regularly. If the shorter of a month, or two iterations go by and this hasn’t happened, it’s a bad sign.

Note I didn’t say you need to produce reams of documentation for this stuff, putting stuff ‘on paper’ and storing them somewhere centrally does help the team be explicit about expectations, but isn’t essential.

Do you recognise any of them in your team?