When I joined Sonatype earlier this year, I joined for two reasons. First, I was intrigued by the unique work environment: everyone works out of their home or a remote office. What makes it more intriguing is that we work within an agile project management framework. If you have read anything about agile, you will find an emphasis on face-to-face communication. So a work environment where everyone is remote seems like the antithesis of agile.
What I found was a highly effective software delivery team. When I joined, the CLM product team was using the scrum agile framework for a year. They had grown to a point where they needed to split into multiple teams of 5-8 people each. This is a typical size for an agile team to maximize communication and self-organization among team members. The roles of product owner and scrum master were also taken on by highly skilled staff members.
In observing further, I found most of the typical ceremonies you would see in a scrum team including sprint planning to plan features to be developed in the next two week iteration, daily standups for the team to check their progress, sprint reviews to review completed increment of the product every iteration, and retrospectives for the team to inspect and adjust their process so they could be more effective. They also had a product backlog that they refined regularly and collaboratively.
The Case Against
Yet many agile gurus would say that a team that is completely remote cannot be as effective as a co-located team. Even the often-referenced Agile Manifesto states that face-to-face communication is the most efficient and effective method to communicate with and within an agile development team. How was this team making and meeting its commitments every sprint?
I have found three characteristics of these teams that makes them highly effective using agile methods.
#1 – Years of Industry Experience
First, everyone is remote and highly experienced. The playing field for these teams is balanced so that everyone needs to communicate in the same way. Also, everyone has years of industry experience and has the professionalism to maintain high technical standards and hold each other accountable to those standards.
#2 – Comfortable with Open Source
Second, many on the team have experience with open source software (OSS) development. This means they are comfortable with the primary purpose of the product line being developed. It also means that they are comfortable with many forms of online communication whether it’s synchronous or asynchronous.
#3 – Experience with Agile
Third, several team members had worked in agile teams before. They had seen what worked and what didn’t in both co-located and partially distributed teams. This allows them to be more effective in adapting their process through the retrospectives.
Where We go From Here
In this blog series, we will be sharing more about how our distributed agile teams operate because many of our customers are seeking to work the same way. We hope they find this series useful. Also, on November 18, Mike Hansen and I will be delivering a webinar where we will talk more about our distributed agile teams and spend a significant time answering your questions. We hope you can join us then or feel free to post your questions here on TheNEXUS.
Latest posts by Mark Kilby (see all)
- Talking the Talk – Focus on Goals, not Best Practices (Part 2) - April 10, 2015
- Focus on Goals, not Best Practices (Part 1) - April 6, 2015
- Distributed We Stand Together: Common Practices with Agile Teams - January 15, 2015
- How We Do It: A Case Study in Virtualized Agile - October 29, 2014
- How We Do It: New Series - September 11, 2014