You might have heard the word “Scrum Master”, “Product Owner”, or “Sprint” before. These are technical terminologies used to define roles and practices within the Scrum framework.
Like other forward-thinking organisations we at Butterfly have adopted the Scrum framework and seen first-hand the positive results that it creates.
A few months ago, in April, I was fortunate to present at the Scrum Australia conference, one of the most prestigious Agile conferences in Australia.
Being the only Scrum Alliance endorsed conference in Australia, Scrum Australia, is a very competitive and very popular event within the Agile community.
The conference featured a remarkable and unparalleled line-up of keynote speakers including Bas Vodde, the creator of Large-Scale Scrum framework; Steve Denning, global leadership visionary; and Manuel Gonzalez, the CEO of Scrum Alliance.
What I talked about
My talk was about how to implement Scrum framework in distributed teams. By distributed we mean when the team members work from different offices. These separate offices can be in the same city, different cities, or different countries.
One of Butterfly’s differentiating competencies is expertise in open-source web technologies. We provide our development services to our clients in a variety of models depending on the project and the client. Some of our clients engage us as a vendor to build an end-product for them, while other clients have internal development teams, and engage us as expert consultants to work collaboratively with their teams.
When working with a client team, we always try to co-locate the whole team. Depending on the project either our developers move to the client offices or the client team members move to our offices. This way we will have the whole team in one location and have the benefit of sharing a physical space and all that entails.
Sometimes, however, especially when working with interstate clients, it may not be feasible to co-locate the whole team so we have to work in distributed teams. Over the past few years, we have successfully finished a number of projects in distributed environments.
Generally speaking the success rate and the quality of distributed projects are lower than co-located projects. But this has not been the case at Butterfly. One of the factors affecting our success rate at delivering distributed projects has been our effectiveness in implementing the Scrum framework within distributed teams.
Scrum Australia conference provided a great opportunity for us to share our recipe with the community.
At Butterfly, we are committed to continuous improvement. To make sure we are always up to date with industry best practices we study everything from academic peer reviewed papers to tech blogs, and we love to talk to other organisations that excel in our industry.
In my presentation, I not only focused on our past experience but also included results from two interviews we did with two other companies excelling at implementing globally distributed Scrum. Additionally, I included findings from the top 7 most popular academic papers on the subject.
So, let’s get into it all. A bit of prior understanding of the Scrum framework will help with the technical details, but I have summarised this in such a way that anyone —even those without familiarity with Scrum— can relate.
A Guide to Distributed Scrum
Implementing Scrum in distributed environments is not an easy task. Especially when the project is undertaken by multiple parties and organisations. Research has shown using the Scrum framework reduces the chances of project failure in distributed environments significantly.
Having said that we should consider that Scrum is neither a silver bullet nor a panacea. This is because there is no one “right” way to do Scrum in distributed environments. Instead, Scrum is based on empirical process control. You must inspect and adapt the Scrum process within your organisation to match your needs.
Why is implementing Scrum in distributed teams challenging?
So why is it harder? The bottom line is that it all comes down to communication. It’s actually common sense — if teams are co-located they will communicate and collaborate better, and better communication means better projects. Besides common sense, there is a lot of research to back this up. One survey of 11 academic papers on distributed Scrum found that communication problems are the most common challenge in distributed Scrum. Another survey of 21 academic papers found the same thing.
The speed and quality of development are proportional to the speed and quality of the movement of ideas between minds. Research has shown that even 10 meters of distance between team members decreases the level of collaboration significantly, let alone off-site team. We really have to try hard and invest a lot of energy to compensate for the distance and keep communication and collaboration levels high.
There is a theory called “media richness theory”. This theory categorises different communication mediums based on a richness metric. To define richness this theory considers the following factors:
- Can the media handle multiple information cues simultaneously?
- Does the media facilitate rapid feedback?
- Does the media establish personal focus?
At the top of the spectrum, we have two guys with a whiteboard. We will have real-time question and answer, you are close enough to see all the little cues like little eye movement, facial expressions, leaning back and forth, and so much more.
If you are on the phone you will only get the rapid feedback but you will lose all of the visual cues. In addition, the voice quality drops so you get a lower signal-to-noise ratio.
If you are in different time zones the richest media is video recording. The real time aspect is gone but video scores the best against other non-real-time media because we have multiple communication channels and can transmit multiple information cues.
Alistair Cockburn has an interesting quote: “communication is like perfume. It gets stronger the closer you get.”
In distributed projects apart from not being able to have face-to-face communication, cultural and work style differences are another impediment for effective communication and collaboration.
Sometimes a very small cultural difference which could look trivial initially can become a major impediment in distributed projects if they are not addressed. One example of this is that some cultures speak much softer than us in Melbourne. So it becomes extremely difficult to hear them over teleconferencing or low-quality VoIP calls.
If you are interested in knowing more about how different cultures communicate have a look at the Lewis cross-cultural communication model
While ethnic culture is a very big communication barrier, another thing that we should consider is organisational culture and working styles. Almost certainly two different offices and two different organisations will have different working styles and organisational cultures. These differences must be identified and recognised early in the project.
Now, the quality of the communication is only relevant if what is being communicated is true. Communication needs to be honest and transparent.
One of the big impediments to honest and transparent communication is fear. Fear is not unique to distributed projects. However, it is more common especially when a client-vendor relationship is involved.
You can see things like trying to look good and in control and not raising concerns. It is very important to not let these fears impede the Scrum values of honesty and transparency. Which brings us to the question of how much trust is within the team.
Trust is only built by being honest and transparent not by trying to look good and in control. It is kind of a ‘catch 22’ situation: you need trust to be honest and you need honesty to earn trust. Sometimes, to make it even worse, these fears are compounded by cultural differences. For example, some cultures perceive asking for assistance as a sign of incompetence.
The best way to remove these fears is to have frequent visits by team members, especially at the beginning of the projects. Frequent visits not only remove fears and build trust, they also help to address cultural differences and the differences in working styles.
What to focus on when implementing distributed Scrum
In our project teams, we want to have presence and awareness, highly collaborative self-organising teams, and honesty and transparency. We want to create an environment embracing the values of openness, courage, respect, focus, and commitment. Based on my experience the most important factors to focus on in distributed projects are improving communication and establishing trust.
The first step to having better communication within the team is to promote the use of richer media types. For example investing in high quality videoconferencing equipment is a reasonably cheap and definitely quick win.
Think about it this way: let’s say you spend a thousand dollars on high quality video conferencing equipment. Even if it improves your productivity by 1% on a half a million dollar project you will be saving $5000. And that’s just one project.
On top of that, the improved communication will significantly reduce the risk of project failure. Wouldn’t it be the dumbest thing if a half a million dollar project failed because of a $1000 cost saving?
The second step to improve communication is to help the team build a better human connection. Be honest and transparent and provide feedback to address cultural differences and different working styles.
Better communication is achieved when people have a better human connection and the best way to achieve better human connection is via social events and working together. We want our teams to have coherence. Coherence comes from the Latin word for ‘sticking together’. We have to form better human connections within the team to achieve coherence.
We don’t want to have tension in the room and we don’t want to be impeded by fear. We also don’t want team members to get defensive and go into protection mode.
So, what do you think is the best way to build a human connection between team members who work in different locations? The answer is frequent travel.
The value we can get out of travel is huge. Frequent travel helps team members to bond and get closer to each other. Team members that are friends with each other and are coherent communicate significantly better, even if they are not in the same office.
Just a quick back-of-envelope calculation shows us how much ROI we will get from frequent travel. For example on a $1M project if travel increases productivity by 10% we will be saving $100,000 compared to travel cost of maybe $20,000 to $30,000. In reality, productivity will be increased a lot more than just 10%
According to Pete Deemer in his distributed Scrum primer, overall improvement in project ROI due to frequent travel because of face-to-face knowledge transfer and relationship building is in the order of 30 to 50 percent of the value of the project.
Improved productivity is just one of the benefits of frequent travel. The biggest benefit is a reduced risk of project failure and improved product quality.
Next, let’s focus on trust. Building trust is of vital importance if we want to have honesty and transparency. The first step in removing fears is establishing trust. The following is a list of strategies on building trust:
- Have a trust budget
- Travel frequently and spend time together
- Focus on increasing human connection and friendship between team members
- Work on a smaller pilot project before moving to larger and more risky projects
- Be honest and transparent
- Take responsibility for mistakes and avoid the blame game
- Be clear on the common goal
We need to make sure there is a sense of unity in the team. Some of you probably have recognised the symbol for existential quantifier below. When you add an exclamation mark to the existential quantifier it becomes the uniqueness quantifier. This is the symbol used in mathematics and logics to denote the existence of one-and-only-one. So this phrase reads there exists, one and only one team.
Rules of thumb for success in distributed scrum
To summarise, here are a few rules of thumb to follow in distributed projects:
- Distributed projects have a higher risk than collocated projects. This means it is very important to utilise the Scrum framework to manage the risk and complexity.
- Focus on improving communication and trust
- Travel and co-locate as frequently as possible
- Use technology to the fullest — get high-quality video-conferencing equipment
- Get Scrum training and hire expert coaches to set up the best systems for you
- Inspect and adapt
If you are interested, you can download the slides and references from my presentation here:http://www.slideshare.net/ScrumAustralia/arash-arabi-a-guide-to-multiorganisational-distributed-scrum-61699892
Conference highlights and interesting moments
Instead of writing about the interesting moments of the conference I thought it would be more interesting to share tweets of those interesting moments from the conference attendees.
So to finish up please enjoy tweets from the Australia’s foremost Scrum event, #auscrum.