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.

(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.https://scrumguides.org. November 2017
2. James, Michael. https://scrummasterchecklist.org. Revised 2 Feb 2016.

So I am a beginner in using agile frameworks and came to Munich for LeSS Conference for one purpose only – to find out how to quickly and effectively and painlessly make use of the framework in my own context. Simple, right?

I knew there would be a lot of inspiration – and there was! Thank you all content givers! I knew there would be many interesting discussions about different implementations in details or specific problems on the way or discovering the mindset it is great to manifest – and there were! (Some discussions/presentations ended up standing because of hot topic) I expected many experienced, positive, I-know-why-I-came people to meet and to stay in touch afterwards and I wasn’t disappointed. Finally, I hoped for great food ;) and it was de-li-cious (though still… less is more).

I also have learned that silent high five actually works for big conference, that (piano) keyboard is not designed for one player only (and pattern „one keyboard – one screen – one developer” is only my heavy bias) and that bully hen was a great team player 6 generations earlier, so promoting good teams as a whole is far better than promoting individuals in the long run.

Did I find answer to my initial question? Yes, quite quickly. There is no shortcut to success. The best thing I can do is to get training(s) and coach guidance. And take it with no guarantee. And then: experiment, fail, learn, experiment, learn, have something almost done, explain, fail, experiment, engage, learn, practice, come back for missed rules and principles, learn, gather data and measure, experiment, learn, do less… and once again.

This was my main learning. And I’m thankful for that. I have one year of learning ahead before the next Conference takes place. And I’m looking forward to having little success in our LeSS adoption. See you next year!