I have been working on Agile Scrum teams for many years. I am also a certified Certified ScrumMaster® with the Scrum Alliance. I’ve seen some good — and bad — agile environments, but mostly bad. When agile goes wrong, it goes really wrong — the kind of wrong that burns out engineers or sends them looking for another employer or another career.

When agile goes right… it both empowers engineers to decide how much work can be achieved in a single sprint and protects them from management dictating unhealthy amounts of work. Most importantly a scrum master (team coach) can clearly layout in a dispassionate way to stake-holders and product owners what can not be done without negative consequences, to both the current application and the overall organization, if their advice is ignored.

I’m constantly arguing with friends about the value of agile. One in particular always says that it’s a waste of time and effort… and only used by people who don’t understand software engineering. I’ve tried to tell them that they have only seen agile poorly implemented, but it’s an uphill battle. Here are a few of what I think to be the most common mistakes made by enterprises who attempt to adopt agile practices:

Application team scrum master utilization.

No scrum master. There is a 100% chance agile will fail for your enterprise.

Part time scrum master. If your scrum master is assigned to multiple projects, then they can’t focus on any one… which means all will suffer. If the scrum master has a bunch of sprint planning meetings all on the same day… developers are sitting around waiting for the sprint to start… and even worse — that time is often still counted within the sprint period.

Dual-hat project manager. This is probably the single worst thing I have seen. If your scrum master signs your timesheet, approves your leave, and/or approves expense reports — then you don’t have a scrum master, you have a project manager. Every interaction with the scrum master is now an interaction with your boss. A scrum master is a master of ceremonies… and a coach on proper agile implementation, not a manager. When your scrum master is your project manager (PM), guess what happens when your product owner or stake holder’s ask for additional features (aka scope creep) to be added to a product backlog item (PBI)… or a completely new PBI added after the sprint starts? Yes, your project manager is going to say “of course we can!” and then force the team to just work extra hours.

hours. Dual-hat product owner. This is similar to the dual-hat project manager. However this time there is no one to push back on that scope creep or PBI added at the last second to the sprint. Since there is no one to say whether this activity is good or bad… the product owner just says “do it”. They get a promotion basically by stepping on their engineers.

Dual-hat developer. If the developer is the scrum master, how can they properly coach the product owner or stake holders? How can they both effectively address blockers with external teams and build the product?

The Project Manager, Product Owner or Scrum Master decides how much will be accomplished during the sprint.

This is anti-agile. Remember, agile is not project management. Managers, who are often neither software engineers nor qualified to determine the complexity of any given task, should not be empowered to dictate how much work is done in a sprint. If they are allowed to decide how much work will be done in the sprint… welcome to scrum-fall. There is an extremely good chance that the management burns through their developers like it’s going out of style.

This is so egregious that you should immediately consider the impact on your health and sanity. This organization will 🔥 burn 🔥 you out. Probably in less than a year. I’ve seen this cause good software engineers to retire or change careers.

No product backlog review.

Product backlog items (PBIs) consist of feature requests, requirements, bugs and team generated refactoring ideas. They should be constantly reviewed and estimates assigned during regular grooming sessions. When does your team review them, and what does that say about agile in your organization?

During a sprint planning session. Your planning sessions most likely take more than 4 hours… which is greater than the agile prescribed max length for a two-week sprint planning session.

During a sprint planning, and attended by your PM/manager. First of all, your manager or PM shouldn’t be anywhere near a self-organizing agile team. I’ve seen a manager tell team members during sprint planning that there is no time to discuss a product backlog item (PBI) to accurately evaluate a story and assign it points because it’s a waste of everyone’s time — which is, of course, the opposite of agile. If you are not allowed to estimate a product backlog item (PBI)… and are required to give an immediate , knee-jerk, no-idea, random guess… how agile is your organization?

that there is no time to discuss a product backlog item (PBI) to accurately evaluate a story and assign it points because it’s a waste of everyone’s time — which is, of course, the opposite of agile. If you are not allowed to estimate a product backlog item (PBI)… and are required to give an , knee-jerk, no-idea, random guess… how agile is your organization? During regular weekly Product Backlog Reviews (PBRs). This is how it should be done. The whole team is required to triage all incoming product backlog item (PBIs), but not all at once. Make it a rotating affair, with an odd number of engineers. Their task is to review, clean up, categorize (assign labels to tell the team / product owner (PO) that the issue has been reviewed) and assign a rough story point estimate, if possible.

