Ticket-driven development: three modern flavors of the anti-pattern

A recent discussion in the Rands Leadership Slack helped me frame a problematic behavior I’ve repeatedly observed as a manager: ticket-driven development. ^[1] Early in my career, when I worked at large, legacy organizations, ticket-driven development was the norm. While I’ve observed it less and less as agile practices have taken hold, it can still rear its ugly head.

Ticket-driven software development is an approach to development in which

• Ticket creation and work queue (backlog) management is primarily handled by an individual or small group, usually in roles such as engineering manager, product manager, project manager, tech lead, etc.
• Tickets defining work are picked up from a queue (or backlog) and completed by individuals with a limited say in ticket creation and queue management.
  Simply put, there are work creators/planners and work doers.

A few of the reasons ticket-driven development is problematic:

• Delivering real value becomes a secondary objective to completing a ticket. Individuals are incentivized to focus more on what is in front of them (the ticket) rather than the bigger-picture goals of the team, project, etc. Individuals are ill-prepared to notice disconnects between tickets or issues with individual tickets.
• In software development, designs and plans are never perfect. The outcomes of smaller pieces of work (tickets) are critical and necessary inputs to refining the plan and design as you move forward. Again, individuals are less able to participate in continuous refinement plans.
• If a project doesn’t go well, people tend to argue about ticket hygiene, discounting the many other factors impacting software delivery.
  Ticket-driven development directly opposes the idea of a highly engaged and self-directed team invested in continuous improvement.

I’ve come across a few different drivers for ticket-driven development. As an engineering manager, I found that each situation required a different approach to find success.

Seeking safety

In one situation, immediately after joining a new team, I realized the QA engineer was practicing ticket-driven development. Digging deeper, it was apparent the QA engineer was overworked, was dealing with an extremely high incidence of bugs, and was worried about being singled out for allowing poor-quality work to be released. In addition, the other team members spent significant time disagreeing, going down rabbit holes, and dealing with constantly changing priorities. Reverting to ticket-driven development was a safety mechanism for the QA engineer. They could avoid the drama overwhelming the rest of the team and ensure some structure in their QA work. If something went wrong, they could blame a poorly constructed ticket. The QA engineer was locked into their approach, hesitant to change, and adamant that they could get by just grinding through tickets.

Instead of addressing the ticket-driven development behavior, I focused on the upstream challenges within the team. I worked to align the engineers and product manager on priorities and decision-making approaches. Once there was some broader stability across the team, there was space for the QA engineer to engage in helping to define what work the team took on and how. They successfully transitioned to a fully engaged team member, with individual tickets dictating much less of their day-to-day work.

Well-intentioned cross-team efficiency

More recently, I supported two infrastructure engineers, who in turn supported four cross-functional delivery teams. The company's infrastructure was reasonably mature, and the engineers on the delivery teams were highly enabled, so embedding them on the delivery teams didn't make sense. The infrastructure engineers proactively guided other engineers on ideal collaboration and communication to avoid ticket-driven development. They wanted to collaborate directly with the delivery teams, not pull tickets off a queue.

Interestingly, software engineers on delivery teams still defaulted to a ticket-driven approach when working with the infrastructure team. They would create tickets in the infrastructure team’s Jira project and await a response. An oft-repeated mantra in software development is to minimize dependencies between teams, as coordinating work across teams is challenging and perilous. Sometimes, these dependencies are unavoidable, likely due to the organization's structure. Unfortunately, a reaction to mitigating risk and avoiding overhead can be defaulting to a ticket-driven approach. It took consistent effort by the infrastructure engineers and me to change this default behavior.

Individual preference

Over the years, I have worked with a handful of individuals who strongly prefer ticket-driven development within cross-functional teams. Reasons for this preference included:

• Collaboration with a broader team and engagement are perceived as counterproductive overhead, even in the absence of team dysfunction.
• A strong desire to minimize their workload as much as possible in line with their job title. They did their job well and were pleasant to work with, but they were adamant about the narrow scope of their responsibilities. (They wanted to “clock in and clock out.”)

In one case, the individual who preferred ticket-driven development was an engineer who reported to me. The individual was frustrating their teammates, given the outcomes of their work often misaligned with the team’s higher goals. The engineer pushed back against my guidance and feedback from their peers. I coached them out of the organization, understanding they were better suited for an environment that was not team-based.

In another case, an automation engineer was a member of the team I supported but reported to a different manager. My attempts to move the automation engineer beyond ticket-driven development were unsuccessful. In hindsight, I assumed more alignment with the QA engineer’s manager than existed. Although we agreed on the goal of highly collaborative, highly engaged, cross-functional teams, the other manager and I had different perceptions of how that ideally manifested. That manager saw the role of test automation as a “follow-up” activity to product development. I incorrectly and unproductively attempted to address individual behavior instead of focusing on the bigger context and aligning with the manager

There are cases where ticket-driven execution of work is appropriate. A customer support organization is one example. The danger is when this model is applied to an environment built on engaged, self-directed, cross-functional teams. Ticket-driven development is assembly-line development or, worse, Taylorism in action. Whether due to broader team dysfunction, well-intentioned attempts at cross-team efficiency, or personal preference, addressing the root cause of ticket-driven development is critical to mitigating it.

Feedback is welcome via Bluesky: @computersandpeople.com.