This is the first part of a multi-part series about how the OpenDNS Dashboard team adapted the practices of agile software development to our needs – the lessons learned, the mistakes made, and what has continued to work well.

The team had been operating fairly efficiently for the past eight months. We had our ups and downs when it came to estimating the amount of time to finish specific technical tasks, and the occasional miscommunication, but what team hasn’t?

Could we do better? Could we become more efficient? We wanted to answer these questions, and upon beginning the process of answering them we also, unknowingly, began a process that was an exercise in transparency.

The Team

The team is comprised of myself, an engineering manager, plus a product manager and six engineers. We are neither the largest nor smallest team at OpenDNS, but we are one of the more varied in backgrounds and abilities. Two of our engineers reside in Vancouver, working at our other awesome office, while the rest of the team is here in San Francisco. This separation has always made for challenging communication; Google Hangouts sometimes doesn’t work and finding quiet places to talk at either office can be impossible. Even with these known difficulties we decided to add a whole new layer to the mix – ” programming” (more on that later).

Pair Programming

Training: Agreements

“Agile” has been a rather contentious term over the past 10 years and has come to mean different things to different teams. To succeed we knew the team needed to get to a common understanding. We brought in a specialist from Industrial Logic to help us. He walked us through the various Agile methodologies and concepts, and even had us build mock engineering projects using Agile methodologies. The training was eye-opening for a lot of us.

The key element to the success of our training was something called “team agreements”. Team agreements are a set of guidelines produced by the team that help the team come to a shared sense of behavior and responsibility. An example of an agreement might be, “We agree to be fully present during meetings.” “Fully present” might mean different things to different teams, but for us, it means that our phones and computers are put away and we’re all participating in the conversation.

Any team member can propose new agreements or propose amendments to existing agreements at any time, and once an agreement is accepted it is up to the team members to uphold the agreement. These aren’t rules or mandates but simply a way of saying that “this is the way we want to work together.” It is important that every member of the team fully support each agreement or they simply won’t work.

We like to post our agreements in a place that both the team and other members of the organization can see any time they walk past. Our initial team agreements:

  1. Pair programming is highly encouraged, but not required: we believe that having more than one person working on a problem reduces the number of bugs and increases the overall quality of the code
  2. Unpaired code follows a code review process, which is tightly coupled with Github: Enterprise:
    1. Create a pull request in Github
    2. Find at least one person to review the pull request and get feedback from them
    3. Make revisions based on feedback
    4. Merge pull request into the master Git branch
  3. Code deployments to customers are okay Monday – Thursday until 4pm; outside of those hours only bug fixes are to be deployed to customers
  4. Be fully present during meetings

To tell you the truth these agreements are our third revision since coming out of Agile training. Our original agreements were a bit too focused on already established Agile practices, and we didn’t think they were adding any real value to the team. We decided the agreements you see here would be a great revision to the original, and so far they have worked pretty well for us.

This post is categorized in: