Agile burnout is a common occurrence due to the relentless pressure to deliver, deliver, deliver. Deadlines are constant, and the environment often fails to alleviate this stress. With numerous deadlines, technical debt accumulates, leaving little time for refactoring, testing, or improving the codebase. This leads to unmaintainable code and a decline in quality. The overwhelming number of reports used to manage sprints, coupled with the lack of transparency for developers to view the same metrics, creates a chaotic and inefficient environment.

Scope creep, a frequent occurrence in Agile projects, further complicates matters. It makes it difficult to pivot and prioritize tasks when already working against tight deadlines. Multitasking between development and other priorities adds to the workload. Top-down decisions, without developer input or pushback against the client, often force developers to bend reality to support unrealistic claims from sales, management, and the company’s reputation. Developers frequently find themselves caught in the crossfire of stakeholder disagreements.

Excessive meetings, such as daily stand-ups, planning, backlogs, retrospectives, code reviews, and “scrums of scrums,” can lead to fatigue and diminish productivity. These meetings often deviate from their intended purpose or exceed time constraints. Dropped features can create a sense of unappreciated effort and stress. The bastardization of Agile principles, combined with micromanagement, contributes to this burnout.

Rise of Agile

Over the years, I’ve worked for a variety of companies—large corporations, small businesses, and even start-ups running out of someone’s apartment. Nowadays, I run my own business. I’ve experienced the Waterfall Software Development Lifecycle (SDLC) in both its prime and its limitations, especially when client requests changed frequently. This often impacted earlier phases that were already completed, making the process inefficient.

Then Agile development arrived, shaking things up. It was viewed as fresh and innovative, empowering teams to manage themselves in ways that worked best for them. At its core, Agile allows teams to set their own policies, track their results, and adapt as needed. While there’s more to Agile than that, this is the essence of the methodology.

Agile typically operates on shorter cycles, with teams delivering work and going to production every week, two weeks, or a month, receiving feedback, and starting the cycle again. In contrast, Waterfall often took years before reaching production, at which point the product would shift into maintenance mode.

Freedom of Choice

In Agile methodologies, developers have the freedom to choose the tasks they want to work on. They assign a complexity value to upcoming tasks and use systems to request clarification from stakeholders about task details or push back on unrealistic expectations.

This autonomy in task selection encroached on managers’ responsibilities, causing friction. Managers, who were accountable for product delivery, were often resistant to Agile. However, they soon found a way to reassert control, typically by taking on roles like Scrum Master or Product Owner, allowing them to influence team processes. As Agile gained popularity, managers increasingly sought certifications like ScrumMaster, similar to how they pursued Project Management Professional (PMP) credentials. Many pushed for consultants to bring the rest of the staff into compliance. Certified ScrumMasters often took pride in their qualifications but, in some cases, disregarded Agile’s core principles. Developers seeking certification were sometimes denied, as it would enable them to challenge the ScrumMaster’s practices.

Scrum^ish

Companies frequently adopted a hybrid approach, blending Agile methodologies with their existing processes. This led to terms like “Scrumish” or “Agilish,” where teams lacked real autonomy. In some companies, there were long planning phases and stages, with the only Agile elements being daily stand-ups and sprints. It was also challenging to get clients to regularly use the product or provide feedback when they were accustomed to interacting with software only after release. Developers often saw Agile rituals being added without real process changes. As a result, they left companies that offered “pseudo-Agile” in favor of those that practiced “true” Agile, making it a key selling point for talent.

Implementing only parts of Agile practices can cast Agile in a negative light. At one company, we blended Agile with Waterfall while also using CMMI Level 3 (Capability Maturity Model Integration). CMMI involves extensive documentation, including numerous policies. When I first started, a colleague grinned at me and said, “Lewie, they pay by the pound of paperwork.” The essence of Agile is that policies aren’t set in stone and can be changed at will without authorization. A fundamental principle of Agile is that policies are not meant to be mature or rigid.

What happens when you’re unable to change your policies, can’t make accurate time estimates, and management uses task complexity to predict product delivery? The team often overshoots the deadline and rarely finishes early, only to wait for the next sprint. This gives the impression that your team struggles with meeting deadlines or providing accurate estimates—two core principles of Waterfall.

Daily Stand-Ups / Interrogations

Agile was designed to minimize the distractions of random meetings and the frustration of losing focus, which often took about 45 minutes to regain before you could start coding effectively again. Agile introduced daily stand-ups, where team members were meant to spend no more than two minutes sharing updates on their progress and issues. Any longer discussions were to be taken offline, as the rest of the team didn’t need all the details. However, some people tend to talk too much, and what should be a quick status update often turns into an interrogation.

In one workplace, developers had to justify everything—why they chose certain tasks, how the work got into the sprint, why there was a problem, who was responsible, and provide time estimates. Rarely did I see people actually standing during these meetings, though I believe it’s suggested to keep meetings short, as standing makes people less inclined to drag things out. One thing I noticed was that the start of the workday often shifted with the stand-up. If the stand-up moved from 10 AM to 11 AM, people would start arriving just before 11 AM.

