Applying Governance and Constraints to Jira to Increase the Potential for Agility

How we can use governance and constraints to get the most out of customisable software and reduce organisational headwind.

By Neal Taylor and Paweł Przedlacki

Customisable software is a double-edged sword.

Whilst flexibility means that we can customise a piece of software to the unique needs of an organisation (and even to various unique needs within an organisation), the downside is that too much unaligned and unconstrained customisation, increases the risk that a chaotic system ensues.

This is particularly problematic if this software is the logistical infrastructure for the concepts, ideas and tasks that the organisation is working on in order to achieve its aims. If the task management system designed to execute operations becomes chaotic, what chance is there, then, for the organisation to succeed in any of its aims?

In this article we look briefly at the inevitability of ‘organisational headwind’: how this is not only often reflected within the tools we use to manage ourselves (such as Atlassian’s Jira), but also how the task management system has its own inevitable headwind which, in turn, can impact the operations of the organisation.

We will examine how, in an organisation’s efforts to increase its potential for agility, applying constraints to its customisable software can be a blessing in disguise.

Whilst we’re predominately looking at Jira here, it provides us a useful understanding into important concepts such as systemisation, constraints, decentralization and chaos in the context of organisation, agility and technology.

Every organisation faces an inevitable ‘organisational headwind’

The goal of an organisation is to collaboratively achieve a common intent — usually perceived to be something of value in terms of a product of service.

The further assumption is that we cannot achieve this intent alone; we need a team or multiple teams. With extra team members comes extra communication (as well as extra friction, competing goals, increased confusion, etc.) and so somehow, we need to organise ourselves towards that goal.

And yet, despite our best attempts to organise ourselves as best we can, we always face the inevitable ‘organisational headwind’. For an excellent and light-hearted overview of how organisational headwind manifests itself, see the work of Alex Komoroske at komoroske.com. In a wonderful and innovative slide deck, the author makes a strong case that organisations need to be more like slime-mold to avoid this organisational headwind!

From Slime Mold … to Jira!

In “The Wisdom of Slime Molds: A New Science of Decision-making”, David Bennett, discusses how the characteristics of slime mold can teach us about adaptability, creativity, and the importance of diverse perspectives in decision-making process.

Slime mold, a simple organism with no central nervous system, is able to solve complex problems and adapt to changing environments by relying on decentralized networks of communication.

Decentralized decision-making allows for more flexibility and adaptability, as it encourages open communication and collaboration across all levels of the organization. We use tools like Jira to enable the communication and collaboration within organisations — but how does the use of the tool often end up in chaos instead?

The tools and systems can face their own headwind

Jira is often used as a logistical infrastructure of the organisation. If the management tools are chaotic, however, then what hope does the organisation have?

Whilst on the one hand, the software might reflect the chaos of the environment, on the other hand, the tool itself can descend into its own chaos through neglect and its own confrontation with the organisational headwind.

It’s all the more important therefore that, if the organisation is going to use a tool like Jira, the tool should enjoy the attention and care of any well-maintained system.

So how can we ensure that these tools do genuinely help us in our goals?

What exactly are we trying to achieve with tools like Jira?

Technology is really about the power to extend human capability - and our potential to achieve something.

So a tool must be extend some human capacity. What capacities are we trying to extend with the use of Jira or similar? Among others …

• Memory (store of information for quick recall)
• Communication to many people at once
• A rapid flow of information
• A kind of map (to show where we are in abstract terms)
• Reduction of the cognitive load of repetitive tasks (automation)

Beyond this, a software can help in systematizing operations, in other words, scaffolding approaches to doing things and how to make decisions such as: how we describe a piece of work, how we prioritize work, how we link concepts together. So, in this sense it’s also a kind of psycho-technology: it potentially affords us greater capacity in defining HOW we get things done.

As you know, much of Jira is already based on agile and lean concepts — already, as in, ‘out the box’. But we may wish to modify the default settings because they’re not one size fits all. Jira allows us to customise its settings.

