Why I stopped using JIRA as a Scrum Master

Earlier in my Scrum Master career, I made some decisions that I realised were not in line with the true expectations of my role. So, I made changes – I stopped meddling with JIRA (and similar tools). Today, I focus on valuing people and interactions over rigid processes and tools. Let me show you why. Here is my story.?

Why did I become a Scrum Master??

I often joke that my preferred job title is “professional meddler”. I thrive in uncertainty; love learning and can’t resist getting involved. When I was a Business Analyst in my first Scrum team if something needed doing, I would always say yes. While others on the team carefully selected tasks aligned with their expertise, not me. I filled the gaps in the team, taking on tasks that others avoided or were not available for. The image of a cowboy taking on a bucking bull, minus the danger of impalement, feels quite appropriate here.?

My passion was rewarded with a promotion to Scrum Master and in time I learned how to efficiently serve all the team’s admin needs. My organization’s leaders congratulated me as I lived up to their definition of good leadership. I began to see myself as a great Scrum Master.?

And then I went on holiday...?

Maybe I am not as good as I thought?

I forget how long my holiday was, but enough time went by for admin tasks to pile up. With way too much enthusiasm I fixed the problems and then invested time in updating the documentation of all admin duties I could think of to prevent the pile up happening again. However, I could not shake the feeling that my actions were not enough.??

My leadership model was lacking something.?

Then I took a Scrum course. Best decision. I was lacking. A lot.?

My Scrum course taught me many lessons, though one stands out: "A good Scrum Master helps the team to be successful without them". Mind blown away. I was not a great Scrum Master.??

I realised that every time I took on a task for the team, I had been denying them the opportunity to learn to do it themselves and thus making them more dependent on me. My company was valuing the wrong behaviours: my leadership style was actively constraining team maturity!??

I realised that I was a bad Scrum Master. I needed to do better.?

?

I made a change - I let go of control (and JIRA)?

I was disappointed in myself at first, but I used that feeling to motivate myself to improve. I found some podcasts (links at the end) that exposed me to new ways of thinking. As I learned I began to recognise problems in my team that I had previously not recognised.??

I want to be honest at this point and make it clear that I did not have a formal plan or structure to support what I was doing. I did not have a clear vision or complete confidence in my actions. I just started. I knew I was an imposter, but I knew that only I could fix that. I had a support network, but I still felt lost. The steps I took and the value they delivered have become clearer with time.??

I started by announcing that I would no longer update tickets in our workflow tool (JIRA) on behalf of anyone else. I told the team that I was no longer accountable for the state of the JIRA board at the end of the sprint. Obvious problems occurred as a result, but these issues were not severe and mostly resulted in minor embarrassment. In a short time, team members stopped using me as their admin. The team started to really own their tasks from inception to completion.?

This first battle started a positive cycle for the team. As team members took more ownership: they became interested in the wider context; which led to possibilities for ownership; which led to them taking responsibilities from me; and the cycle began again. As the team changed so did my role – I was pushed away from team operations. With this push, the initial problems I fixed (gaps in the team, absences) began to re-emerge.?

??

I continue to step back?

The initial problems I saw in the team occurred because of how the team thought about and approached work. Tasks were selected based on prior experience and or skills. I experimented with different ideas to try to improve our approach, but my ideas were never really accepted by the team.?

Weirdly the problems I could see were not seen in the same way by the team, and our conversations at retrospective focused on completely different subjects.?

I decided to experiment with my approach to retrospectives and problem discovery (inspired by podcasts). We began to discover and discuss problems as a team. This included the problems I had seen but also problems I had not seen. What confused me was that the changes we made were not that different from those changes that I had tried to implement.??

Then I understood. I had forgotten my lesson.?

I had been breaking the lesson I was taught in my course. I had been presenting a solution and denying the team the possibility to learn about and manage the problem. I stole agency from the team and pushed ideas onto them that they were not ready to receive.??

I realized that my role is not to solve problems, but to create the conditions for the team to orientate towards those problems. Teams solve the problems they see, understand, and feel able to affect.??

?

Now for some magic - the team grows?

Changing how we approached work was a breakthrough for the team - it showed us that everything can be changed. Then began several months where every day was exciting - I never knew who was going to come up with something brilliant next. Every sprint, new small changes were occurring, and the culture of the team shifted.??

We broke cultural norms. Pushing past boundaries is an exciting sport. We smiled at the risks we took. Every giggle took us further along our journey.??

Our teams’ culture had started to prioritize learning.??

Our shift was reflected in the statistics. Every single metric had improved, including a drop-in delivery time from 6 sprints to 3 for a single feature. This improvement was a result of everyone feeling ownership of our product and being prepared to take a leading role without direction. We were no longer a team of individuals with one leader.?

Every individual had become a provider of leadership.??

I wish there were a happily ever after with credits rolling as I disappear into the sunset with a few lines describing my team’s continued successes. However, I was about to learn how important it is to take leadership on the same journey as the team.?

A Scrum Master I came to realise that part of my role should have been to guide leadership to understand, support and promote the changes that had happened within the team. What I did not grasp until too late was that our team’s culture had diverged from the broad company culture. I had not created the conditions for the leaders to be able to recognise and bridge that gap.?

My mistake set the stage for the beginning of the end of our fellowship (but that’s a story for another time).?

Conclusion - Why should a Scrum Master avoid JIRA??

I remember talking to another Scrum Master and their team late in my team’s journey. They wanted to know the status of tickets in my team’s backlog and if I needed to update them. My answer shocked them - I told them I had no idea but to proceed with their activity (some report). I clarified that in my team, the Scrum Master is not responsible for tickets being up to date. Their team looked at me like I had grown an extra head. Why have a Scrum Master if they don't take on all the team’s admin??

I said that I learned a good Scrum Master helps the team to be successful without them. However, now I think that that is more complete to say that a Scrum Master helps the team to be successful without them (and thus master Scrum) and prepares the leadership to further that success.??

In a volatile and uncertain world, good Scrum Mastery is a form of insurance as it leads to resilient teams. Resilience is more than the ability to survive – it’s the ability to freely make conscious choices in complex environments. Resilient teams thrive.??

A Scrum Master needs to behave more like a sports coach than a secretary. Stepping back from admin and operational detail is the first helpful step. A team’s self-management journey cannot begin when the Scrum Master, their coach, is on the field checking if their shoes are tied.?

????

(P.S. I lied; I do still use JIRA / Azure DevOps.... But I won't do the teams admin work)?

Some podcasts I recommend:?

1.????? The Scrum Master Toolbox (https://Scrum-master-toolbox.org/)??

2.????? Agile Coaches' Corner (https://agilecoachescorner.libsyn.com/)?

3.????? Agile Pubcast (https://www.youtube.com/@theagilepubcast)?

??

?

??

?