The Ticket Is Not The Work

When I said tickets have almost nothing to do with agile software development, I was greeted with some very odd looks and incredulous "huh?" sounds.  

So...

Agile and stories

In the beginning, the processes that were to eventually become agile were focused on delivering early and often, getting frequent feedback, and applying what they learned to the codebase so that they can continue developing early and often.

To do this sustainably, it was necessary to use taste, judgment, and good craft so that the code remains ready to take on new knowledge and new functionality. To support that, XP chose to always work in groups (pairs, generally) and to have lot of tests to support refactoring, and lots of refactoring.

So how does one keep track of what needs to be done - what customers have asked for? For this we had user stories (likely no relation to what you've seen called 'user stories'). The user stories were typically written on a sticky note or a card, since teams were colocated at the time.

The card was a nice thing; it could be scribbled on, drawn on, flipped over, marked with colored stickies, whatever decorations you needed to denote the state of the work. This was helpful. Some of my teams used to clip their names or photos the the card they were working on together. 

When Cards Become Tickets

Then came the Industrial Complex -- the selling of certificates and tools became too important, as the real money was to be had in selling things, not in simply making better software and better decisions. 

And then came 'tickets' and 'ticket trackers' rebranded as "agile tools". The 'ticket' was nothing like the card. It wasn't just a quick description and decorations; it was a relational database table. Only it didn't have the ability to flip over, colour, clip things, and customise as needed. The ticket has a fixed set of fields, and (frustratingly) only one person could be associated with a ticket—not the team, not a pair, not a mini-mob of three or four, ONE person.

These "agile lifecycle tools" were successfully sold, and over the industry a lot of people decided that "agile" was about tickets -- filling them out, enriching them, adding details, adding test criteria, detailing the design, estimating them, assigning them each to exactly one individual, and tracking ticket closure rate. 

When this happened, the idea of teams working together to deliver early and often was eclipsed. Teams were individuals serving the ticket system (basically a "call centre" operation), and actually delivering code or receiving feedback disappeared behind the serious-seeming ticket backlog and ticket refinement work. 

... With Disastrous Effects

Soon this focus on tickets grew into a laser focus on solo work and utilisation, in contrast to the principles every agile method supported from the start. 

With solo developers working tickets alone, each ticket needed to be a stand-alone specification that any developer could pick up and implement without interacting with other team members. Teamwork died in the ticket system. 

The lightweight process of teams working together to define and deliver new work was replaced by a process of writing detailed specs and contracts for development, and ensuring that each individual had full utilisation (in sharp contrast to all we know about Kingman's Formula, process flow, and teamwork).

In other words, it resurrected waterfall processes, big design up front, and sticking with a plan over learning and discovering better products.

The original version of agile famously produced deployments of code early and often, which is a highly desirable way of working. Sadly, the solo ticket-based development system did not. Since "high performance teams" was an original goal of agile development, implementers of this system became frustrated. The ticket-driven way simply did not deliver on the promise of agility.

The "obvious answer" for managers was to track "velocity" and create pressure to drive it upward - produce more tickets, close more tickets, and generally make the graph go up and to the right. 

The Losses

Whereas teamwork and craft were the engine powering agile methods, this corporate 'dark scrum' removed those elements. In fact, the standard way that teams tried to meet the demand for velocity was to do the maximum amount of work in parallel, and defer or avoid "wasting time" on tests and refactoring. The push for velocity even eliminated the use of feedback to revise plans and product concepts.

Teams are expected to do nothing but burn down the backlog at full speed.  This has nothing to do with agile-as-intended, and is in fact the antithesis of agility. But here we are, and that's the process to which they attach the name 'agile' and also the term 'scrum.' 

To developers who have entered 'agile software development' in the past 20 years,  this is all it is, and all it ever was. It was the original intent, and it is a total sham since it does not lead to superior performance.

And, if this were it, they would be right.

The fact is that the tickets are not the work. They never were. In fact, tickets have almost nothing to do with agile software development. 

A Chance For Renaissance

Properly understood, the goal is still to deliver code early and often so you can collect feedback and improve your product concept, and to maintain a highly maintainable codebase so you can keep doing so. 

The point of working in groups isn't "because it's nice" or "because we like it" -- it's because one person's judgment is subject to personal preferences and blind spots, and that inconsistency and risk of failure require handoffs and reviews. That's all terrible for flow. If we could produce code at the desk that has already passed all the tests and reviews and also implements entire features (not just backend or just frontend or just data or service), then we can deliver early and often again. 

If we could get our eyes off of tickets, ticket grooming, and ticket closure, then maybe we could focus on deliveries and feedback and code craft again.

The Agentic Age

After all, there are dozens of boring articles being dumped into social media about how "agile is dead because of AI" -- but realise they're not talking about original agile. They're talking about the ticket culture. I hope they're right. 

This is our chance to drop the ticket culture and return to developing releases instead of "percentage of backlog completed by ticket count." 

A few people augmented by a competent agent to research and, review intentions, vet ideas against the shape of the code, support coding and testing... well, it makes all of the things we did in XP suddenly affordable.  

Not sure how to implement the next feature? Have agents research libraries, techniques, tools, and approaches. Have it give 5 or 10 suggestions. Have it research the current codebase(s) and see which fit the prevailing design and pattern. It can be enlightening.

You don't have tests? Have agents produce test scaffolding, which you can improve into "proper" unit tests later. If you have the right agentic skills, it can create testing seams as it works, leaving your code more testable and readable.

You don't like writing new tests? Okay, critique the agent's tests. Have it write them; you give corrections and suggestions so that the tests fit your sense of clarity and usefulness.

Refactoring seems like more faff than you want? Fine, have the agent make the changes for you. Tell it what you don't like about the code, have it make suggestions, argue, and then have the changes made (now you have tests, so they should all still pass before and after).

You only know the backend language? Grab a friend or colleague who knows the frontend and have agents modify both 'ends' as you work through the practical issues.

You don't "dig" writing for readability? Get some competent code tools, and have the agents suggest ways of producing more well-modularised code, better names for classes and functions, and maybe better data structures and algorithms.

The parts of "agile" that you didn't want, or were never offered, are cheaper than ever and less scary to try. Try to get your head out of the pile of tickets and focus on delivering code today, getting feedback, and bringing what you learn back to the codebase within a day or two.

But the key here is that the tickets are the wrong focus. When companies took their eyes off delivery and feedback, they lost the plot. You can use this time to bring back actual high performance.

If you want to know more about how, watch this space and also go see what the Continuous Delivery people are saying. They've got their fingers on the pulse of delivering early and often with high quality. Maybe follow up by reading Emily Bache and David Farley. And, while you're at it, read up on the original agilists, who I happen to know are all as sad about the current "dark agile" world as I am.