Anyone who works in agile software development knows how important it is to have an issue tracker application. These applications show the issues your team has completed, is working on, and will be working on in the future.
For many teams, Jira is the issue tracker of choice. One of the perceived advantages of Jira is that it serves as a “single source of truth” across an organization. This gives managers an accurate view into the progress, or lack thereof, of an organization against its product development goals.
But is Jira, or any issue tracker application, suited to this role as single source of truth? Is Jira an anti-pattern; poised to attack us when our back is turned?
Is Jira an Anti-Pattern?
The article Is Jira an Anti-Pattern? details some of the problems organizations can face when relying on Jira. It is challenging to simultaneously provide people with a long-term view of a software project, as well as the day-to-day progress against short-term project goals. The author, Jon Evans, makes the following points:
- The “get ticket, complete ticket” work pattern of Jira tends to encourage a focus on details. This is at the expense of a broader understanding of the big picture.
- Jira does not easily support organizing work to build technical infrastructure that cannot be mapped to an individual feature. This includes data models, multi-page user interface components, and third-party software upgrades.
- Jira’s assembly line mentality in pushing stories and bugs through a workflow can replace one big waterfall with a thousand little ones. This mentality incentivizes teams to complete small chunks of work at high throughput. The results are difficult to integrate with other small chunks into a coherent whole.
The points raised in the article are valid. Organizations must take steps to mitigate this forest-for-the-trees myopia that can engulf teams. Jira is a robust and useful application, but it is a tool. Like any tool, if used in the wrong manner, the results can be disastrous.
Agile Does Not Mean No Documentation
One common shortcoming in agile teams stems from a misreading of the second tenet of the Agile Manifesto — “working software over comprehensive documentation.” As the Manifesto goes on to explain, working software is valued higher than detailed documentation. This doesn’t mean that you don’t need any documentation. It also doesn’t mean that your product backlog in Jira is sufficient documentation. As Jon Evans says,
Allow me to propose something shocking and revolutionary: prose. Yes, that’s right; words in a row; thoughtfully written paragraphs. I’m not talking about huge requirements documents. I’m talking about maybe a 10-page overview describing the vision for the entire project in detail, and a six-page architectural document explaining the software infrastructure…When Amazon can, famously, require six-page memos in order to call meetings, this really doesn’t seem like too much to ask.
In practice, the problem identified here is that development teams can complete the aforementioned small chunks of work without ever grasping what the end result of the project should look like. It is important to think in terms of the value delivered to the end user.
To illustrate, one of our TeraThink teams are working on functionality to allow an application user to generate a “snapshot” of a benefit application on-demand. This consists of the application form, supporting evidence, and documents generated by the client when processing the application. All of which is ordered per the client’s requirements, with a nice table of contents, a header, and a footer.
Sounds easy, right? Well, not so fast. Future enhancements to this functionality will include the functionality not just to generate snapshot of a single application, but a snapshot of every application submitted by an individual to this client.
But wait, there’s more. Additional enhancements include functionality for the client to dynamically reorder documents within the snapshot. Later they will be able to remove documents altogether and replace the removed document with a placeholder template. Had our development team charged ahead and executed strictly against the first requirement (one application, all related documents, statically-determined order), the design and infrastructure would likely not be able to support the future enhancements. This would cause no small amount of rework and developer frustration.
Communicate and Iterate
To address this potential landmine, we refer again to the Agile Manifesto, this time to tenet one: “individuals and interactions over processes and tools.” For this effort, we have conducted multiple design sessions with the development and testing team. This socializes the vision for the short term, minimally viable product (MVP) and ensures that the team is also cognizant of what the functionality should look like long-term.
We also take care to address the user experience early in the planning process. This is invaluable in providing developers context into how the code they are writing will be presented and utilized by the application end user. We represent all of these requirements in epics and component user stories in Jira. Additionally, our Confluence documentation provides the requisite level of detail to the entire team, as well as outside stakeholders. These are the words in a row…thoughtfully written paragraphs that the author is pleading for in the article.
Find The Right Balance
The trick is to find the right balance that works for your team and project. There is no single formula but documenting the features so future team members can understand why things were done is key. Code is never self-documenting and neither are agile projects. Capture the basics in Confluence and point your Jira stories back to that documentation.
If you use Jira correctly and don’t rely on it for everything, you too can avoid the Jira antipattern.