An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.
There are plenty of these knocking about when it comes to agile. Plenty has been written about them before too, by people much more articulate than me, so rather than listing out a bunch of common themes I wanted to dig a little deeper into two of them.
Two that seem to be ever present, yet are without question the most damaging to the productivity of any team trying to get shit done.
- Team members not being 100% allocated to the team.
Yep – that old chestnut. All of the people on a scrum team should be available to that one team, all of the time. Why?
- So they can focus on the work that needs to be done and reduce context switching.
- For them to build deep and meaningful relationships with the other people on the team.
- For them to evolve and grow as a unit over time.
- For them to become collectively more efficient and effective at what they do.
One of the key benefits of working in an agile way is the speed at which a team can deliver small units of value. The constant feedback loops. The high level of collaboration. Start messing with the team members and giving them other priorities and distractions, then guess what’s going to happen?
Let’s look at how specific roles not being available at any given time during the sprint can impact this.
Scrum master: Conflict starts to surface within the team. The product owner wants to change the sprint goal in the middle of the sprint. An environment goes down and the team don’t know who to contact. Do these situations need to be spotted and addressed quickly to reduce the impact? Yes. (Note that I’m not suggesting here that these are the Scrum masters problems to solve, but she should be available to spot them early and help the team resolve them as quick as possible).
Development Team – A bug surfaces on a piece of code written by a developer who is not around for a couple of hours. Backlog refinement and discussion takes place without the input of the team member who later picks up the work. The team delays the sprint retrospective to day 3 of the next sprint in order to ensure everyone is there. Do these sound like a good idea? Not even close.
Product owner: The team needs a priority decision made before being able to completed the development of a backlog item. The team is running low on work deemed ‘ready’ on the backlog. The team has a queue of work waiting for business sign off for multiple days. These are all symptoms of the P.O. not being available due to other priorities. Do any of these increase the efficiency of the team? No. Now, it is possible for a product owner to serve multiple teams, however their full time role should be the product owner role alone.
2. Being physically distributed.
Q. Does Scrum recognise distributed teams? A. Yes. It recognises them as an impediment. (Source: Tobias Mayer).
There is no substitute for face to face interaction. Period. Anything other than this can lead to increased misunderstanding, confusion, and delays. Waiting for colleagues in a different time zone is a form of waste. Writing an email in 10 minutes that would have been a 2 minute conversation is waste.
Scrum is designed to minimise waste. To enhance communication and collaboration. To bring a team of people together to find a balance of skills, become self organising and deliver in short increments. How can having half of the people on the team sitting on the other side of the world possibly help this?
What is the problem you’re trying to solve? If it’s purely the cost per person on the team, fine. Go for it. But if it’s speed of delivery or enhanced team work or quality (or anything else!!) then please just find people who can sit next to each other and let them work it out.
OK, rant over. If you want to know more about agile anti patterns check out the great work of Stefan Wolpers over at www.age-of-product.com 😉