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?
So many different opinions on all kind of topics and it seems like people always want you to choose between left or right, up or down, etc.
McDonald’s is a restaurant. You maybe don’t like the food or have other ideas about the definition of a restaurant. But is a fact, McDonald’s is a restaurant. My daughter is 14, within two years she is allowed to work at McDonald’s. She could work in the kitchen, prepare my food. I love her, and she has great talents, but I did not yet see the talent of cooking food. Still, she will be allowed to work in a kitchen in two years. (Update: her talent for baking cakes is developing well)
I believe in Management 3.0. I think it can help you manage complex adaptive systems, or in other words organizations. However, the kitchen of McDonald’s is not managed using a Management 3.0 approach. It is about order, rules, and checklists. And I am very happy it is not a Management 3.0 organization, taking into account that my daughter will be able to work at McDonald’s in two years :).
De Librije is a restaurant in The Netherland and has three Michelin stars. I just checked.., they are almost fully booked for the rest of the year. I have seen a documentary about this restaurant, and their kitchen is nothing like McDonald’s (yeah duh… you think). The management style in their kitchen is Management 3.0. It is about creativity, experiments and taking responsibility, on every level.
McDonald’s with Management 3.0 would fail, De Librije with Management 1.0 would fail.
When I ask people for Management 1.0 examples, people often mention the army. But is that really true? I disagree with the statement that the military is completely and always Management 1.0. Imagine you would be send into battle with a team, and you have to ask permission for every decision you want to make to the commander in HQ. The same for him, he has to ask permission from his commander. You would lose the battle. However, when the battle is over, things will go back to Management 1.0. Based on the situation, a management style is decided.
An important meeting within Scrum is the daily standup. Most Scrum Master will tell you, that when you don’t do a daily standup, you don’t do Scrum. But is that really true? When my team is sitting in one room, including the Product Owner, and they have extensive communication during the day, I don’t mind if they skip the daily standup. I know they will communicate about progress and impediments. They don’t need that safety net. It will be different when I coach a new distributed team. In that case, I strongly advise the team to have a daily standup.
You can have the same discussions on the topics I mentioned at the start of this blog post. Yes, sometimes SAFe will be a good approach, but also sometimes LeSS will be a good approach. There will be projects where a waterfall approach can help you but also projects where Scrum will give you most value.
Always look at the context, what could work? Don’t judge any method, framework or whatever upfront. Most approaches can give you value when you use them in the right context.
Maybe some of you did a Management 3.0 workshop, maybe some of you read the books about Management 3.0, or maybe some of you read some experience blog posts. In most cases, you will have read about Delegation Poker, Moving Motivators, Personal Maps, Competency Matrices, etc. Just to name a few of the popular practices of Management 3.0.
Most people think about how they can apply these practices in their role as team lead, manager or coach. Applying the practices on other people… that is easy… but is it completely fair? Using your team members as guinea pigs for the things you learned or read about?
So, did you ever think about how to apply these practices on yourself? Let’s take a look at some of the different practices and how they can help you as a professional.
Personal Maps is a technique that is often used as an icebreaker in new teams. People can learn more about each other and really get to know people.
You can, of course, create your own personal map, but I don’t expect it will present you with many surprises. However, what would happen if you ask your team members to create your personal map for you? A personal map of the manager – what do they know about you? Which values do they think matter to you? Do they know your experiences, strengths and/or weaknesses?
When people ask me about how to apply Moving Motivators, I sometimes share the experience that I had with an engineer who was not really happy in his role. I used moving motivators to give him insight into his personal motivators and I was then able to link them to his current role.
Are you really happy at your job? Are you delegating things you really like to your team members? Do some people in your team really annoy you? Let’s be honest, every manager once had or will have people on their team that they are not particularly fond of.
Play the moving motivators game with yourself and find out what your motivators are! If it turns out you like order, you will understand better why you always get agitated when you look at the desk of your marketing manager. Do you also dare to share your motivators with the team? Why not let them know which things motivate you? They can also help you create an environment where you are more motivated.
The most common application of the delegation levels is by you as a manager creating a delegation board with the team. A board that defines and sets boundaries on particular work areas.
One less common approach is to first ask the team to play delegation poker on the areas you would like to define for yourself. It could surprise you how the team perceives the current delegation levels. Are you really that manager who applies servant leadership or are you seen as the dictator who needs to decide on every minor detail?
Look back at the last five decisions made in a meeting – meetings that you attended. What was the delegation level that was actually used? Was it you who in the end made the decision, or were you checking LinkedIn while the team made the decision? And how happy are you about this delegation level? Do you think the team should have made the decision, do you regret that you checked LinkedIn? Just keep track in Excel (you are a manager 😉 )for a few weeks what the delegation levels are. Are you aware of your actual delegation levels?
As you become an official manager, things tend to change. You are no longer one of the guys or girls. You may still believe that you are the same as before you were a manager, but things change as you become a manager. When you enter the coffee corner, you may notice that people stop talking, and for some reason, you don’t hear all the gossip anymore. Maybe you are lucky and you work in an organization where things don’t change that much – well, lucky you then.
You ordered set of Kudo Cards for the team, it is a nice Management 3.0 practice. However, as a manager you are no longer part of the crew, you belong to another crew now, so you won’t get any…poor you. There are six different kudo cards. Put a set of those six different kudo cards on your desk. Every week on Friday, look at the different kudo cards: can you write a kudo card for yourself? Did you do something great this week, something great for the organization or your team? Use the kudo cards to instill a moment of self-reflection: where did you make the difference? And if not… what do you need to do next week to be able to give yourself a compliment?
And probably you are now thinking to yourself: “I am not going to give myself a (mental) kudo card.” Why not? There is a Dutch saying: “If you don’t tickle yourself, nobody else will…”
12 Steps to Happiness
I know you are a good manager or do I? You are doing everything possible to implement the 12 Steps to Happiness for your team members. Happy workers will be more productive and engaged. So you got them a nap room, fresh fruit every day, they can go for a daily walk, etc.
But what about yourself? What are you doing to implement those 12 steps for yourself? Do you think you are too busy to have a healthy lunch? You think you need to make 60 hours a week? Be online 20 hours a day? Have meetings always inside instead of taking a walk around the block with your people?
When you are happy as a manager, you will radiate happiness to your team members. Take some time to look at the 12 steps and implement them also for yourself!
In 1961, president Kennedy said in his inauguration speech: “Ask not what your country can do for you, ask what you can do for your country.” So after reading this blog post: ask not what Management 3.0 can do for your team, also ask what Management 3.0 can do for you as a manager!
Yeah right… and Management 3.0 is only about Kudo Cards and the game Moving Motivators?
I don’t know if you know Scrum? Scrum is a framework that makes it easier to deal with complex projects. It is based on three very important principles: inspect, adapt and being transparent. Every serious scrum master would shiver when you would say: “Scrum is just about doing daily stand-ups.” The daily stand-ups is just a practice, a practice that supports inspect, adapt and being transparent.
Continue reading here…