Planning

Before a sprint begins, there is often a planning phase. This is where the developers look at what is in the backlog and decide what they would like to work on next. In practice, Management or a QA manager filling out the role of product owner usually picks these out for the team. The team will sometimes play a game of “sprint poker” where each member has playing cards representing the Fibonacci sequence of numbers, along with a question mark, and a cup of coffee. As each task comes up, everyone lays a card face down and reveals them all at once. If the manager doesn’t like the answer, they get the team to agree to a number. If someone is way off from the rest of the team, interrogation shortly follows.

Metrics

Managers love performance metrics, and Agile initially didn’t provide any. Instead, it offered a way to estimate the complexity of tasks using things like shirt sizes (small, medium, large), animals (ant, dog, panda), or even buckets (empty, half full, overflowing)—whatever worked for the team. These were intended to help teams gauge how much they could accomplish by reflecting on the previous sprint during the retrospective. Most companies adopted the term “Story Points” for these estimates.

Management, however, quickly began translating Story Points into estimated hours, adding their own metrics to account for unexpected issues. They would look at prior sprints and insist that planning wasn’t complete until a certain threshold of tasks had been assigned to the current sprint, making sure it didn’t exceed that threshold. Small tasks, like fixing typos, weren’t recognized for their insignificance, and larger tasks that couldn’t easily be broken down weren’t given the full attention they required. This often led to overloading teams with more work than they were comfortable taking on, and when the sprint ended with unfinished tasks, it hurt morale.

There were also challenges in terms of task variability. Senior developers or those familiar with specific areas of the system could complete tasks more quickly, while new hires or junior developers needed more time. Additionally, managers were hesitant to record Story Points as actual hours in the system, likely to avoid discrepancies when compared with their own time estimates.

Velocity

As Agile became more widespread, managers started relying on different reports, including the velocity chart—often humorously called the “Velociraptor.” This chart tracked the daily burn-down of remaining tasks, but it usually showed a flat line with only a few drops, followed by a sharp decline right before the sprint ended. It didn’t provide much insight into whether the team would meet deadlines. For my teams, this was especially problematic because we had multiple swim lanes, and many tasks required external teams for testing before they could be marked as “done.” As a result, near the end of the sprint, anyone without tasks would step in to handle integration testing—despite it being against policy for developers to test their own code. Sometimes, this led to developers simply rubber-stamping their own work and pushing it through.

KanBan & Swim Lanes

In many Agile environments, you’ll see the use of KanBan or Swim Lanes. In one environment, I saw three large cork boards on the wall with index cards, with each board labeled: To do, Doing, Done. Yarn was sometimes used to separate parts of the board into different areas, and some index cards had color markings for priority. Many various types of online services for managing issues will offer customized swim lanes to filter and visualize this style of issue management. Once a sprint was over, we would move cards to a small index box witch would be considered for future releases to production.

Backlog & Batter-Up!

Certain Agile methodologies feature a backlog from which new tasks can be selected. I’ve seen some that implement a “batting cage” system, allowing tasks to be chosen for the following sprint, with the option to work on them when no other tasks are available. However, we also contend with “scope creep,” where managers attempt to introduce additional tasks that weren’t agreed upon during our sprint planning meetings. Often, these tasks could be postponed until the next sprint, but managers are frequently under pressure to deliver quick results, or the sales team may have made commitments that shouldn’t have been promised without adequate compensation for the team.

The Red Team / DevOps

In some small businesses, the members of the development operations team may also be part of the development team. This responsibility often falls under the Cyber Security umbrella nowadays. In one instance, we implemented a rotating schedule for the next two members who would be on the DevOps team for the week. DevOps was challenging because it required deep research into data and historical code to uncover the root causes of issues and understand the “why” behind them. I worked on systems that handled the distribution of millions of dollars each month, so receiving a client call about calculations being off by a fraction of a decimal was a significant issue. This added an element of unpredictability to sprints, as it was uncertain whether the DevOps members would be available during part or all of the sprint. This was especially critical if they possessed unique domain knowledge for a specific feature that no one else had.

Feature Branches

Before joining a company that genuinely embraced Agile development, I often wondered how developers managed to work on code without impacting others. In my previous experience, someone was always breaking the build, which halted all progress until the issue was resolved. Prior to Agile, I had used source code repositories like SVN, CVS, SourceSafe, and Microsoft Team Foundation Server (TFS). TFS did offer a feature called “Shelves,” but it was seldom utilized and generally discouraged.

After making the transition, I was quickly introduced to Git for source code management and learned about branches that allowed me to work from a specific point in the codebase. It was a game-changer. I could make changes without affecting my teammates or worrying about their work. I could even commit my changes to my own branch, even when I wasn’t connected to the network. It was astonishing. We had a structured process for reviewing features, some of which had been completed years earlier. The manager would come in, sit down with a developer, pull down the branch, and verify that the changes were implemented before approving them for the next push to production. I had never encountered anything like it in my professional career.

