Scrum Confessions: Real Devs Spill Their Agile Pet Peeves
Source: Canva
By now, you’ve probably seen any one of the many Me at Work versus Me After 6 pm memes. They’re popular because, let’s face it, most people are not their full unfiltered selves at work.
As a result, you may not get an complete view of how people feel about their jobs in employee surveys, yearly 1:1s, or even exit interviews. And if an organization’s leaders don’t have this information, they probably can’t take steps to improve things in a meaningful and impactful way.
If you want a truly unfiltered glimpse into the most popular complaints about certain jobs, your best bet is to check Reddit, comment strings on articles, or message boards in industry-focused sites. In the case of developers and coders on agile teams, sites like softwareengineering.stackexchange.com are virtual troves of helpful advice, coupled with unfiltered rants about the day-to-day struggles of hardworking devs in every sector.
This blog will seek to shine a flashlight on some of the less talked about barriers that hard-working people in the agile sector face. We’d like to help scrum masters to look beyond the higher-level complaints like “daily meetings are too long” or “retrospectives are unproductive” to unearth the more specific (and possibly hidden) core reasons that devs may feel that way. If you know the most popular issues that people are reticent to say, you can still mitigate these problems without your team having to voice them.
The Truth About Daily Scrum Meetings
It’s no secret that a lot of devs could do without daily scrum meetings. The common complaint is that they’re unnecessary, intrusive, and generally take you away from the “real work.”
However, a user going by the handle Asclepius raised an excellent point in a post at softwareengineering.stackexchange.com. He stated that:
“ Daily scrum puts too much stress on a developer to produce something daily. They need freedom to experiment freely without having to justify their experiments to anyone on a daily basis. Weekly is better.”
This is an incredibly concise summary of a frustration that thousands of devs share.
The ability and freedom to try new things and experiment are at the core of innovation and creative problem-solving. Without it, companies would be doomed to produce nothing but “the same, only slightly different.” So, in this respect, we could see why someone would feel like daily scrums indirectly get in the way of innovation.
If you’re going off script to dive into a problem or experiment with something, you may not be keen to report, “I’m still working on ___, which is not technically related to the sprint per se, but ___.”
However, if you only had to check in once a week, you could conceivably report, “Last week, I worked on ___ and I ____. And this can help us ___ in the future.” Now you’re a hero, instead of the person reporting the same off-scope task for 3 straight days.
Key Takeaway: If you’re going to continue doing daily scrums, make sure team members know you encourage them to experiment and try new things, even if that means it will be a day or two. Or more. Their expertise and imagination are the assets that will drive innovation.
The Truth About SAFe
SAFe has quickly become one of the go-to models for enterprise-sized teams because of its ability to scale agile and coordinate large projects with many cross-functional teams.
However, popularity comes with criticism. While there are countless articles on Medium and LinkedIn espousing the virtues of SAFe, a lot of devs would disagree. In fact, some hate SAFe and don’t mind telling you why.
One particularly pithy string on Reddit contains quotes like, “SAFe is a training and certification racket.” Or, “Inside your 100 person project is a 10 person project trying to get out.”
Another user reminds us that, “Martin Fowler, one of the authors of the manifesto for agile software development called SaFE, “$&|tty agile for enterprise.”
However, one user asked a very insightful question in response to another’s struggles with SAFe. They offered, “I'm really just wondering if your company is practicing SAFe to ‘keep up with the Joneses’ instead of having a need to align teams around a common vision. Are your seven teams working on a common product? If not, maybe SAFe is not for you.”
SAFe is not for every team. And if it’s not right, it can do more harm than good. A company switching to SAFe to “keep up with the Joneses,” is ill-advised, but not inconceivable. If a company finds itself outpaced by a competitor that’s doing SAFe, the switch could be made without considering bigger questions about whether it’s the right fit.
Key Takeaway: Whenever possible, involve your team in the discussion to make a major decision like moving to SAFe. They should always feel that their voices have been heard, even if the outcome isn’t exactly what they wanted.
The Truth About Retrospectives
Image Source: Unsplash
LinkedIn and Medium are full of countless ways to make your agile team’s retrospectives more fun. But before you consider setting up fun retrospective games, you might want to read the (virtual) room, so to speak.
There are a significant number of devs who feel retrospectives don’t need to be fun, and some feel that retros should never be fun.
In one Reddit post, a young scrum master was seeking advice, writing “Getting the team to have fun during retrospectives is hard, it’s like they’re just answering my questions like another meeting.”
While she received a number of helpful links and book suggestions, other people offered sentiments like, "fancy templates and other ‘forced fun’ activities tend to be awkward and cringey.”
Another user chimed in with, “Why does the retro have to be 'fun'? Personally nothing makes me more anxious than this idea that seems to have become so commonplace.”
Another user simply stated that, “Retros don’t need to be fun.” They added, “Have the team provide feedback on what they want, not what you want. You gotta meet them where they are first before you start throwing ‘mandatory fun’ at them.”
The concept of fundatory meetings is certainly not limited to retrospectives or the agile world. While often intended to boost morale and foster team-building opportunities, you run the risk of achieving the opposite.
If your retros are missing the mark, have a retro on your retro. Ask your team what they want from the experience. What’s missing right now? Would they prefer a more traditional template?
Key Takeaway: Seek out specific feedback and find out what is ruining your retros. As we explored above “Our retros are boring” doesn’t necessarily mean “Our retros need to be more fun.” A team member might find the retros boring because they find them unfocused or unproductive, which leads them to tune out.
Agile retrospectives are often hurt by several hidden problems that have nothing to do with fun.
Want to know what they are and how AI can actually help you prevent them? Download our free ebook, “Uncovering Blind Spots in Agile Retrospectives: Advancing Retrospectives with AI.”
