How We Do It: A Case Study in Virtualized Agile

Author, Mark Kilby

Author, Mark Kilby

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?

Three Characteristics

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.

The following two tabs change content below.

Mark Kilby

Agile software project mentor helping organizations achieve profound productivity, increased quality, and intense customer loyalty to rapidly adapt and thrive in today's marketplace. Interests include organizational change breakthrough methods, collaboration techniques and technologies for distributed and co-located teams as well as automation of software construction to allow developers to focus on craftsmanship and quality.

Related posts