Why we want some systemisation

Generally, systematizing the operations allows our system to execute them in very repeatable and predictable ways, and that improves visibility into how outcomes are achieved.

This in turn gives us an empirical view of how we work together. Like good biologists, we can then inspect the system to find waste is or uncover the golden nuggets of improvements.

We can then:

• Measure the outcomes (or products) of the system
• Measure the efficacy of this system in helping to achieve those outcomes
• Adapt accordingly

Defining the constraints within customisable software

A piece of software like Jira can support how we work together, almost like a sort of organisational ‘operating system’.

When designing a system, we can determine different levels of precision and strictness of constraints.

For example, Jira doesn’t allow ‘story points’ in Kanban boards because the principles of Kanban don’t support story points. That’s an in-built constraint.

However, the system does allow other aspects to be customised:

You can use ‘story points’ in scrum board tickets — but, if you really wanted to, you could add ‘t-shirt sizes’, ‘time’, ‘estimated time’ and ‘actual time’. Regardless of your opinion of story points, imagine ten different teams were using ten different metrics, ten different sizes, ten different terms, and ten different ways of saying something is ready. Anyone wishing to know ‘how are we getting on’ would be hard pressed to get a clear overview. But we need that overview to make strategic decisions!

So how can we keep an overview and avoid this situation?

At this point, it’s worth understanding what we mean by constraints.

What are constraints?

Constraints were brought into systems-thinking literature via the work done by Alicia Juarrero in ‘Dynamic in Action — Intentional Behaviour as a Complex System’.

Constraints refer to the extent of the possibilities that can ‘potentially’ happen. White noise is an example of something with no constraints — we need constraints to guide potentiality into actuality.

Juarrero differentiates between two different types of constraints:

• Enabling constraints bring us more possibilities for outcomes to potentially happen once prompted into action and
• Selective constraints (or governing constraints) narrow the range of possibilities

You could also think of them in terms of constraints which widen possibility (albeit not necessarily more likely); and selective / governing which narrow the possibilities (but perhaps more likely to occur).

The pitfalls of unconstrained customisable software

Any piece of software will automatically have certain constraints in place which may make certain outcomes more or less likely.

Software, like Jira, is highly customisable, so affords us many different ways of customising the system towards our needs.

The danger with customization of multipurpose systems is that if the application of constraints doesn’t lead to the outcome we wish to see from the system, then the predictability of consistent outcomes (i.e., the value we’re trying to achieve) decreases.

For example, if many different users adjust the configuration without consideration of potential impact the changes have at a wider organisational level (i.e., no alignment), then, in our experience, we see a greater likelihood of a proliferation of

• Terminology or taxonomy
• Ways of doing things or statuses
• Competing data points

We neither have good information about the system nor about the work itself. An undesirable tendency which fosters a loss of focus on any existing structures, that could have been predesigned.

We have also witnessed how these trends lead to anti-patterns such as:

• ‘Hand-cranked’ metrics
• Status reports based on second-hand interpretation
• A reluctance by teams to engage with a task management tool that has no clear benefit to them or their work
• A lack of clarity within the tasks

Here we see that we’ve started encountering a headwind within Jira.

Encountering headwind within Jira

All this added friction has further knock-on effects and can contribute to:

• Reduced clarity
• Confusion about where we are or how we are doing
• Inability to inspect or improve

So, without anybody being at fault, we’ve seen how tools can face their own headwind, which can have a detrimental knock-on effect on the organisation’s ability to work together, solve complex problems and create value.

How can we avoid this?

The system needs some constraints in order to reduce the possibility of certain things happening:

• Mitigate the risk of trending towards chaos
• Prevent the system itself (i.e., Jira) from becoming so muddled that its information cannot be used to make decisions or improve

If constrains are not maintained, it will require more and more effort to return the system to its optimal state.

