As maybe most of you already know, the Happy Melly One team is completely distributed. In case you didn’t know let me tell you about our team.
We cover four continents, five time zones, six languages, and eight people. The team, in different settings, has been working together since 2011. You can read more about our team members on this page.
Our zookeeper is Lisette Sutherland. She recently published a book about Distributed Teams. We are not going to promote the book here, but in case you are interested click here. Lisette interviewed more than 100 people. Asked them about their experiences with all kind of different setups of remote teams. The Happy Melly One team is of course also mentioned in her book.
We do everything remotely and use all the best practices regarding remote working.
We always use webcams when we are in a meeting. Webcams are turned on, no discussion about that. Even when one of our team members is still in bed (and decently dressed, no worries). We all have the best headsets; we even once ordered a headset for a team member who didn’t think they needed one (they did!). We all are aware a perfect internet connection is essential.
We use the best tools available, and fit for our team. We use Slack instead of email; all information flows through Slack. Even when you have a question for one person we use Slack. We are in love with threads in Slack. We use Zoom for meetings. It is reliable and always works. When on a group call, you are not affected by the lowest bandwidth of one person (like Skype). Also, the gallery view of Zoom is great because we can see everyone on the call at the same time. We use IDoneThis to have asynchronous conversations every day. We use Bonusly and Kudo Cards to give each other compliments and feedback. We have introduced the concept of a proposal document to be able to make decisions in a distributed team. We use Google Docs for collaboration on documents. And most of all, we apply the concept of working out loud. Yes, we are definitely a showcase in Lisette’s book as proof that remote teams are possible and can be effective.
So far, so good… So what is the problem?
We did not realize that it could have been so much better all these years. This is also described in the book as a must-do and it’s one thing we didn’t do until January this year.
In-person retreats! Sorry if you expected something more shocking. It is that simple.
As I said, we all agree that remote teams can be as effective as co-located teams, however only when you realize it is not like working in the office. You need to set up extra tools, working agreements, hardware, etc.
However, getting together now and then, and looking each other in the eyes while discussing difficult topics, partying together, and being able to work for hours in a row together on a topic is important.
We believe that as a team, we made a huge step forward after our last retreat. One of the most important conclusions from that retreat, which was our first, was that we need to do this every six months.
So our next retreat will be in Dublin at the end of June. Again a weekend of building relationships, working for hours together, being able to make decisions and most of all, having fun. Last time not everyone was able to make it, we had three people joining remotely, this time almost everyone will be able to make it!
So remote teams are great, but meeting each other a few times a year makes things even greater!
I did many projects in my career. I had the role of developer, tester, manager and scrum master. During these years, I can even almost say during these decades (I am getting old…), I learned one thing: I do not like the people who at the end of the iteration, project, whatever, say “I already knew that for many months.” “Err… so why didn’t you speak up earlier?” “You didn’t ask.” Followed by a look from me like WTF-are-you-a-professional-or-not?
I learned about a simple practice, a really simple one to make sure the right information is flowing through the team when necessary. Let me explain, and I will do it based on an iteration.
At the start of the sprint, the product owner and scrum master decide on a sprint goal, the objective that will be their compass during the sprint. When I am involved in a team or when I am coaching a team, I ask them to perform a sprint confidence vote a few times a week. I ask them on a scale of 1 to 5 how confident they are that they are going to meet the sprint goal. Most often, we will vote on Tuesday and Thursday in the first week of the sprint, and on Monday, Wednesday and Thursday of the second week. Assuming a sprint of two weeks that ends on Friday of course.
You simply vote by using your hands. If you show your thumbs (up), you are 100% confident the team will realize the sprint goal. If you show five fingers, a full hand, it means stop! Hold it right there, we won’t make it. The score is on a scale of 1 to 5, where 1 is fully confident we will make it, and 5 is a no way we will make it. Everyone votes at the same time. So, someone counts 1-2-3, and the group cast their vote. Look at the hands, if everybody votes the same number, it is clear. Still, you maybe need to take action. If everyone votes a five, and you all then continue as if nothing happened, then again you will see my WTF-are-you-a-professional-or-not face?
Now the interesting scenario is when a few people vote a 1 or a 2, but some other people vote a 4 or 5… This then implies that some people have information about the progress towards the sprint goal that other people do not have. In such a case, you apply the practice of let’s talk about it. People need to explain why they voted for the number they gave. By talking about it, information will start flowing through the team. When information flows, things become transparent, and it will allow the team to inspect and adapt. I always keep track of the score in the sprint over time, just to see if things are getting worse or not. It sometimes is possible to discover trends in your sprints.
By explaining and using this practice, I got several questions and remarks.
Who is allowed to vote? Should the product owner or the manager who are in the room during the standup also be allowed to vote? I don’t know… what do you think? I personally feel that everyone in the room should vote. Everyone may hold a piece of information related to achieving the sprint goal. If you, as a product owner, think the team won’t make it, but the team is 100% confident, it would be a good idea for the team to update the product owner about the progress.
I also had many discussions about what exactly are we voting for? Are we voting for a great demo, are we voting for finishing all sprint backlog tasks, or are we voting for the sprint goal? Again… what do you think? I would say you are voting for achieving customer value. Who outside of the team would care whether you finished all sprint backlog tasks? Who cares about a great sprint demo if what you are showing is of totally no value to the customer? So, I would say you vote for the realization of the sprint goal. Moreover, I assume your sprint goal is adding value for a customer.
What happens when you work distributedly? Well, nothing special. Why do some people think working distributedly makes things hard or even impossible? Turn on your webcam, as always, and on the count of three, you show your score.
I worked with a team once, who voted the day after their sprint planning. They spent the whole previous afternoon together with their product owner on making a sprint plan and defining the sprint goals. The next morning, so approximately 16 hours later, they all voted and to our surprise, one team member voted a 5. He was totally not confident the team would make the sprint goal. Only 16 hours before, however, everyone committed to the sprint. Let’s call it at least remarkable. We had a good discussion with the team and looked for a root cause of this behavior. That became a different story altogether. The practice of confidence voting got us talking, however, and made things visible.
I said earlier that everyone should vote. What happens though, when someone just got back from holiday, or someone has their first day on the team. Well, I don’t care. IMO, you have your professional experience. You listen to what is being said in the standup and based on that information you vote. Should you vote something completely different than the rest of the team, you talk about it, because someone is missing some information. If you vote the same as the team, it seems you have a good understanding of the progress (or you were just lucky ;)).
We already have so many meetings, is this again an extra meeting? Err, no. I would say you just vote at the end of your daily standup. It will take you just a couple of minutes. Yes, when the voting is done, and the votes are all over the place you need to talk about it. However, I think this is valuable time because for some reason people are not aligned.
Where should we put the flipchart with the score? Somewhere where management can’t see it I assume? Why? I always believe that everyone in the team is a professional, and committed to doing everything (what is legal and possible) to accomplish the sprint goal. I also believe that most projects are empirical projects, that we live in a complex world. Therefore, things will not always go as expected. You can do two things, just ignore it and assume everything goes according to plan or open up so you can inspect and adapt. As you can understand, I prefer the latter. Therefore, in my opinion, there is nothing wrong showing the outside world how you feel about the sprint goal.
Does this practice solve a problem? Nope. Just like itself, Scrum doesn’t solve any of your problems. However, it can help you become more transparent, and with that, you can start addressing your problems.
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.