I recently spoke at the Agile People Conference 2016 about how I coached a distributed organization use the principles and patterns of Sociocracy 3.0 (also referred to as S3) in order to self-reorganize. In this blog I have collected the most frequently asked questions from the audience after the talk and my answers to them.
You can watch the full video of the talk here:
If you have any more questions, please post them in the comments below and I will answer to every one of them.
How did you know enough transparency and accountability was established?
As for many of the other decisions made in this organization, we created transparency through several iterations and we kept measuring it periodically. We visualized everything! And we created a few short meetings (each for 15 minutes) described below.
SoS (Standup of Standups)
In the first iteration, all of these distributed teams agreed to have a Standup of Stanups meeting every Wednesday and every Friday. One representative from each team was invited to this meeting. Technically everyone was invited, but one from each team attended. The representatives took turn to give an update about their team’s progress, plans and whether they had an impediment they needed help with. And if they needed help with something, they asked and some other team offered to help. Just like a regular daily standup meeting, some discussions were scheduled for after the SoS meeting.
The SoS meeting was eliminated completely after we all learned to create a written visualization of the status of the work. To be honest, it appeared to be a waste of time after we had had it for three weeks. Instead of this meeting, everyone was automatically reminded to update the status page (plan, progress, problems) once a week. All teams got to do this at their own time when they found a moment during the day. The result was not only to give an update to the organization but also to have the latest status and the history of the work available at all times.
As I said in the talk, each team had full ownership of their internal agreements and processes and how they wanted to visualize their work. For communication between the teams however, we had global agreements. We made all of our decisions using the consent decision making model suggestion by Sociocracy 3.0.
PoP (Planing of Plannings)
We agreed to have one planning meeting for all teams distributed across different countries. Every Friday everyone who thought they would add or get value (or cake) attended this meeting. Product Owners attended this meeting to get updates about the progress and give updates about priorities. When something was finished, we got to see it visually on the planning board and we clapped its movement to the ‘live’ column.
Each week before this meeting, the Product Owners made sure the backlog of ‘next’ issues to be developed, is prioritized. During the week prior to the meeting, the Product Owners gathered all the necessary information to put these issues in a ‘ready’ state for developers. This allowed the teams to confidently ‘pull’ their next item i.e. feature, improvement, system, refactoring, etc, to their team backlog. Gradually, the team members who didn’t attend the meeting trusted their representative to chose the item on their behalf. That was mainly because they all had chosen the ‘next’ item together before the meeting. Sometimes there was negotiation between the teams and the product owner about who pulls in what. I boldly claim that’s a sign for having true cross-functional teams.
NOTE: Rotation
The representative of each team for SoS or PoP was not a fixed person. We wanted to share the responsibility amongst all members. Therefore each team had their own way to rotate the representative role inside the team.
Distributed Demo (Review meeting)
Every Friday, before the PoP, there was a Demo (or review) session where we also served cake. The format and tool choice for this meeting also evolved in iterations. In the end, I facilitated the demo session such that everyone in the distributed organization got the same experience. Everyone was equipped with a camera and a microphone. They all sat at their own desks and took turns demonstrating their team’s work. The demo-ers then took questions, feedback and comments. Sometimes there was a need to further discuss an issue. In such cases, interested people discussed the issue afterwards.
Sometimes product owners, customers or other stakeholders joined the demo. They often sat at a conference room and watched the demonstrations. They could also ask questions after the demo.
How do you know when people are unhappy? How do you motivate them?
This is a common question for managers who have not worked with remote teams. If the only reason you need to see people is to know whether they are unhappy(!), you have bigger problems than that. But if you want to make sure you’re doing the right things so they stay happy, then I can share with you what I did.
Instant Messaging
When you’re working remotely, you need to sharpen your writing skills. You need to learn how to convey a tone of voice or an emotion trough writing. Luckily the millennials and Gen-Z are quite comfortable with this style of communication. They use emojis and internet memes to add a tone to their message. That’s what happened with my teams. Naturally the more experienced people also got onboard the IM culture.
As their coach, I was a member of all the chat rooms and often monitored the overall temperature of the conversations in each room. When the usage of memes was going down, often I threw in a meme or a question asking what they were going to demo and engaged others in a conversation about it. If I got low energy responses, I knew something needed attention. Otherwise I tried to cheer up the *room* or I used 1:1 chats to speak to individuals.
Happiness Pie
I also kept track of the biweekly happiness survey. All team members responded to a one-question survey I sent to them. The question was: “How do you feel?”
They could chose from these five options:
- Excited
- Glad
- Indifferent
- Sad
- Mad
I then visualized the team’s responses on a pie diagram and put it on a health check page on the common wiki page for everyone to see. This page triggered the curiosity of the product owners or other leaders. With a little help, they could then address the underlying issue.
Retrospectives
At some point in time, we had six teams. I facilitated all retrospectives. Clearly for the distributed teams, one needs to be creative in facilitation methods and tools. Most of the time we used a free tool called web white board. This tool works just like a regular white board with post its on. I captured the issues that related to unhappiness and helped the teams with those issues.
[quote]It’s really important to create the same experience for everyone, when you are working with distributed teams.[/quote]
Distributed hack Day
We spent every last Friday of every month to explore and sharpen our skills. A few people chose to create something using a new technology. Some worked on fixing things in the product that were annoying to them but were not high priority. Another group worked on creating a new tool to be used by the team. We had ideas of all kinds. The most important thing was that this day was sacred. No meetings or disturbances were allowed on this day. It was a full day of calm and tapping into creativity.
When people stopped showing up to the hack day, I knew there was pressure on the product development or support. The same applied to other fun or free activities.
In my humble opinion, you cannot motivate a group of people by using specific methods. However here’s just the common sense coaching approach that I undertook:
- Chatting 1:1 with every single person in the organization
- Creating personal relationships with people
- Recognizing people as human beings
- Truly caring about them, their fears, their hopes and what they care about
As a leader, when you come from a place of authentic and willingness to help, your people trust you.
When you open up and show a little vulnerability, you make a human connection. You allow others to open up to you too. They can then speak their truth. And that’s what I did. That’s how I knew the underlying issues despite what the symptoms meant in a general case.
[quote]When you open up and show a little vulnerability, you make a human connection.[/quote]
How did you make design decisions with remote people?
In the beginning, just like many other organizations, we had a startup meeting for each new feature. They were long boring and endless meetings most of the time. We changed a few things to address this issue. The most important and effective decision was to have no meeting mandatory.
No mandatory meetings
The values of this decision for the organization were tremendous. Most importantly, it helped people to really think about whether or not they needed to call for a meeting to discuss something or make a decision.
If you need to inform people about something, you can very well use an email to do so. They can then read it when they chose to. There’s no need to ask people to interrupt their productive flow state to just listen to you especially if it’s not urgent. You can also create a wiki page on the intranet. You can inform people in a chat room. And if you really want to offer this information face to face, you can wait for a weekly meeting.
[quote]The reality that most of the topics you tend to create meetings for can be solved via email or IM.[/quote]
Asynchronous distributed design meetings
Since we had realized the value of asynchronous written communication, we made design decisions in that fashion too. One or two people with the most expertise and passion for the new feature (or system) created a preliminary design proposal. They made it available for everyone in the organization via the internal wiki tool. Everyone could then have a look at the proposal at their own time and comment on it.
After a first round of comments, the original proposers then reflected and improved the design as the discussion went forward. Anyone could edit the wiki page (there’a reason it’s called a wiki). Usually after a few days, we had an acceptable design ready to be shared with the entire team and the POs. This made it easier for any team to estimate the work required and for the POs to prioritize better. Most of the time, those who had started the design conversation were the ones implementing the feature. But that was not the case for all features.
Tips or tricks for improving communication in remote teams
I can write a whole book about this topic. Here I will mention just the most important ones from my experience.
Visualize everything
In this particular organization that I was coaching, we visualized almost everything. The product vision was visualized on Confluence. I have to add that this company had a team of Confluence experts who had created a great setup for using of Confluence. We visualized the product roadmap and also what team was working on what item as well as the state of each item i.e. live, in acceptance testing, in implementation, in planned, in unplanned, etc. We had a visualization for all the global agreements, happiness barometer of each team, support issues, bugs and all meeting minutes.
On the product side, we had flat screen TVs in all locations to visualize the status of our Continuous Integration. We also had a running demo of a customer product on another TV. This allowed other people passing by in the office to stop, play around with the live (or in production) product and get a better understanding about what we had created.
Asynchronous written communication
I cannot emphasize this enough. Most decisions are not made in one meeting. From those that are, many did not require a meeting in the first place. There are many tools that companies are already using to enable asynchronous written communication amongst their employees. For example, Jira is used for tracking issues. We literally used Jira for communicating with our users and our team members. The comment field (which most organizations do not use) became yet another effective channel of communication for us. We tagged people in our teams and in the rest of the company to ask question. Sometimes we used that field to provide clarification by adding links to design documents or other documents, etc.
We used Confluence for many other decisions. As I explained above, we made design decisions on Confluence. Developers communicated with each other through comments and collaborative documents on Confluence. We even decided our next fun activity or get-together using a voting macro on Confluence.
Instant messaging is an inevitable tool for a distributed organization. We categorized our work into the teams chat rooms, product feature chatrooms, fun vs work chat rooms, customer support chat rooms, you name it. We also retrospected this division and evolved it periodically.
Be human
Make an effort to chit chat with your remote colleagues. Ask them about their new apartment, their pet, their kids, their last vacation, their future plans. Share photos of yourself from your beach office or balcony, wherever you’re working from. Use video for your daily meetings if possible. Just remember that geographical distance should never become an excuse for you to care any less about the person.
And above all do not treat your employees or colleagues like children who need to be monitored and controlled. Trust that they care about the success of the product and the company as much as you do. Instead make good agreements and help create a collaborative environment for everyone to thrive.
[quote]People offer their best work when you assume people are whole, smart and responsible.[/quote]
If you liked what you read, share it with your friends and press the button below to subscribe to Remote Forever and learn about new posts, workshops and courses.
And please comment below if you have any experience with any of the topics described in this post.
Very interesting and useful, thank you for sharing 🙂
My pleasure Nenad 🙂
Very interesting presentation. Question: what do you mean by cross-location? Google did not find anything useful in terms of definition.
It means across several locations. Sometimes a team is consisting of people who are all in the same place, and sometimes that’s not the case. Cross location, remote, multi-site, cross-site, geographically distributed, etc are all different names to describe the situation where team members are not all working in the same place i.e. office, building, city, county. Based on your Medium articles, I’m guessing you refer to such teams by ‘virtual teams’ 😊
Superb inmrtfaoion here, ol’e chap; keep burning the midnight oil.
Even the Chronicle has their virtual window covered, showing only a few lines, then:“This content is only for subscribers. You can gain access by purchasing a (subscription).”
One thing that I wonder about watching your video: in my experience, the meeting rhythm of scrum works wonders in distributed teams. One of the main problems is the lack of communication; because we’re not in the same office, we just forget to talk and align. Scrum makes meetings mandatory + timeboxed. People don’t want to do meeting cause they want to ‘get to work’ (which is a great virtue). If the meetings are voluntary, I bet people will skip them (I would, because over time they become freaking boring). If we skip them, we get back all the troubles because of non-communication.
How did that play out in this case?
Very good comment Hugo. A very important thing to remember is that you cannot make all meetings optional right away in an organization that is built on blame and punishment! Some cultural changes need to be made before you can introduce the “no mandatory meetings” concept. The most important of all is that leaders need to learn to operate from the assumption that people are smart, whole and responsible. And non-leaders need to feel safe to assume responsibility and show leadership qualities. Training and coaching the people to get to some level of trust and ability to show openness and tolerance is something that needs to be done at the same time as introducing the rule of “no mandatory meetings”.
When you make meetings optional, you start to make improvements to meetings so that every single meeting becomes valuable for every single participant. Also you will identify what meetings can be eliminated (or replaced by some other means of communication such as email, chat, wiki page, etc).
Even a daily scrum standup that is mandatory can lose its purpose after a while and people may fall into those boring status reporting meetings instead of high energy synchronization and focusing-on-the-goal kind of meetings where people come together to help each other out. Every once in a while, you’d feel the need to shake things up. Isn’t that so?
When all meetings are optional, if you (who needs the meeting) show up to an empty meeting where no one else shows up, that’s only an indicator that something needs to change. People are *not* naturally laid back or non-caring. They most probably did not show up because of either of the two reasons:
1. They do not get any value from this meeting.
2. They cannot add any value to this meeting.
Which brings you to think about answering two questions:
1. What am I trying to achieve by holding this meeting? (AKA Purpose)
2. What am I hoping to get out of this meeting? (AKA Outcome)
When no one shows up, instead of feeling hurt and letting things go for too long into non-communication, you as a leader/coach can initiate a chat in the group chat room and tell people the purpose and the expected outcome that you have in mind. Then ask them to help you figure out how you as a team can achieve those. Most often no meeting is needed for achieving those results because people often can suggest some other way to address the issues. Sometimes, they will end up then telling you their frustration with the meeting the way it has been in the past and you can ask questions to find out “what they expect” for a meeting to be valuable.
By having a conversation about it, you together with the team can improve the flow of information and make a more pleasant work environment for everyone. If someone is impacted by a decision made in a meeting, they will want to go to that meeting, wouldn’t they? If they don’t they delegate the decision making power to the group who is making the decision. In the case of the former, you have created a collaborative organization and in the case of the latter, your people trust each other very much. Either way people end up happier.
Also do not forget that constant communication over chat messages is a necessity for a distributed team. So non-communication can only exist if we stop caring about one another. I have written some tips about how a coach can monitor the temperature of the group by monitoring the chat rooms.
It seems that you wrote this under assumption that meeting participants are available to attend the meeting in the first place 🙂
Let’s remember that in many teams members do many different things, particularly if they are volunteering their time and skills. Projects “compete” for our attention. Very often people simply can not attend.
Actually Nenad, Hugo and I were both referring specifically to meetings where people are available to attend. However I have mentioned in the comment about the fact that many meetings can be eliminated or replaced by other means of communication. Read the comment again in case you missed that part 🙂
Also please note that this entire blog is written with regards to a very specific context i.e. agile software development. From your linked website, I figured you’re not working in this field. Please do not assume that any claim is made for all kinds of projects. I am well aware that many of the content of these comments or blog posts cannot be applied to many kinds of projects. Especially the ones that cannot use agile framework in the first place such as building/city construction projects.
I see, thank you for your clarification – also the one above 🙂
Yes, I’m not agile software development practitioner but I’m interested in mixing elements of agile approach with volunteer social change activist collaboration in teams, of all things… I’m convening a group of people with experience in both to make Agile Manifesto Remix.