How a Digital Issue Tracking System affects Your Journey to Scrum
Three examples of how our approach to Jira changed our way of working with Scrum.
Talk to any team about their tools and they will most probably tell you they work with a digital issue tracking system. Jira is probably the most popular one. I myself started working with Jira 8 years ago and I’ve become quite the guru at it. I find it an invaluable tool.
However, I’ve always struggle with the way a digital issue tracker encourages a process-driven approach which often leaves little room for the more humane aspects of an Agile approach. Setting up huge controlling processes is simply too easy, and it ends up turning the first Agile value on its head:
Individuals & Interactions over Processes & Tools
The image below shows a rather typical example. This is an organisation where processes have been set up by a team of experts mainly to enforce a governance system.
If you were to visit this organisation you would get the feeling that they had made a successful Agile Transition. Scrum Teams, dogmatic adherence to the Scrum events and an inexhaustible smattering of jargon. An Agile paradise!
Dig a little deeper and you would start learning about the problems they have: lack of ownership, extremely long cycle times, disconnect between teams and stakeholders… All symptoms of a failing Agile adoption.
To me, the Jira implementation shown above gives a very clear picture of the actual situation in the organisation. Inspired by a SAFe approach, we see how work filters down from higher management, going through the Architecture and Design departments. The work is finally pulled in by team analysts, who break it into stories and finish specifications. Teams have nothing much left to do but estimation and building. It is nothing more than a very elaborate form of waterfall, disguised as Agile.
Sjoerd Nijland describes a similar situation beautifully in this article: The unmistakable signs you are participating in Fake Agile theatre!
The dominance of a process-driven approach
The hard bit about Agile is to realise it is more about a mindset than about processes. We as human beings are good at processes, so the really innovative aspect of Agile is the focus on the human side, the new way of thinking. Check this article for more details on this: What is Agile?.
To make things even more challenging, developers, in general, are very process-minded. It comes with the kind of work we do. Writing code is the kind of work that reinforces a highly structured approach. In general, as developers grow in their careers they continuously add new tools and techniques that reinforce this structured approach. Think stuff like Domain-driven Development, Code reviewing, Test-driven Development, Design Thinking. And of course the Scrum framework itself.
Looking at myself, 5 years have passed since I stopped programming and yet this way of working is still so deeply ingrained in me that I will rarely start anything without thinking about a suitable process.
Indeed, for me, the biggest struggle with a Scrum Team has often been to stop trying to solve everything with a process, in Jira. Figured out a DoD? Let's add it to Jira as a blocking checklist that needs to be ticked off whenever an issue is transitioned to DONE. Started using INVEST? Set up an issue template in Jira with all the necessary fields. Testing not up to standards? Let's add an extra column to the Jira board.
There is nothing wrong with these solutions. The problem is that they do not focus on changing the way we think, but on enforcing the change we want. It is really just good old command & control.
And that is the problem with Jira, that it offers so much flexibility that it makes it very easy for people to abuse it to organise things in a process-driven manner.
Take for example the simple fact that an issue has an unlimited amount of space and brilliant formatting options. Open the description and start typing and you can go on forever, adding row after row of details. And this is literally what happens.
In many cases, the result is that the idea of the user story as a placeholder for a conversation is lost and instead we have the issue as a vehicle for everything, from design and architectural definitions to minute-keeping and contractual agreements.
This is not only detrimental to an Agile approach, but it is also a horribly inefficient way of documenting information, as there is no other way to maintain an overview than having to open issues one by one in search of information.
This struggle has led me to experiment. In the rest of this article, I share 3 experiments.
No content!
Perhaps the most ridiculous experiment I ever got away with was to have everyone in the organisation agree to always and absolutely leave the description in the Jira issues empty. Definitely a don’t-try-this-at-home approach, and I think it only worked because we were a relatively small start-up.
What I was actually trying to address here was a situation of ownership, where sales and product owners created detailed specifications leaving no room for developers to take ownership of the work.
The results, however, were unexpectedly far-reaching. After an initial panic, people looking for information gradually started finding each other. Everyone started talking to everyone else. The idea of a user story as a placeholder for a conversation became reality in a way that I wouldn’t have thought possible. It even had a positive effect on our events, as since everyone was involved in the conversation, they started to really listen to what was going on. There was no other way to get information.
Eventually, we did start using the description again, but it happened more sensibly. Having learned to work without the description, we now had the luxury to explore the possibilities of the description field more thoughtfully. It ended up turning into an iterative process where our focus was on having only really necessary stuff in our description.
For me, this was the first time I consciously realised that humans are hugely complex and irrational beings and that change sometimes needs drastic measures, often triggered by simple interventions.
From a system thinking perspective, the fact that the success of a Scrum implementation could be catalysed by such a small and simple intervention is fascinating. This has formed me. It has made trying to find that one magic bullet in any problem I encounter a private obsession of mine.
The Product Goal
I once worked with a Scrum Team where we learned to work with a Product Goal, long before it was added to the Scrum Guide. This happened out of necessity. We worked on projects lasting 2 to 6 months for old-fashioned clients that liked a clear and rigid presentation of budget and pricing.
As a team, we learned to quickly break a project into parts and estimate them, however roughly. Time is money.
The interesting side-effect of this was that because the whole team was fully involved in preparing the project, everyone had a clear and shared idea of the goal of the project. Because we all knew exactly what we were aiming for, Jira lost its importance as a tool to document work. We completely stopped using it during Scrum events.
Instead, it became what to my mind is the purpose of a digital issue tracking system, a tool specifically for managing the Sprint backlog. Because of this focus, we started using elements of kanban quite organically, measuring our flow and looking for optimisations.
For me, as a Scrum Master, this was the moment I realised that ownership and an overview of the work is probably the most important aspect to help a team become Agile. As soon as a team takes control of the work as a whole, all the Scrum puzzles seem to automatically fall into place.
For more details on this amazing effect, check this article where I describe the situation in more detail: Every member of a Scrum Team should be a Product Manager.
A Digital Whiteboard
My latest experiment, and one where I feel I may have hit the jackpot, is using a digital whiteboard instead of Jira.
This experiment started off as a way to see if I could find a digital solution for the concept of a “team space”. Before COVID we used to have our Sprint backlog on a whiteboard. I used to plaster anything of importance on the walls of our team room. Including doodles and even cartoons relevant to the dynamics of the team — just to give you an idea of what I mean by important.
But with COVID this all disappeared. Struggling with the consequences, one of the things I realised is that it is hard for a team to take ownership of things that they cannot see. And as I mentioned above, Jira is not an effective tool to make work visible.
At the same time, I was experimenting with Miro digital whiteboard as a solution for remote collaboration, such as for example for Retrospectives. I find a digital whiteboard fits very well with the creative character of the event. I gradually learned to design colourful themes which really helped to set a positive, creative environment.
As the team got used to the digital whiteboard, I started using it for energisers and ice-breakers too. Here the advantage was that anything the team shared — pictures, drawings — stayed there, giving the whiteboard character and an almost cosy, home-like feeling.
The next step was to use it for brainstorms and refinements. The result was that next to the pictures and drawings we started to develop an alternative backlog on the whiteboard. Post-its as stories, other post-its with details, estimates and just anything that felt relevant to what we were trying to achieve — it created a clear and powerful overview of all work to be done. And everything available at a glance!
Somehow, working with simple post-its changed the focus away from the details. Jira issues just have so many functionalities and so much content that they psychologically invite you to click on them. And then you get sucked into the details and automatically get into working those out.
By simply switching to post-its we created a new way of visualising work that completely changed our way of work. Without making any kind of conscious decision about it, conversations changed from working out specifications and doing estimates to organising and managing the work. We were able without any effort to stay at a higher level of detail and leave the details for the sprint itself.
Eventually, we got to the point where we started doing the Sprint Planning on the whiteboard and setting up a Sprint board there too. Again, just by having this new way of visualising work the team switched from just selecting user stories to making a proper plan for the sprint.
We even created a kind of timeline beside the Scrum Board with important milestones and targets and this became the focus of the Daily Scrum.
To me, this experiment showed me how hugely important it is to look at the environment to make changes. As a Scrum Master, I have spent countless hours trying to explain to teams why refinement is not about the details and why it is better to leave those for the sprint. I know my teams understand the theory, but putting it into practice has always been a challenge. Our intellect is not always the best way to make changes. Chip & Dean Heath wrote a brilliant book about the subject:
Conclusion
So there you have it, three experiments that highlight three aspects of Agile, specifically in the context of one of the most popular tools we use, the digital issue tracking system:
individuals and interactions over processes and tools,
the importance of a systemic approach and finding the most high-impact interventions,
the importance of the environment to change the way of working.
For me, all three experiments were an amazing experience because of the huge impact they had. And the most important lesson: that we can learn all we want about the theory of Agile, but putting it into practice is a different thing altogether.
Maybe thinking ourselves into Agility is the hardest route to Agility and we should instead focus more on the environment and the tools we use.