Agile vs. Developer Productivity
Developer Productivity is big business in 2024. If nothing else, the rise of various AI programming copilots has brought the conversation to the forefront. You should definitely equip your software developers with these tools if you haven’t already. But there are a lot of things you can do that are easier and less expensive than licensing an AI copilot. I’m going to start sharing a few of those in this blog.
Let’s start with an observation:
Software developers hate meetings.
It’s hard to overstate this. Software developers really, really hate meetings. Organizations like Google and Microsoft that regularly do developer satisfaction surveys have known this for years, and they have talked about their research publicly in various ways so there’s no excuse not to be aware of this. Software developers notoriously never agree on anything, but if you put, “I feel productive when I’m in meetings.” on a survey with a “Strongly Disagree” => “Strongly Agree” scale, you’ll be amazed at where the median answer converges.
If meetings impact developer productivity as much as the developers themselves are telling us, then it only stands to reason that one of the best ways to improve productivity would be to start reducing the number of meetings.
Why do software development teams have so many meetings in the first place? Depending on a number of factors like the size of your organization and the team’s proximity to customers, some amount of meetings is unavoidable. If we want to start taking some meetings off the calendar, we should focus on what we can control, specifically the meetings that development teams inflict upon themselves. And the vast major of those come from one place:
Agile Methods.
This argument applies to some extent to almost all of Agile, but let’s take a typical Scrum implementation as an example. If you just follow the basic cadence that every single “Agile Coach” will teach you, you’re having the following meetings over every two-week period:
Sprint Planning (Duration: 2 hours)
Daily Standup (Duration: 15 minutes per day, although everyone will tell you that realistically this usually ends up being more like 30 minutes)
Sprint Review (Duration: 1-2 hours)
Sprint Retrospective (Duration: 1 hour)
For a grand total of up to 10 hours just for the basic Scrum ceremonies. Or put another way, software developers on a Scrum team spend up to 12.5% of their time in meetings just off the top, before you add in any meetings with other stakeholders, or compliance, security, and technical training.
This just sounds insanely inefficient and (when you consider how much you’re paying your software developers per hour) insanely expensive. When you consider this alongside what we learn from developer productivity surveys about the impact of meetings
It’s a very straight line to “Agile Methods negatively impacts developer productivity”.
Or maybe not? Let’s give Agile the benefit of the doubt for a minute. Maybe Agile has a positive ROI. Perhaps the productivity loss caused by the various meetings is more than made up for in other ways, such as be increased team communication, cohesion, knowledge sharing, and a better working relationship with product owners.
Once upon a time — say, when Agile got started some 20-odd years ago — this might have been the case. But the world changed, and for the most part, Agile practices have not. Today, the development team is radically online and connected with smartphones and Slack and apps and integrations with real-time notifications and communications for the entire software development toolchain. It’s much less clear in this environment that most Agile meetings are truly necessary anymore (especially daily standup, which is a particularly egregious productivity sink for other reasons that I’ll cover in a future post).
In fact, I’d suggest that in this day and age most Agile meetings (with the possible exception of Sprint Review) serve exactly one person — the Engineering Manager, and certainly there are better ways for them to get the knowledge they need to keep the team unblocked and manage performance. (Google: “Management by walking around”)
I’m going to come back to discuss daily standup in a future post, but in the meantime if you’re a software engineering leader, your homework is to look for ways to keep your software developers out of meetings as much as possible. Some things to consider:
Who is this meeting for?
Can their needs be met some other way? (Yes, we’re talking about the “this meeting could’ve been an email” observation.)
Can we do this asychronously?
Can we have fewer software developers involved in this meeting?
If you’re used to seeing the entire development team in the same room (or Zoom) frequently, cutting back on meetings might seem a little uncomfortable at first, but give it a try and see how much more productive and satisfied your software developers are after a month or two.
