I am part of a distributed team: Happy Melly One. We have ten people in our team and we are distributed over five different time zones. We work with freelancers. Most of us also have other projects that they work on. We are responsible for Management 3.0 and Happy Melly. Like every organization, we need to experiment, make decisions and adapt when necessary.
Some decisions are easy to make. If necessary, you inform the people concerned and you are done. When I need to order new items for the web shop, I just order the new supplies. When I decide to merge some files into a new folder on our team share, I just do it. Life can be easy, sometimes…
There are experiments that we would like to run that affect many people, customers, commitments, etc. Experiments that you would like to discuss first with as many people as possible in the team. If possible, you want to talk about it with all team members. Remember I said life is easy? Well, discussing these kinds of experiments in our team is not so easy. Reasons are the time zones, other projects, other obligations, and sometimes team members are also enjoying holidays.
How to solve this?
First, let’s take a quick and brief look at holacracy:
A holacracy is a governance structure characterized by a distribution of power among self-organizing groups, rather than the top-down authority in the typical hierarchical corporate culture model.
One of the meetings described in Holacracy is the Governance meeting. In a governance meeting, a circle can change the roles of the circle, it can change policies of the circle and/or elect people to the elected core roles of the circle. More information about governance meetings can be found here.
I looked at the structure of the governance meeting and realized it could help us in making decisions. Time to run an experiment in our team. So, I created a Google Docs template, called the proposal document template. I know, sometimes it is hard to be original.
Let me explain our process, inspired by the governance meeting structure.
As soon as someone would like to make a decision, propose something, run an experiment, they will create a new proposal document.
The first section is the proposal. What are they proposing? What would someone like to change and why? For example, someone would like to change the logo of Happy Melly One to a huge purple square. In the proposal, they can then describe the what and the why. They can explain why a huge purple square is better than our current logo.
The person concerned will then share the document on Slack. If necessary, they can tag people to make sure they will be triggered to look into it. People can read the proposal and ask questions to the proposer. Questions that will clarify the proposal.
The proposer will make sure everyone will either ask a question or that they say “no further questions” (or something similar). If the proposer does not chase people for this info, there is probably no urgent need for the proposal, and it will just fade away. For example, why choose a huge purple square instead of an enormous yellow square? Or how did you get this idea in your head? I love the current logo, if you change the logo then I am out of the team.
As soon as all people have asked questions or made remarks, the proposer can answer the questions. In the section Amend & Clarify the proposer can provide the information or even change the proposal if necessary. In this example, the proposer could change the proposal to a huge yellow square, or they can explain that it is proven that the color purple attracts more people according to research. Or they can just leave the proposal as it is.
Again, all team members should then provide input. This is the final step. Does anyone have objections to this proposal? The answer can only be yes or no. If no, a reason would be nice but it is not necessary. If there is someone who objects, the proposal is not accepted. In this case, I am sure the proposal for a new logo will be rejected, so the proposer should come up with a new proposal or discuss it in a meeting.
One thing is very important. You are only allowed to object if you think the proposal will hurt the organization. In this example, if you just don’t like purple, bad luck. Run the experiment, learn and adapt.
In the last weeks, we made two big decisions based on two such proposals. Thanks to the small process, all team members were able to provide input. What is more important, we were able to make the decisions in a week where it otherwise would have cost us weeks to get everyone in a meeting. Another advantage, we are keeping track of our decisions, our decision-making process and most important: we document the why.
Excuse me? Oh, so you are a level 4: Certified Holacracy Master Coach and you are telling me that this is totally not as it should be according to Holacracy? OK, well no problem. I was inspired by the governance meeting and we adapted it to our team. We made it work for our team.
Feel free to create your own proposal document template and use this idea in your (distributed) team. I would love to hear your experiences!
If you want to learn more about how to make fast decisions on remote teams, also listen to this podcast from Lisette Sutherland.
Let me jump directly to the conclusion: nowhere in the Scrum guide, it says that a team should be co-located. Additionally, nowhere in the Agile Manifesto it says that a team should be co-located. Focus on building relations and interactions between team members and make sure they have the right tools and hardware!
Teams will work distributed more and more: it is hard to find the right people locally, people work from home because of horrible commutes, because they want a healthy work-life balance, etc.
With that being said, why do so many people say that Scrum is only possible when a team is co-located? I think there are several reasons. Let me try to explain some of their arguments. The arguments that I hear most often.
You can’t communicate when you are not in the same room? Huh… where did they live the last ten years? OK, I agree that most every Skype call still starts with the infamous words: “Can you hear me?” One of my team members at the Happy Melly team, however, is working in Sudan at the moment. She has a great internet connection. I therefore assume that most everyone can have a good high-bandwidth internet connection. Tools like Skype, Slack, Zoom, Sococo, Trello, Retrium, I Done This, Teams, Fun Retro, Lino, etc. all these tools provide the facilities you need to communicate within a Scrum team. So communication should not be an issue in my opinion.
But wait, in the Agile Manifesto it is stated: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Yes, and I totally agree with that. This is the reason why I will always use a webcam in meetings or even record meetings so other team members can watch the meeting when they are online.
You can’t use sticky notes when the team is not co-located. Err, why not? Depending on your team setup, you can work with a buddy who keeps physical boards in sync. You can make pictures of boards and share them via the tools described above. Or you can use Trello or LeanKit for example, in combination with a (huge) touchscreen. Is not being able to use sticky notes really an argument? Don’ t think so.
Then, a more tricky argument… “How do I know they are really working?” If you have doubts whether your team members are actually working, well you may have a completely different problem… Don’t like it, but let me answer with a counter question: How do you know today that all co-located team members are working? Are you not fooling yourself if you think that simply because people share the same room, they never doze off? It is about the results, not about the time people spend in their office chair. You should know when people are not contributing to the results: it should not be connected to their location to be aware of this.
I worked with many Scrum teams, and many of them were distributed teams. Some teams were even located in three different time zones. Some of the teams performed better than others: I will be honest about that. The teams that performed well had one thing in common: the teams really were a team. They would do everything for each other, everything to realize their goal. Everything to be successful as a team!
Tools solve most of the problems that remote working team members encounter. However, there is one team characteristic that tools can’t solve: team camaraderie. Building the team, making sure they act as a team is important. When you have a team that will rely on each other to do a good job, it doesn’t matter where they work. The organisation should make sure they do everything to build a great team. A team where members trust each other. Where they can rely on each other.
There are many practices to build great teams, think about defining team values, making personal maps, do shuttle diplomacy, define clear work agreements, etc. Beside good tools, you need to invest in team relations and you need to continue investing.
The agile manifesto states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” This for me is one of the most important principles.
Nowhere in the Scrum guide, it says that a team should be co-located. Additionally, nowhere in the Agile Manifesto it says that a team should be co-located. Focus on building relations and interactions between team members and make sure they have the right tools and hardware to get the job done!
What do you think about distributed Scrum teams?
This is probably my last post of 2016. In total I wrote 12 blogpost so far. Explaining Management 3.0, trying to explain why I don’t want to implement the Spotify model but also describing how to create an auto-reply script in GMail.
Let’s close the year with just a small and easy to read blog. Some of my friends work in construction, they have a van fully loaded with tools and materials. Every year we participate in the local carnaval parade, we build a small carriage. Having friends with a van full of tools and materials is very handy 🙂
I don’t have a van but everywhere I go, I take my rucksack with me. The rucksack contains my tools and materials.
So which tools and materials do I drag with me all over the world?
That is it… so next time you see me dragging around that rucksack you know what is in it.
Last year, I wrote a blog about how teams can discover their team values. This year, I helped several customers to improve their way of working with distributed teams or got them started working in a distributed environment. This again included the discovery of the team values. Having team values, talking about team values and making them visual are all important activities to grow your team culture. You can’t decide on team culture or assign a culture to a team.
Now when I work with teams to discuss values, there are some values that get mentioned a lot – values such as trust, respect, etc. When a team asks me how many team values they can have, I always tell them as many as they want. Just look at Big Value List of Management 3.0 to get inspired. I believe, however, that it will be difficult to work with 42 values… so most teams end up with 4 to 7 values and trust, respect, etc. are often part of those values.
Then again, it always makes me wonder… please note that I don’t want a team to skip those values, but on the other hand… they are so basic: should you really mention them?
Values that most teams, and thanks for that, explicitly mention as their team values. So that again made me wonder… next time when I am on a discovery with a team, why not mention “The Five Universal Values” from Rushworth Kidder as a given. Teams don’t need to mention these values explicitly anymore as part of their team values. This will give the teams the room to focus on their unique set of team values, as I believe and hope that the “The Five Universal Values” are always there, in any culture.
But what happens in case the “The Five Universal Values” are not present in a team? Well, then you’ve got a problem. A problem that you won’t solve by just identifying team values.
This blog first appeared on LinkedIn: https://www.linkedin.com/pulse/respect-team-value-ralph-van-roosmalen.