Frustrations with Agile: A Developer's Perspective on Inefficiencies
Written on
Chapter 1 The Agile Dilemma
Many developers express a strong dislike for Agile methodologies. Recently, I've begun to suspect that my company employs Agile strategies solely to frustrate developers, as the reasoning behind their peculiar approaches remains elusive.
The Situation
In our organization, it appears that each team member is committed to hindering progress. Instead of delivering on commitments, we often find ourselves stalling, frequently citing that we are "waiting" for a meeting rather than taking initiative. One of the tactics to avoid delivery is to participate in numerous meetings, which distracts us from addressing the actual problems at hand.
Consequently, our tasks tend to extend across multiple sprints. Since the workload is consistently spread thin, attempts to improve teamwork have been initiated. Here’s a summary of our experiences.
Section 1.1 Estimation Woes
To facilitate our workflow, we utilize story points for estimation instead of time, which ideally should ease the burden on developers. However, in our quest to prevent tasks from spilling over into future sprints, we not only estimate using story points but are also expected to provide a time estimate in every status meeting.
This results in a frustrating duplication of effort in estimation, leading to increased frustration among team members.
Subsection 1.1.1 Defect Meetings
Our working methods inadvertently encourage defects (or "dephucks," as humorously referred to by our offshore team). We do not test the mobile front end independently of the backend, which means identifying the source of a bug necessitates a thorough examination of the entire system. Consequently, when defects arise, a meeting is scheduled for the following day—or perhaps the day after, depending on everyone’s availability.
This meeting typically requires the following personnel:
- BE mobile
- FE mobile (2 members)
- Testers (2 members)
- BE
- Business owner
At times, the issue can be as trivial as a single string modification made during the sprint that leads to incorrect display on mobile devices.
Effect: 2–3 hours wasted in meetings per defect.
Section 1.2 The Retro Meeting Conundrum
At the conclusion of each sprint, we hold a retrospective meeting to discuss potential improvements as a team. Or at least, that’s the intention.
In reality, while we do have these meetings, they are frequently rescheduled or canceled in favor of more pressing matters. In fact, we went without a retrospective for three sprints, totaling six weeks.
Effect: No improvements made, despite the time saved from these canceled meetings.
Chapter 2 Conclusion
Feel free to take these insights and apply them to your own organization. You too can obstruct feature delivery and throw sand into the gears of progress—wouldn't that be fantastic?
About The Author
The author, a professional software developer known as “The Secret Developer,” shares insights on Twitter @TheSDeveloper and regularly writes articles for Medium.com.
Read every story from The Secret Developer (and thousands of other writers on Medium). Your membership fee directly supports their work.