fbpx
 

AgileJiraConfiguring Jira For Maximum Agility: A DoD Case Study Ariel Partners

July 15, 2022by Craeg Strong

Want the Full PDF version of the whitepaper? Enter your information below to get a copy.

[wpforms id=”5589″ title=”false”]

1.0 Abstract

This paper illustrates the Jira configurations, processes, tips, and tricks we developed while supporting a large Department of Defense customer that was migrating to Atlassian Jira to support their adoption of Agile and DevSecOps principles and practices.  Rather than providing an Agile transformation how-to recipe, we will describe some of the configurations, templates, processes, and systems we have helped our DoD client establish and the benefits that were observed.  We will cover tips and tricks we used to help make the Jira experience amazing for teams of any variety. We will cover several scenarios such as supporting a large heterogeneous organization, scaling up to larger efforts, how to supercharge daily standups, enforcing governance, and finding better ways of doing backlog refinement.  

Our Jira consulting practice focuses on properly configuring the tool and leveraging the extensive third-party ecosystem of plugins to best support the organization’s emerging Agile processes.  Rather than simply setting up Jira for the DoD and calling it a day, we focused on education, ensuring that the customer was able to configure and maintain their Atlassian products over the long term.  This avoids a common pitfall we have seen for organizations that are new to Jira.  A poorly tuned Jira is a daily struggle for Agile teams.  Inconsistencies in Jira usage and configurations produce unreliable data that limit an organization’s ability to properly manage Agile projects from the team level to the executive level.  Lacking an appropriate level of investment and understanding, Jira can become little more than an expensive task tracking tool, rather than something that can help catalyze improvements and drive organizational change.  In order to derive the maximum possible benefit from their investment in Atlassian products, organizations must appreciate the complexity and sophistication of these tools and assign an appropriate level of investment – both initial and on an ongoing basis.  This involves three main steps:

  1. design a set of initial templates, taxonomies, configurations, and reporting metrics,
  2. establish roles and responsibilities for Jira administration,
  3. and initiate a process of continuous improvement that welcomes configuration changes rather than discourages them.

This paper describes how we performed these tasks for our DoD customer, leaving them with a well-tuned Jira instance, leading to happier, more productive teams, and much more accurate information to make business decisions.

2.0 Background

A directorate within the Department of Defense is undergoing an ambitious transformation effort to roll out Agile methods and tools across their entire operation, in an effort to improve quality and decrease time to market (“faster, better, cheaper”).  The directorate is new to Agile and Jira, and among their personnel there is a wide range of experience levels with both.  The mission of this DoD directorate is to provide logistical support via software systems that manage information such as maintenance, materiel, supplies, suppliers, and readiness at bases and forward locations across the globe.  The directorate is distributed across a number of physical locations and characterized by large, complex bespoke software applications that are integrated with those of several other branches of the armed forces, financial institutions, and both civilian and military Agencies.   The directorate spends more than $1B annually on software operations, maintenance, and development.  It has a staff of 2,000 personnel distributed across four US states and supports nearly 150 programs for tens of thousands of stakeholders within more than 80 large organizations.

The complexity, diversity, and age of the software systems, the large size of the maintenance teams, the number of dependencies and integrations, and the need for transparency and traceability all the way up to the senior leadership level, all served to make the prospect of establishing Agile practices extremely daunting.  Agile methods were initially intended for small, co-located teams of a dozen or less, developing brand new software from scratch, with direct involvement and constant communication with their customers.  When Jira was originally designed for software development, it was  intended to operate in this kind of small-scale Agile environment, utilizing a plugin called Green Hopper.  Most Agile coaches and practitioners operate in this sort of environment and relatively few have experience applying Agile methods outside of this comfort zone.  

Fortunately, over the last five years, Atlassian Jira has grown exponentially more capable, both through the introduction of new features as well as the availability of hundreds of high-quality plugins available through the third party Atlassian Marketplace.  In addition, recent years have witnessed the development of new Agile frameworks, additional tools and practices, and extensions to existing tools and methods designed to be applied at scale and outside of pure IT settings.  Ariel leveraged these new developments to help the directorate create a set of configurations optimized for both flexibility and governance, establish Agile practices supported by matching Jira workflows, and train practitioners and administrators to maintain and continuously improve Jira over time.

3.0 Approach

3.1 Jira’s Configuration Philosophy

One of the core features of Jira is its configurability.  It was designed and built from the ground up to support the needs of large diverse organizations.   The design of Jira projects and Agile boards make it straightforward to support multiple usages, including scaling up a single project across multiple teams, using separate discovery and delivery boards, value stream coordination boards (usually multi-project), and strategy-level boards.

The central metaphors for Jira are the project and the Agile board.  A Jira project is a repository for issues, each of which represent a unit of work (e.g., story, claim, loan, initiative, investment, order).  An Agile board is simply a visual view of a workflow for multiple issues mapped onto a canvas of vertical columns and horizontal swim lanes.  Jira’s Agile boards can support Kanban or Scrum teams, and there is a one-to-one, one-to-many, or many-to-one relationship between projects and Agile boards.  The most typical relationship is one-to-one: where each project has one main Jira board, but multi-board configurations are not uncommon.  

Rather than storing configurations in a single flat space, Jira configurations are split out into multiple schemas.  Projects are configured via associations with these schemas.  This enables projects to share some, all, or none of their configurations with other projects.

Figure 1: Jira splits configurations into groupings called schemes to support granular reuse

By configuring multiple schemes and mapping an organization’s projects to them, a single instance of Jira can support projects with widely different workflows, work item types, and permissions.

Through the use of naming conventions, we can create templates for each of the major project types needed. The main objective is to adopt an initial set of schemes that provide maximal reuse, enabling aggregation of metrics across multiple projects, while still providing as much flexibility as possible.  

3.2 Project Templates

We configured several project templates for the DoD directorate, including Scrum, Scrumban, Kanban, Scaled Scrum, and Legacy O&M, illustrated below:

Figure 2: Ariel configured a set of project templates to support our DoD customer’s diverse project requirements

The Scrum template provides a standard task board with TODO, DOING, and DONE columns.  The team creates sub-tasks and performs story point estimation during sprint planning.  The Agile board tracks the status of each sub-task.  This template cleans up the standard Jira configuration by hiding inappropriate fields and adding a Severity field for bugs.  Non team members do not have permission to do potentially destructive things like creating or closing a Sprint.

The Scrumban and Kanban templates enable teams to do all of their planning at the Story level and capture more workflow steps in the Kanban board (such as “in review” and “ready for acceptance”).  Teams can use checklists to capture details about each Story, and the progress of the checklist items is displayed on the front of the card.  Scrumban uses this Kanban-like approach but adds 2-week sprints, while the Kanban template uses a continuous flow.   This template adds custom fields including “class of service.”

The Scaled template leverages the Scrumban configurations and by convention includes a separate Agile board for each team.  A “Component” is defined for each team, so that assigning an issue to a team simply involves assigning the appropriate Component.  This means we can have our cake and eat it too—there is a single shared backlog for the entire product encompassing all teams, but each team can still easily focus on their own issues via a simple board filter on the Component field.

Legacy O&M teams have special workflow steps, permissions, fields, and screens to handle the extra efforts required to complete items within the legacy environment.

Because the templates support reuse through schemes, we did not have to create separate configurations for every single combination and permutation:

Figure 3: We created reusable project templates from combinations of schemes, facilitating both maintenance and evolution

In our training classes, we emphasized that Jira’s configuration schemes are not merely conducive to creating reusable templates, they also greatly facilitate change management.   One of the fundamental Agile principles is to embrace change.  Agile teams are encouraged to make regular experiments to identify process improvements.  Used correctly, Jira’s schema-based configuration design virtually eliminates the risk of change, and greatly reduces the cost of deploying and managing changes.  Jira’s support for evolutionary change is so pervasive and fundamental, that we go so far as to say: No Jira administrator should ever discourage change.  Making changes, applying them selectively, and rolling them back or forward is trivial in Jira.  A separate testing Jira instance is rarely needed.   The below illustrates a typical change management process:

Figure 4: Jira configuration schemes facilitate change management obviating the need for testing environments or complex scripting

3.3 Administration and Training

While Jira is fundamentally architected for change, none of this will work well without properly trained administrators.  We recommended treating Jira like any other sophisticated enterprise tool, with a sufficiently resourced centralized administration team.  However, we also recommended that each team designate a Jira project administrator to handle team-specific administrative duties.  The team’s project administrator role is not a full-time role, and we suggested that the role should be rotated across team members in order to spread knowledge throughout the team.  Some Jira project administrators may ultimately express a desire to become full-fledged Jira administrators, and this should be encouraged as a career path.  The below illustrates our recommended set of Jira administrative roles and responsibilities.  Perhaps most importantly, Jira administrator roles should require Agile training and certification, in addition to expert Jira knowledge.   

Figure 5: Every Agile team should designate a part-time Jira project administrator to reduce the burden on the centralized administrative resources and increase agility

Throughout the course of our DoD contract, nearly a third of all students chose to continue their training past fundamentals and to dive into administrative topics.  In our opinion, this bodes well for the success of the directorate’s transformation.  In our experience, organizations often err on the side of too little training rather than too much.  By supplementing an initial set of Instructor-led training sessions with other types of training we can get better outcomes and a much better overall return on training investment.  For example:

  1. Self-service on-demand training videos
  2. Remote and in-person Jira coach “office hours”
  3. Seminars / brown-bag lunch sessions on tips and tricks, improvements
  4. Sample Jira projects for teams to try out templates and improvements

3.4 Supercharging Standups

Now let’s jump over to the configuration of an Agile board in Jira.  A typical scrum team is going to meet in front of the board every day for our standup—so we want the board to be as informative as possible.  In our experience, Jira users rarely take full advantage of Quick Filters.  By adding the Script Runner and Color Cards third party plugins, we are able to colorize the board and enable more sophisticated filter buttons, as in the example below:

Figure 6: Selected Jira plugins and thoughtfully configured quick filters greatly increase the utility of Jira’s Agile board, making daily standups more productive

In the above example, User stories show up in green, bugs in red, and blocked issues in yellow.  The quick filters help us pinpoint issues we should be focusing on, without having to go to any separate reports.  For example:  

  • we can see any issues that are blocked,
  • we can see issues that are blocking other issues,   
  • we can check to see who the busiest person on the team is—they are probably going to be a bottleneck for us, 
  • we can check which cards moved since yesterday,
  • stale cards haven’t been touched in a couple days,
  • slow cards have been in progress for more than a week—we should aim to complete each story within a week,
  • has anything been carried from a previous sprint?  We better make sure we get those done,
  • And finally, was anything added after the start of the sprint?  That is a no-no.

The power of Jira’s JQL query language, combined with the Script Runner plugin makes the possibilities virtually limitless.

3.5 Customizing Workflows: Balancing Governance and Flexibility

Jira enables us to set up our workflows to get just the right combination of enforcement and flexibility.  For the DoD directorate, it was important to capture important actions such as approvals in the audit trail.  Fortunately, Jira enables us to set up very flexible workflows that enable users to immediately recover from fat-fingering and other mistakes, while enforcing business rules such as “nothing can be closed normally unless it is approved first.” We demonstrated how workflows could be constructed using global transitions for most status values, and defined transitions into and out of the Approved status.  We defined a Jira transition screen to capture the specific user who granted the approval so this information would be captured properly in the audit trail.  This is because the approver may not be the same person as the one recording the approval in the tool.  The below workflow illustrates the completed workflow design:

Figure 7: We customized Jira workflows to enforce strict governance where needed, while providing ultimate flexibility everywhere else

3.6 Discovery Board

In our experience, many Scrum teams struggle with the backlog refinement process. Development teams may view backlog refinement as a tedious chore to be minimized.  Teams may struggle to secure time from customers and/or subject matter experts to get their questions answered.  Refinement meetings may spend time discussing items that many of the attendees feel are not relevant to them, or that they feel they lack the understanding to contribute to.  Backlog refinement meetings may struggle from a lack of good facilitation, leading to a few highly vocal participants dominating the conversation while most remain silent.  The result of all of these difficulties is the same—the team performs sprint planning with backlog items that are not well defined, with a significant number of open questions, questionable feasibility, and few or no acceptance criteria.  Low maturity teams may not recognize these problems immediately, with the result that these problems often manifest themselves downstream when defect counts skyrocket.  Fortunately, Scrum teams can turn to Kanban to help solve this problem, and Jira provides excellent support for this.

Jira enables us to create a separate Agile board to help improve our backlog refinement.  This upstream process is often called “discovery Kanban” or “customer Kanban.”  The discovery board codifies a workflow process for backlog refinement that occurs “out of band” from the normal Scrum delivery work.  Some Scrum teams attempt to run this as a parallel Sprint that is one to two Sprints ahead of Delivery (thus ensuring that backlog items are refined just in time), while others simply use Kanban’s minimum WIP limits as warning indicators to drive the process (e.g., ”When we get down to only two soup cans, it is time to order more soup”).  Both the Discovery and the regular Delivery Agile board are available from the Jira “board” menu, and the team can refer to either, as needed.

Below is an example of a Discovery board we set up for our customer.  While we often use card colors to signify work item type in a Delivery board (differentiating user stories from bugs, documents, and tasks, for example), we use color here to differentiate whether or not an Epic has been decomposed into child tasks and stories.  In the example below, Epics that contain child cards are orange, while Epics lacking child cards are displayed in green.  

Figure 8: We configured a separate Discovery board within Jira to guide and improve the backlog refinement process, leading to improved quality and smoother flow

3.7 Handling Dependencies

One of the most difficult challenges large teams face is how to handle dependencies.  Teams may discover dependencies late in the process, leading to the need to shift gears and interrupt work.  Teams may have dependencies on separate teams or even external stakeholders, leading to delays and conflicting priorities.   Fortunately, we can leverage Jira’s ability to define multiple boards that display different views onto the same underlying data to create an integration board.

For our DoD customer, we created a coordination-level board for a large-scale effort having four teams working on a single product.  The integration board displayed all of the work being done during a sprint by all four teams, grouped by Epic.  For this board, we colored the cards according to the team doing the work.   In this way, it is immediately obvious when two or more teams are working within the same Epic, as in the case of the “Home Page” Epic in the example below.   This board also enables teams to create “reservations,” or slots for upcoming user stories that ensure that another team will reserve capacity in an upcoming sprint for them, thus preventing a dependency from becoming a bottleneck:

Figure 9: Coordination-level boards display work for multiple teams collaborating on a single product. Each team has their own color, making it trivial to see places where known or suspected dependencies exist, and coordination is needed

3.8 Scaling up

By default, Jira only supports a simple hierarchy of work items, namely Epics and child user stories.  While this hierarchy works well for traditional, small Agile teams, it is insufficient for the larger efforts that our DoD customer needed to support.  Many reports and workflows depend on Jira’s Epic Story structure, so rather than change that, we simply extend it by adding an additional set of work items linked to each other via the “Implements / is implemented by” link type.

 Using the Structure plugin, we can visualize these higher-level work items as a hierarchical backlog, thereby facilitating our Agile planning processes.  We can also use the coordination-level boards described in section 3.7 to track higher-level work items like Functions and Capabilities as they progress through their own workflow.

Figure 10: We extended Jira’s built-in issue types to support Agile at scale
Figure 11: The structure plugin enables us to easily visualize work items above the Epic level to better support large-scale Agile initiatives

4.0 Ariel Jira Jumpstart

Ariel has a wide range of offerings to help our customers get started with Agile or turbo-charge their Agile implementation.  Our Jira offerings include a “Jira Jumpstart,” which bundles a set of Atlassian product licenses with configuration, training, and coaching to get an organization up and running immediately.

Figure 12: Ariel provides comprehensive Atlassian coaching, configuration, training, and consulting support

5.0 About Ariel

