Untangling Agile Development Misconceptions

Last Sunday, TechCrunch published “Death to JIRA,” an article that pinned the challenges of software development on one of the most powerful tools in the market. Author John Evans pointlessly misrepresented agile development to make a case for better communication in software projects. I’d like to untangle several points about agile development the author missed.

Essentially, JIRA fell into the crosshairs because it’s such a popular agile tool—the same way Kleenex would be at the center of a takedown on tissues. Ticketing is problematic, in Evans’ experience, because teams use it to define their project requirements. His solution is “good prose.” Specifically, Evans states that “…a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets.” Evans doesn’t explain what to put in the eight-page doc (besides “Words in a row”). And he says you should automatically parse that document into smaller elements or, if you must, tickets (a.k.a. “issues” or “stories”).

According to Evans, “JIRA’s design is fundamentally antithetical to good software development, if it is used for anything more than simple bug tracking.” But, as Evans later acknowledges, “JIRA’s great sin is only that of being the most successful and widespread ticketing system. The notion of specifying a software project with a set of tickets is itself the enemy.”

In other words, the piece is really a diatribe against development teams that fail to write out their project requirements. But “Why You Should Write 8 Pages to Define Your Software Project” isn’t as catchy a headline as “Death to JIRA.”

Here’s the thing: agile development ticketing systems are not designed to capture the nuances of a complicated system. Cprime has implemented JIRA at more than 500 companies of all sizes. We train our clients on the importance of documenting project requirements. “Death to JIRA” overlooks multiple Atlassian product on the markets (such as Google Docs and Atlassian’s own including Confluence, released in 2004) designed to address this exact issue. Agile developers use them in tandem with tools like JIRA.

Document collaboration tools are meant to capture product requirements, a roadmap, release dates, and other info that would appear in the eight-pager. Developers use these tools to translate requirements into epics, sub-stories, and releases inside agile development tools. In our experience, clients have success using products like JIRA as a platform for planning purposes, mapping out dependencies and building a roadmap and release plan. The ticketing system merely translates requirements into a set of coherent, assignable tasks.

So, Evans wants readers to believe that JIRA (i.e. the agile approach) is “antithetical to good software development” because companies can misuse such platforms. If you tried to cut down a Christmas trees with a sledgehammer and failed, you could write an article titled “Death to Sledgehammers” with the same logic. When you misuse a tool and fail, it’s tempting to blame the tool.

When DevOps teams use modern development software they can do everything that Evans claims you can’t do. They can capture the complex relationships among stories (tickets). They can work on Subsystem A, Subsystem B, and Interface AB iteratively because developers have independent, automated, cloud based testing environments. They don’t feel psychologically pressured to work stories one at a time. In fact, many teams intentionally keep stories open and only close them at the end of a sprint. And no, stories do not hijack software architecture – the requirements set forth in your requirements document shape the architecture, which, in turn, shapes the stories.

Now, let’s consider Evans’ eight-page document: how does that evolve with a dynamic, iterative project without confusing everyone? Most software is not built in isolation by a single individual. It is built by teams or often many teams. The eight-page document can’t scale as a software team grows from five to 50, 50 to 100, 100 to 500 and 500 to 5000 employees. Atlassian Confluence, on the other hand, adapts as team members complete tasks and share updates. Changes in Confluence change the stories. Once you’ve parsed the eight-pager into
assignments, as Evans suggests, backtracking would be messy. Fine, you could throw the eight-pager into a cloud document and let your collaborators modify it. But if you’ve experienced the pain of collaboratively editing a cloud doc with five people, you understand why sharing it with 2,000 developers would be a total cluster-jam.

“Death to JIRA” is just an ode to waterfall development rehashed in the name of good prose. At scale, waterfall’s hyper centralization undermines the iterative process Evans claims to value. Agile development, DevOps, and platforms like JIRA are reactions to waterfall. They’ve helped developers improve speed, productivity, quality assurances, uptime, and other markers of good software development. I would note that Evans’ own employer seeks JIRA skills in its job listings, as do a laundry list of companies building groundbreaking software.

A ticketing system does not communicate system requirements; it just translates them into tasks. Let’s be under no illusions though: JIRA is complex software. Like Salesforce, NetSuite, and any other powerful products, JIRA has to be configured properly.

“Death to JIRA” is not a sound attack on agile, but rather a call for better communication in software development. I can get behind that, but there was no reason to misrepresent agile development while making that point.