The One Introducing The Dooehr

The Dooehr Archetype

Teams thrive on collaboration, shared ownership, and adaptability. Every role in the team is designed to contribute to a smooth, iterative development process where ideas are refined, tested, and improved.

At least, that’s the theory.

But in reality, Agile teams don’t always function like a perfectly synchronized jazz band. Sometimes, you get a lone guitarist shredding at full speed while the rest of the band is still tuning their instruments.

Enter the Dooehr—an archetype you won’t find in playbooks but one that exists in many development teams. These aren’t born, they’re made - typically by overzealous scrum aficionados, known as Scrumtificators.

The Dooehr is the developer who does Dev and nothing else. No testing. No documentation. No stakeholder discussions. No sprint refinements. Just Dev-rah.

Their world consists of code commits and little else. They aren’t interested in the user experience, product goals, or whether their feature plays well with others. They build, push code, and move on. If you ask them about edge cases, they shrug. If you bring up technical debt, they speak in abstractions. If QA is flagged, their response is often a simple, “It worked on my local.”

To them, Agile is just background noise—a constant stream of standups, planning meetings, and ceremonies that distract from what really matters: getting code into the repo as fast as possible.

And while speed might seem like a good thing, the Dooehr’s hyper-focus on coding at all costs creates chaos in teams. Bugs pile up. Features don’t integrate properly. The documentation is nonexistent. And worst of all, the team is left cleaning up after them sprint after sprint.

The Dooehr may be a highly productive individual contributor, but they’re a team liability. And the worst part? Many Agile teams unknowingly reward Dooehrs for their behavior because they conflate “lots of code” with “lots of value.”

But how does one recognize a Dooehr before their code clogs up the pipeline? Let’s break it down.

Defining the Dooehr

If the team process is a well-rehearsed team sport, the Dooehr is the player who refuses to pass the ball, ignores the coach, and only cares about making highlight-reels. They operate in pure developer mode, caring about one thing and one thing only—writing code.

But writing code is just one part of the software development lifecycle. Teams thrive on collaboration, iteration, and shared ownership—all things the Dooehr ignores.

So what exactly makes a Dooehr a Dooehr?

• They write code—and nothing else. No tests, no documentation, no considerations for scalability. If it compiles and runs, it's "done."

• They resist process awkwardly and unreasonably. Standups? A waste of time. Sprint planning? Just assign me tickets. Retrospectives? What’s the point?

• They dance around engaging with the team. Product Owner has a question? "Check the commit." Quality issue? "I’ll provide a quick fix." Another dev needs clarification? "Just read the code."

• They despise anything that interrupts coding. Refactoring? "Later." Collaboration? "No need. I mean sure" Design discussions? "Just let me build it."

To them, software development isn’t a team effort—it’s an individual sport. If the code gets written, they believe they’ve done their job, and everything else is someone else’s problem.

The Dooehr is not necessarily a bad developer—in fact, they often write a lot of code, and it's even good code. But their refusal to engage in the bigger picture of Agile delivery makes them a liability to the team rather than an asset.

Dooehr Characteristics

• The Silent but Smelly

  • Avoids standups, sprint planning, and retrospectives.

  • Communicates minimally—responses are either one-word answers or a GitHub link.

  • Ignores direct messages, PR comments, and stakeholder questions.

  • Example: A teammate asks, "When I click on the button, it behaves funny" The Dooehr Click Click and replies,”OK, it’s fixed" - No further explanation. 

• The Development Process Ghost

  • Does the bare minimum to engage in the values of delivering a product.

  • Contributes to the progress pageantry of backlog refinement, planning, and demos.

  • Sees processes as distractions rather than essential collaboration tools.

  • Example: When asked for feedback in a retrospective, the Dooehr responds, "Nothing from me."

• The "Just Dev-rah" Mentality

  • Writes code but ignores testing, documentation, and maintainability.

  • Pushes untested code and considers their job done after merging.

  • Dismisses technical debt, security concerns, and performance optimizations.

  • Example: Quality degraded with a critical bug, and the Dooehr replies, "worked fine when I wrote it."

Dooehr’s Impact on Teams

The Dooehr isn’t just a personal quirk—it’s a team-wide problem. Their "just Dev-rah" mindset quickly sets in as culture and creates ripple effects that disrupt collaboration, slow delivery, and increase long-term technical debt. While their output may seem high in the short term, the hidden costs to the team and product are significant.

Breaks the Feedback Loop

• Agile depends on continuous collaboration, but the Dooehr resists input.

• Ignoring backlog refinement and sprint planning leads to misaligned expectations—what they build may not match what the team actually needs.

• The pageantry displayed in demos and retrospectives means the team loses critical insights on what’s working and what’s not.

Creates Technical Debt Faster Than Value

• By skipping documentation, testing, and refactoring, the Dooehr turns the codebase into a maintenance nightmare.

• No tests mean future changes carry a high risk of breaking existing functionality.

• Poor code structure leads to slow development cycles as others struggle to modify or extend the Dooehr's work.

Bottlenecks the Development Process

• The Dooehr works in isolation, leading to integration issues when their code doesn’t align with the rest of the system.

• Their lack of participation in discussions means teams must adapt to their work, rather than the other way around.

• When issues arise, they deflect responsibility, leaving others to clean up the mess.

Kills Team Morale and Collaboration

• Agile thrives on shared ownership, but the Dooehr resists teamwork.

• Their dismissive attitude toward testing, documentation, and planning forces others to compensate. Compensation turns into a team flesh eating bacteria. 

• Frustration builds when teammates feel unsupported and have to constantly fix Dooehr-created issues.

The Dooehr might see themselves as efficient, but the time saved in writing code is lost in fixing their mistakes later. Agile practices aren’t about individual productivity—they are about delivering value as a team. The Dooehr’s resistance to anything beyond coding drags the entire team down.

Managing a Dooehr

The Dooehr isn’t a bad developer. Their intent is often to stay productive—they just have a narrow definition of what “productivity” means. The key is to shift their focus from just writing code to delivering value as part of a team. This requires both structural changes in the team’s process and individual coaching to change behaviors.

Make the Invisible Work Visible

• Dooehrs resist documentation, testing, and collaboration because they don’t see their value.

• Use metrics and real examples to show the cost of their behavior. Track:

  • The time spent fixing bugs due to untested code.

  • The delays caused by unclear or undocumented implementations.

  • The number of rework cycles caused by missed discussions.

• Example: If a feature took two days to develop but four days to debug and integrate, highlight the inefficiency caused by skipping better collaboration.

Redefine “Done”

• The Dooehr believes “done” means “I wrote the code”. Change that definition to include:

  • Tests written and passing.

  • Documentation added where necessary.

  • Code reviewed and approved by at least one other team member.

  • The feature deployed and validated in a real environment.

• Example: Require that no pull request can be merged without test coverage. The Dooehr will initially resist, but over time, they’ll see it as just another step.

Encourage Cross-Functional Accountability

• Pair programming or mob reviews force the Dooehr to work with others.

• Testing responsibilities should be shared, not left entirely to some QA function.

• Code ownership should be team-wide, so no single person can avoid accountability.

• Example: If a Dooehr refuses to participate in standups, assign them a role (e.g., “Sprint Demo Lead”) that requires engagement.

Help Them See the Bigger Picture

• Dooehrs often dismiss processes because they don’t understand how their work fits into business goals.

• Connect code to user experience, performance, and customer satisfaction.

• Show how their participation in ceremonies reduces rework and frustration for everyone—including themselves.

• Example: If they ignore retrospectives, frame it as a way to make development easier for them—not just a “meeting.” Ask: “What slows you down? How can we fix that?”

The goal isn’t to force the Dooehr into unnecessary meetings or bureaucracy. It’s to help them realize that collaboration, testing, and planning actually make their job easier in the long run.

From Dooehr to Developer

The Dooehr isn’t a lost cause. In fact, some of the most valuable team members devolve into the little-known Power Ranger role of Dooehrs. Not all is lost, this strong individual contributors just needs a shift in mindset to become a well-rounded, high-impact developers.

The transformation happens when they realize that:

• Agile isn’t about moving fast alone, it’s about moving effectively as a team.

• Writing more code isn’t the goal—delivering working, maintainable software is.

• Good process and planning actually save time by preventing issues later.

With the right coaching, Dooehrs can become exceptional developers—ones who not only write great code but also understand its impact beyond their own screen. The best teams aren’t made of solo stars; they’re built on collaboration, where individuals elevate each other to create something greater than the sum of their parts.

Take Michael Jordan—he joined the Bulls in 1984 but didn’t win a championship until 1991 when the team was complete, with Scottie Pippen’s playmaking and Dennis Rodman’s rebounding locking in their success. Just like in sports, software development isn’t about one person’s brilliance—it’s about assembling a team that works together to build complex, high-impact systems.