stack twitter tryhackme rss linkedin cross

Wilco van Esch

Skip to main content

Search results

    How to prevent a team from feeling overburdened

    Context: Software development teams with an Agile/Scrum-like way of working.

    Say you've got a pretty good situation going. Executive-level managers tell the feature teams they have full autonomy and responsibility for their work. The teams are told the company goals, given some problems to solve that could help reach those goals, but the teams are free to come up with better solutions, prioritise their efforts, anything they think is best to reach the company goals. Within the teams, the product owners are fully on board with this as well, with team members having the autonomy to decide what goes into their sprints.

    Yet, the feature teams almost universally complain that the workload is excessive, that they feel like they're always just pumping out features, always rushing, that there's no time to do proper design thinking or refactoring, that there's no room to develop themselves at this company.

    How could this possibly be? The teams have been told they are autonomous, they've been given the space to plan their own work, yet they feel overburdened.

    Imagine an airline which holds safety as its highest priority. It does all it can reasonably do in terms of safety procedures, audits, reports, training, corporate communications. Yet, lots of minor incidents are happening and even a near disaster. When digging deep, you find that the experience of personnel is not that safety is the highest priority. They feel that the informal communications and performance evaluations are geared towards the number of on-time departures and arrivals and the amount of time a plane is out of action. Sometimes when a situation feels trivially worrying, maintenance personnel and pilots alike decide to forge ahead. After all, it would be hard to explain to management why so much time was lost in extra checks for something that most of the time will turn out to be a non-issue.

    The point is you can invest lots of time and effort into communicating how you want people to behave, but unless your incentives and your casual interactions don't line up with it and do so consistently, it won't matter.

    How do you fix it?

    1. Decide if you actually do trust the teams. If not, you have other problems to fix first.
    2. Be consistent in your communication. You could encourage teams in just the right way for a year, but one "it feels like there's very little output" or "is my favourite feature X done yet?" can undo all of it.
    3. When anyone still complains the pace is unsustainable, ask them what's keeping them from changing that pace. At this point the solution should require only a conversation and the answer will make it clear who need to have that conversation.