With each passing demo, I realize that it may be time for a moment of enlightenment for those out there wandering the dark and dusty plains, trying to decide which tool to use. Are the tradeoffs with system A worth the price of integration with system B? Is monolithic system C really worth that cost, in hours or budget? Meanwhile, our team has been keeping the lights on with this tool since the Reagan administration… so on and so on. Have faith in yourselves and to quote Shakespeare:
“We are such stuff as dreams are made on, and our little life, is rounded with a sleep.
Better three hours too soon than a minute too late.
We know what we are, but know not what we may be.
Our doubts are traitors, and make us lose the good we oft might win, by fearing to attempt.”
We are constantly beset by struggles and choices between competing platforms and priorities; too often, these are driven by archaic thinking: “This is how we’ve always done it.” “We don’t need to change.” “This is fine.” How often do we take the time to stop and ask, “How should this work?” We are prisoners to our own success as much as we are to our failures; this prison is one of the terrors of making calculated, strategic moves in new directions.
Where is this leading?
JIRA is an enterprise tool that can support the depth and breadth of an organization: the Service Desk; development lifecycle and application management; to release and maintenance management. JIRA’s bandied about as the preeminent agile tool for a reason – but the reality is that it can work just as well, providing all the advantages afforded to agile teams – to waterfall teams as well. Not every organization has raced to agile methodologies; many more face a daunting task of deploying systems which can serve both user bases. JIRA exists in a space to serve both groups – not just “agile for the agile stuff and something else for our legacy systems”. Everything we do in our work lives – from Portfolio management, to development and release planning – is based around a set of processes. And that process – Agile, Waterfall, ITIL, or something of your own making – can be created and enhanced via JIRA.
What is process?
As defined, process is nothing more than a series of actions or steps taken in order to achieve a particular end. Another way to define it would be that it is a sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, machines, money) to convert inputs (data, material, parts, etc.) into outputs. These outputs then serve as inputs for the next stage until a known goal or end result is reached. A series of processes, with data collected throughout, coalescing into a solved state – quite simply, this is what JIRA does. HR on boarding and off boarding, code review, security audits – these are all processes that can be carried out as a series of steps (a workflow, if you like) – all the same as becoming Agile, or ITIL/ISO compliant.
So, you have a system that can carry out these workflows, but where does Service Desk fit in? Or Bitbucket, or for that matter the new divide between JIRA Core, JIRA Software, and JIRA Service Desk? Recently, a client presented us with a challenge to provide an end to end solution – client request to developer and back again. Now in our development world, it would seem like an easy task; create an
issue, work the problem in an Epic or Story, and release it. But what about all the tasks that keep the development teams ticking? What about the resource planning, release date, requirements and the inescapable millstone of those pesky budgets? The client was looking to get multiple tools based on each functional area and have them integrated through an API or some other form. Yuck.
Digging into client requirements, it became very clear that our clients requirements, although genuine, were not as overbearing as initially thought. The client did not need to buy a solution for their Program Management office, and that his service desk requirements did not need the weight and cost of a suite of tools that could well have predated many of the teams who would be working in it – in implementation date if not development date. Dogmatic addition to “what has been done before” defined the need for both of these groups – and while the development group had been moving towards agile methodologies, the smouldering remnants of waterfall development methodology still drove a majority of business decisions.
The solution consisted of:

  • JIRA
  • JIRA Agile
  • Tempo Timesheets
  • JIRA Portfolio
  • Confluence
  • Confluence Questions
  • Team Calendars
  • Comala Workflow

What was the solution?
This is by far a simplification – for each status there were a number of checks, screens, and other workflow tricks that we were able to use to develop a unified solution – but this ought to provide some context:
In Summary
The Atlassian stack – of which JIRA is a workhorse, to be sure, but far from the only tent pole – provides an incredible amount of flexibility that borders on the magical at times. In my many years of working with the Atlassian tools, it is clear that the Atlassian stack – often combined with both expert guidance and the excellent community of marketplace plugins – can work for any organization. Small businesses and independent development shops have been the front line JIRA adopters for a long time; Enterprise clients too are now seeing the incredibly transformative power of the Atlassian toolkit to empower teams and streamline overwrought processes – vastly reducing maintenance costs and TCO for myriad systems. We can cling to the shadows of the past and refuse to grow into new opportunities and discoveries, or we can embrace the opportunity that a new challenge provides us to transform our organization. Your organization can only improve by taking the chance to change your view.
Leave the footprint tainted by the past on this road of discovery, review your requirements and change the viewpoints. Make your organization more efficient and spend less on maintenance and TCO.