Blog

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 hugo@ekipa.co).

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):

Sprint Planning
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.

Daily Scrum 
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.

Sprint Review 
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.

Sprint Retrospective 
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.

Conclusion

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 hugo@ekipa.co.