I met Hugo Messer a couple of years ago, when I connected with Bridge Global who started publishing guest posts from me. We talked about working with remote teams to find out that our thoughts on this are quite similar. In this guest post Hugo explores how Scrum can help distributed software development teams.
I’ve been working with distributed teams for over 10 years. I’ve learned through trial and error what does and does not work when your teams are spread across the globe. I am usually not an early adapter because I have seen so many hypes; stuff comes and goes. My suspicion was that Scrum would be one of those hypes. Software development companies suddenly all claimed to be agile and work with Scrum. And in many cases this is marketing talk, not operational reality. But a couple of years back I decided to dig a bit deeper and found out that Scrum truly helps distributed software teams.
There are four reasons why:
1. You work in short cycles
Each ‘sprint‘ takes 1-4 weeks (Scrum typically talks about 2-4 weeks, but in my experience 1 week can bring wonders in some projects). In a remote collaboration, you don’t speak to each other regularly. You can’t see what your foreign colleagues are doing. If you have a big project and you organize that work as a long term big project with deadlines far ahead, you loose ‘grip’. With Scrum, work is cut into small iterations. Each 1-4 weeks you plan the sprint, the team gets to work and you see results after the sprint. This enables the team to learn faster what does and does not work. It also enables the team to incorporate changes brought by new ideas and customer feedback.
For more general management, this is also very valuable. If you have a team of let’s say marketeers, they have projects. Those projects may span many months. By cutting those projects into weekly iterations, you continuously have an orchestrated team effort to bring those projects to completion. And because you learn and implement changes along the way, the result of the project is better.
2. The team decides
With a remote team, it’s crucial that you move the authority for the results of your project to the remote team. You can indicate and discuss with the team what you believe needs to get done. But the team decides ‘how’ they’ll tackle this. I think this is a powerful management mindset. You have hired a team of experts. Those experts know their line of business. So you should let them decide how to complete your projects. If you bring your car to a garage, you trust the mechanic to fix it (because you probably have no idea how to do it yourself).
One ‘method’ that I often think about during my workdays is ‘monkey management’ as described by Ken Blanchard. Here’s an excerpt from ‘how we lead‘ that explains well what monkey management entails:
A “monkey” is the next move after two individuals meet, as illustrated here: Say you meet an employee in the hallway. He says, “Can I see you for a minute? We have a problem.” He explains; you listen; time flies. Twenty minutes later you know enough about the problem to realize you’ll have to be involved, but you don’t know enough to make a decision. So you say, “This is very important, but I don’t have time to discuss it now. Let me think about it and I’ll get back to you.”
The detached observer understands what just happened, but when you’re in the middle, it’s harder to see the big picture. Before you met your staff member in that hall, the monkey was on his back. While you were talking, the matter was under joint consideration, so the monkey had one leg on each of your backs. But when you said, “Let me think about it and I’ll get back to you,” the monkey moved squarely onto your back.
The problem may have been part of your employee’s job, and he may have been perfectly capable of proposing a solution. But when you allowed that monkey to leap onto your back, you volunteered to do two things that this person was generally expected to do as part of his job: (1) You accepted the responsibility for the problem, and (2) you promised him a progress report. Just be sure it’s clear who’s in charge now, your staff member will stop in on you several times the next few days to say, “Hi! How’s it coming?” If you haven’t resolved the matter to your employee’s satisfaction, he may begin to pressure you to do what is actually his job.
3. The team measures its own performance
In scrum, a software development team often measures its own velocity. Velocity as defined by the scrum alliance:
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
Velocity is the key driver of performance for a software team. In most software tools that support remote software teamwork, velocity is calculated automatically.
For broader management, it’s useful to have the team members define their own KPI’s. Let them think what’s the most important impact they can have on your project and how to measure this. They can report progress in a sheet or system each week, which you then discuss in your weekly meeting. I always use a google sheet which has a KPI dashboard on top. Each team member can access this sheet so the whole team knows what each person’s up to. You can use my free top priorities template for this (let me know your thoughts about the sheet via firstname.lastname@example.org).
4. Meeting rhythm
Scrum has a structured set of meetings. This excerpt from the scrum primer describes each meeting (I recommend the Scrum primer to learn more about scrum):
Summary: A meeting to prepare for the Sprint, typically divided into two parts (part one is “what” and part two is “how”).
Participants: Part One: Product Owner, Team, ScrumMaster. Part Two: Team, ScrumMaster, Product Owner (optional but should be reachable for questions)
Duration: Each part is timeboxed to one hour per week of Sprint.
Summary: Update and coordination between the Team members.
Participants: Team is required; Product Owner is optional; ScrumMaster is usually present but ensures Team holds one.
Duration: Maximum length of 15 minutes.
Summary: Inspection and adaption related to the product increment of functionality.
Participants: Team, Product Owner, ScrumMaster. Other stakeholders as appropriate, invited by the Product Owner. Duration: Timeboxed to one hour per week of Sprint.
Summary: Inspection and adaption related to the process and environment.
Participants: Team, ScrumMaster, Product Owner (optional). Other stakeholders may be invited by the Team, but are not otherwise allowed to attend.
Duration: Timeboxed to 45 minutes per week of Sprint.
In a remote team, this meeting rhythm enables the team to stay aligned. If you don’t schedule this, days or weeks may pass without alignment talks. This can completely derail your project.
For a non software team, the Rockefeller habits uses a rhythm of yearly, quarterly, monthly, weekly and daily meetings to align your distributed management team.
Remote teams can be managed more effectively with a strong process. Scrum is by far the best process to manage distributed software projects. There are four things that are well suited for distributed work: work is done in short cycles of 1 – 4 weeks which enables quick learning and adaptation; the remote team decides on ‘how’ they will get work done, moving the ‘monkey’ fully on their shoulders; the team (members) measure their own performance using velocity or other KPI’s; and there’s a scheduled meeting rhythm which enables the globally distributed team to continually align and progress towards its goals.
About the Guest Author
This is a guest post from Hugo Messer, an expert in distributed agile. Hugo is the co-founder of Ekipa.co.
To help (distributed) teams in the implementation of scrum and agile, Hugo regularly organizes training. He has also written 6 books about managing remote teams. Feel free to get in touch with Hugo via email@example.com.
This Post Has 4 Comments
It is so true: Agile and remote work have many leverage! points. I just came back from a training course with a client about working in remote teams. One of the participants asked me. “Do you think that a scrum project could be done virtually”? His team’s scrum instructor had told them that this could not be done. They should try to work face-to-face. After our training, it was clear that effective work in distributed team and agile principles have very much in common. Obviously, it is not mandatory to follow the scrum/agile “rule book” literally for every project in every business area. But the principles in Hugo Messer’s post hold true for every project in distributed teams: short milestone cycles, distributed leadership (meaning: self organised and focus on team members), thoroughly planned reflecting activities, and extensive stakeholder involvement and management.
Does anyone know where this “Scrum and distributed teams don’t match” come from?
Hi Hans, thanks for the comment! I think it comes from 2 things:
1. Scrum in general talks about collocation > they say collocation is better than the alternative
2. Many people face challenges when they’re not in 1 room and so they prefer to work in 1 location.
I think in general we all have to learn how to work distributed. It’s the future of organization: technology enables us to work from any place on earth and it also helps us live more human lives, where we skip travel, traffic jams and sitting in a cubicle all day.
Software development companies suddenly all claimed to be agile and work with Scrum. And in many cases this is marketing talk, not operational reality.Many companies follow agile scrum process.
I’m unsure how your comment relates to this article Sarah. Can you elaborate on what you are trying to get across, please?