Digital tools considered harmful - Jira

Digital tools considered harmful: Jira

At the time of this writing, Jira is probably the most widely used digital tool in Scrum and LeSS adoptions. Unfortunately, using Jira commonly leads to some predictable dysfunctions. Some of these are:

  • Scrum confusion and tool-owned processes
  • Micro-management due to integration of Product and Sprint Backlog
  • No shared team responsibility due to poor Sprint Backlog

Scrum confusion and tool-owned processes

Many companies start “enterprise-wide” Scrum adoption with mandating Jira. People learn Scrum through Jira, or so they think. However, Jira was never a Scrum tool. It is an issue tracking tool with many ideas integrated into it, such as Scrum and many… not-Scrum. Teams end up adopting ideas that they think, or were told, are included in Scrum.

The overall result is anti-Scrum. How? Scrum has a minimum of prescriptions as it implements empirical process control. Team practices are not prescribed or fixed but are adopted and adapted as context changes. Scrum implies team-owned processes rather than tool-owned processes.

Micro-management due to integration of Product and Sprint Backlog

Jira integrates the Product and Sprint backlog. This might seem like a good idea but in practice, it is not. It leads to confusion about their purpose.

The Product Backlog contains items that represent product features or improvement work. The Product Owner uses the Product Backlog for tracking product progress, deciding features to create next, and for making scope/time/cost trade-offs.

The Sprint Backlog is a plan from the Team on how they are going to attempt to achieve the goal of the Sprint. It is valid for one Sprint – it is created at the start of the Sprint, never earlier, and ceases to exist at the end of the Sprint. The Team keeps it up-to-date all the time. It enables them to take a shared responsibility and manage all the in-Sprint work.

Integrating the Sprint Backlog and the Product Backlog easily leads to the Product Owner and management starting to track in-Sprint progress. By doing so, they take over the responsibility of the Team to manage their own progress during the Sprint. The temptation to interrupt the Team during their Sprint is often irresistible. And this will change Scrum from a framework for supporting self-managing teams to a micro-management framework.

No shared team responsibility due to poor Sprint Backlog

Good teams avoid having half-done items at the end of the Sprint. They do so by truly taking a shared responsibility and by working one (or a few) items at the time. They achieve this through fine-grained task splitting so that each team member can pick up tasks related to the same item at the same time.

Creating tasks in Jira is slow. This might be because Jira itself is slow – most of my experiences with Jira were self-hosted installations (due to cloud restrictions) and they were all slow. Or it might be because tasks are created in Sprint Planning with one person typing. Whatever the slowness reason, all teams I’ve observed minimized their Jira typing time by avoiding small tasks.

Large tasks lead to less shared work, which leads to less shared team responsibility, which leads to a less effective team. How do you know this might be happening? Half-done items at the end of the Sprint and the Team talking about ‘spill-over’ or ‘carry-over’ work.

Key point: The phrases ‘carry-over’ and ‘spill-over’ are not Scrum. They’re signs of dysfunctional Scrum.

We are stuck with Jira, now what?

How to use Jira so that it causes the least amount of harm? My recommendations are:

  • Never use Jira for Sprint Backlogs
  • When using Jira for a Product Backlog, simplify it. Make it work like a spreadsheet.
  • Avoid any complicated features and avoid workflows. Out-of-the-box Jira is already too complicated.

Digital tools considered harmful - Sprint Backlog

Digital tools considered harmful: Sprint Backlog

It is unfortunately common to use a digital Sprint Backlog. I explicitly say ‘unfortunately’ because of the negative impact a digital Sprint Backlog tends to have on team dynamics and collaboration. Using a digital tool for a Product Backlog might also be common but is less harmful. Digital Sprint Backlogs should be avoided!

I’ve observed four causes of digital Sprint Backlog,

  1. The team is not co-located.
  2. Management mandates a tool for Sprint Backlog.
  3. The team uses a computer during Sprint Planning.
  4. The Scrum Master adds tasks to the Sprint Backlog.

Each cause is a reflection of a team or an organizational dysfunction.

1) The team is not co-located

Dispersed teams are common as many companies pretend co-location doesn’t matter and allow organizational stupidity to disperse the majority of their teams. Check out my article related to this, called “co-location still matters!

Dispersed teams frequently end up quickly deciding to use a digital Sprint Backlog. Yet, I’ve known quite some teams that manage fine with post-it Sprint Backlogs, white boards, video and photos.

2) Management mandates a tool for Sprint Backlog

Although I have often inquired about the benefits of ‘harmonizing’ the Sprint Backlog tool, the reasons to do so are still unclear to me. The most common response is a desire for better in-Sprint progress tracking. This is a clear sign Scrum is being misused for micro-management purposes as in-Sprint progress tracking is the responsibility of the team. Another frequent response is to derive metrics from the Sprint Backlog, but the metrics for tracking team progress and release management are derived from the Product Backlog and not from Sprint Backlog.

