Agile Anti-patterns - The key to success isn’t just standing up

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

This standup sounds a lot like this - “Yesterday I worked on FEAT-1273, today I’ll work on BUG-9821, I can’t work on FEAT-9218 as it’s blocked by BORE-1241”.  Unless your development team have an encyclopedic knowledge of your backlog then they don’t know what those index/reference mean.  If the team tends to refer to tasks like this, then guess what, they're not paying attention to what each other is doing and you’re getting little value from the standup.  

It smells when: Referring to issues/stories by their index, rather than a short task summary.  

Likely outcome: Developers aren’t working as a cohesive group, they’re not paying attention to what each other is doing and they’re just waiting their turn to justify their existence at the standup.

Potential solution:  Simple, refer the tasks using short summaries that everyone understands and has previously discussed at a planning session. 

Variant: The Monotonous Roundup - this differs in that team members stand in a circle, waiting in a zombie like state to take their turn to speak, giving just enough attention to determine if it's their turn to speak yet.  When it is their turn they give their update then return back to snooze mode.  It's time to find a way to break up the monotony, one technique we've used successfully is a catch ball, rather than doing a 'round' whoever has the ball gives their update, then chooses who to throw it too next, it's a surprisingly effective way to keep people focused.

Standup Anti-pattern: Let’s all talk through these blockers until they are solved

Blockers are inevitable, and it’s important to discuss them to get them resolved otherwise time is wasted and progress stifled.  However some teams have a tendency to try to solve the blocker there and then when it’s raised at the standup.  A team member highlights the issue and the standup get’s derailed, it turns into a problem solving session. The entire team is focused on the problem, where perhaps it only takes 1 or 2 team members to resolve it.

It smells when: Blockers get too much airtime, instead of being noted and taken offline.

Likely outcome:  Team members that are not likely to be involved in unblocking the solution feel obliged to stay to ‘try to help’, instead of focusing on other productive work they can be completing.

Solution: The scrum master should give the blocker ‘just enough’ airtime to identify the issue, who should be involved in resolving it, making a note and then taking it offline and following up after the standup.

What "Good" looks like

There are many other anti-patterns and there can be cross over between them, sometimes the the root cause can present in other fashions.  But keeping an eye out for ‘suspicious process smells’ and taking corrective action will lead to a more efficient and productive standup.  

Keep in mind that, it is NOT A serial status reporting, you are not reporting your activities to your line manager, you should not be ‘justifying’ your existence. The standup is primarily a 'sync point', a quick status 'update', an opportunity for the team to communicate and coordinate the day's activities, an opportunity for them to commit to each other what they will work on today.

A good (admittedly idealised) standup sounds a lot more like this; the team gather around the card wall, the scrum master has ensured it’s up to date, the scrum master looks at one of the tasks that has moved to dev complete, it’s Jimmy's, they look at Jimmy who then says…

Jimmy: “I ironed out that bug in the new authentication service yesterday, I’ll need to bounce all the test servers to deploy it this morning, then I’ll pick up the new error code reporting task this afternoon”.
Jane: “Oh wait, I’ve got big report running on the test servers, can we wait until noon to deploy it? I’ll ping you when my reports have run.  My turn, I finished that change to the reporting micro service architecture, that’s what’s running now, once that’s confirmed I’ll migrate the other reports this afternoon”
Jonny: “I was working on the new web deployments yesterday, I got blocked with exposing the port via docker last night”
James: “Ahh, I’ve got that working recently, I can help you out with that this morning …”

A good agile process requires pragmatism, and being a pragmatic agilist, knowing what agile practices to use and when, is part science and part art.  We at 51zero are able to help you on your journey to agile success, contact us to find out more.

We also recommend

We've worked with Mountain Goat Software before and they have excellent examples on good Agile practices, we recommend their writeup on what makes a good standup.  Martin Fowler also has a good write up on standups.