At 51zero we’re huge advocates of Agile, we love Agile, we use Agile methodologies to successfully deliver software for our clients. We believe Agility is the foundation on which Continuous Delivery and DevOps can be successfully implemented. However, we’ve seen Agile misinterpreted and misapplied so badly, so often, that it gets a bad name.

There are many great resources online for agile best practices and patterns (see end of post for some links), but sometimes it’s just as useful to identify anti-patterns, things to avoid, ‘process smells’ to look out for. Anti-patterns can be useful tools to help determine where things are going wrong, giving you the opportunity to apply improvements to your process and improve your team.

As such we’re launching a series of blog posts on Agile Anti-patterns and today we’re starting with stand-ups.

Standup Anti-pattern: The super-sized standup

We were recently engaged to help rescue a failing project. When we first attended the standup we were amazed to find the entire corridor, where the standup was held, packed. There were 14 developers, a few BA’s, a product owner, scrum master and an couple of interested stakeholders. Everyone of the developers and BA's took their turn with the ‘Yesterday, Today, Blocker’ pattern, and then the PO and stakeholders had some things to say. Even though the updates were fairly succinct (not all of them were) the standup took 30-40 minutes, everyone was getting frustrated and bored.

It smells when: More than 5-7 team members talking at the standup

Likely outcome: Many people are working on different quite unrelated things, they don’t care about half of the updates and the overall feeling is that the standup is a waste of their valuable time.

Potential solution: Your agile team is probably too large, it’s time to consider splitting it up, consider investigating scaling agile (perhaps running scrum of scrums).

Standup Anti-pattern: The serial status / daily micromanagement meeting

It can present in several forms, it can be the scrum master tracking the time taken for each task and asking for effort estimates during the standup (“you said that’d take 4 hours, it took all day, why weren’t you able to complete it on time?”). It can present as the scrum master/product owner, directing the activities of the day, telling each developer what they have to work on today, or it could be a daily reminder that they’re late and failing on delivery so they have to do x, y and z today.

It smells when: The scrum master or product owner is addressing the team members individually. The team aren’t talking to each other instead they’re reporting publicly, daily, to line management.

Likely outcome: Developers become disengaged with the processes, they are less likely to report blockers, they’re less likely to take ownership and responsibility for tasks, they will not hold each other to account as a line manager is holding them to account. The agile team breaks down and a command and control structure takes it's place.

Potential solution: This can be tricky, it should certainly be discussed and options considered at a retrospective. The scrum master/product owner will likely need coaching on agile practices.

Standup Anti-pattern: By the numbers