Agile teams: 5 signs of trouble

Say “agile” to any technology leader, and software development typically comes to mind. As someone who has hired, trained, mobilized, and managed cross-functional teams over the better part of two decades, I’ve seen the word “agile” used extensively as the gold standard for developing, launching, and iterating complex systems.

While a small, self-organizing team can sprint through tasks and deliver results quickly, it can be surprisingly easy for even the most well-intentioned teams to get things wrong. In fact, it’s likely that your team might not be as agile as you think.

[ If you simply break legacy development process into two-week sprints, that’s not agile. Read also: Beware the dark side of agile project management. ]

Here are five signs that your agile team isn’t meeting its full potential.

1. There are too many people on the project

Jeff Bezos instituted a famous rule in the early days of Amazon: A team is too large if it needs to be fed with more than two pizzas. An agile team should have fewer than ten members to remain efficient, but companies often add people when a project becomes too big for one team. This leads to longer briefings, more handoffs, and a drop in efficiency.

Agile teams follow the mantra “less is more.” Rather than adding more people to the project, the objectives of the project should be broken up into more manageable chunks that a team can sprint through and deliver better results.

2. The team is disorganized and chaotic

An agile team needs autonomy, but every team needs proper management and organization given the fast-paced nature of agile development. The duty often lies with the scrum master, who should be implementing the best communication processes suited for the team. However, if your daily standups are longer than 15 minutes, then your team might not be as organized as you think. I have seen many different organizations hold long, crowded meetings with people who weren’t necessary to the project - which, not surprisingly, led to a bored and unmotivated team.

The best practice is to narrow the number of invites to the people who are vital to the task at hand: Wasted meeting time leads to a lower ROI.

Another consideration is to assess how teams are communicating on schedules, stories, and responsibilities. Determine if your team is communicating adequately on their boards, and ensure that everyone understands the overarching goal and that each person is aware of their role. If these points are not drummed into each individual member, then you need to take a step back and reorganize how the work is being done.

[ What tools can help? Read also: Top 7 open source project management tools for agile teams. ]

3. Sprints are agile in name only

Some companies have implemented their own versions of agile teams but kept or reintroduced aspects of the traditional “waterfall” paradigm method. Instead of a week-long sprint based on developer estimates, the agile team is forced to do three or four week-long “sprints” to meet business deadlines.

Agile teams are structured to have time to test and measure incremental progress on a project to ensure both the product’s quality and that it meets the client’s needs.

Companies working with traditional team management methods produce features that have long development time and become irrelevant by release. I have always brought the agile methodology with me wherever I went during my professional life because it results in higher ROI for the company and a better employee experience.

What about team members’ personalities? Let’s explore why they matter: