Expium–the Atlassian division of Oasis Digital— is deeply experienced working with JIRA in a variety environments. Our customers run the whole gamut, from pure software dev shops to government agencies simply using it as a project management tool. Because we see such a broad spectrum of implementations we are able to see some trends forming early on.

In this article I want to talk about trends in agile practices and JIRA in the enterprise in 2016.

A typical conversation with a client will start by focusing heavily on their agile needs. Their teams organize work in sprints, they hold retrospectives, and they have quick daily meetings. There is a sense of pride in what they have working and they truly see themselves as an agile organization. A little later in the engagement we will start to hear how management reporting also requires some additional planning and configuration. These discussions invariably relate back to two needs, schedule and budget. Management is invariably looking for traditional reporting from these agile teams.

Agile training organizations attack this problem in a number of ways. They might simply ignore the problem and stand their ground. These folks insist that an Agile methodology will work its way up through the organization and win over the C-suite. Others will apply some or all of the scaled agile framework. This approach adds a layer of organization and reporting onto accepted agile practices to yield a coordinated effort that can provide the data necessary. These approaches are effective, but come at a significant overhead cost in staff and productivity.

At Expium we have worked with organizations and enterprises facing this problem and used the flexibility of JIRA to solve it without the overhead cost of additional staff and productivity. Each environment is unique but there are some strong organizing principles in JIRA that can be brought together to solve this problem proactively and make reporting near real-time. JIRA cannot solve the software development at scale problems solved by approaches like SAFe, but it certainly can expose parameters typically obscured by normally operating agile teams.

The first step is to understand and identify all the parameters needed by various levels of management. This list should be fairly exhaustive and created with a working knowledge of Field Types in JIRA. Some organizations track projects from a schedule first perspective. If this is the case, multiple date Fields will be needed. Other organizations track projects based on dependencies. This one is tricky to get correct, but by building the proper Field and Issue Type hierarchy in JIRA, it can be accomplished. Yet other organizations are driven deeply by priorities, this one is actually the simplest to support. A complex engagement could include all of these in one organization.

Once you have the requirements defined you need a way to introduce these into your projects without distracting and burdening the teams. This is extremely important!

Dev teams need to be focused and spending their time writing software, not updating reports and sitting in progress meetings.

We achieve this by using a combination of Issue Security and Custom Issue Types. Each environment is somewhat customized, but generally the rule is to create a set of Issue Types that are specifically designed for reporting and tracking. These Issue Types are maintained by the project leads or project managers but are not visible to the development teams beyond the leader. The Issues are linked in some predetermined and often automated way to the development Issues that are being worked by the development teams.

Achieving this type of structure essentially allows agile teams to function in an organization that cannot relinquish waterfall-based expectations. Whether we like it or not, this describes a very high percentage of our customers. Dealing with this reality is not agile processes failing, it is adjusting to the immovable object of capitalism. All businesses need to know what they are spending their money on and how much they will spend for a unit of progress. This is not something that can be escaped and why many executives are turned off by agile zealots.

Those that have read my previous articles will already know what I am about to say…

Agile processes and principles are a set of tools, not to be confused with an ideology. Applying those tools to make dev teams more successful while not ignoring the business needs is something Expium does very well. We apply agile processes ourselves every day on our custom software projects at Oasis Digital, we believe they . I will say that every single project we have operates slightly differently based on the actual needs of the team and the customer. We do not dictate that every project run a certain way because that is “How we do things”. Reality is much different than delusion and the confluence of those ideas can be quite painful. Fortunately JIRA is flexible enough to support some very effective but creative solutions to business problems.