The Atlassian JIRA started life as a bug tracking tool. However, today, it has become a nimble planning suite for planning, tracking, and launching great software. In many organizations it has become the main map of software projects, the center of all development, the infamous source of truth.
It is typical that the map is not the territory. Unfortunately, this seems especially true of JIRA. Its origin as a bug tracker, and its resulting use of "tickets" as its fundamental unit of definition, have made its maps especially difficult to follow. Jira1 is too often used in a way that inadvertently makes it an "anti-pattern" across the industry, that is, "a common response to a recurring problem that is generally ineffective and risks are highly counterproductive."
One thing that elegant software writing has in common with art: its creators must remain aware of the project's macro overview, while working on its smallest micro details. JIRA, unfortunately, implicitly teaches everyone to ignore the larger view while focusing on the details. There is not a whole. At best, there is an "Epic", but the heart of an Epic is to break it down into smaller pieces to work independently. JIRA encourages the breakdown of macro vision.
Also, feature-based JIRA does not easily support the concept of infrastructure for the entire project that does not correspond to individual features. A data model used throughout the project. A complex component used on multiple pages. A caching layer for a third-party interface. A background service that provides real-time data used on multiple screens. insurance may Guelos in the JIRA ticket paradigm … but the resulting web of dependencies does not help anyone.
Worst of all, however, is the endless implicit pressure for tickets to be marking finished, to go to the next phase. Tickets, in JIRA mindset, are taken, focused until completed, and then passed, so they are never seen again. They have a one-way life cycle: specification; design; development; tests; launching. Doesn't that sound a little … um … waterfall? Gil development is not supposed to be fundamentally different From waterfall development, instead of just replacing a large waterfall with a thousand small ones?
Here is an analogy. Imagine a city planning tool that makes it easy to design city maps that include towers, residential districts, parks, shopping malls, and roads … but that doesn't easily support things like waterworks, sewers, subway tunnels, the electrical grid , etc. ., which can only be embedded through awkward hacks, in any case.
Now imagine that this tool is used as a model for construction, with the implicit assumption that a) the neighborhood is the fundamental unit of city construction b) cities build one neighborhood at a time and neighborhoods one block a the time. What's more, one is incentivized to move on to the next only when the latter is absolutely complete, down to the flowers growing on the medium strips.
Now Imagine city developers, engineers, and construction workers are asked to estimate and report on progress in terms of how many neighborhoods and blocks have been completed in their entirety and how far each is. Do you find this a particularly effective model for urban planning? Do you think you would like to live in its result? Or, in practice, do you think that the best way to grow a city could be a little more organic?
Let's extend that metaphor. Suppose you started building the city in a more organic way, so that, at a significant point, you have a center filled with a mix of temporary and permanent buildings; the foundations of the skyscrapers were laid (that is, the technical uncertainty was resolved); much of the central infrastructure built; a few clusters of initial structures in the central neighborhoods, and slums on the outskirts; an airstrip where the airport is; and the traffic that comes and goes between all these places. In other words, you have built a crude but functioning city in process, your skeleton built, ready to be developed. Well done!
But if you measure by how many blocks and neighborhoods they are absolutely finishedAccording to the artistic interpretations of urban planners, what is their progress? By that measure, your progress is zero.
So that's not how JIRA encourages you to work. That will look like a huge column of tickets in progress and full zero. That would look beyond the terrible. Instead, JIRA encourages you to complete one complete block and then the next; an entire neighborhood, and then the next one; to remove as many different tickets as possible, to mark them as complete and transmit them, even if joining them after the fact is more difficult than building them to work together in the first place,.
(If you prefer a smaller scale model, just transpose: city condo building, neighborhood flat, unit block, etc.)
And so, people take the tickets, implement them as they are written, pass them on to whoever is next in the workflow, consider their work to be well done, even if working in dispersed groups in parallel can be much more effective … and without even considering the greatest goals. "Implement the Load button" says the ticket; so that's all that's done. The ticket does not explain that the main purpose of the Upload button is to allow users to back up their work. It may be technically easier to automatically load each state change, so that the user gets automatic buttonless backups plus a full undo / redo stack. But all the ticket says is: "Implement the Load button". So that is all that is done.
Too often, the only time someone cares about the vision of the project as a whole is from the beginning, when the overworked project manager (s) initially grapple with the thankless task of breaking down the entire project. in a forest of Tickets. But the whole point A gil development is to accept that the project will always be changing over time and, although to a lesser extent, for several people, everyone on the team, to contribute to that change. JIRA has become a tool that really works against this.
(And I'm not even talking about asking engineers to estimate a project that someone else has broken down into subcomponents whose partition feels unnatural, giving them about thirty seconds per function during a planning meeting, and so basing the entire project plan on those half-blind guesses, without investigating, without investigating, without revisiting them or giving time for more careful analysis. That anti-pattern isn't JIRA's fault … exactly. But the JIRA structure contributes to this.
I am not saying that JIRA does not take place. It's great when you're at the point where breaking things up into small parts and finishing them sequentially makes sense. And, unsurprisingly, their track record is extremely good at tracking issues.
Let me reiterate: To write fancy software, you need to keep both macro and micro vision in mind while you work. JIRA is good at handling micro parts. But you need something else for the macro. (And no, a selectable prototype is not enough; they are important, but they also require a descriptive context.)
Let me propose something shocking and revolutionary: prose. Yes, that is correct; words in a row Carefully written paragraphs. I am not talking about huge requirement documents. I'm talking about maybe a ten page overview describing in detail the vision of the entire project and a six page architectural document explaining the software infrastructure where the water, sewer, electricity, metro and airport services are located. the city. How they work, to extend the metaphor. When Amazon may, famously, require six-page memos in order to convene meetings, this really doesn't seem like too much to ask.
Simply neglecting to treat JIRA as the main map and project completion model undermines much of its implicit antipathy. Use it to track iterative development and bug fixes, by all means. He is very good at it. But it is a very poorly adapted tool to be the overview map or the infrastructure of a project, and it is Never The source of truth. The source of the truth is always the running code. In software, as in art, micro work and macro vision must always be informed of each other. Let JIRA map the micro work; But let plain old language describe the macro view and try to pay more attention to it.
1Atlassian appears to have decapitalized JIRA between versions 7.9 and 7.10, but descriptively, everything in upper case still seems more common.