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

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.

Co-location still matters!

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

(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.

(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.