Seven best practices for agile in Jira (Medium.com)

Russell J Zera _Philadelphia_ May 3, 2019

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!

https://medium.com/@russell.j.zera/seven-best-practices-for-agile-in-jira-c3177bc3a9fc

 

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.

1) KISS (Keep It Simple, Stupid)

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.

2) Is administering my configuration a job? Administering Jira probably isn’t your primary job, don’t allow it to be

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.

3) Make Jira work for your team, instead of your team working for Jira

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.

4) Utilize role-based permissions

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.

5) Prioritize working software over comprehensive documentation

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.

6) Remember that working software is the primary measure of progress

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.

7) Respond to change over following a plan

image courtesy https://thecreative.cafe/if-you-want-to-make-god-laugh-tell-him-your-plans-413ee471c7b7

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.

In Summary

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.

1 comment

Comment

Log in or Sign up to comment
em27gi December 9, 2019

It could just be how I've seen it used, but despite reading this article I still feel Jira is NOT agile. It's more of a micromanagement tool. Making pieces smaller (#3 and #7) just increases the micromanagement and slows things down more. If I am required to add in any tool/process to my workflow, my work has become less agile (less about interactions more about tools, less about responding to change more about a plan).

I agree with having fewer than 22-step workflows makes development more agile. In the extreme, the minimum number of steps is most agile. Anytime anything Jira gets included though, it just adds another step and more work. The most Jira could be freed up to serve teams would be to ditch it altogether.

Russell J Zera _Philadelphia_ December 11, 2019

@em27gi Thanks for your comment! I agree with your points about if you are required to add in any tool/process to your workflow, and also "In the extreme, the minimum number of steps is the most agile." Furthermore, I would like to offer up reinforcement from my post that, used improperly or over-configured, that ANY tool (even a physical agile board) can be manipulated into being a tool for micromanagement and command and control. Yes, the Agile Manifesto states clearly "Individuals and Interactions OVER processes and tools", but that is not to be misunderstood as "Individuals and interactions WITHOUT processes and tools". That is to say that you should never compromise your Individuals and interactions because of a process or tool, but that you should rather tailor your processes and tools to serve your individuals and interactions. In this growing global economy and workforce, effective digital tooling are becoming a necessity to ensure we are effectively enabling business people and developers to work together daily throughout the project, and to enable the squad to quickly and easily track changing requirements, even late in development to harness change for their customer's competitive advantage.

I would like to offer up that, based on your comment, that perhaps some of the lessons I have shared in this post may have been misunderstood. I have found that Jira being perceived as NOT agile is often less about the tool, and more about the administrator BEHIND the tool. The primary objective of my post was to point out that "Jira is designed with agile in mind, which is obvious when you break down the core organization and flexibility of the tool." In my summary I start off reinforcing your comment's primary theme: "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".

I guess I would like to ask you a question as a follow-on to your comment about if you use any tooling at all for helping your teams to collaborate on agile development (besides a physical agile wall), and if so, if you could share how you use it so that it freed your agile teams? 

Thanks so much for taking the time to read my post and provide your insights and opinion!

Like Dave_Liao likes this
em27gi December 13, 2019

Thanks for your reply. I'm in more a developer than Jira administrator role. That said should I ever be a Jira team administrator there are key take aways from this post. (I'm not sure I could tactfully refer our admins to your Medium post). I particularly like the idea of team members having ownership over their workflow, which is how I interpret your points 3 & 4, rather than the administrator always creating description-less tickets for everyone. So your point about me misunderstanding lessons is a fair one since I'm newish to Jira and I've only seen it used with one administrator behind the tool.

I haven't used other tools on other teams for day-to-day tracking, so maybe I haven't even used true "agile" practices before. In those teams, workflow felt more smooth with less starts/stops than Sprints though. Everyone knew what they were working on in the big picture sense, and the lead would meet with individuals for 5-10 minutes once or twice a week to make sure developers were on track and if tasks should be re-prioritized or given to someone else. That said it was not great to keep track of progress. Jira or other electronic trackers are helpful for going back and reminding managers I've already looked into a feature.

Thanks for your post.

TAGS
AUG Leaders

Atlassian Community Events