I was a professional software developer for 15 years (before getting into digital marketing). And nearly all of my agile software teams failed to implement an effective scrum.
First, agile development is a big step up from waterfall. Going long periods where all of the stakeholders aren’t checking in on how development is going is a recipe for disaster.
Scrums eliminate that catastrophic problem by having a daily meeting. But, despite being an improvement, I’ve primarily been watching them fail for the following reasons.
1) Scrums are Being Used as an Accountability Tool, Not a Knowledge Transfer Tool
Scrums fail because people lose sight of the primary purpose of this meeting. Knowledge transfer is why you have scrum calls!
You’re asking what people did yesterday, what they’ll do today, and if they have any blockers, because it prompts discussions that the group can learn from. And you can help get stuck individuals moving again.
Too often, management takes over these meetings, and that point gets lost. An excellent way to tell if your scrum is broken is to ask yourself, “When was the last time I learned something valuable in one of these meetings.” If the answer isn’t “nearly every day,” your scrum is broken.
2) Scrums Were Supposed to Eliminate Other Pointless Meetings
Even if your Scrum has become an accountability tool for management, at least it eliminated all the other pointless meetings you were having. Oh wait, did it?
How many of you have entered a scrum, and by the time you left it, you were signed up for two or maybe even 3 additional meetings?
If this is happening, your scrum is broken. The point of organizing things via a board and a tiny daily meeting was to eliminate meetings. If you’re not finding ways to reduce the amount of meetings you’re having, your scrum has failed.
3) Scrums Were Supposed To Have The Major Stakeholders Involved
I’ve been on so many Scrum teams where a vital member opted out almost every day (good for them!).
In my experience, big-time managers or clients never show up to the scrums. Which would be good because the point is knowledge transfer and not accountability. Except that half the time, they put a scrub middle-manager with limited technical knowledge in charge of the meeting.
Now we’re missing all the people who make all of the decisions, and we’re not learning anything on top of it. Great job management.
4) Scrums Were ONLY Supposed To Have The Major Stakeholders Involved
On one of my projects, I was on a scrum call with 25 people. Imagine having 25 people for a 15-minute call (36 seconds per person).
How much knowledge transfer do you think was going on when each member has precisely 36 seconds to talk? Worse, do you think any member of this team cares what 24 other people are doing today?
Scrum calls can and do get too big. If you have a team of over 10 people on a scrum call, it’s time to think about breaking things up a little bit. Do you really need the entire requirements team, test team, development team, and middle-managers on this call? Couldn’t each group do a call and then a representative of each group do another?
5) Daily Stressors are Bad for Employee Morale
A daily meeting in which you tell your boss how productive you were yesterday in front of all your peers… That’s a mildly stressful event that you repeat every day. Particularly if you’re not as talented as the rest of the group or had a bad day, week, or month (it happens).
I personally believe employee morale is more important than actually getting anything done. I’d much rather have a slightly less productive group where everybody feels happy.
If you’re weaponizing the scrum as a way to shame the unproductives (instead of using the time for knowledge transfer), please stop!
6) Smooth-Talking Bullshit Artists Go Waterfall
Every now and again, you’ll come across a developer that never gets anything done despite claiming the opposite on your daily calls.
You need a scrum-leader that’s talented enough to recognize that the bullshit artist is stuck even though he’ll never admit to it. If you have middle-management leading the call, you’re going to see this happen multiple times throughout your career.
The end result is that you’re back to waterfall. Nobody will notice there’s a significant problem until the date the software is actually due. This is the exact thing that agile was trying to prevent!
7) Management Shouldn’t Be Leading The Call
If you haven’t figured it out by now, I’m not a big fan of middle-management in general.
But, no form of management should really be leading these calls. Not unless they have the technical expertise to turn the call into an informed discussion. Because an informed discussion was the point of the call.
8) The Team Shouldn’t Hate The Scrum-Master
One time I was on a team with a smart young man who was leading our scrum calls. He had enough technical expertise to lead a call, but also zero interpersonal skills whatsoever. We all despised him.
This person can’t lead your scrum call. It doesn’t matter how smart you are if everybody hates your guts. You need a good dialogue in these calls for them to be productive. You’re not going to get that if everyone on the call thinks the scrum-master is the worst.
9) The Scrum Board (And All Other Agile Methodologies) Are a Complete Disaster
I’ve been on teams where nobody kept the tickets with the proper status ever. You can’t have this. An agile team needs fewer meetings because it systematized tasks (like who’s working on what).
If you simply stop doing all of the systematized tasks, now you need big meetings again or else those tasks will go undone.
Your agile team needs a lead that can keep all of these vital tasks on track and make sure they’re getting done. Agile doesn’t work without that.
10) The Scrum Board Shouldn’t Be the Main Discussion of The Scrum Call
Sometimes agile teams use scrum calls to manage the board rather than for knowledge transfer. In particular, my calls with 20+ people, were used to give ticket status’s (and nothing else).
Even though managing the board is essential, the scrum call is not the place to be doing it. The scrum call is for knowledge transfer. To get teammates unstuck. If you only talk about bureaucratic non-sense then knowledge transfer isn’t happening.
11) Timezone Fails
Have you ever been on an 8AM call with your teammate on the west coast, or in Hawaii?
For this person, it’s a 5am call (or worse). That’s just cruel. How much knowledge do you think you could transfer between yourself and others at 5 o’clock in the morning?
Being agile means you adapt to an ever-changing world. If you can’t handle a simple tweak to the time you hold your daily meeting, you really need to look in the mirror and ask how agile you really are.
12) Scrums Shouldn’t Repeatedly Go Over 15 Minutes
I’ve also been on teams where the scrums could easily last 30 minutes or an hour if we got to talking. While going over time a little bit usually isn’t THAT big a deal, if you’re constantly going dramatically over time, it’s a sign something is wrong.
The point of scrums was to reduce the amount of time spent in meetings. It’s draining for your staff!
And that’s it! Twelve reasons why more often than not, scrum calls have failed throughout my 15-year professional career as a software engineer. If you’re in a position of power and are reading this, I beg you to try and fix these issues before you burn out your engineers.
Because I’m a full-time blogger now…