The Sprint Backlog is for the team; not for the Scrum Master or for the Product Owner, and definitively not for management. It helps the team to take a shared responsibility and to manage their work toward creating a releasable product Increment. What tool (or not) to use is the decision of the self-managing team. Management that mandates a tool doesn’t seem to understand Scrum and how it is founded on self-managing teams. That is the real problem to solve.

3) The team uses a computer during Sprint Planning

Computers cause boring meetings. They centralize discussions with the typing person becoming a bottleneck. Computer-centric meetings are life-sucking events and waste people’s time as they stare at the ceiling while waiting for the typist to finish.

Computer-less meetings can be much more productive and fun. Meetings automatically decentralize when the focus is on conversation and using cards or post-it notes to invoke collaboration. Everyone writes in parallel. Sub-groups emerge and later merge again. And the cards on the table provide an overview of what was done.

Sprint Planning is shared software design and ought to be fun!

4) The Scrum Master adds tasks to the Sprint Backlog

Scrum Masters who touch the Sprint Backlog will own it and they become fake-Scrum Project Managers.

Example: Non-digital Sprint Backlog

Following is a non-digital Sprint Backlog from a team I worked with.

Example Sprint Backlog

This Sprint Backlog is the software design of the system, with the black boxes representing the current system and the red ones the envisioned design for this Sprint. The post-it notes are the tasks needed to do. This is the ‘to-do’ column of a task-board Sprint Backlog.

I’m not suggesting that your teams should work this way. This is how this team worked, they owned it. That is the most important reason for never using digital tools for Sprint Backlog. When using a digital tool, the tool determines the way the team is working. Without digital tool, the team can own and improve their own way of working.

Co-location still matters

Co-location still matters!

It is 2019 christmas. Will you skip the traditional family visit in favor of remote communication technology?

“Dispersed teams is the reality that we have to deal with!” is a common reaction when people discover that the LeSS rules includes “each individual team must be co-located.” Do we need to accept that as reality?

Many claim that modern communication technology has made co-location irrelevant. This is not my experience. Although it is certainly possible for a dispersed team to become high-performing, a typical co-located team still performs significantly better.

A co-located team, where team members are sitting at the same table facing each other, has the potential to be fun and effective. But what makes co-location better? It is the face-to-face conversations that speed up building the high-trust environment required for taking a shared team responsibility. It is the dynamically emerging discussions. It is the unknowingly, accidentally overhearing of a conversation and then suddenly contributing an essential fact to it.

Co-location does matter! It’s impact can be huge.

There are many factors that impact team performance which are not included in the LeSS rules, so why include co-location? Because after exploring the reasons for having dispersed teams, we concluded the most common one is organizational stupidity. Nobody ever bothered to try to co-locate the teams. The most common scenario is where someone high up in an organization decided to have half of the development to be done in a low-cost location. Instead of then designing the organization to maximize co-location, that decision is propagated as a rule through each layer of the organization. The result is that every team becomes a dispersed team. Organizing the same people differently could have resulted in only co-located teams, for the same cost.

Another common reason for dispersing teams, beyond organizational stupidity, is that certain skills are only available in certain locations. This might be a valid reason when acquiring these skills relate to being at that physical location, such as being close to a customer. More often, it an excuse to avoid other teams having to learn that skill. If that location is truly important, it might be worth having a whole team there.

It is always possible to co-locate every team? Perhaps not. But by having co-location included in the LeSS rules, we hope organizations stop accepting dispersed teams as an unchangeable fact and instead put thought and effort towards co-locating teams. It will have an impact on the team and the development.

Actively Doing Nothing

(this article is for a series of posts of which some might be published in the upcoming book “97 Things every Scrum practitioner should know” in the O’Reilly series, which will be edited by Gunther Verheyen)

Actively Doing Nothing (is actually hard work)

What do Scrum Masters actually do, all day long? This is a hard question as the behavior of a Scrum Master is very contextual. It depends greatly on the maturity of the team, the experience of the Product Owner, and the amount of dysfunction in the organization. I use the “five tools of Scrum Masters” for clarifying what a Scrum Master does, when he does that, and why,

  1. A Scrum Master asks questions.
  2. A Scrum Master educates.
  3. A Scrum Master facilitates.
  4. A Scrum Master actively does nothing.
  5. A Scrum Master interrupts (in exceptional cases).

These tools require little clarification, except probably the tool I probably use most: actively doing nothing.

What is actively doing nothing?

Actively doing nothing means that when you observe non-optimal dynamics or plainly wrong behavior within your team or organization, you chose to not do anything at that moment.

A way to clarify actively doing nothing is to contrast it to its opposite: passively doing nothing. Passively doing nothing means you do nothing and you don’t care. However, actively doing nothing means you care, you carefully observe what is happening, and decide… to do nothing.

For example, you notice two people from two different teams are having a minor conflict about which team ought to do what. You observe and listen carefully, ask yourself whether this will cause permanent team damage, and if not, … you chose to do nothing.

Why would you do that!?

By actively doing nothing, you actually do something. You create the space for the team to take responsibility for the situation they are in. By doing something, anything, you are taking the responsibility away from them, and you prevent the team from solving that problem, you prevent the team from growing as a team. Therefore, as Scrum Master, I often observe the situation, think about the team and organizational dynamics, and consider whether not doing anything would cause harm. In most cases it doesn’t. If it doesn’t cause harm then often there is an opportunity for team self-learning and growth. Thus I force myself to not do anything other than to actively continue my observation.

Actively doing nothing might be followed up with actively doing something. For example, ask questions to help the team reflect to solidify the learnings they have from resolving that situation. Or, ask questions to help the team to reflect on what they could have done differently so that next time they might be able to resolve the situation. Asking questions is often followed up with two of the other Scrum Master tools, (1) facilitation when questions lead to interesting discussions and potentially decisions, and (2) education when the questions lead to a learning moment.

Actively doing nothing is hard!

Yes, doing nothing is hard and this often comes as a surprise. Why would doing nothing be hard? Because, as a good Scrum Master, you care about your team and you want to help them. You want to resolve the pain they are in by jumping in. However, a good Scrum Master realizes that this will not benefit them in the long run. Building a team means you need to create the space for the team to resolve issues themselves, learn from it, and grow.

A potential problem with actively doing nothing is that it will look like you are doing nothing, and not adding any value. Many of the teams I was a Scrum Master of joked that I don’t do anything. They noticed the team worked better when I was there, but they often couldn’t see why. Indeed, it seemed like I was… actively doing nothing.

Go out and become a better Scrum Master by actively doing nothing.

The Scrum Master as a Technical Coach

(this article is the first in a series of posts. Some of these might be published in the upcoming book “97 Things every Scrum practitioner should know” in the O’Reilly series, which will be edited by Gunther Verheyen)

The Scrum Master as a Technical Coach

The best Scrum Masters that I’ve encountered spend part of their time as a technical coach for their team. Unfortunately, it seems that most Scrum Masters do not do this. To me, this seems like a lost opportunity since spending effort on technical coaching for your team can help them enormously, and it will help you with your other Scrum Master responsibilities.

It often comes as a surprise when I suggest that a Scrum Master could (or even should) do technical coaching. It shouldn’t! Technical coaching isn’t explicit in the Scrum Guide [1] as it is written to be applicable to both technical and non-technical work. Therefore, technical coaching is only mentioned as “Helping the Development Team to create high-value products.’’ That is unfortunate. However, some other great Scrum resources do refer to technical coaching explicitly, such as Michael James’ Scrum Master Checklist [2]. In the checklist, one of the four focus areas of a Scrum Master is “How are our engineering practices doing?”

Scrum Masters can (should) do technical coaching and that shouldn’t come as a surprise.

Why should a Scrum Master doing technical coaching?

Regular technical coaching has three important benefits:

  • It improves the team’s development practices.
  • It lets you experience the real problems that the team faces. This helps you in deciding where to focus the team, the Product Owner and organizational improvement work.
  • It keeps your technical skills up-to-date.

What kind of activities can a Scrum Master do?

Some examples from my own work as a Scrum Master are:

  • The most common activity: pair up with team members. Just announce during the daily that today you would like be pairing.
  • Setup your computer so that you can build and run tests.
  • Refactor some tests and code and have a sharing session with your team.
  • Create some unit or acceptance tests.
  • Organize a learning session about technical agile development practices. Use your team’s code as examples.

What to avoid?

The biggest risk is to become too involved in design decisions, and the team starts depending on your contributions. You can avoid this by:

  • Never plan your development time in the Sprint.
  • Never pick up a task from the Sprint Backlog.
  • Avoid making decisions. When asked for your opinion, provide many alternatives and keep reminding the team that “it is your decision.”

How to start?

It shouldn’t be hard to add technical coaching to your work as a Scrum Master when you have development experience. It just requires you to prioritize and plan for it. One option is to plan one or two days a week to focus on this. As the context switching might make it hard, alternatively, you can dedicate a Sprint on technical coaching and try to limit other Scrum Master activities.

If you do not have development experience it will require more effort. It is possible to learn the basics of development and the purpose of agile development practices while being a Scrum Master of a team. You can ask your team for help. Tell them, “I want to improve my development skills, could you help me with that?” Work out a plan together and dedicate time for learning. Spend a lot of time pairing, but avoid asking too many questions as it will slow down your pair and he/she will become annoyed.

Good luck with the technical coaching as Scrum Masters and I hope you will find it as rewarding as me.

  1. Schwaber, Ken, et al. November 2017
  2. James, Michael. Revised 2 Feb 2016.