I’ve started to catch myself raising my eyebrows whenever someone mentions “Agile” accompanied by an inner voice loudly protesting, “Oh no, not again—Definition of Done, Story Points, Velocity…”
How did I get here?
Since Agile crossed my career path in 2014, I’ve been deeply passionate and interested in it, diving into books, blogs, and videos, finding much of it facinating. In 2015, I earned my Certified Scrum Master badge and embraced a dual role of Team Lead/Scrum Master for my team. We tackled a demanding project—the signalling and monitoring system for four London Underground lines. Despite the project’s four-year delay, I thrived on the collaboration and fun we had.
Agile was indeed fun; using physical whiteboards, gathering around a single keyboard to tackle blocked cards, and conducting intense yet fascinating user trials every quarter.
Our users would simulate operational scenarios for a couple of hours, noting down malfunctions or discomforts, as well as suggesting improvements. The conclusion of these sessions left us with a valuable list of potential fixes and enhancements to focus on before the next trial.
This journey ignited my passion for Agile, this process of building just enough software to solicit feedback, having users test it, then iterating based on their input is the best way to develop software.
However, by the end of 2016, as I relocated from Manchester, UK, to Katowice, Poland, to assume the role of an Agile Project Leader, the nature of my interaction changed. Though I enjoyed working closely with the teams, our direct access to users was diminished as the primary project was managed in the US, with us handling development in Poland, diluting the inspiration I fed on.
Joining Red Hat in 2018 to work full time on Fedora’s Infrastructure marked a pivotal shift. While it was my dream job, it was also my first remote position, which intimidated me due to my fear of exposing my knowledge gaps. Despite being a competent engineer, the prospect of working alongside some of the most brilliant and experienced individuals in the industry made me hesitant to show vulnerability.
Our primary mode of communication was public IRC chats, which only added to my initial discomfort. My focus shifted towards technical growth rather than Agile practice. I observed that Open Source development gravitated more towards individual contribution than team collaboration, leading me to work on new tasks when blocked or awaiting PR reviews, rather than collaborating with teammates to complete started tasks. This approach resulted in a constant busyness, managing a lengthy to-do list of pending PRs and tickets. If my top priority work waited on a colleague’s review, I’d wait a couple of days before following up, knowing well the shared burden of busyness, sacrificing true collaboration for loosely connected tasks.
A couple of years later, going through a career shift into management, I aspired not to become the archetype of a “bad” manager by imposing work methodologies on my team. I believed in the power of self-organization, trusting that engineers are best positioned to determine what works for them. Yet, ironically, we fell into practicing what is known as Zombie Scrum going through the motions of Scrum ceremonies without grasping their underlying purpose. I now reflect on my failure to either help my team abandon this ineffective approach or better understand the true value of Agile, culminating in what I’d describe as Agile fatigue, or more precisely, Scrum fatigue.
So, what now? This blog post marks my first step towards reconnecting with the essence of Agile—the principles that captivated me early in my career. To me, Agile goes beyond Story Points, Velocity, or Definitions of Done. It embodies teamwork, collaboration with our users, and the agility to adapt based on feedback. My goal is to reignite the Fun, Creativity, and Energy that Agile promises.