Common Pitfalls of Agile Teams

Common Pitfalls of Agile Teams

foot about to slip on banana peel

Agile, and Scrum in particular, has become mainstream for most development teams. Despite so much knowledge in the field and an ever-increasing number of coaches, many teams still struggle with common pitfalls which could hinder their productivity.

The Development Team is Responsible

When talking about teams, it is not only the development portion of it that’s important but everyone else as well, including the product owner and Scrum Master.

The whole team is responsible for providing an incremented and potentially shippable product at the end of each sprint: The added value is identified and defined by the product owner before being materialized by the development team under the guidance and support of the Scrum Master.

It is a shared responsibility, and each member of the team is responsible for the overall goal.


Some teams might misuse the retrospectives by transforming them into a blaming or complaining (and sometimes justification) event. A retrospective is the team’s opportunity to take a break and reflect on the events and outcomes of the finishing sprint. It is an opportunity to learn, inspect and adapt. Teams shouldn’t skip retrospectives and should try to identify as many potential lessons as possible.

Agile is Fast

The nomenclature of agile might falsely give the impression that agility means speed. Although most agile teams deliver faster than normal teams, this is not what agile really means. Agile really means responding quickly to change. There might be short sprints with shippable product increments at the end of each, as in Scrum or, more often, prioritization and releases as in Kanban.

The essence is to get earlier feedback and rapidly respond to customer requirements and business change. Teams shouldn’t be tempted to sacrifice quality or improvements to achieve the illusion of being fast. If they fall into this trap, they will actually get slower by incurring technical debt. So, it’s crucial that teams understand what agility really means and take care to focus on aspects other than speed.


The most commonly argued question in the software industry is: “What can be considered a bug?” Some teams might find it easier to close a failing user story and create a bug as follow-up. Well, such a team is not one whose members understand agility.

The team should focus on delivery and ensure that each user story that is closed can be potentially delivered to the customer the next day. A bug is only reported when something is not working as expected after delivery, but closing a user story after reporting a bug for it within the sprint is more like showing and reporting progress than building and delivering products.

The Big Picture

Teams are not working on user stories in sprints. Rather, teams use an incremental approach to deliver functionalities. This means that they need to see the big picture of what they are working on and how to maximize the value delivered to their stakeholders.

Again, it is necessary to highlight that the product owner is part of the team and that it is his or her duty to draw this picture, make it visible to the rest of the team and get their feedback on it. The big picture could be named a theme, an epic or a feature—call it what you wish, but please make sure that it is present.

These are some of the common misunderstandings and pitfalls agile teams could fall into. Did you face any of them? Have you experienced others? Feel free to share in the comments section.





Islam Kotb Ismail (PMP, CSM, CSPO) is a senior agile project manager and Scrum Master at Wirecard Technologies GmbH in Munich, Germany.

Learn More
comments powered by Disqus