Privacy Policy and Cookies

By continuing to use our site, you agree to our Privacy Policy and our use of cookies to understand how you use our site, and to improve your experience. Learn More.
I Agree.

Three Problems with Agile

Last modified date

The essence of Agile is to ramp up communication between team members to an extreme degree. The idea behind this is to minimize the functionality gaps, design misses and rework so often encountered in waterfall development processes, with an end goal of maximizing the output of usable software.

Ramping up communication, however, has its own set of challenges. For starters, here are just three:

#1 Distributed team logistics

For a myriad of reasons (cost, morale, retention, etc.), the past ten years have seen more and more companies allow team members to work from home. However, coordinating sprints across dispersed teams is very difficult. There always seems to be someone missing or joining the conference call late and ‘catching-up’. This is causes disruption and irritation.

Now consider that the typical team these days has members spread across the world. The scrum may start at 9am in San Francisco, but it is lunchtime in New York, dinner time in London, and past bedtime in Bangalore. There is really no good compromise in this scenario. No matter what time the scrum starts, some or all of the team will not be happy.

#2 Continuous sprints

With Agile, the team is always in a “sprint”. Anyone with even basic sports awareness knows that after a sprint there should be a period of rest. However, there is never a “rest week” on an Agile schedule. For some reason it is always just ‘sprint’, ‘sprint’, ‘sprint’. This can lead to burnout and management resentment.

#3 Availability conflicts

Very often, business requirements and design validation are sourced from actual business users. However, business users actually have a day job. They can’t be in a room in a scrum all the time. If they are only available intermittently, the process starts to fall apart.

With lack of business user input, teams often end up in an intense discussion of a problem, where no one really understands the problem clearly enough to meaningfully discuss it. And this can be yet another source of team friction.

What is the solution?

It would seem that these problems and others could be solved by technology, but there are surprisingly few (no?) options out there. What would the ideal solution look like?

One thing is for certain … since different team members (e.g. designer versus developer) have different skill sets and needs, any new tools will have to be role specific.

More thoughts to follow …


Jason Hardy-Smith