Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Effectively Using Jira with an Overarching Vision

Effectively Using Jira with an Overarching Vision

This item in japanese

Dzmitry Hryb, apps marketing manager at Atlassian partner DevInit, has recently published a series offering effective strategies to combat seven reasons why use of Jira can be frustrating. He expresses the importance of using Jira alongside other tools and customisations to represent an organisation's own workflow. Hryb responded to a recent TechCrunch story titled "JIRA Is An Antipattern" by engineering journalist Jon Evans, where he suggested that overarching needs such as the "macro-vision" and architecture are often neglected when coordinating delivery concerns using a model which is primarily project and issue-centric. Matt Saunders, head of DevOps at the Adaptivist, has also written a response to Evans' in which he concludes that Jira should be a single piece in a wider toolbox, offering a "toolset designed for organisations to shape around their specific people and process needs."

Evans' article presented an examination of anti-patterns which he claims exist "in many organizations" where Jira is "the primary map of software projects" and the "infamous source of truth." He states that Jira's excellence in tracking project and feature delivery provides a model suited to decomposing project and epics into "tickets," at the cost of losing a shared macro-vision and strategy. Evans adds that neglect of broader concerns such as infrastructure and design are made worse due to an "endless implicit pressure for tickets to be marked finished." He writes:

...feature-driven JIRA does not easily support the concept of project-wide infrastructure which does not map to individual features. A data model used across the project. A complex component used across multiple pages. A caching layer...

Saunders wrote of how his company, which specialises in providing Jira consultancy, sees two types of organisations: those with "very successful Jira implementations", and those which assume that "out-of-the-box Jira is a solution that improves the work of all development teams." Saunders emphasised the importance of out-of-platform collaboration and "adding appropriate documentation outside the ticketing system." He emphasises the importance of bolstering Jira with an ecosystem using other tools such as wikis, Slack and Zoom. Saunders wrote:

Jira does not function in isolation — and nor was it designed to. Expecting teams to move forward coherently just by using the native structure of Jira is unrealistic, as it's intended to work best when complemented by an environment of other tools and communication methods.

Hryb also addressed Evans' critique about losing the ability to communicate a macro-vision, by pointing out that this has "very little to do with the tool, and much more with its misuse or the organizational culture". Hryb attributes a myopic over-focus on delivery detail to the way in which some firms choose to "measure teams' effectiveness", suggesting that we first check whether the choice of "trash KPIs and useless reports" are the causes of "toxic behaviour." He also wrote about the need to surround Jira with other tools, and the way in which Atlassian has done this through Jira's sibling products and its market place. He wrote:

Sure, Jira on its own doesn't have the capabilities for proper project management, but there's clearly a reason why Atlassian developed Confluence. The second tool allows to create product sheets, track requirements, and link them to Jira issues, as well as document the overall business strategy for a given project.

Evans described the dangers of foregoing an infrastructural and overarching strategy by using the metaphor of city planning without the support for underlying amenities:

Imagine a city-planning tool which makes it easy to design city maps which do include towers, residential districts, parks, malls and roads … but which doesn't easily support things like waterworks, sewers, subway tunnels, the electrical grid, etc., which can only be wedged in through awkward hacks, if at all.

Evans wrote that "JIRA is good at managing micro pieces. But you need something else for the macro." He proposes architectural documentation and prose to capture the macro vision. He expressed that "a clickable prototype isn't enough" either as it too would "require descriptive context." He suggested:

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 — where the city's water, sewage, power, subways and airports are located, and how they work...

Eltjo R. Poort, a solutions architecture researcher and the practice lead at CGI, recently wrote about the need for specific value-driven architectural documentation. He wrote about how "documentation bloat" can slow down the "architectural feedback loop" and "caused significant delays." Poort observed that this often "causes organizations to start questioning the added value of architecture documentation." He wrote that the business value of architectural documentation can be measured in "terms of decision support, driving progress, design quality, risk and cost control." To be effective, Poort suggested different artefacts, using appropriate tools, for each of the following scenarios:

  • Explaining how stakeholder concerns are addressed through "architectural views" using prose and diagrams, produced for specific concerns about plans, projects, epics or stories.
  • Preserving "architectural knowledge" as it becomes available, for future direction, analysis and clarity; utilising wikis and documentation systems.
  • Supporting collaboration and flow by capturing new decisions in a decision register as they arise; traceable across Jira, Wikis and documentation systems.

Poort wrote that by creating targetted and value-driven architectural documentation, he measured improvement in the "start-up time of smaller projects from (typically) two months to two weeks – a real boost to agility and benefit to the organization."

In his article, Hryb responded to common complaints around Jira usability, performance and its impact on process agility, grounding his answers on it being just another tool. He reminded his readers of the importance of customising Jira for their own workflows, and that they may use its marketplace to fill capability gaps. Overall Hryb pressed the need to get your workflow and communication structures right first:

There's no tool which could substitute a solid working process and communication in the team, and if you already use Jira, try to learn it as much as you can to achieve better results.

Rate this Article