How to Get JIRA and Agile to Play Nice

JIRA is an incredibly versatile tool. Agile is a proven philosophy with frameworks such as Scrum and Kanban helping teams manage their deliverables in an agile manner.

And yet, often when an organisation that is trying to be agile installs JIRA, it continues to have organisational challenges even months later. We hear statements such as “JIRA is useless” or “We used JIRA at our last place and it didn’t work.”

It’s not JIRA that’s at fault, however.

JIRA is just a tool. Try to put up a set of shelves with a kettle and you’re going to have problems.

Imagine you wanted to build a house. Some would say all you need are the tools. But without people, and people knowing the process of building the house, the house won’t get built.

People, Process, Tools

JIRA is just a tool; it’s how you use it that counts. Agile teams around the world are very successfully implementing Scrum or Kanban using physical cards on glass walls, or Post-It notes on whiteboards.

So what goes wrong when JIRA comes on the scene?

JIRA has two very effective use cases:

JIRA is a tool with a great UI and UX and can be a very effective digital Post-It note-type system JIRA is an incredibly powerful and customisable workflow engine that can be extended with lots of plugins.

And it goes wrong when these two use cases are mixed. 

Just as Scrum teams that use physical boards don’t have a person standing at the side, slapping people on the wrists when they move a sticky note from one column to the next, you also shouldn’t programme JIRA to do the same.

I’ve personally lead many agile programmes across a global organisation with out-of-the-box JIRA. Simply by teaching agile mindsets and Scrum, and leaning JIRA down, JIRA becomes an incredibly effective agile tool.

In Summary

Agile teaches us that it's about the people more than the tools. Agile Principle No. 5: “... trust [the people] to get the job done.” Agile Principle No. 10: “Simplicity - the art of maximizing work not done - is essential.”

JIRA is an incredibly powerful tool that can be used very effectively within agile teams; just because you can do it in JIRA, doesn't mean you should.

Keep the tool simple, keep the agile and lean values, principles and practices in mind, and JIRA can help you succeed with agile.

And that is how to get JIRA and agile to play nicely together.

Choosing a Retrospective Topic

I am a firm believer that the best retrospectives tend to be focused on a specific topic. Picking a theme and exploring what we currently think of it, and how we can improve in that area is almost always more productive for a team than having a general "how can we get better" conversation.

But how do you pick the topic? There are a few common ways for teams to do this ...

Ask The Team

Dedicate some time at the start of the retrospective to ask the team what they think the topic should be.

This could be as simple as giving each member of the team three sticky notes and asking them to write a topic on each, then gathering them all on the wall and looking to see if there is a clear majority winner such as "Dealing wiht bugs."

Perhaps there are some connections that make sense to tackle together.

Alternatively, we could ask each team member to write three feelings on sticky notes and do the same exercise of clustering them on the wall.

We might then end up having a retrospective on frustrattion. Why are we frustrated? How could we become less frustrated in our next sprint?

Ballot Box

Technically, this is still in the "ask the team" area, but there is a difference in that this is anonymous and in real time before the retrospective as opposed to at the start of the meeting.

With ballot box, a box is placed in the team area where team members can post cards with an idea for a retrospective topic as they occur during the sprint.

Then, at the start of the retrospective, we just empty the box and see what ideas we have, and make a decision.

ScrumMaster Choice

In my Scrum Mastery course, I explain that I believe ScrumMasters should always reserve the right to pick the topic that the team should explore in a retrospective.

An elephant in the room is what the English refer to as an obvious truth that is going unaddressed.


Sometimes the team may be too nervous to address the topic that really needs addressing and in those cases, the ScrumMaster should be prepared to help the team by highlighting it. 

As with anything, if the elephant is avoided for long enough, the team will develop coping mechanisms.

The problem is, these coping mechanisms don’t deal with the issue and actually make the problem even less likely to be removed because it doesn’t seem quite as necessary any more.

Great ScrumMasters courageously expose, and encourage teams to explore, the elephants in the room as soon as they notice them.

They don’t judge, but neither will they let their team tolerate and get dragged down by these problems.

Instead, they offer to lead an exploration. For example, the elephant in the room could be that one of the team members is getting into the office later and later.

The team is accommodating him by shifting the daily scrum and, sometimes, writing up their conversations, but this is leading to inefficient teamwork and resentment is growing in the team. 

Before this spirals into outright anger and rebellion, the team should confront and solve the problem.

A great ScrumMaster acts as a mirror for the team so she can reflect back what is happening in the team.

This is not a finger-pointing exercise but done with as much compassion as ruthlessness so that the team feels this is important enough to tackle but not defensive about admitting it needs tackling.

I recently blogged on compassionate ruthlessness here.

There is always room for good old ScrumMaster intuition. During the sprint, ScrumMasters are in a privileged position, able to see a lot of what is going on with a certain detachment.

They can -- and should -- be listening to what is being said and what is not being said, looking out for good examples of team dynamics and development as well as opportunities for further team growth.

Great ScrumMasters have no issue with starting the retrospective with a challenge based on their own observations, for example:

“This sprint, I have noticed a larger proportion of time than normal has been spent on fixing defects. I wonder if it would be a good idea to take some time out to explore why this might be and what we could do about it.”

Set The Team Up

Whichever method you choose, and you will definitely take the context of the situation into account, it's almost always a great idea to start the retrospective with a compelling goal that engages the team and helps set them up for success.

Most of the time, this goal will come from the team, but sometimes, it's OK for the ScrumMaster to step in and challenge the team with a compelling challenge to explore. 


Agile ShuHaRi

ShuHaRi, a term that originated from Japanese martial arts, is often used in agile classes to describe a learning model.

Shu represents the first stage when the student imitates techniques.

Ha represents the second stage when the student understands the underlying principles and theories, and feels comfortable making modifications, keeping the principles and theories in tact.

Ri represents the final and the most innovative stage. The student is creating his own approaches and adapting what he’s learned to his unique circumstances.

When I’m teaching students who are new to agile, I use a cooking analogy, both to describe ShuHaRi and to describe the difference between what it means to “be agile” versus following a methodology, such as Scrum.

I tell the class that agile is like cooking and Scrum is more like a recipe. Agile gives us the manifesto and the 12 principles, but does not provide a step-by-step “cookbook” approach to either project management or developing software.

When we are new cooks, we need to follow a recipe. This is the “Shu” stage of learning to cook.

As we become more familiar with different flavors, we reach the “Ha” stage, feeling comfortable modifying the ingredients to our taste.

Finally, as we become chefs (“Ri”), we create new recipes or maybe write a cookbook ourselves, striving to create a unique and innovative set of recipes or approach to cooking.

If we compare this to agile, when we are new, it’s best to use the more prescriptive approach to following a methodology, such as Scrum. In other words, we need to “follow the recipe” at this stage.

Though agile promotes adaptability and flexibility, when a team is new and still in the “Shu” stage of learning, they are probably better off starting with the recommended “best practices” provided by the experts.

Too many people feel that they will be more agile by not following a recipe or rule book, but that really depends on how experienced the team is.

If you have a bunch of people who are inexperienced cooks who throw a bunch of ingredients together without really understanding the concepts behind cooking, the chances are that your resulting dish is not going to taste that good.

Similarly, inexperienced agile practitioners who pick and choose different agile techniques to follow may end up with a methodology that doesn’t work too well.

It’s really better to at least start with that recipe. However, having the benefit of gathering feedback and constantly adapting and improving allows the team to develop the skills to move to that next learning stage.

Whether it’s cooking, music, art, software development or project management, when we are new, we start the learning process by imitating others.

Over time, we gain the skills to make modifications, and at the highest levels, we create something entirely new.

Should The Product Owner Attend The Retrospective?

One question I get asked a lot is:

Should the product owner attend the retrospective at the end of the sprint?

The word “should” makes this a multi-dimensional question, so first, I want to address a slightly different question.

Can the product owner attend the retrospective?

This one is easier to answer, because according to the Scrum Guide:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

Since the Scrum Guide also states that the Scrum team = product owner + Scrum Master + development team, we can deduce that (officially at least) the product owner is allowed to attend the retrospective.

Now whether they should attend is not as easy. Having worked with many many Scrum teams and seen many, many retrospectives, I have noticed two patterns:

The best Scrum teams tend to have their product owner attend their retrospectives The worst Scrum teams tend to have their product owner attend their retrospectives

What I have determined from these two patterns is that the product owner attending a retrospective tends to have a big impact on the development team in one way or another. In the positive examples, it is a very clear symbol of everyone acting as one team, working together collaboratively to improve the overall situation with true transparency and respect.

In the other cases, I see teams avoiding issues, scared to speak up and customers looking for individual SMART goals for improvement and targets for velocity growth.

Going back to the Scrum Guide, the Scrum Master is responsible for “removing impediments to the Development Team’s progress,” and if the product owner being present at the retrospective is proving to be an impediment to the team feeling comfortable and exploring their situation, reflecting upon it and identifying ways to improve their process, then you could argue that the Scrum Master should remove that impediment.

As a coach, the Scrum Master would most likely coach the product owner in the impact they are having on the team, and how that is ultimately affecting the results they are receiving from the development team. This is because, in an ideal world, having the product owner present at the retrospective has got to be better than not having them there.

As the Scrum Guide points out, the retrospective is for the Scrum team, and any decisions that are made in order to improve the Scrum team’s process will inevitably impact the product owner. Making decisions is an important part of our THEMED structure of facilitating retrospectives:

Topics to help everyone focus in on a specific area
Hooks to engage all attendees as soon as the meeting starts
Events of the last sprint or iteration using interactive exercises
Meanings behind the events
Else - exploring variations on the exercises or considering alternative perspectives or things they might be missing
Decisions they need to make as a team to move forward

You can find out more about this structure and get some ready-to-use templates for retrospectives in my newest course with agile coach Paul Goddard -- the "THEMED Retrospective Handbook" -- here.

How DEEP is your product backlog?

All good Scrum teams need a good product backlog, but how do we know if ours is up to the task?

“DEEP” is a handy acronym developed by Mike Cohn that describes the ideal attributes of a high-functioning product backlog. If you find yourself drowning in a huge list of stories, then DEEP is a great way to start digging your way back out. 

Let’s take a closer look at each of the criteria to get a feel for how it will work on our own backlogs.

Detailed Appropriately
We want the stories near the top of the backlog, which our team will be working on next, to be well defined enough that the team can be productive with them as soon as they pick them up.

A good indicator of this is that the stories near the top of the backlog are smaller and more fine-grained, but become progressively larger and less specific as we start to move down.

Each item on the backlog should be estimated ‒ even if it’s only a rough estimate. This helps us prioritize each story against the others and also helps us project completion dates for each batch of work.

But, since the stories at the top are better defined than those at the bottom, we accept that the estimates will become less precise as we move down the backlog.

The product backlog is not a fixed object. It is a living document that evolves over the course of the release. We should expect the items in the backlog to change priority, new ones to be added, and even some to be removed.  

As we progress through the release and learn more about the needs the product is trying to solve, the product backlog will evolve to reflect this knowledge.

Our product backlog is prioritized with the most important items at the top, and the least at the bottom. This ensures that the team is always ready to work on the most important item next. A good rule of thumb to help us know if our backlog is prioritized appropriately is to walk down the backlog and imagine that our product is suddenly shipped – including only those features above the line.

If we’re not happy with the features that were shipped or if there were other features that we wish had been included instead, then we need to re-prioritize our backlog.

Looking Through the Lens DEEP
DEEP is an incredibly powerful tool for helping us tune our product backlog and keeping it in shape. Much of its power lies in its simplicity; not only is it easy to remember, but also we can apply the criteria to our own backlogs in a surprisingly quick amount of time.

If you’d like to see DEEP in action, or learn more about how to create and maintain a great product backlog, check out my course, "Agile Release Planning," which is available now on Front Row Agile.

Creating Comfortable Workspaces for Agile Teams

Ilan Goldstein is an agile practitioner and thought leader based out of Australia, perhaps best known for his tips on "Scrum shortcuts," a compilation of ideas that became the basis for his published book: "Scrum Shortcuts Without Cutting Corners." 

Ilan talks a lot about the Scrum startup, and the elements that go into making Scrum adoption successful. At the foundation of this is team morale, and he believes that team dynamics and workspaces are the cornerstone for productivity in agile development.

In a field that often casts its professionals into lightless caves in order to toil away in solitude (often by the request of the developers themselves), Ilan argues this isn't always best for the Scrum team. We caught up with Ilan in this interview to hear more on his thoughts around creating a work environment that makes Scrum work better.

With new Scrum teams, how do you help shift the mindset from individual accomplishments or goals to doing what's best for the team?


Ilan: It really is incumbent on the business to communicate and reinforce what is truly important - the creation of quality, working products that delight customers.

Simply put, a product is not built by an individual, it is built by a team. As such, it needs to be appreciated that individual accomplishments are the building blocks that make up the overall team accomplishment; they are a means to an end. 

No doubt, the individual building blocks are still important but it is critical that they are all aligned and supporting one another to create something much bigger and more important then the blocks themselves.

You talk about the physical workspace impacting the Scrum team. Can you expand on that a little here?


Ilan: First, let me say that I couldn't agree more with the truism, "It's the small things that matter." You'd be surprised by how many retrospectives I've witnessed that have been dominated by concerns and complaints about the physical environment.

Whether it's a lack of meeting rooms, limited wall space or microwaves that were bought when Reagan was in office, these day-to-day annoyances can really drag on morale and lead to direct and indirect productivity loss. 

Some of the best environments I've seen haven't necessarily been slick, extravagant settings decked-out with multi-million dollar fittings complete with slippery slides and lava lamps. No, in fact, they've actually been rather economical and grungy; however, they got the basics right and in turn became super-productive yet really comfortable spaces. 

Now if I was to choose one key consistent element of the worst environments I've seen, I would say the least optimal environments are those that impose email as the primary method of communication. This imposition may be due to physical or cultural boundaries but irrespective, relying on an asynchronous and easily misinterpreted communication channel is not conducive to effective teamwork.

What are your tips for changing the way Scrum team members interact with one another if it's a less than friendly environment? 

Ilan: My solution to this problem is to avoid it in the first place. So how do you do this? Well, you hire the right people with the right attitude and you model the behavior that is expected.

I worry about trends in our industry where the focus is on hiring "rock stars" with a total focus and emphasis on technical brilliance as opposed to interpersonal brilliance. The latter brings out the best in others and will ultimately lead to happier and more productive teams.

For more from Ilan, check out his course on Front Row Agile: Scrum Shortcuts