I just posted my newest article on Medium! Go ahead and take a read on Medium to boost my readership there, but I'm also posting below, and feel free to discuss in the thread here!
As an Agile Coach at Elsevier, Inc and co-lead of the Philadelphia Atlassian Community Events group, I am passionate about sharing ideas about Agile practices and Atlassian tools. Throughout my experience as a Scrum Master and Scrum Product Owner, and now as an Agile Coach, I continually run into situations where teams feel they have to choose between following agile principles and organizing and tracking their work in Jira. In fact, Jira is designed with agile in mind, which is obvious when you break down the core organization and flexibility of the tool. The challenge these teams have faced is that some administrator (admittedly, sometimes that administrator was me) has made Jira rigid and rule-laden. In my early days as a Jira administrator, I felt that if a feature was available in Jira’s back-end, then it must be used. But true to the adage, “Just because you can do something doesn’t mean you should,” Jira exists to add flexibility — not take it away.
If you want your teams to work agile within Jira, you should first keep in mind the Agile Manifesto and the Twelve Principles to the Agile Manifesto. Some of the best practices described below specifically call out some of these principles and values. Configuring your solutions according to those two resources will solve most of your problems. With that in mind, here are my seven best practices for working agile in Jira, which I impart to every team and instance I support.
The Office [TV Series]. (2005). NBC. courtesy 1999jfs_08 on Reddit ( https://www.reddit.com/r/DunderMifflin/comments/7zubij/keep_it_simple_stupid/)
Every time I over-complicate a configuration, it comes back to bite me in one way or another. Whenever I look at an instance, stand up a new project configuration, or help overhaul a weighty and problematic existing configuration, the first thing I do is boil it down to the most basic of components. It’s important to understand the underlying need of the team or department and support that need with base functionality. The biggest problem with complex and rigid structures is that they are incredibly difficult to change.
To keep it simple, short and clear workflows are a great start, minimize use of ‘conditions’ on transitions, use as few issue-types as you can in your issue-type scheme to help your team clearly understand and differentiate the work, and don’t utilize too many ‘required fields’. Jira should be used to supplement your processes and team working agreements, not enforce them.
Silicon Valley [TV Series]. (2014). HBO. courtesy https://imgflip.com/i/303kfg
Very few people reading this have the job title Jira Administrator.” Most are project managers, scrum masters, or development leads; meaning their primary job that isn’t Jira administration, and that’s perfectly fine. Jira system administration (not including server administration, like updates and hardware) should not be a full-time job. Of course, some larger instances need team members to help keep the instance clean, evaluate add-ons, and keep the back-end from from spinning out of control with too many custom fields, statuses, and resolutions.
So ask yourself: Are you creating a configuration that will be a ton of work to upkeep? Will you be constantly adopting new workflows for every fringe case? Are you creating a custom field or resolution or status for each team, or are you helping them see the value of using custom field “Contexts” and reusing existing fields? Are you constantly having to help teams with questions like, “why can’t I see this issue?” or “why can’t I move this issue to this status?” These are all signs that you’ve over-complicated your configuration, and you’ve effectively dis-empowered your team. If you haven’t heard it yet, you will soon hear a familiar phrase: “Jira is too cumbersome to update my work.” Think about scaling back and revisiting the basics, and you’ll soon see positive results.
Cool Hand Luke [Motion Picture]. (1967). Warner Bros. courtesy https://memegenerator.net/img/instances/66545191/any-man-dont-keep-original-order-spends-a-night-in-the-box.jpg
As mentioned above, if your team is altering their agile process to make it track-able in Jira, then you MUST re-evaluate your configuration. This directly applies to the agile value “Individuals and interactions over processes and tools.” You should employ the simplest configuration that also promotes effective transparency for each team. Sure, you need certain standard statuses, issue types, etc., but having too many inhibits a team’s ability to change, iterate, and evolve. I have had many heated debates with administrators, scrum masters, development leads, and managers about their 22-step workflows and why those workflows are right for them, and while I won’t ever tell a team that what they are doing is blatantly wrong, I will ask them to think about why they need so many steps when they’re operating in a supposedly agile framework. Typically, I see this when their tasks are far too large and should be split into smaller tasks; they’re trying to track Epic level progress; they’re not really agile, and they have some heavy requirement being pushed on the team that is robbing them of their empowerment; or, in some rare cases, they might have enough automation in place with their Jira instances that they have the ability to update ticket status so frequently that it’s not onerous on their teams to keep their issues properly updated.
Review your own team’s workflows and see if you are a larger workflow and see if there are areas you could boil down your own statuses to be simpler, or if your Story sizes are so large they demand expansive workflows, and if they are that big, there are fantastic resources on the web for guidance on splitting Stories. I wholeheartedly believe there is no agile work that can’t be completed with a single-digit stepped workflow.
Stakeholders should have access to everything pertaining to your product development, and your squad should be able to determine who has rights to perform different actions on your projects. Therefore, I encourage teams to set up a permission scheme with role-based, rather than group-based, permissions. Role-based permissions allow for anyone with project-level administration rights to determine which team members have access to certain permissions, such as creating and deleting tickets, assigning work, and working on tasks. These permissions can be articulated in the Team Working Agreement, which every agile team should have. My typical configuration gives read-only permission to everyone in our stakeholder and departmental hierarchy, and allows each team to determine the remaining permissions for their projects. The advantage to this is that it requires less support from administrators, since admins alter group membership but not project role membership. This best practice empowers teams to control and own their projects.
Dilbert cartoon courtesy dilbert.com
This isn’t to say that documentation should be non-existent. Rather, you should enable key integrations to make documentation easy and as automated as possible. Employ Jira-to-Confluence integrations to have your documentation update automatically when releasing (see Creating a Change-Log in Atlassian documentation). Also, be certain to link any Confluence references to Jira tickets by including the URL to the issue, which will automatically link your Jira tickets in an inline link to show proper documentation and where each ticket contributes to the larger picture. The version history feature in Confluence is often overlooked, and gives you key insights into the evolution and progression of your documentation and software. The concept of working software over comprehensive documentation is really about having concise and valuable documentation that is created with the lowest impact on your team, ensuring the team is always focused on delivering the highest quality software possible.
Dilbert cartoon courtesy dilbert.com
Don’t develop some over complicated way of reporting progress with partial completion of tickets. Effectively mapping your Stories to Epics (and, if you have Jira Portfolio, Epics to Objectives) allows you to report clear and up-to-date progress at the level your executives, PMO, stakeholders, and product owners wish to see without disturbing your teams. If executed properly, it will also reinforce and encourage your teams to break down Stories and tasks into smaller pieces, because you only gain progress on Epics and Objectives when a task is “done-done.” If you try to status something that isn’t truly complete you might fall victim to the 90–90 rule. The 90–90 rule (first identified by Tom Cargill of Bell Labs) states that “The first 90% of the code accounts for the first 90 percent of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” People are notoriously bad estimators (myself included; — ask my wife how often I underestimate the run time on yard projects), but if you break tasks down into smaller, meaningful, achievable chunks of time, you’ll notice fewer significant impediments, more sustained velocity, and much more consistent accuracy in your team’s commitments.
Configurations like workflows are plans for how you are going to do work. If, like I mentioned above, you’re working with 22-step workflows, you are over-configuring. It may seem counter-intuitive, but by adding fewer steps to your workflow, by using smaller Stories, you actually increase the transparency of your progress. Each step has more significant meaning, teams have flexibility to define what each status means (within the larger definition of “done” within your company), and it’s easier to see where bottlenecks are occurring because there are fewer columns to review and decipher. The more steps in your workflow, the more opportunities there are for something to get lost in translation or a hand-off to be missed. You want the shortest possible feedback loops for each and every task your team works on.
Less Is More. (2019). Russell Zera.
The main takeaway here is that less is more. The more you can free up Jira to serve your teams, without overly complicated configurations, the more powerful your results will be. There is a reason this software comes with a very basic configuration out of the box — it’s the best way to use the tool for an agile team, and also allows configuration for fine-tuning, or for more regimented, non-agile configurations. Try to think of back-end Jira as fine-tuning rather than department defining and enforcing, and you will see a dramatic improvement in team performance, tool acceptance, and overall workplace happiness. I often refer to a fantastic book by Gene Kim, George Spafford, and Kevin Behr called The Phoenix Project. The book touches on many facets of how we organize work (the authors approach this from a DevOps perspective, but the concepts apply across the board) like a manufacturing floor. Teams manage different work centers that should function effectively and in balance, and must be able to effectively visualize this flow. Simplify your configurations and workflows as I mentioned above, and you will enjoy greater freedom and trust across your teams, increased visibility into problem work centers, and more efficient throughput of your product.