Here at Oasis Digital, we are always agile, and depending on the project needs, sometimes use Agile (in the “capital A” sense) processes extensively. Yet regardless of agility, iterations, steering, and so on, the planning and decisions made at the beginning (and in the early months) of a project often have profound and very difficult to change consequences later.
Therefore, while we would never argue for the straw-man Waterfall, we aim to think very hard about a project at the beginning.
Strategies for successfully traversing the ever shifting Atlassian UI
Atlassian’s JIRA is a fascinating platform for me to use, teach about, and study. I have been working with computers since I was a child in the 80’s. My parents did not buy an Atari game machine when they were popular, we bought an Atari 400 computer. I did play games, but I had to type them in from the back of Byte magazine first.
To those who understand that last reference, we are few in number but we understand why so much works the way it does today. As I keep my eye on staying current in this field, I watch what develops in the context of the full path of the personal computer (pun intended).
In many ways, the fluid JIRA interface is a triumph of SaaS over the technical lethargy that typically comes with enterprise software. The application rapidly improves in any area the company focuses on. Missteps in design are sometimes corrected surprisingly quickly. Soft launches of new features are incredibly valuable, the new project interface is a perfect example. With the first soft launch it was horrid, now it works pretty well. With hundreds, and possibly thousands, of talented developers working on the application, the scope of the management problem is hard for many to fathom. It does yield some interesting results.
Over the last few years there have been various waves of updating the UI in JIRA and other Atlassian products. I currently see four concurrent waves of UI modernization in JIRA. I am sure some of them will not expand much further but disappear, although not without creating potential confusion for users.
This challenge hits us directly in almost every class I teach. I will regularly run into a UI change that occurs during the class or while I am traveling to a class. This leads to some interesting results when, for example, you are setting up a project and end up in the administration pages without warning. It keeps you on your toes as an instructor.
Above and below are two very different examples of interfaces to share something you create with other users.
As a prime example, many more can be found in the images throughout the article, lets look at what users manage in the system. They manage Dashboards, Filters, and Agile Boards. The important features for users are creating, editing, sharing, showing favorites, these are just a start. Yet when you compare the UI mechanisms for all three, it is very rare for the three areas to work the same way. This simply confuses users.
From my perspective, there are three types of organizations using JIRA Cloud.
If an Enterprise is using JIRA Cloud, they are progressive by definition. Many Enterprises could simply not overcome the internal hurdles to use an app outside of their physical control. Even a dynamic company of this size will struggle with organizational weight and will need support to keep users productive.
A key strategy I have seen implemented in this type of environment is to have a designated advocate in every organizational unit. Connect these advocates together and give them a steady flow of release notes regarding UI updates. Very quickly these staff become the first line of support for users that need help. Over time they can proactively address new updates for people they work with every day. This is more efficient than asking a training organization to hold boring classes devoted simply to UI changes, that are reminiscent of Office Space.
Organizations in this size range often have less defined processes, and may not have a dedicated support team for software. Very often the IT department fills this role. Often individuals that can have very disparate job titles become the “go to” problem solver for a part of the organization. Find and recruit these people, they like helping others or they would not become that person. Empower them and let them help you.
Another approach is to use your normal notification mechanism (possibly the one built into JIRA) to notify staff of changes to the interface that will affect them. Proactive communication, if consistently delivered, can build confidence and improve productivity.
Teams that are using JIRA Cloud are a much simpler scenario. It does not mean that less diligence is required to keep your team productive, but the approach is different. Watch for those that are getting behind, talk within the team at lunch or during meetings about changes.
My software teams fall into this category. I try to be aware of the various generations in the teams and anticipate problems. A perfect example is Windows 8. As I watch people use it, I see a clear divide between those that use the Metro interface vs those that avoid it at all costs. This does not mean users are less capable, they have had different experiences. Instead of ignoring this, use it to your advantage. It will increase your knowledge and improve the cohesiveness of the team.
This article was written about JIRA but it really applies to all kinds of software and systems. The consistent theme here is proactive communication. None of these strategies involve one person trying to solve every problem. Engage others, increase knowledge transfer, and build consensus. These are strategies that work in many situations and circumstances.
The rapid development of new features is one of the reasons I strongly advocate for JIRA software in many situations. Atlassian has done an amazing job building up the capabilities of the system at scale in a fairly unique way. The uniqueness of this is often unexpected to users and hopefully the strategies discussed here, or some variation, can help you keep your team moving forward for many years to come.
Here is another example of UI differences within a major function of the application, editing a name.
Anyone familiar with JIRA understands that jumping into building a workflow without an overall plan can lead to problems. While navigating JIRA’s workflow editing tools, half of your brain is focused on your workflow design, and the other half is dealing with the tools. While I encourage new users to try their hand at the software, it is important to understand it is unlikely any first effort will be usable. Following are some suggested strategies that will help you avoid completely starting over, the normal result of a failed attempt at workflow development.
First of all, grab a piece of paper and a pencil. A good workflow takes some thought and some iteration. Fully expect to erase and redraw statuses and transitions if you want to have a truly effective workflow. The more complex the problem domain, the longer it will take. Common mistakes that can take a long time in the editor can be sorted out quickly on a piece of paper. Having a sketch makes the work more easily done (therefore also a possible candidate for delegation).
In my experience, a diluted focus is where even experienced JIRA users might fall down. Focus and flow are very important to the user experience. Focus can be diluted when the driving purpose of a workflow changes midstream. If a user is following a workflow focused on a task progressing through teams and suddenly has to deal with a time (deadline) based status, it can lead to frustration and mistakes. A good user experience is important in a support system like JIRA: a bad experience leads to poor performance. I believe this focus can be achieved by a good initial decision on what type of workflow to build. I break these focuses down into three categories; tasks, time, and resources. Each one is very different, and probably should not be combined in one workflow.
This is a natural way for many organizations to work, and possibly the best way to approach a workflow in JIRA. In this design mode you specifically map out the work based on the steps it will go through from start to completion. You should be able to easily describe statuses and needed transitions.
If you are concerned about a bottleneck in your staff capacity, inventory, or other resource issue, guard against modifying the workflow to accommodate this. For example, adding a status to the workflow to sort out an overcommitted resource will disrupt the workflow, this can better be handled within a task-based workflow by a screen popped in a transition. If you want to incorporate scheduling a coordination meeting, or other time issue, adding a status to represent this is also a bad idea. Instead, set a trigger to generate the meeting in a properly named status. Those are examples of diluting the effectiveness of a task-based workflow. If you do so, then you tend to start making workflow design decisions that can confuse users. This does not mean that capacity constraints and time considerations are not addressed. These can usually be exposed in filters and typically addressed in transitions.
If your world is filled with Scrums, SLAs, or Gantt Charts, or if your workflow is completely budget driven, then you should consider a time-based workflow. Build your workflow around the processes and meetings that will occur. A good indicator of a time-based design is that your statuses look quite similar to titles in your emails and calendar events. There are lots of examples of this type of workflow, such as the one below. In a time-based workflow you can use post functions and triggers to set dates in an external system and tie the timing of the tasks to various statuses, transitions, and custom fields. If you tend to sort and look at issue lists based on date fields, then a time-based workflow might be a good choice.
Another way to slice through a workflow is to strongly consider resources and people directly in the design. This type of workflow is focused on capacity, issue counts at various stages in development, and looking for where you need more resources or people to maintain productivity. Statuses will be related to the functions or resources needed for a step in the workflow. A workflow designed in this way will make heavy use of custom fields, components, and automated assignment of issues in transitions. If you tend to sort your lists by assignee or component, then you are a good candidate to build your workflow this way. Including similar items to a task-based workflow as described above is natural. Make sure your workflow is consistent from start to finish with steps regarding resource allocation spread across the entire work cycle.
If your workflow has more than eight statuses then you are likely going to find layout to be a struggle. One approach that can help is to think of the workflow as sections, or silos, of work. JIRA automatically does this for you by creating three categories to put your statuses in (To Do, In Progress, Done). You can take this into your layout by grouping these categories. There may also be pieces of your workflow that typically run in sequence with little deviation. Tightly group these in a small area to assist in the readability of your workflow. By thinking through this process you can avoid the spaghetti syndrome that permeates many workflows. Unfortunately, the best planning cannot prevent a JIRA update from making a mess out of your pretty workflow. But they can be easy to sort back out as long as you are using the same principles.
I show the Resource workflow example from the previous section below without this organization to demonstrate the point. I did not intentionally make it bad, I used the standard order generated by JIRA. The statuses are simply dropped in chronological order, and without some thought an intense mess can develop. Note how it is difficult to see the true flow of work.
When approaching the design of workflows in JIRA it is important to understand the need behind the workflow you are building, have a strong vision for that plan, and execute it with user efficiency in mind. The concepts discussed in this post are a good starting place, but there is much work to do to effectively execute a workflow. There are many good options for targeted training in this area, we recommend users start building workflows immediately and use that process as a platform to learn the system. As a user gains deeper understanding, they can immediately incorporate advanced concepts into their workflows.
