On Co-Location

Having worked in a few distributed teams my experience has been that  with large disparate time zones, with people either getting up very early or having to stay in very late, working together can be very painful.

From my perspective working on complex, emergent solutions that require a lot of communication and free expression being co-located is the most conductive and least inhibiting way to work. Sure, on paper there are technical solutions for pretty much everything, though there is one thing they did not solve: Human nature.

From what I know Humans are “designed” to work best in direct interaction. Expressing, finding, establishing and maintaining shared values and a unified vision is something that has shown, at least for me, to be very time-consuming and costly trying to do it remotely.
Especially if you’re working with a new team the issues of trust, prejudices, fear of looking stupid and general unease can take weeks and months to be resolved, if they can be resolved at all.

I’ve been working with people remotely and had – despite honest efforts – severe communication and alignment problems. Then we finally met for a week of working co-located. And suddenly it clicked. It was the actual closeness, the direct face-to-face communication that broke barriers and tore down (hidden) misunderstandings that had been existent for months.

I look at current efforts (at least in my division) to co-locate teams and break up distributed structures. I see Design Thinking Workshops that emphasize high-energy, low-friction direct face-to-face interaction. I see the difference in my daily work between remote and co-located teams.

For me this tells me co-location is not a luxury but a necessity to fully unleash teams and employees potential. Companies that are driven by innovation, not lowest-cost, should use co-location as an investment to stay competitive. And I welcome any efforts towards this goal.

Opinion: What Makes a Scrum Master an Effective One?


I’ve recently been asked:

“Would you have any pointers to any internal or external information you recommend on guiding/teaching scrum masters on how to be an effective one?”

This very straightforward question actually has a complex answer.

The main cause for this is that the role of the Scrum Master is, intentionally, not something that you can map to some of existing clear-cut roles of Project Manager, Team Lead, (People) Manager. It also has some restrictions that are required to keep the role effective.

So before I delve into dishing out recommendations, I first want to deconstruct the role that is a “Scrum Master” from my first-hand experience and point-of-view.


As said before the Scrum Master role is a hybrid. It has been intentionally crafted from different pieces of other roles and received new responsibilites. As such many people, especially if they transition from traditional roles (e.g. as a Project Manager) struggle. I’ve seen quite a few attempts at “mapping” existing processes and behaviors to the new role. My take is, if you actually “succeed” in doing that, you miss out on the chance of a profound change in the way you work and thus forfeit many if not all of the benefits this brings.

So with that in mind let’s not try to see what role is similar to a Scrum Master or how you can best map your existing stuff – let’s take a look what a Scrum Master, in my opinion, should focus on.


The Scrum Master’s responsibilites are broken up among three areas, all in equal measure.

1. Process

Knowledge and application of Scrum within the Agile Mindset. Understanding the different elements and artifacts, why they have been created and where to apply them.

2. Coaching

Enabling others to understand and implement the Agile Mindset. Understanding their issues and offering support in resolving them. Helping the team and stakeholders to achieve mastery in their craft.

3. Leadership

Offering guidance and a clear vision where needed. Ensuring organizational alignment across all levels. Establishing and maintaining communication between involved parties. Creating transparency where ever possible.

Beyond Process Ownership

The first thing that might be surprising is that the responsiblities go beyond pure “Process Ownership”. Although the Scrum Master is usually introduced as a role to whip the team an stakeholders into shape the role needs to quickly transcent that singular focus if to be able to unleash to the team’s full potential.

Just owning the process alone but not being able to foster understanding in the “Why” and communicating the results will just lead to people blindly following it “because Scrum says so”. How will you ever achive wide acceptance or continuous improvement if nobody gets why you are actually going Agile (Leadership) and addressing their concerns (Coaching)?

Providing Coaching without knowing the process can cause you to miss the realities of the business and denies you the tools to model the day-to-day work (Process). Also if people do not follow your leadership why would you even make suggestions (Leadership)?

Finally assuming leadership is not something reserved for those carrying a “Manager” title. Everybody can take up leadership if the cause is worthy and the time is right. That said a Scrum Master is the embodiment of a “Servant Leader” – working not to order people around but to offer assistance and then get out of the way as quickly as possible. To provide leadership you need to understand the issues people are facing (Coaching) and have the right tools to offer solutions (Process).

In the end it all comes together to form a whole, rounded role that goes way beyond Process Ownership.

