That’s not my job!

This is a story from a colleague who was providing technical coaching at a client.

He was one of the technical coaches working with 40 Scrum Teams to improve on their technical, development practices and bring them on a par with 21st century standards.

At one of these sessions, the technical coaches provided training, mentoring and coaching about modern development concepts like test-driven development (TDD) and acceptance-level TDD (ATDD). One of the involved developers went to his desk, opened his drawer, pulled out his working contract, pointed at it, and said: “It does not say ‘testing’ in here.”

Clearly, that developer was heavily relying on his paper contract. If it didn’t state to wash his hands after he went to the toilet, maybe he wouldn’t have done so. Who knows?

But, seriously. Does it help if an idle team member points out that something is not his or her job, while the work needs to get done, and all the other people involved are too busy to do it? Not really.

Taking a closer look at companies large and small, we see a particular pattern. In smaller companies, it seems to be more like an accepted behavior to take overwork, even though it may not be part of your job description. In larger companies though, people are more hesitant to do so as the likelihood of stepping onto someone else’s toes might cause problems, not to mention that it often doesn’t help them advance their career.

Regardless, we don’t think the latter attitude is helpful to solve the complex problems we typically intend to solve with Scrum.

As humans, we are born with little skills. One of the core things the human brain is capable of learning new things, continuously and life-long. We learned to crawl, to step up, and to eventually walk and run. This freed us from the perceived problems when we grew up. Just because something is not your job should not keep you from learning the necessary skills to perform the work if it has to be done.

What if that work does not have to be done? Well, why then do it at all?

As humans, we learn all our lives long. That’s what distinguishes us from other species. Use that one thing that makes you human to contribute to your team’s efforts, meanwhile also developing yourself.

“That’s not my job” really is a pretty cheap excuse for not doing the related work. Don’t go there as it undermines team morale and your self-development.

(taken, and adapted from Save our Scrum)

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

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.

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!

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.

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