Common Pitfalls of Scrum Teams. Observations after working with… | by Ardy Gallego Dedase | Sep, 2022

Observations after working with multiple organizations

Photo by Kelly Sikkema on Unsplash

Scrum is a framework that helps facilitate effective collaboration to build software. Most of the organizations that I’ve joined were using the scrum framework. I’ve been working with scrum teams for most of my career.

Most of the posts that I’ve already seen discuss ways to use scrum effectively. This post will be different. I will use Charlie Munger’s mental model of Inversion.

“It really works to tackle much of life by inversion where you just twist the thing around backwards and answer it that way.. All kinds of problems that look so difficult, if you turn them around, they are quickly solved.” — Charlie Munger

I experienced scrum’s benefits firsthand. However, just like any other framework, it is not a silver bullet.

Scrum itself isn’t the problem. What causes undesirable results could be its misuse and/or existing fundamental issues within your team or organization.

A story point in scrum is the unit of measurement used to estimate the effort required to complete a story or task. A typical scenario will be: Teams agree on the story points required to complete a story. The story gets broken down into tasks for developers to “complete”.

We could underestimate our stories and tasks. If this happens constantly, we will end up frustrated because we failed to deliver what we have committed to. Over-committing to a sprint that we can’t complete can take its toll on the team’s morale.

The root causes:

  • The team is not familiar with the product that they’re working on. e.g. Another team recently handed over the product or service.
  • The team is new. Members are still adjusting to working together.

We might default to just trusting the process, i.e. assume that teams will improve their estimation skills over time. However, I recommend tackling this proactively. We can do this through knowledge sharing or conducting training with our teams. I had a story point estimation training in my current company conducted by one of our senior developers. It was a very productive workshop that helped my team.

Getting better at story point estimation is a fairly big topic on its own. There are a lot of resources online regarding story point estimation.

Just because a process or a meeting worked well in your previous team or company, it doesn’t mean that it will work well now.

For example, a software developer who just joined a new team might say:

“In my previous team, we didn’t provide estimates or story points on what we were working on. Therefore, we must not use story points in our team.”

In the example above, the developer assumes that not using story points will work in the current team because it worked in their previous team. This is an example of “cargo-culting”.

Your scrum process is fine-tuned over time. It’s a cycle of gathering feedback and error corrections. It all depends on what’s suitable for the team.

There are many variables that shape your team’s scrum process. These variables could be your team’s experience, personality types, company size, expertise, etc. However, it’s always tempting to shoe-horn into our current team any tools or processes that we feel have previously worked well for us. It’s easier to copy in most cases.

There is always room to try something new. Then abandon that new thing if it doesn’t work out well. However, it’s useful to check if we are blindly copying what seems to work in another setting.

Meeting inefficiency

Scrum relies on the team’s effective collaboration. The team collaborates through “scrum ceremonies”. Scrum ceremonies are meetings that are scheduled in a regular cadence around your team’s sprint.

Your team has to facilitate these ceremonies effectively. Otherwise, you’ll end up wasting a lot of time every sprint. For example, if your sprint planning involves people that don’t need to be there or your daily stand-up takes up 10 minutes more time than expected. Imagine the time wasted here, given that these are recurring meetings.

Bring awareness to the team around meeting efficiency, making it a shared responsibility. A “ceremony” is still a meeting.

  • Regularly update the attendees in your ceremonies. Remove those that don’t need to be there.
  • Assign a facilitator to help keep everyone on track during your ceremonies.
  • If guests from outside your team need to attend one of your ceremonies, front-load the topics relevant to them. Your guests can leave before your team starts discussing the topics that are irrelevant to them.

Your scrum team relies on constant feedback for incremental improvement. There is a scrum ceremony called “Sprint retro” where the team discusses what went well, improvements to make, and actions.

Team members need to be comfortable sharing honest feedback in order for scrum teams to be effective. If the team members are not comfortable. They don’t feel “psychologically safe”. The scrum team will underperform in the long term.

Make sure that your manager or senior developer is regularly checking in with the team. Raise any concerns about psychological safety as soon as possible. Sometimes the root cause is miscommunication, which is easier to solve.

However, personality conflicts are harder to resolve. An individual who’s not a good cultural fit overall with the organization can also cause psychological safety concerns. Get help from your manager to handle such complex cases.

Scrum is a framework. We don’t always have to strictly adhere to what’s written in the book or what’s taught in training courses.

We are using scrum in the real world, not in the ideal world. Scrum is flexible. Scrum teams can customize it according to their needs.

One example — I attended a scrum training where the instructor had a firm opinion on excluding product managers during daily standups. This might sound fair in theory — we can theorize that those daily stand-ups are a time to share updates between developers about what they’re working on.

However, in reality, daily stand-ups can also be a good time for the product manager to stay up-to-date with what’s going on in the sprint. It can help the product manager to follow up on any concerns with the team members after the daily stand-up.

News Credit

%d bloggers like this: