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.

What is the Role of the Project Manager on an Agile Project?

The most common question I get asked related to roles on agile teams is around what becomes of the traditional role of the project manager or the business analyst.

The question comes up because agile projects have only three roles: the Scrum Master, the product owner and the development team member.

In this post, I will focus on the project manager role and its evolution in relation to agile projects. 

The Project Manager: How Do You Fit into an Agile Team?

As teams began to adopt and transition to an agile software development environment, and as it became more popular and mainstream, the Project Management Institute (PMI), Project Management Association of Canada (PMAC) and other organizations around the world created the agile project manager role and introduced a career path for professionals transitioning to agile projects.

On some agile teams, the agile project manager is referred to as a Scrum Master. If you've ever wondered how different the roles are of a Scrum Master and agile project manager to the traditional project manager role, let's look at that now.

Authority: The traditional project manager role moves from a command-and-control, hierarchical position to a servant-leader or facilitator position. This is the essential role of the Scrum Master.

Requirements: The responsibility of ensuring the requirements are defined and providing direction for the product and services being delivered move from the project manager to the product owner. The product owner assumes the responsibility for ensuring the requirements are defined, prioritized and ready for the team. This is achieved iteratively, through just-in-time planning and progressive elaboration of requirements. Work Assignments: Assigning work and getting the status of the work completed moves from the project manager to the team members. The rationale behind this is that the agile team is a self-organized group of highly skilled professionals, accountable for the work they commit to in a sprint. The team takes ownership and accountability for meeting the project and team goals.

Managing Stakeholder Expectations: Providing the project status to stakeholders and sponsors moves from the project manager to the product owner, since it is the product owner who provides direction and leadership to the team, so that they can build the right thing and deliver business value based on priority and ROI.

Leadership and Support: The Scrum Master serves the product owner and the team so that they are better able to do their jobs by assisting them, facilitating creativity and fostering empowerment. The goal is to allow the team to self-organize and become a mature high-performing team. This is a change to a servant-leadership model.

Removes Impediments: If the agile development team is unable to resolve issues within the team, for example external dependencies and challenges that are out of the team’s immediate control, the Scrum Master helps remove obstacles and support the team.

To be successful in this transformation, the project manager needs to take on the role of a Scrum Master to become the champion of the Scrum process and facilitate the team’s adoption of Scrum with the understanding that they have no authority over the Scrum team. If this is a role you are considering, you will need to not only adapt and transition your skills, but also move towards an agile culture that embraces agile values. 

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: Not Just for Software Developers

“Let’s create a backlog for all the things you want to do,” I tell my friend, Joe, trying to convince him to give Scrum a try in helping to manage his ever-growing personal to-do list. “Then we’ll pick the highest priority things and you can focus on those for the next two weeks.”

At the end of those two weeks, Joe had started on a bunch of things, but hadn’t finished much. “I think your ‘stories’ need to be smaller and you need to limit your WIP,” I advise. “Finish some of these before you start on anything new.”

After breaking down some of his bigger stories into more manageable chunks, the next two weeks showed much more progress – and some of the projects that had been on his to-do list for months were finally done! He was an agile convert!

Agile, No Matter What the Situation

There’s something about checking off an item as complete that really gets your endorphins flowing. That was a comment from a student in an Agile Boot Camp I recently taught for a bunch of engineers that were not software developers.

At first, they were very skeptical about using agile, feeling like the concepts really wouldn’t apply (because in their field, they needed to know the entire design up front).

However, the more I described various techniques for creating smaller stories and continually checking in for feedback, the more head nods I got from the class that showed that they could see advantages of working in a more agile manner.

There are certain concepts, such as working collaboratively with customers, breaking tasks up into manageable pieces and continually “inspecting and adapting” that make sense no matter what domain you work in.

I recently wrote an article about personal Scrum giving examples of ways Scrum is being used outside of software development and was especially impressed with the creative use of Scrum in wedding planning by Hannah Kane and Julia Smith in their business venture, Scrum Your Wedding.

The article I wrote generated comments including a reference to the book, "Agile Kids," which promotes the use of agile techniques to empower kids to be in control of their tasks while still respecting parental authority.

The Tools to Manage Anything

Agile concepts and techniques are proven project management and leadership practices that work well both in business and in personal life, regardless of your profession.

You don’t have to be a software developer or techie to jump on the bandwagon. Start by learning some of the terminology and concepts, and then if you want to get some experience, try using the concepts to manage your personal to-do list.

Elicit a friend and work together on some of the tasks. Spend some time after each iteration to host a retrospective so you can “inspect and adapt.”

Mike Cohn describes how he uses Scrum in his personal life using tools like Things and Asana. I’ve used Trello, a free, easy tool that provides a task board that will help you visualize your workflow.

Don’t get too caught up in tools if you’re new to agile, though. Simply using a pen and paper or even notecards or sticky notes is fine and even encouraged in agile circles.

Undoubtedly, as agile techniques continue to become trendy in everyday life, people will start to refer to their “backlog” or suggest they should “time box” an activity or “limit their WIP.” So, why not get ahead of the game?

Do you use agile techniques in your personal life or to manage your own to-do list? What are creative ways you’ve seen agile used outside of software development?

Agile Transformation: Tips for Organizational Change

Jason Little describes his career as helping organizations "discover more effective practices for managing work and people." He is the author of the book, "Lean Change Management: Innovative Practices for Managing Organizational Change," a speaker, agile coach, Certified Scrum Professional, ScrumMaster and Scrum Product Owner. 

In this interview, Jason reveals what to watch for when trying to implement agile into an organization -- especially in larger companies that value control and stability. Here, we'll dive into the concepts featured in his course on Front Row Agile: "Agile Transformation: Four Steps to Organizational Change." 

In your course at Front Row Agile, you talk about the idea that understanding your organization’s culture is a good start, but it may not be a good idea to intentionally try and change it. Why is that?

Jason: Despite the agile community’s consistent message that agile isn’t a quick fix, it’s still perceived as being one. The pace of change, disruption and innovation is constantly increasing, and agile isn’t going to undo years of cultural baggage and organizational debt in a short time period.

I mention it’s a good idea to understand what your culture is because it’s important to pick an approach that is more likely to work. That means in a “control” culture that values structure and stability, you may want to start with considering agile to be a new process. 

What I mean by that is approaching an agile transformation in this type of environment by leading with the agile values and principles might be perceived as “fluffy,” and it may turn people off. 

In this environment, people might need a bridge built between how their processes work today and what they might look like tomorrow. For example, larger organizations I work with have more governance in place so developing an “agile governance process” can be a good short-term strategy for people to figure out how to move forward. 

After they’ve seen how what they do works in an agile environment, then more focus on agile values and principles might be a good approach. 

You teach different options for how organizations can learn about what agile means before they get started. Can you elaborate on that?

Jason: Back in 2007 when I started with agile, there weren’t nearly as many options as there are today for learning about agile methods. I still see organizations using only training and certification as a way to learn about agile, which is one of many ways to get educated about agile.

The agile community has grown substantially since 2012, and there are numerous conferences, meetings and virtual learning opportunities.

One of my favorite education tools is to send people to agile coach camps of which there are many around the world. That is a great way to connect people in the organization to experienced agile coaches that they can learn from.

You stress the importance of retrospecting often in your course. How can larger organizations use this technique at scale?

Jason: I recommend conducting retrospectives at the team, management and organizational layer; this helps get people focused and aligned around the purpose behind transforming to agile in the first place.

I recently used that technique with an enterprise client. Their team wanted to know the answer to one question: After a year, do we want to keep going with agile?

I coached the internal coaching team lead on how to do a large-scale retrospective for 30+ teams, management and executives. The short version of the story is that the answer to the question was yes. Even with all the problems and pain, they wanted to keep going.

The interesting part of that exercise was how it was executed. I worked with the internal coaching team lead on how to do the technique, and she then coached the existing Scrum Masters and Kanban team leads to do that exercise with their teams. 

This way, there was no single bottleneck. We took full advantage of a network of people, and then the coaching team lead took all the data from the teams and compared it with the data from the manager and director retrospectives.

She found it to be a great deal of work, but well worth it in order to see where staff, management and executives were aligned or misaligned.

“Scale” often scares people, but it’s not difficult to do large-scale retrospectives. It simply takes a little more planning and coordination. 

Organizations often lose sight of how their journey towards agile is going because they get too caught up in the day-to-day challenges and organizational problems agile is exposing. Taking the time to stop and reflect shows a serious commitment by leadership to helping make agile work.

For more info from Jason or to get in touch, head on over to his website.