Changes to the sprint, during the sprint.

This is anti-agile, yet happens all the time. Every organization that I’ve worked for claimed that it had to be done because executive manager X or stakeholder Y absolutely had to have this bug fixed immediately or this feature built immediately. How could they say no? This manager / organization have neither accepted nor are agile and you are not going to be able to convince this scrum-fall organization to see the value of agile.

Sometimes work is pulled off the sprint to support it, sometimes everyone is required to work longer hours… and in some cases just the senior developer is required to work extra hours — all for free.

At best your management views agile as a way to force developers to work unhealthy amounts of hours. They probably treat developers as nothing more than a resource to be consumed. Like electricity, they will consume you… and when you are burned out, they will simply request that their staffing agency send them another developer. This often leads to other unhealthy work situations like longer then normal work hours (40+/week) with no overtime pay, little to no sick, little to no leave (< 3 weeks/yr.), and/or less than normal holidays (10+).

Using story points as a metric of comparison.

Story points are meant to be used within the team as a gauge of the complexity of a product backlog item (PBI) for that team. Every developer and every team will assign the exact same task with wildly different story points based on understanding of existing code, known scenarios and/or experience. Welcome to scrum-fall.

When story points are used as a metric to compare teams one of two things will happen:

Inexperienced teams (e.g. predominantly inexperienced with the area of code or technology) will inflate their story points so management will think they are getting more done or to allow themselves more time to accomplish the tasks, aka story point padding (bloat).

Experienced teams (e.g. predominantly experienced with the area of code or technology) will be penalized and required to work even longer hours (often for free) to accomplish as many story-points as the junior-heavy team… all while wondering why they are being penalized for having a lower story point count… which leads to story point padding (bloat).

Using total task hours as a metric for comparison.

Task hours are meant as a guide for the team only. They should not be matched to hours worked. They should not be compared to any other team to show who is working harder or is more productive. They are intended to help determine the likelihood of sprint success by providing the data necessary to build a sprint burndown chart. The burndown chart in turn is used help identify blockers for the team. Again, they do not represent worked hours and should not be compared between teams.

Senior developers often have a lot of code-adjacent tasks that they struggle to accomplish on these teams: code reviews, architecture reviews, mentoring and helping other team members. Why? Because these tasks are often not on the board… and therefore management assumes they are not working, or attempting to bill extra hours.

When task hours are used as a metric to compare developers… or teams, this will inevitably lead to one of two results:

Task hour inflation. That 2-hour task is now estimated as a 4-hour task. See I’m working harder! Burn out. Senior developers don’t have any time for those code-adjacent tasks which leads to lower quality and longer hours for everyone. Some senior developers will push themselves to accomplish these tasks outside of their reported hours… leading to 50+ hour weeks and ultimately, burnout.

No code reviews or pair programming.

If code reviews (another developer reviews your code for clarity and consistency with the accepted team standards) are non-existent… then how good is their code? I’m willing to bet it’s not very maintainable and/or they have no code standards… which leads to increased maintenance and development times even for the simplest of code.

If pair programming (the act of multiple developers talking through and building a single PBI) is not common then getting help from other developers will probably not be possible. If you are a junior to mid-level developer in this environment then for your career growth you should find an organization that insists on pair programming. I can’t stress enough how much you are not learning by doing it alone. I know because most of my career has been as the only developer on a team or a developer on a team that hates pair programming.

I have underestimated the value of code reviews and pair programming in my career. Don’t be like me — find the company that both cares about you and the quality of their product.

No Sprint review.

The sprint review is where the team shows off their work and the stakeholders accept the delivery. When this doesn’t happen, stakeholders have no visibility into a team’s output or no one truly cares about the delivered product.

If stakeholders don’t accept the delivery… then any problems or misunderstood requirements will be compounded by the next sprint review or release.

No Sprint retrospectives.

I don’t know how many times I’ve had to fight to get a retrospective… only to have them be completely worthless because the project manager and/or product owner are in the room. Developer’s are employees. If your manager is in the room how can you speak freely? Whatever is broken will remain broken and you have no way to address it.

If you are an engineer and any of the above is true and there is no way to fix it — don’t waste your career with this organization. They haven’t accepted agile. It’s time to consider your own health and sanity.