Automate Jira — Change your life.

Automation can be a powerful tool to leverage within a scrum team. Atlassian’s Jira automation can be used in a myriad of ways to keep things organized and reduce the time-cost of manually making associations or status changes within the Jira.

This is a link to Atlassian’s documentation on automation: https://www.atlassian.com/software/jira/guides/expand-jira/automation

Let’s take a look at three common automation types that can be incredibly useful to a team:

1. Updating the Fix Version (Release Version) of tickets linked to an Epic

Epics are deemed the highest in the hierarchy chain for Jira. In many cases, teams will associate Epics to a correlating version (or versions). Enabling an automated rule to update all “children” tickets which are linked to a given Epic, via the Epic Link field, is a major time saver! This type of automation is also a critical way of ensuring tickets don’t get lost in the shuffle.

Rather than passing off the administrative responsibilities of associating epics to other ticket types throughout the course of a release; a reduction in cost can be realized by enforcing this type of automation.

2. Setting the Resolution Status of a Ticket

Another handy automation to configure is to have the “resolution” of a ticket marked to a specified status upon completion. This can assist at completion of a specific group of tickets (such as a release) to ensure that items in a given state are associated with a correlating resolution status.

In the example to the left, items moved to the Done or Accepted state (for a group of workflows) will have the resolution field set to a given/defined status. This can be repeated, for other workflow-end statuses as desired.

3. Set the “Summary” and “Epic Name” fields as the same

When it pertains to an epic, the Summary and Epic Name fields are not the same — and in many cases are both required by default. This can lead to issues when querying by one or the other.

For example: If I created a new epic ticket type, as part of a large project, with the Summary of: “Pittsburgh Steelers” & then typed the Epic Name as “Pitsburgh Steelers”, one could have a very unpleasant time trying to find the epic by querying the text — Epics are displayed using the name, and in this case, the name and Summary don’t match.

The automation example to the left shows how to remedy the issue of a mismatched summary and epic name.

4. Set the start date to when development begins

The example to the left is a blanket automation, affecting all issues of any project specified in its details. In this case, any ticket moved to a development stage has the Start date field cleared (assuming there may ave been something populating the field before if the item had been paused) Then the Start date field is re-populated using the following Jira smart value for the date of development starting in the automation: {{now.plusDays(0)}}

This automation is particularly useful for observe statuses/goals (i.e. on the Jira “Plans” Gantt charts)

5. Set the due date to the end of the active sprint

While there are many other uses for the automation feature within Jira, one last example to consider, specific to teams who are “sprinting” or using a scrum board, is where the due date of an issue can be set to the end of an active sprint using the following Jira smart value in the automation: {{issue.Sprint.endDate.jiraDate}}

This means that the issue that was allocated, or pulled-in, to an active sprint should be technically deemed due at the end of that sprint (as part of the sprint’s work commitment).

This field can be reset, or left as the sprints end date, if it doesn’t get completed in the sprint it was initially part of.

Like the start date automation above, this automation is particularly useful for observe statuses/goals (i.e. on the Jira “Plans” Gantt charts); as well as to review missed sprint commitments.

How to Build a Race Car… or a really good Agile Program

Building a great agile program is hard and an ever-evolving activity. It’s complex and requires system-level thinking with an intuitive understanding of engineering tradeoffs, bottlenecks, and flow dynamics. Much like a race car driver, one cannot expect a driver to understand and be consciously aware of every detail happening in his car while he is racing down the track.

An interconnected system has to be in place allowing the driver to navigate the car given a few specific levers and controls. Following this analogy of building a race car, these are some of the steps we took to ensure the continued agility of our program following the onset of the COVID-19 pandemic.

Step 1: Define Workshop Location

“Remote-first means working remote is the default. It means making sure your remote employees are as much a part of the team as those in the office.” — Stack Overflow

Technology previously integrated into futuristic-feeling race cars has become commonplace in most modern vehicles. For example Disc brakes, carbon fiber, push-to-start, etc.

In the same way, the technology, processes, and innovation used by truly effective teams will eventually become commonplace. It is important to identify areas of change and best practices so that they can be appropriately adopted.

Many teams, especially those in the technology development fields, previously took advantage of at least some sort of remote work & access capabilities. However, in 2020 (due to a global pandemic), the unexpected happened. Many teams were faced with the task of shifting their mindset from co-located teams to fully remote teams. Inevitable challenges around communication/cohesion, system access, and scaling became the business concerns du jour.

The important thing is to realize that an effective agile team can be built anywhere. Just like a car can have its parts manufactured in different locations across the world, a modern team (or group of teams) can still operate in a distributed/remote manner. While the pandemic has been a truly horrific occurrence, it has also been a catalyst that has created a necessary reaction — forcing many teams to embrace a remote-first mindset. Some interesting takes on this shift have been expressed in the following articles:

“What the Cloud was to 2008, the Distributed Organization is to 2020.” — TechCrunch “Our Economy Was Just Blasted Years Into the Future” — Medium

Now that organizations have had their teams’ “workshop” locations changed, it is important to organize the “workshop” tools in a way that promotes efficiency. These tools will be used to build out a chassis, which will support the entirety of a team and/or program.

A couple of key areas of consideration while shifting to a remote-first mindset:

• Define remote work expectations

• Increase & standardize communication channels

• Continuously review the benefits & pitfalls of current activities

Step 2: Basic Chassis Framework

“A chassis is the load-bearing framework of an artificial object, which structurally supports the object in its construction and function.” — Wikipedia

Building and implementing a team chassis revolves around the standardized use of tools and the implementation of events. Decisions and best practice standards should be set for a team, program, or group — with the expectation that the tools will be used in varying ways for unique teams and situations.

Essentially, the team chassis is the process framework that a team uses to deliver software. Regardless of standards or terminology used (i.e. SAFe, DAD, Scrum, XP), a team should establish explicit norms around their unique way of working.

For illustration: Nearly all cars use the same core elements, such as wheels, engine, braking system; and are also limited to the same laws of physics. Similarly, teams within a program (or even more generally) should operate using similar core elements, including a framework, KPIs, defined roles, etc. However, how these items are configured, used, managed, and reviewed can be unique to a team or program.

A couple of key areas of consideration for building a team chassis are:

• Implementation of standing sessions for routine ceremonies

• Standard recurring program-wide event calendar(s)

• Designated event facilitators

Step 3: Install the Engine

Similarly, to the build of a team “chassis”, there are norms and standardized frameworks which may govern individual teams. However, a team (or group of teams) should be able to define, refine, and use varying components within those constraints.

A real-world example of this variance is the comparison between the hybrid LaFerrari and the fully electric McLaren P1. Both are supercars, both have core elements of a car, both require manual operation, and both go VERY fast. For all intents and purposes, these cars have very similar output specs. However, the differences between car engines are intriguing.

• The LaFerrari uses a 6.3 L F140FE V12 (gas) engine & 1 electric motor and KERS engine (963 PS; 950 hp)

• The McLaren P1 uses a McLaren E-Motor engine (916 PS; 903 hp)

While the larger organization or program standardizes core expectations & preferred framework, teams should address needs through a focus on value. Being value-driven means different things to different teams. However, all teams should work toward producing a useful output or something that delivers value to the overall project/effort (similar to the production of components for a car or an engine).

A couple of key areas of consideration for building a value-driven team:

• Align teams around the end-user with User Stories

• Ensuring sprint/cadence reviews are focused on value to end-users

• Make explicit the role of component teams

Step 4: Bodywork

Focus on bodywork is when a team ensures their work is following an expected or engineered outcome.

For example, a car manufacturer must ensure that the vehicle that they are producing meets the specific standards governing things like the engine and the body shape/size. Similarly, it is important for a team, or group of teams, to understand different areas affecting a given project/effort.

In certain cases, teams may be asked to build (or design) a product that possesses certain qualities or characteristics. In other cases, teams may be asked to build (or design) a product that utilizes external teams’ components. The importance of cross-team collaboration and the configuration of ARTs (Agile Release Trains) becomes increasingly important to be aware of as teams and products mature.

A useful tool to ensure that projects are on-track, and align with the efforts of contributing entities, is a roadmap. Roadmaps can assist in the visualization of progress or events, as well as help teams juxtapose their throughput compared to the proposed timeline.

Step 5: Final Touches

Just like the paint, decals, and tinting added to a finished car, the final touches to put on a highly effective team are also important. Final touches can help define the car or team, call out the brand, and offer a guide to what was done (as well as what could change over time).

In the context of a team, final touches may include things like:

• A program-wide framework handbook covering prescribed norms and expectations

• The introduction of self-service tools eliminating bottlenecks and single points of failure

Conclusion

Building a world-class race car is difficult and an ever-evolving activity; just like building a great agile program. Software is complicated; how much more the effort to rigorously predict its delivery. The complexities involving defining and standardizing the tools, processes, frameworks, and constraints are vast; it’s even harder as human beings are involved.

The intricacies of working with associated groups, and within the bounds of stakeholder expectations and timelines are tough. However, the ability to adapt and seek value at the team level will both help yield quality products and position the program for success.

This is why the job is never done. The greatest requirement of all, that has been covered, is the need to be flexible and always learning, changing, and evolving with the needs of the program and the marketplace.

*Images from Google Image Search