No Discliplinary Power

In my opinion the Scrum Master cannot be someone with disciplinary power over the team members.

The Scrum Master can also not (asked to) be part of the performance review process for team members.


The Scrum Master’s goal is to unleash the power of the team. To that end the Scrum Master must work on neutral grounds and the principle of confidentiality when talking to to team members, especially on touchy subjects.

Sometimes team members may be hesitant to name issues openly if it concerns their work, mistakes or other people – especially if the person they are talking to is supposed to hand out their performance rating at the end of the year.

A first-line manager cannot be a Scrum Master. Avoid this at all cost.

No Part-Time Job

If you look back up at the three responsibilities you see topics that are as vast and diverse as can be. Many companies today are hiring people for full-time Scrum Master jobs.

And for a good reason: It is a full-time job.

To enable a Scrum Master to actually be able to fill out all of these responsibilities the time has to be available to do so.

Just adding Scrum Master responsibilities to an existing “Developer” or “Lead Developer” role might sound obvious but is also wrong.

The dual role automatically creates a conflict on time allocation starving both roles for focus and attention. With the constant context switches and lack of depth you will not see a 50:50 split – rather something along the lines of 20% and 20% is more realistic. Around 60% will be getting lost because of interruptions and the person becoming quickly overburndoned and entering a purely reactive state, working down the ever-increasing stack of “stuff to do”.

This not only increases stress but also a creates a liability for the team and the business as both cannot rely on the person to both deliver the development and Scrum Master commitments.

If you want somebody to become a Scrum Master make it a full-time job.

Also: A good Scrum Master can handle two teams. An excellent Scrum Master can handle one team.

Mindfulness Required

Just as the Scrum Master is not just a Process Owner the person owning the role is not just an employee – we’re (thankfully!) working with human beings. And this requires a surprising knowledge of the human self.

Mindfulness is a broad topic oftentimes stretched to cover different areas of conscious behavior, recognition of (inner) body signs, empathy and vision.

For me mindfulness starts at the self – recognizing that you are more than just your intellect and logic. Accepting that your emotions and instincts are not something to be turned-off or pushed away. And finally listening closely to what your body is very subtly trying to tell you. If that sounds like new-age feel-good mumbo-jumbo… well, let me tell you that ignoring all of this for too long could lead to you being at an all-time high stress level until you suddenly get nosebleeds in meetings and almost collapse from exhaustion. All the while being completely confused why you are all-time angry and your damned body refuses to play along.

This is not a place you want to go. Ever.

The problem with a lot of that is many people – including me – have learned to suppress their needs over so many years that the natural signals are no longer properly recognized or automatically subdued. This is not a process that happens in a few weeks or months. It takes years to manifest – or “learn” – until it has become a state that feels completely “natural”.

A Scrum Master being lodged in between many parties and having to negotiate sometimes really tough topics needs to have a lot of mental and physical buffer to take almost anything with a degree of calm and professionalism. This calmness cannot be enforced or upheld by pure will. It is something that requires the Scrum Master to ensure regular de-compression from stress and work-related pressures.

To do be able to achieve this state is is neccessary to properly and honestly understand where one currently is. How stressed am I really? What do I REALLY need now? What is my body REALLY needing now?

This requires careful approach, reflection and – especially – time.

This creates a shared responsibility both for the Scrum Master to establish practices for Mindfulness as well as the surrounding business to give the space to do so.

Failing to do so could jeopardize entire teams by subjecting them to overworked, stressed-out Scrum Masters.

It’s About Succeeding Better

You might have heard of other projects that did things that I have recommended against and still were considered successful. And I have no doubt that they were successes.

But have you ever asked yourself it there is only a binary state of Success/Failure or if there are degrees?

What if the projects you heard of where successful with only 20% of their potential realized? Where would the projects be now if they could have realized 50% or even 70% of their potential?

To come full circle with the initial question about become more effective a lot of the options here are not about “just” succeeding.

They are about Succeeding Better.

I invite you to try them out for yourself and let me know in the comments or via email how it went for you.

Further Information

Process Knowledge

Essential Scrum by Kenneth Rubin

Agile Retrospectives by Derby et al.


Coaching Agile Teams by Lyssa Adkins

Start With Why by Simon Sinek

Drive by Dan Pink


The Humble Inquiry by Edgar Schein

Influencer by Grenny et al.