Git Problems

Git was the primary repository used in Agile development, and I haven’t encountered any companies practicing Agile that used anything else. However, Git did have its challenges. There were instances when GitHub.com would go down, preventing us from updating our local repositories or pushing changes to the remote repository. This downtime impacted our build servers and other systems that relied on it. Personally, I rarely experienced GitHub outages, but with a whole team of developers using it frequently, any instability became immediately apparent.

Another issue we faced was that our code repository exceeded a gigabyte in size. Not only did this result in long download times, but it also occasionally led to problems that necessitated manual garbage collection to make it manageable. It reminded me of the days with Microsoft Visual SourceSafe, where we often had to rebuild a corrupted database.

Retrospectives

Retrospective meetings, designed to assess progress and identify areas for improvement, are typically held at the end of each sprint. There are only three questions that you need to ask in these meetings: What went well? What didn’t? How can we improve? However, managers often dominate these meetings, focusing on missed deadlines and dismissing requests for changes in software, services, work environments, equipment, and more. Over time, retrospective meetings are often the first to be cut, as management sees little value in them and perceives them as opportunities for developers to engage in blame-shifting or self-pity. Developers may agree, given the lack of action on their requests and the perception that policies won’t change. This contributes to a sense of futility and disengagement.

eXtreme Programming

For many years, I worked in an Extreme Programming environment, a methodology that extends Agile principles. In Extreme Programming, all programming is done in pairs, fostering collaboration and knowledge sharing. Developers sit facing each other at a shared computer station, each with their own keyboard and mouse. While there was flexibility in seating arrangements and daily tasks, some developers naturally gravitated towards preferred seats.

One of the challenges with Extreme Programming is the constant need for interaction with others and the lack of individual pacing. This can be particularly detrimental during personal crises such as divorce, death, medical issues, or family troubles. While the expectation is to leave personal issues outside of work, this environment offers little opportunity for respite.

It’s important to note that Extreme Programming may not be suitable for everyone, especially those who require more individual autonomy or flexibility to address personal challenges.

Fixing the problem

Ultimately, everyone desires a sense of accomplishment without the constant pressure of looming deadlines. One of the challenges lies in defining roles, responsibilities, and the underlying principles that guide Agile practices. Holding individuals accountable who deviate from the spirit of Agile is another issue.

A significant problem is often poor management. Agile needs a refresher, and managers require training to respect individuals. This involves recognizing the value of each team member and fostering a collaborative environment.

People and Well-being:

• Prioritize People Over Processes: Individuals are more important than processes and software.
• Well-being and Morals: Prioritize the well-being and moral values of team members.
• Work-Life Balance: Allow for flexible work arrangements, including remote work and unlimited 7 weeks or more paid time off. (“Unlimited” doesn’t mean unlimited)
• Mental Health Support: Provide access to mental health resources.
• Reasonable Work Hours: Avoid excessive overtime and limit work hours to a reasonable amount.
• Respect Personal Boundaries: Avoid contacting team members outside of business hours, during vacations, or during personal crises.

Team Autonomy and Empowerment:

• Team Decision-Making: Empower teams to make their own decisions and have veto rights.
• Direct Communication: Allow teams to communicate directly with clients, QA teams, and other stakeholders.
• Self-Organization: Enable teams to set their own policies and procedures.
• Continuous Improvement: Encourage teams to identify areas for improvement and implement changes.
• New Team Member Onboarding: Provide clear requirements and expectations for new team members.

Manager’s Role:

• Focus on Well-being: Prioritize team well-being, stress management, and moral support.
• Advocate for the Team: Push back on clients and sales teams to protect the team’s interests.
• Respect Personal Boundaries: Respect the personal boundaries of team members.
• Provide Guidance and Support: Identify areas for improvement and offer recommendations for training or development.
• Acknowledge Achievements: Recognize and appreciate the contributions of team members.
• Be Accessible: Be available to address team concerns and blockers.
• Handle Administrative Tasks: Take care of software licensing, budgets, and hiring processes.
• Facilitate Client Interactions: Engage with clients and involve team members in client interactions.

Client Relationships:

• Push Back on Unreasonable Requests: Advocate for the team and resist unreasonable demands from clients.
• Seek Feedback: Actively seek feedback from clients to improve the product or service.

Software and Metrics:

• Prioritize Working Software: Focus on delivering working software over excessive documentation or metrics.
• Use Metrics as Tools: Utilize code coverage and other metrics as tools for improvement, not as a basis for performance evaluation or estimations.
• Avoid Micromanagement: Avoid using metrics to micromanage or create unnecessary pressure on teams.

By emphasizing these principles and practices, organizations can create a more supportive, productive, and sustainable Agile environment.