Finding a balance between enabling and constraining possibilities

The goal is to customise the tool to reflect how we want to work together to get stuff done. This assumes we know how to get stuff done. Not everyone knows, and it’s okay to start with a guess, so long as we can inspect and adapt, which means we also need to start with a baseline to measure our progress.

However, if many agents are the power to customize the system, there is a risk of creating too many possible paths and outcomes which take away the benefit of repeatability and predictability.

At the same time, we want to avoid centralisation:

• We don’t want to dictate, top-down, how things should be done
• We don’t want to diminish the chance of finding new innovative ways of doing things (through bottom-up tinkering)

So how can we create some constraints that reflect these needs- and guide us in the right direction?

A Case Study

Recently, Paweł Przedlacki and Neal Taylor worked together to help an organisation improve their instance of Jira.

In a fairly typical case, an organisation had a ‘carte-blanche’ approach to configuring Jira. In other words: any requirement for the customisation of Jira or any new idea was configured for whoever requested it!

The issue here, as we’ve learned above, is that the new configuration requests don’t take into consideration the strategic direction of the organisation, nor do they consider what was in already in place.

Whilst this might sound like an over-the-top approach for something as harmless as Jira configuration, we need to remind ourselves of the core problem we are trying to avoid: that at a certain point (like a tipping point) over-extensive configurations make the whole system almost unusable — a white noise of options — with no clear way to structure their work or gain any benefit from the tool.

So we need a clear direction — or some way to determine — what benefit a new customisation would bring to the whole.

It was, therefore, important for us to create some new constraints to:

• Restrict the paths that configurations can take
• Define a strategy for dealing with any potential new customization needs
• Set up a core configuration from which exceptions can be made only if it is valuable from wider business perspective

It’s worth noting that the concept of constraints is neither revolutionary nor innovative — it might even be blatantly obvious! Our intention here is to relate why we are adding the constraints — to what purpose.

We’ve distilled our experience into some heuristics.

Heuristics for Jira (for greater agility and reduced headwind)

One of the most beneficial constraints - which helps set the direction for system lifecycle - is to define the governance around its customization and future evolution. As unpopular as this word may be, it may help avoid some of the pitfalls of uncontrolled customization, but still allow openness to the needs and ideas coming from the systems environment.

Some of the key heuristics that we have discovered are:

• Create principles for further design decision-making (i.e., maintain consistency with existing configuration, leveraging existing configurations instead of adding new, framework for system expansion)
• Empower the guardians of the system to keep things simple. Reduce and simplify rather than add new “value” on top. This is about being able to say ‘no’
• Monitor and measure the system and its configuration performance resulting from changes and continuous operations
• Use standardised and consistent terminology and taxonomy of information (terminology, naming conventions and definitions)
• Prioritise generic configurations or components that can increase resilience to edge cases and allow reusability across processes
• Maintain consistent and pre-agreed datapoints (what are we measuring!) used for reporting and strategic decision-making, that do not require many transformations before being used in decision making
• Do not over-customise: Maintaining generic approach as long as possible allows ongoing room for improvement and change when they are truly required. When to know when they are needed?
• Keep removing gunk! Reduce the complexity by constantly removing customisations that are little used (this can all be tracked)
• Plan out the customisation roadmap from the most valuable and simple features to more complex ones
• Respond to the organization’s needs in further system evolutions
• Maintain reference documentation for centralized, clear and transparent point of reference for the configuration

To summarise

There can be several challenges when using Jira Software in an enterprise environment if there is not coherent governance around its customization and maintenance.

Without proper governance, different teams and departments within an enterprise may customize Jira Software in different ways, leading to a lack of standardization and potentially causing confusion and inconsistency. If Jira Software is not properly maintained, the quality of data entered into the system may suffer, leading to inaccurate reporting and decision-making. If Jira is not being used effectively and efficiently, it may not provide the desired benefits and could potentially contribute to organizational headwind and decreased value.