5 ms·

More talking about the comments here than the book - but I'm seeing lots of repetitions of the working-alone-vital and teleworking-vital anecdotes. The thing i

More talking about the comments here than the book - but I'm seeing lots of repetitions of the working-alone-vital and teleworking-vital anecdotes. The thing is - I don't care about individual productivity. I care about productivity of the business as a whole. And on that point pretty much all the evidence I can find shows that co-located teams in a war-room like environment are the most productive. (And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - personal preference, getting access to people who cannot co-locate, etc. But for business productivity I'm not seeing much, if any, evidence). Please not that I am not saying: * Telecommuting is bad (I do it - I like it) * Telecommuting projects will fail (D'oh - of course not) * You shouldn't telecommute (of course you should if you want to - but bear in mind that the business may have good reasons to disagree with that decision) * That telecommuting makes you individually less productive (I'm personally unsure about this. I feel more productive when working by myself, but I know that personal perceptions of productivity can be false. Measuring personal vs team/company productivity becomes hard in anything less than the short term) * That co-location is always the best solution (it isn't - other factors like team location and skills come into play) What I am saying is that there is a lot of research showing that co-located teams in war-room like settings are much more productive. This runs counter to many developers preferences (mine too ;-) so it tends to get ignored. So much more productive that solutions like 'Let's fly everybody to the same place and pay their room and board for a month' can be cost effective. Here are some references to the research (If anybody has any research that contradicts this I'd love to hear about it. Especially if it talks about actual measured metrics of productivity - rather that self-reported 'I felt just as productive at home' ones.) ---- "It doesn't take much distance before a team feels the negative effects of distribution - the effectiveness of collaboration degrades rapidly with physical distance. People located closer in a building are more likely to collaborate (Kraut, Egido & Galegher 1990). Even at short distances, 3 feet vs. 20 feet, there is an effect (Sensenig & Reed 1972). A distance of 100 feet may be no better than several miles (Allen 1977). A field study of radically collocated software development teams,[...], showed significantly higher productivity and satisfaction than industry benchmarks and past projects within the firm (Teasley et al., 2002). Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006). Close proximity improves productivity in all cases." -- https://docs.google.com/a/quietstars.com/document/pub?id=1JqRuCbjWs44SWCRzUhCDepc_dOr7BJG307dFe6Vn3-o https://docs.google.com/a/quietstars.com/document/pub?id=1Jq... "Based on the empirical evidence, we have constructed a model of how remote communication and knowledge management, cultural diversity and time differences negatively impact requirements gathering, negotiations and specifications. Findings reveal that aspects such as a lack of a common understanding of requirements, together with a reduced awareness of a working local context, a trust level and an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders in negotiating a set of requirements that satisfies geographically distributed customers" -- http://www.springerlink.com/content/0137yud7c3k8xryw/ http://www.springerlink.com/content/0137yud7c3k8xryw/ "Our results show that, compared to same-site work, cross-site work takes much longer and requires more people for work of equal size and complexity. We also report a strong relationship between delay in cross-site work and the degree to which remote colleagues are perceived to help out when workloads are heavy" -- http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&tp=&arnumber=919083&isnumber=19875 http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&#... "Our findings reveal that: software developers have different types of coordination needs; coordination across sites is more challenging than within a site; team knowledge helps members coordinate, but more so when they are separated by geographic distance; and the effect of different types of team knowledge on coordination effectiveness differs between co-located and geographically dispersed collaborators." -- http://kraut.hciresearch.org/sites/kraut.hciresearch.org/files/articles/Espinosa07-CoordinationInGlobalSWDevelopment.pdf http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil... "One key finding is that distributed work items appear to take about two and one-half times as long to complete as similar items where all the work is colocated" -- http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/TSE.2003.1205177 http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/... "Our study of six teams that experienced radical collocation showed that in this setting they produced remarkable productivity improvements. Although the teammates were not looking forward to working in close quarters, over time they realized the benefits of having people at hand, both for coordination, problem solving and learning.Teams in these warrooms showed a doubling of productivity" -- http://possibility.com/Misc/p339-teasley.pdf http://possibility.com/Misc/p339-teasley.pdf "Despite the positive impact of emerging communication technologies on scientific research, our results provide striking evidence for the role of physical proximity as a predictor of the impact of collaborations." -- http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0014279 http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna... "Groups with high common ground and loosely coupled work, with readiness both for collaboration and collaboration technology, have a chance at succeeding with remote work. Deviations from each of these create strain on the relationships among teammates and require changes in the work or processes of collaboration to succeed. Often they do not succeed because distance still matters" -- http://dl.acm.org/citation.cfm?id=1463019 http://dl.acm.org/citation.cfm?id=1463019

R_Edward 14y ago
This is quite sensible; if my manager is leaning over my desk asking for that TPS report, I'm more likely to drop what I'm doing and give it to him than if he's asking from 20 miles away. In the latter case, I can tell him I'll e-mail it to him, and buy myself time to get to a natural breaking point. Multiply that by however many people are on your development team, and the manager has to wait all day to get his TPS reports. There is a significant distinction between personal productivity and team productivity, and the wise manager knows how to leverage the former to increase the latter. It bears repeating that the wise programmer knows that he must occasionally sacrifice the former to enhance the latter as well, if he hopes his employer will continue to give him lots of money for having fun with computers. That said, the "war-room environment" is fraught with connotations that just scream "inept management" to me. If your developers are under that kind of stress for long periods of time, you're doing it wrong, and you're deleteriously affecting not only their personal productivity, but the team productivity as well.
- adrianhoward 14y ago
  It's not just about management either. It's about the whole team. It's about fixing that problem your teammate has. It's about noticing that person who's been looking puzzled and them being to make eye contact for immediate help. It's about avoiding miscommunication. It's about spotting problems before they get serious. If your developers are under that kind of stress for long periods of time In these papers 'war room' is just shorthand for 'people working together on a project in the same room'. Also called 'team rooms' and 'radical colocation'. Not meant to imply stress in any way. Quite the opposite if anything. Would have used another term if I'd though about it.
kamaal 14y ago
>> I don't care about individual productivity. I care about productivity of the business as a whole. What follows from individual productivity is productivity of the business. Unproductive people don't make a productive business. >>And on that point pretty much all the evidence I can find shows that co-located teams in a war-room like environment are the most productive. Sure, but only as long 'collaboration' and 'communication' is what occupies most part of the work. Which in the case it makes perfect sense. But if you have all what you need, and you are sitting with 20 other people, working alone at that point makes more sense. War room teams work when a high degree of collaboration or 'piecing together work inputs' is what matters. If you are solving a tough problem. Or dodging a bullet, you will be productive doing it alone.

R_Edward 14y ago

This is quite sensible; if my manager is leaning over my desk asking for that TPS report, I'm more likely to drop what I'm doing and give it to him than if he's asking from 20 miles away. In the latter case, I can tell him I'll e-mail it to him, and buy myself time to get to a natural breaking point. Multiply that by however many people are on your development team, and the manager has to wait all day to get his TPS reports. There is a significant distinction between personal productivity and team productivity, and the wise manager knows how to leverage the former to increase the latter. It bears repeating that the wise programmer knows that he must occasionally sacrifice the former to enhance the latter as well, if he hopes his employer will continue to give him lots of money for having fun with computers. That said, the "war-room environment" is fraught with connotations that just scream "inept management" to me. If your developers are under that kind of stress for long periods of time, you're doing it wrong, and you're deleteriously affecting not only their personal productivity, but the team productivity as well.

adrianhoward 14y ago
It's not just about management either. It's about the whole team. It's about fixing that problem your teammate has. It's about noticing that person who's been looking puzzled and them being to make eye contact for immediate help. It's about avoiding miscommunication. It's about spotting problems before they get serious. If your developers are under that kind of stress for long periods of time In these papers 'war room' is just shorthand for 'people working together on a project in the same room'. Also called 'team rooms' and 'radical colocation'. Not meant to imply stress in any way. Quite the opposite if anything. Would have used another term if I'd though about it.

kamaal 14y ago

>> I don't care about individual productivity. I care about productivity of the business as a whole. What follows from individual productivity is productivity of the business. Unproductive people don't make a productive business. >>And on that point pretty much all the evidence I can find shows that co-located teams in a war-room like environment are the most productive. Sure, but only as long 'collaboration' and 'communication' is what occupies most part of the work. Which in the case it makes perfect sense. But if you have all what you need, and you are sitting with 20 other people, working alone at that point makes more sense. War room teams work when a high degree of collaboration or 'piecing together work inputs' is what matters. If you are solving a tough problem. Or dodging a bullet, you will be productive doing it alone.