The first time I heard about scrum was around 2009. I am usually not an early adaptor 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 year’s back I decided to dig a bit deeper and found out that scrum is way more than a hype.
In his article ‘Scrum is a major management discovery’, Steve Denning explains the origins of scrum and why it should be applied to the whole company and not only to the software department. In Steve’s words:
“If there was a Nobel Prize for management, and if there was any justice in the world, I believe that the prize would be awarded, among others, to Jeff Sutherland, Ken Schwaber and Mike Cohn for their contributions to the invention of Scrum.”
At the basis of scrum lies the Agile Manifesto, a set of guidelines to drive team behavior. Steve translates this to broader management in an interesting way:
“If you extract the practices of Scrum from the esoteric vocabulary in which it is expressed for software developers (“sprints”, “burndown charts”, “product owner”, “scrum-master”) it comprises in essence the following core practices:
- Organize work in short cycles:
- The management doesn’t interrupt the team during a work cycle.
- The team reports to the client, not the manager:
- The team estimates how much time work will take:
- The team decides how much work it can do in an iteration:
- The team decides how to do the work in the iteration:
- The team measures its own performance:
- Define work goals before each cycle starts:
- Define work goals through user stories:
- Systematically remove impediments:
None of these practices is by itself new. What is new is doing all the practices together in a disciplined way of getting all work done.”
Although some people claim that Scrum is meant to be practiced with collocated teams, I am a strong believer in the power of distributed scrum. Of course, working with people in one office is ‘easier’. We’re creatures of habit and we’re social, so if we can work like we always did and talk to each other all day long, it feels more natural. With software development, it does help to have your team at arm’s length. But distributed teams are today’s reality. And I have not found a better process than scrum in a remote collaboration.
There are four reasons why scrum is the best solution to manage distributed work. And these four reasons hold true for any type of work, not only software development. For managing other types of distributed work, I have found ‘the Rockefeller habits’ to be the most effective process. A lot of elements are similar to Scrum. Let’s look at the four reasons:
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 marketers, 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
As you see from the above list, several points state ‘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 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.
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. For other work, the Rockefeller habits offers a strong framework. There are four things that both methods have in common which are specifically 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.