Ariel is an IT Services, Training, and Management Consulting firm with special expertise in Atlassian products, Enterprise Architecture, Big Data, DevSecOps, cloud-based microservices, web and mobile app development, AI/ML, Agile, and Human Centered Design. We are an NWBOC-Certified Woman Owned Small Business (WOSB) founded in 2010. We provide IT services to Federal Agencies and Commercial clients to help them transform their systems and, more importantly, their method of delivery. Our staff includes experts with Professional Certifications for Atlassian products, AWS/Azure Cloud, Agile, Scrum, Kanban, SAFe, LeSS, ITIL, Cyber Security, and Project Management.  We currently hold a Top-Secret Facility Clearance. Ariel Partners is appraised at maturity level three by CMMI for both Development and Services and is certified ISO 9001:2015, ISO 20000:2018, and ISO 27000:2013 compliant.  Ariel is an Atlassian Silver Partner, Certified Training Partner & Certified Government Partner, and is a certified Scaled Agile, ICAgile, Flight Levels, and Kanban University training facility. 

Figure 13: Ariel provides critical support to a diverse set of large Agencies and institutions. Ariel is 100% committed to helping our customers achieve their mission objectives

Ariel has deep experience executing large systems development and implementation projects for Federal agencies and other organizations including the FBI and NYC Department of Social Services.  Ariel has provided project management, business analysis, systems engineering, testing, and support services for system implementations up to $500M in size, spanning all 50 municipal Agencies in NYC, and for FBI programs used in all 50 states and in Interpol countries spanning the globe. We led the 2nd program at FBI to move from waterfall to Agile. We established a large-scale Agile governance and oversight framework for the Social Security Administration, assessing more than $500M of mission critical programs.  We have worked with the DOJ/FBI since 2003 on mission-oriented programs including NCIC and CODIS and have helped them institute major new programs and initiatives including Missing Persons, Rapid DNA, and NCIC Third Generation (N3G).  We have provided public training classes in Kanban, SAFe, Jira, and HCD since 2016.  

6.0 Jira Plugins Used

Our DoD customer used Jira Data Center.  Please note that some of the details described above differ for the Jira Cloud product.  The following Jira Data Center plugins were used:

Third Party App

Where used

1

Easy Agile User Story Maps

User story mapping

2

Actionable Agile Analytics

Actionable Agile Dashboard Report

Forecasting with Monte Carlo Simulation

3

eazyBI

Epic Progress Report

Cycle Time Per Story Point Set Report

4

Structure

All of the structures for scaling up:

Capabilities Structure (hierarchy w/ Capabilities)

DMAPS Structure

DMAPS Current Release Progress Structure (Showed dependencies as nested issues)

5

Automation for Jira

A resolved Bug closes linked Incidents

Automatic creation of sub-tasks

6

ScriptRunner

issueFunction JQL 

Blockers and Cycle Time scripted fields

7

Jira Suite Utilities (JSU)

Clear Field Post-function for Jira workflows

8

Card Colors

Ability to set the color of the entire card in Agile Boards

Craeg Strong

https://arielpartners.com/wp-content/uploads/2022/06/6.png
https://arielpartners.com/wp-content/uploads/2022/06/7.png
ISO 27001:2013
https://arielpartners.com/wp-content/uploads/2022/06/Atlassian-.png
https://arielpartners.com/wp-content/uploads/2022/06/9.png
https://arielpartners.com/wp-content/uploads/2022/06/10.png
https://arielpartners.com/wp-content/uploads/2022/06/11.png
https://arielpartners.com/wp-content/uploads/2022/06/12.png
https://arielpartners.com/wp-content/uploads/2022/06/13.png
https://arielpartners.com/wp-content/uploads/2022/06/14.png
https://arielpartners.com/wp-content/uploads/2022/06/15.png
https://arielpartners.com/wp-content/uploads/2022/06/18.png
https://arielpartners.com/wp-content/uploads/2022/06/17.png
https://arielpartners.com/wp-content/uploads/2022/06/1.png
https://arielpartners.com/wp-content/uploads/2022/06/2.png
https://arielpartners.com/wp-content/uploads/2022/06/3.png
https://arielpartners.com/wp-content/uploads/2022/06/4.png
https://arielpartners.com/wp-content/uploads/2022/06/Flight-Levels-Academy-Logo.png
Better Business Bureau Accreditation Ariel Partners
ITIL

Copyright 2022 Ariel Partners. All rights reserved.

Copyright 2020 Ariel Partners. All rights reserved.