Much of agile software development lore exalts the virtue of in-person collaboration. From literal stand-up meetings to at-the-same-desk pair programming. It’s an optimization for the assumption that we’re all going to be in the same place at the same time. Under that assumption, it’s a great set of tactics.
But assumptions change. “Everyone in the same office” is less true now than it ever was. People are waking up to the benefits of remote working. From quality of life to quality of talent. It’s a new world, and thus a new set of assumptions.
The interesting, and tricky, part of choosing a work pattern is comparing these different worlds. What’s the value of a group of people who a) can only be picked from amongst those within a 30-mile radius of a specific office, b) who have to deal with the indignity of a hour-long daily commute, c) but who’s Agile with that capital A?
Versus a team composed of a) the best talent you could find, regardless of where they live, and b) who has the freedom to work their own schedule, c) but can’t do the literal daily stand-up meeting or pair in front of the same physical computer?
Obviously we’ve made our pick, and the latter setup won by a landslide. But it also made discussions about methodology more complicated.
When you’re talking to someone who thinks that the world is already defined by that first “everyone in the same office” assumption, they’ll naturally champion the hacks that makes that setup more workable. Without necessarily rethinking the overall value of the advice outside that assumption-laden context. Local maxima and all that.
It’s time for a reset. We need the same care and diligence that was put into documenting the agile practices of an office-centric world applied to an office-less world. There’s a new global maxima to be found. Let’s chart its path.
Jeff
on 01 Oct 13REMOTE… now in bookstores everywhere.
Hardy
on 01 Oct 13Good read. I’ve encountered a similar problem with agile in a setup where you have only part time teams. Agile only truly plays it’s full potential in this (narrowly) defined work setup: full-time, same place. If you move away from this local maximum you will have trade-offs. Be it in more communication, more friction or less “clarity”. I think you can compensate this by having more quality/skilled staff like you mentioned – that’s the reason you chose to leave the local maxima – but I’m not sure where the “sweet spot” lies from a pure productivity and quality viewpoint. Replay curious about your experience. Regards.
Joel
on 01 Oct 13Great point! This shift makes so much sense and any discussion about the pros/cons of remote work should take ALL the factors into account. I’m surprised that it’s still taking so long for people to “get it.” Anyways, I’ve been looking forward to months for “Remote” to come out!
Sam Livingston-Gray
on 01 Oct 13Interestingly, having spent the past year and a half doing a ton of remote pair programming, I’m much more strongly inclined to use “remote” pairing tools even on those occasions when I’m in the same physical space as my coworkers. Screensharing across the living room means everybody gets their own comfortable seat, and nobody has to hunch around a single screen, sharing germs and keyboards.
Mark
on 01 Oct 13Is there much of a change with remote workers and applying the agile methodology? I worked at a firm a year ago and we all did our “standup” via Skype and it wasn’t bad at all. Instant Message worked for quick collaboration.
I don’t think the shift is that difficult, it’s more in the mindset I suppose.
Alberto
on 01 Oct 13Remote and agile works fine; I do agree that some practical approaches should be documented. For example, we had our daily 10AM, 10 minute meetings with the team for years. Phone conference, skype, whatever the group needs at the time. The only challenge is deciding 10AM, where? :)
BJ Vander Linden
on 01 Oct 13I’m a firm believer in the principles behind “agile” and remote working. The challenge I face is working in an environment (education) that is still trying to embrace these emerging, powerful ideas. The more information I can find and share, the better my argument for change and growth becomes.
marko schulz
on 01 Oct 13What makes the comparison more difficult: Most companies don’t embrace remote working to find the best talent and give people freedom to work their own schedule. By going remote most companies just want to cut costs (which contradicts „best talent“) and they are afraid to loose control over their employees (which contradicts „work their own schedule“).
Adding the potential problems of remote work, this really makes remote work worse for most companies.
Richard
on 01 Oct 13You are mentioning, the “the best talent you could find”, as if great talent just comes into being. Many organisations and teams also have a need or desire for mentoring and coaching team members to improve themselves. Which i think is one of the appeals of pair programming, the knowledge sharing process, that helps junior programmers to acquire the skills of the more senior team members. I’m not sure yet in how far that maps to the remote situation.
Richard
on 01 Oct 13It seems like the tenet of Agile that is most in conflict with remote working is Scrum. With slight modification to how you share your current status and do your planning I think Agile and Remote can work together.
Rutul Davé
on 01 Oct 13Well put DHH. I would love to participate in charting that path in whatever capacity I can. As we build our team at Bright Funds, we have emphasized on finding the best talent regardless of their physical location, while we find ways to use the best that agile has to offer.
Gregt
on 01 Oct 13Honest question: amongst the ‘remote workers’ of 37S and like firms, does almost everyone literally work at home, vs., how common is it for them to work at a 1-person desk-for-rent type office of the kind that seems to be popping up all over? There is one of these near me and it’s super-cheap, like $250/month or something like that. Presumably people also work from Starbucks, the library etc. as well but I suppose (?) that is more of an every-now-and-then-for-variety type thing?
Adrien Lamothe
on 01 Oct 13Certain companies have been touting extreme pair programming (XP) and TDD as the best way to develop software. Their argument for pairing and having everyone in the same physical location is that such practice diffuses knowledge among the team, so if a team member becomes unavailable his knowledge will not be lost. Such dev shops seek to create “full stack” developers, who can be used as interchangeable cogs in a programming factory.
In reality, not everyone will master the “full stack,” and regardless it takes years to master such a broad spectrum. And certain specialties, such as UI/UX, are in essence very different in thought and approach from programming. So such dev shops end up not strictly following their professed methodology.
Such methodology has merit, but there are different forms of Agile, and they all produce excellent results. The aforementioned XP/TDD dev shops have been disingenuous in promulgating a myth that other software development methodologies are inferior and produce inferior results. I have worked in small groups (1-3 people) where all of us were in different locations, and the results were excellent; we also did not practice TDD. I’ve also experienced very effective results doing Agile where 3 people are sitting close to each other, each person working on their own computer.
Regarding TDD, Jeff Atwood, founder of Stack Overflow, has a blog post where he claims code review is much more effective at reducing software defects than is any level of testing, and he lists a number of case studies to back up his assertion: http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html Testing is still important, but you really don’t have to practice TDD to produce high quality software. Distributed groups of developers working on Github, such as the Rails core team and contributors, are an example of a working methodology where code review is just as important as testing.
David
on 01 Oct 13What Im curious about in these remote setups. Are there any befriending at all going on? If people all work different hours, and its all work, work work, are there any bonding, socializing sort of going on? If not how do you keep the talent, making people care about each other, the project etc? My current experience of remote work is lack luster. I dont even know if my boss is married or really who my coworkers are besides their names. No socializing at all exists here. Have had to force my self upon people to actually get to know who the heck they are. And this is just a company with 15 people ( I think) working remotely and some in groups at some local office.
DHH
on 01 Oct 13David, that’s a real shame. We ensure that socializing happens by doing full-company meetups twice a year, minor group meet ups, and monthly hangout sessions. For remote to work well, you have to have strong social connections.
Gregt, it’s a mix of everything. Some people work exclusively from home, some work part time from a coffee shop, some work from a colocation facility, some go to the office in Chicago.
DG
on 01 Oct 13I personally think you’re dreaming if you’d prefer a dispersed team of hero coders to a co-located team of merely great coders. To downplay the impact of all the spontaneous conversations, the ad-hoc meetings around a whiteboard, the “come over here and watch this” chats is to ignore thousands of years of examples of humans working together to achieve greatness. Yes, the software development world may be becoming more ‘remote’, but don’t try to kid yourself that is about improving effectiveness. It’s about driving down costs. Pure and simple.
Alistair McKinnell
on 02 Oct 13Everyone co-located or everyone remote works great with a reasonable set of tools, attitude, and work agreements. Any mix of co-located and remote not nearly so much.
In no way do I mean to imply that the everyone co-located and the everyone remote teams would have the same set of tools and work agreements. There will be significant differences. As an example, a stable co-located team can rely on tribal knowledge that is largely tacit. A remote team will need to make knowledge more explicit. Note: a reasonable attitude is essential in either circumstance.
Agile as currently understood and documented is a great place to start when everyone is co-located. My sense is that a reasonable set of practices that supports the Agile values and Agile principles has yet to be understood and documented for the team where everyone is remote.
Michael
on 02 Oct 13@DG: It’s not just about driving down costs. We have a two-city setup, with clients and offices in both cities, and two or three people are usually working from home or overseas. We value the offices as meeting places, places that are good for working in, but giving people the flexibility to work from anywhere is (a) humane, (b) a good recruiting tool, (c) what I want as a boss. I want to be able to work from anywhere – why wouldn’t the rest of my team?
gnaluikc
on 02 Oct 131
Marissa
on 02 Oct 13Interesting point – but how about some thoughts/details on how to make an remote working in an Agile environment work? You’re just stating the obvious here, bud. How do we make it work?
Anonymous Coward
on 02 Oct 13Agile as currently understood and documented is a great place to start when everyone is co-located. My sense is that a reasonable set of practices that supports the Agile values and Agile principles has yet to be understood and documented for the team where everyone is remote.
Andrew
steve jones
on 03 Oct 13i like David’s essay on remote and wish for it to work. However, my experience with it has been challenging. http://blogs.hbr.org/2013/03/how-wordpress-thrives-with-a-1/ Automattic does this with a 100% remote configuration. It’s proving much more challenging with us at 50% (the usual issues: trust, jealousy, concerns on productivity). There seems to be a unspoken but sizable barrier of how to trust that the remote worker is not goofing off and really pulling their weight (or more). With part remote and part office, i sense that office-bound folks experience jealousy over the arrangement and sabotage the effectiveness. Would love to hear other’s opinions on how these issue can be overcome.
Hernan Soulages
on 03 Oct 13It’s nice to read you Adrien. Have one of your books here :)
I don’t think that Jeff Atwood’s post on code review is a good parameter to compare effectivity vs testing. It’s based on Code Complete and the information on that book is skewed. The problem with comparing both techniques to uncover bugs is that most programmers can do pretty good code reviews without learning anything new. Most programmers don’t write good tests unless they spend some time to learn how to write them properly, time that it’s not that easy to get. Now that unit testing has a much higher priority in a lot of shops, the effectivity in finding bugs and fixing them early is known to be higher than when the book or the blog post were written.
The important part of code review that you don’t get with testing is that it ends with code that’s understood by at least two developers. If one developer creates code that he thinks is well written, that code will probably be easily understood by a small portion of all other developers (lets say 30%). If another developer also think it’s well written and easy to understand, it will probably be the same for a much higher portion of all other developers (maybe 60-70%). You also get this with pair programming.
In this sense, what I think is the path to Remote Agile Development is to understand the key goals and benefits of each practice and see if we can create tools and practices that achieve the same. For instance, for me the key benefits of standups is to have clear picture of where you stand in your current assignment and that everybody knows what everybody else is doing to share knowledge at a later time. This goals can probably be achieved by doing the standup in a virtual blackboard.
For pair programming it’s a little bit different. There are a lot of benefits going on, like culture/team building, knowledge transfer, team onboarding, avoiding distractions, etc. I don’t see how this could be effectively replaced by remote tools and practice. My choice would be to promote having pairs of programmers working at the same location. It could be two good programmers, or one great with a trainee having a sempai/kohai (or master/padawan) relationship.
Getting the team to work all together from time to time is something that I think is well worth the cost. The productivity goes up for a good time after the meetup, specially the first time around.
mike s
on 04 Oct 13I think in-person is a must for a core team in the early conception/design phase where change is high and whiteboards and napkins are the canvas. This phase may last a week, or a few months.
Once a product vision takes shape and the death march begins, I am open to any resource location strategy that uses ‘pragmatic agile’ processes and keeps people working happy and hydrated.
In my humble view, its ultimately about leadership, not location. A project can hit the ditch in either location scenario, so beware of dogma and keep your eyes on the road.
PostAgilist
on 04 Oct 13Great David! I’ve been talking about this for eons. Agile is based on outdated ideas and needs to be bypassed. Jordan
Quality of communication trumps manner of communication. I have more thoughts about the postagile world on my blogSteve S
on 04 Oct 13This post has a LOT of information and ideas about distributed teams:
http://www.scrumalliance.org/community/articles/2013/july/managing-distributed-teams
Kevin
on 04 Oct 13We’re currently beginning to implement agile development at OnSIP, and we’ve had success so far. One of our Senior Software Engineers works in Colorado (our offices are in NYC), but we were able to eliminate barriers to communication by using a SIP to SIP video phone setup. The traditional notion that agile development must implement physical proximity amongst coworkers is just not true for our company; we’ve been able to communicate clearly and effectively with our engineer in Colorado, who is definitely the best man for the job, and not simply a reasonably good alternative who lives in proximity to our office.
Find out more about our setup here: http://www.onsip.com/blog/2013/10/03/we-find-remote-working-in-agile-development-environment-easy
Rachel Ben Hamou @AgileImprov
on 05 Oct 13David, thanks for sharing these thoughts and inspiring such a great amount of discussion around an interesting subject. I won’t repeat points previously made but I will say that great culture (a culture of caring, kindness and positivity towards your colleagues) will overcome any practical barriers to distributed working and making agile successful in these circumstances. I wrote a piece about this on my own blog if anyone would like to check it out. I’ll definitely be purchasing ‘Remote’ and sharing it with interested colleagues at Riot Games. http://www.agileimprov.com/posts/productivity-and-collaboration-via-distributed-working-2013-09-20.html
This discussion is closed.