One of the principles behind The Agile Manifesto states,“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” I couldn’t agree more! However, for three years, I ran a dispersed team which could not meet face-to-face. Of nine team members, only two were co-located in the same commercial office. The rest of us worked from home offices in Arizona, California (3), Kansas, and Florida (2). When I tell people we were doing agile development and implemented Scrum, an amazing number tell me we were not agile because we were dispersed and thus “in violation of” the above principle. Yeah, right!
This is a principle behind the Agile Manifesto. The Agile Manifesto itself states, “Through this work we have come to value: Individuals and interactions over processes and tools.” Individuals and interactions is exactly what we had – a few of the former and a lot of the latter! In a perfect world, we’d all co-locate, someone would get my Diet Coke and rub my shoulders and….well, they didn’t specify the kind of interactions! 😉
“Through this work we have come to value: Individuals and interactions over processes and tools. – The Agile Manifesto”
What Others Are Saying
Jeff Sutherland, co-founder of Scrum, wrote an article with Peter Valhansky and Anton Victoroy for the Agile Journal, Hyperproductivity in Large Projects Through Distributed Scrum. In the article, the authors state that one of the”new best practices” is to have “no distinction between developers at different sites on the same team”.
There are two critical points in this one statement; “different sites” and “same team”. You do not have to be co-located to be on the same team! Everyone was equal despite someone having more familiarity with a particular topic, or a longer background in the field, or better subject matter expertise, etc. We were a team, with no “I”. If you are to be agile across long-distances, you must work to break down all barriers and form a team that behaves as-if it were co-located. As ScrumMaster, it was my job to ensure that everyone respected each other as an equal team member. To that end, I have a golden rule for the teams I lead: “You may critique anything, but you may never criticize anyone.” In other words, don’t make it personal!
“You may critique anything, but you may never criticize anyone!”
Scott Ambler, with thanks to Erich Gamma, John Kellerman, and Ian Skerrett, describes the Eclipse project in “Imperfectly Agile: You Too Can Be Agile!” for Dr. Dobb’s Portal. He points out that the Eclipse development team has “managed to successfully deliver six major releases over the years” and that “it has done so on time, every time, by following an agile process.” Sounds successful, right? Now, consider that, according to the authors, the Eclipse project is “comprised of 10 projects, with 23 subprojects, and 262 committees working for 15 different companies in 12 different countries“. It can be done on a very large scale!
Over on the Agile Software Development blog, a member by the name of Vaibhav posted the article, “Distributed Agile Development -1: Reinterpreting the manifesto”. In his post, Vaibhav points out that “the manifesto was put together in 2001; a long time ago by software industry standard.” The article goes on to point out that “offshore development (the primary scenario for distributed development) was beginning to gather momentum, but most such development occurred using the traditional heavy-weight development methodologies.” Vaibhav gets to the crux of the matter by asking, “How do such teams cope with being almost totally against the spirit of one of the principles of the Agile Manfesto?” Geographically dispersed teams encounter different issues the further the geographic dispersement is. Our team had no communication problems whatsoever. I have heard horror stories about US companies that have contracted with Russian firms only to sever the relationship and find all the class and method names in Russian after taking over the code base. I’ve also heard the stories of two and three hour meetings every day between dispersed teams just to review code and work out issues that arose because of a misinterpretation of earlier communications (i.e. specs). No one said it might not be difficult, but a large part of being agile is to constantly inspect and adapt. As the ScrumMaster, I always tried to keep the bigger picture in mind and inspect the team’s environment working to minimize distractions and disruptions. I tried to let the team focus on the Sprint tasks and jealously guarded them from outside interference while at the same time inspecting their inner workings to see that we were doing everything possible to be moving in a positive direction towards our many goals. The process of inspection and adaptation is never ending and being geographically dispersed only adds to the complexity that you must work to simplify!
Martin Fowler wrote about the pain offshore development inherently brings with it in an article on his website entitled “Using an Agile Software Process with Offshore Development”. In the article, he points out “the weak spots of offshore development come from culture and distance with the business. Because agile development works best with close communication and an open culture, agilists working offshore feel the pain much more than those using plan-driven approaches.” He concludes his thought on this by saying, “but it’s still less pain than the plan-driven methods themselves!” If I interpret this correctly, he is stating that while there is definitely some pain associated with a geographically dispersed team that a co-located team would not experience, it’s not only acceptable to use agile methods in a geographically dispersed environment, but preferable!
Distributed vs. Dispersed
One thing that has interested me about the above perspectives is the intermingling of “distributed” with “dispersed”. To me, these are two distinctly different scenarios. Dafydd Rees appears to agree with my interpretation (or I with Rees) in the article “Distributed Agile Development” on i.t.wales.com. In the article, Rees points out the definitions of Distributed development and Dispersed development:
“Distributed development: This usually means co-operation between several teams located at different sites.”
“Dispersed development: Dispersed development refers to individual developers located separately, working together over a network.”
I would have reworded the definition for Dispersed development to something like “refers to geographically dispersed developers working together as a team.” What I have been examining in this post then is not a distributed development environment, but rather a dispersed development environment.
In my opinion, dispersed development refers to geographically dispersed developers working together as a team. Therefore, dispersed agile development refers to geographically dispersed developers working together as an agile team.
Co-location, While Desirable, Is Not Absolutely Necessary
Yes,physically being face-to-face is the most desirable means of communication. However, it is not absolutely necessary in order for an agile project to be successful. There are many, many organizations proving this today. What I am looking forward to is the realization by large organizations that onsite presence of the developer is not necessary! After all, if you can make it work across continents, then you can make it work – period.
The productivity on our small team shot through the roof when I sent them all home. They knew it was a privilege, not a right, but more importantly, they knew that the company truly valued them to show them that kind of trust. Believe it or not, there was a significant reduction of distractions (these are professionals with “real” home offices) and they were able to focus in like lasers on their tasks. Now, make no doubt about it, there were things we would have done differently, but co-locating the team is not one of them. No one could argue with our success!
It took a lot of work from me as ScrumMaster to make sure the company as well as the customer were comfortable with the arrangement, but once both saw that the productivity was not dropping off but continuing to increase over time, they were on-board with the arrangement. I took it to be my responsibility as ScrumMaster to ensure that the company and the customer knew on an ongoing basis the continuing high-level of productivity that was coming from the team. I know at least one of my trainers from my Certified ScrumMaster course would argue that this was outside the role of ScrumMaster, but as I’ll post later, I believe the ScrumMaster serves all the needs of the team, not just the easy ones or the ones they’re best prepared for. I believe the velocity of the team has as much to do with the ScrumMaster’s ability to serve the team’s needs as it does with the capabilities of the team members! In the case of a geographically dispersed team, the ScrumMaster is a busy individual!
So, the next time someone tells you they’re doing distributed agile development, please correct their misuse of “dispersed agile development”. And, the next time someone tells you that you can’t be agile if you’re dispersed….give them some body language to help them understand that you can indeed do dispersed agile development!
You’re not agile if your team is dispersed….. this manifiesto greatly depends on what kind of company your business is into. Agility can still be present even with spread out employees as long as communication are all circulated to one person. With the technology today, distance is a no problem to communcation. In fact any person can be in touch even if they are both located at both ends of the earth and they can still be agile in their work.
My point exactly!
Interesting article. We have a bit similar situation, with individual developers and project managers living in three different countries and three different cultures, with up to six (6) hours of time difference. How do you see the need for all persons in team to be online and available same time during project? How did you arrange it with time differences and people working/being in different rhythms? We have some challenges in this and would love to hear your experiences on it.
My team’s current spread is 3 hours so it’s not as tough as when we were spread 11. During that time, we had to plan very carefully for those activities that did require the entire team be present. We prepared well in advance (i.e. read ahead material), set an agenda and a time box the meeting. We split the time difference and met in the middle. I would estimate we were able to complete 90% of the activities with careful planning. As much as possible, we coordinated such that the team on one continent would not impeded the other; we documented everything (we’re now using Confluence to achieve this) and I made certan that every team member knew everything there was to know about the project. We had some working ETL with Java, others working a front-end with J2EE, some working an Oracle backend, but I made sure everyone knew who was doing what, when and why. If someone from one continent needed something from the other, they could reach out to anyone and get what they needed. Now that we’re 3 hours apart, we all scrum together late morning Pacific. I make sure to spend time after the scrum answering any questions but also asking questions to be sure people understand where things stand. Geographically dispersed teams require greater effort on the part of all team members, but agile methodologies certainly ease that effort, IMHO. I wouldn’t want to do it any other way.