Scrum distribuido
David Starr es responsable jefe de la creación de software para Scrum.org, donde se centra en la mejora de la profesión de desarrollo de software. También fundó la comunidad técnica en línea, ElegantCode.com.
Julio de 2012
Los equipos distribuidos a menudo tienen dificultades para lograr una comunicación coherente, oportuna y eficaz. Scrum ofrece un contenedor en el que diferentes tipos de equipos distribuidos pueden mejorar y triunfar.
El marco de trabajo Scrum no dice nada acerca de los equipos de desarrollo distribuidos. Scrum no requiere que todos los miembros de un equipo Scrum o incluso los miembros de un equipo de desarrollo trabajen en la misma sala, edificio, ciudad o zona horaria. Los equipos Scrum plantean activamente impedimentos para el aumento de la productividad, y cuando la comunicación es un impedimento, Scrum lo hace muy visible.
Cuando los miembros del equipo no trabajan juntos físicamente, las comunicaciones dentro del equipo son necesariamente más complejas, como lo es también el software creado por ese equipo. En 1968, Melvin Conway escribió lo siguiente:
Las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.
Se ha demostrado que la ley de Conway es más que un proverbio; se trata de una dinámica mensurable dentro de los equipos de desarrollo de software. Un estudio demostró el efecto de la Ley de Conway midiendo el efecto que la distribución del equipo puede tener sobre la arquitectura del sistema. Cuando los miembros del equipo están distribuidos, los desarrolladores de software suelen crear más capas de abstracción en el código para intentar aislarse unos de otros[1].
Información general
Ver el equipo en el código
Stella es desarrolladora de un equipo Scrum que siempre entrega el trabajo previsto para cada sprint. Su equipo tiene fama de crear software de alta calidad, aunque el código es un poco difícil de entender para otras personas que lo leen.
Trabaja en casa y en una zona horaria diferente que el resto del equipo. Utiliza correo electrónico, un costoso sistema de administración de requisitos y en ocasiones videoconferencia para hablar del trabajo en cada sprint. Utilizan Scrum según lo prescrito, con un scrum diario programado para admitir la programación de todo el mundo. Asiste a las reuniones de planeación y al scrum diario por teléfono, sin ver las caras de sus compañeros de equipo cuando hablan. Tampoco oye las conversaciones que se mantienen antes y después de cada scrum diario.
Con buena intención, Stella crea una capa de abstracción en el código para que su trabajo se pueda aislar y probar más fácilmente. La nueva abstracción separa la implementación de la interfaz que ha declarado y está disponible para otros miembros del equipo. Este tipo de sistema conectable produce arquitecturas de sistema desacopladas limpiamente, afirma. "El uso de interfaces como límite de implementación es un buen diseño orientado a objetos", se recuerda a sí misma. Su nuevo modelo de complemento le permitirá trabajar solo en su sección del código y no interferir con los compañeros de equipo que trabajan en otras áreas.
Como predijo la Ley de Conway, el código refleja ahora su comunicación con el equipo: acoplamiento flexible. Su diseño reemplaza las conversaciones que pudiera haber tenido con el equipo y el sistema es innecesariamente complejo. Esta complejidad innecesaria es un reflejo de sus relaciones con otros miembros del equipo de desarrollo. En última instancia, estas decisiones cuestan dinero a la compañía porque hay más líneas de código en propiedad, más niveles de direccionamiento indirecto que los desarrolladores futuros deben entender y más pruebas que realizar para demostrar que la funcionalidad de la abstracción funciona correctamente.
Stella no ha hecho nada malo. De hecho, ha aprovechado correctamente buenas prácticas de diseño orientado a objetos para aislar un área problemática en el sistema. Desgraciadamente, el problema que aisló eran sus propios problemas de comunicación y la solución permite una comunicación incluso menos frecuente. Desafortunadamente, el sistema que cambió al abordar el problema era el software. Una manera más eficaz de tratar este problema habría sido simplificar las comunicaciones con el equipo de desarrollo.
Cuando los miembros del equipo no están sentados juntos, suelen reemplazar los intercambios verbales sencillos con conversaciones más complejas y formales. En lugar de mantener conversaciones rápidas y eficaces sobre pequeñas decisiones tácticas, los asuntos se acumulan y se espera tratarlos más adelante. A menudo, ese momento nunca llega. Menos comunicación interpersonal significa derivar la comunicación hacia otros aspectos, como especificaciones, vales de trabajo o incluso código. ISomeInterfaces existe para atender las disfunciones de los equipos que las crean.
La complejidad involuntaria de la distribución de los equipos
Las decisiones tomadas fuera de un equipo Scrum son las que tienen más probabilidad de aumentar la complejidad. Raras veces los equipos de desarrollo de software son sencillos en cuanto a su composición o a las tareas que realizan, y Scrum proporciona un límite dentro del cual el equipo Scrum maniobra y trabaja para reducir la complejidad. A pesar de ello, la complejidad que supone realmente escribir código y entregar software palidece a veces con respecto a la cultura y los procesos de la organización a los que se enfrenta el equipo de desarrollo.
En consecuencia, la decisión de crear un equipo Scrum de miembros que viven en zonas horarias diferentes raramente la toman quienes realizan el trabajo. Las decisiones de crear un equipo Scrum distribuido proceden probablemente de las personas encargadas de reunir un equipo muy cualificado de especialistas o (más probablemente) de intentar reducir los costos de producción subcontratando externamente el desarrollo de software por menos dinero. Aunque estos modelos pueden reducir el costo inicial de desarrollo de software, normalmente no tienen en cuenta el costo del mantenimiento continuado y la complejidad adicional que supone dar cabida a las complicadas comunicaciones del equipo de desarrollo.
Independientemente de cómo o por qué se crean equipos distribuidos, el hecho es que son una realidad y no hay ningún indicio de que vayan a desaparecer. Incluso en situaciones de equipos distribuidos, Scrum sigue siendo un marco de trabajo excelente para administrar la planeación y ejecución de la entrega de un producto de software. Los miembros del equipo simplemente deben ser más diligentes para mejorar los canales de comunicaciones existentes y protegerse frente a infraoptimizaciones como las descritas en el ejemplo anterior.
La realidad distribuida
Los equipos distribuidos permiten contratar a la persona adecuada para el puesto independientemente de donde residan o, en el caso de algunas personas, que vivan donde ellos elijan en lugar de residir en el mismo lugar donde se encuentra la oficina central de la compañía. Si bien es fácil aportar razonamientos contra los equipos distribuidos, el ahorro que supone la subcontratación de recursos externos, la subcontratación interna, la subcontratación cercana y la subcontratación rural sigue resultando muy atractivo para muchas organizaciones.
La guía de Scrum, publicada en Scrum.org, codifica Scrum y contiene el conjunto de reglas necesarias para aplicar el marco de trabajo Scrum. Aunque la guía de Scrum guarda silencio sobre el problema de los equipos distribuidos y no proporciona ninguna instrucción dedicada especialmente a ellos, Scrum hará muy evidente los retrasos y pérdidas de comunicación que se producen en los equipos cuyos miembros no pueden comunicarse entre sí sin un dispositivo electrónico que llene el vacío.
La confianza importa
Gran parte de lo que los seres humanos se dicen unos a otros se comunica a través del lenguaje corporal. La información que se obtiene observando a alguien durante una discusión de diseño puede resultar tan valiosa como la información que se escribe en una pizarra. Por eso, gran parte del intento de cubrir el vacío entre los trabajadores distribuidos implica superar la barrera del lenguaje corporal.
Steve McConnell escribió, "La vida media de la confianza es de unas 6 semanas". [2] Esta frase reconoce que los desarrolladores que trabajan y colaboran juntos a diario desarrollan un nivel de confianza mutua. El grado de confianza varía como ocurre en cualquier relación, pero la confianza potencial es mayor cuando los compañeros de equipo se ven y trabajan juntos a menudo.
Cuando los compañeros de equipo dejan de verse a diario y no trabajan cerca unos de otros durante seis semanas, el grado de confianza de la relación es aproximadamente la mitad de lo que era antes. La poca confianza que queda disminuye rápidamente a medida que pasa el tiempo.
No es que las personas implicadas no tengan una consideración positiva o un respeto mutuos, pero la confianza y la eficacia del equipo se pierden. Sin confianza, la colaboración disminuye y las fronteras entre los compañeros de equipo aumentan. Esas fronteras suelen quedar reflejadas en el código.
Cámaras, teleconferencias, mensajería instantánea, videochat, uso compartido de la pantalla y otras herramientas de colaboración ayudan a salvar las distancias a que separan a los compañeros de equipo, y el uso de este tipo de herramientas debe estar tan generalizado como el aire que se respira para que los equipos distribuidos sean altamente productivos. Una comunicación por vídeo frecuente puede ayudar mucho a recomponer la confianza.
Cualesquiera que sean las herramientas empleadas, los equipos distribuidos pueden aumentar su eficacia explotando las posibilidades de una comunicación de alta fidelidad. En resumen, la propia voz es preferible a la mensajería instantánea, que a su vez es preferible al correo electrónico y así sucesivamente. Pero es todavía mejor reducir el tiempo que transcurre entre las interacciones.
Grados de separación
Hay muchas formas en que los miembros del equipo se encuentran separados unos de otros y normalmente hay patrones recurrentes de la distribución del equipo. Como ocurre con los patrones típicos de otros entornos (como el diseño de software), los patrones de distribución del equipo pueden producirse intencionada o accidentalmente. Los patrones accidentales ocurren como una respuesta inconsciente a la presión existente y los patrones intencionados se implementan deliberadamente para controlar la complejidad.
Los patrones Scrum distribuidos que se describen aquí pueden ser prescritos o involuntarios. Pueden estar inspirados en decisiones tomadas fuera del equipo Scrum o pueden deberse a la propia organización del equipo Scrum sobre un problema determinado. Con independencia de su procedencia, los siguientes patrones de distribución son comunes en la naturaleza.
Los equipos de desarrollo remotos trabajan conjuntamente, pero están separados físicamente del resto de la compañía.
En el patrón miembro remoto del equipo, un único miembro del equipo trabaja en una ubicación diferente que el resto del equipo del que forma parte.
En un equipo distribuido, los miembros individuales del equipo trabajan juntos para lograr el mismo objetivo, pero cada uno de ellos lo hace desde una ubicación única.
El equipo de desarrollo remoto
Algunos equipos de desarrollo están separados geográficamente de su organización matriz o, lo que es incluso peor, de los propietarios de los productos. Esto suele ocurrir cuando una compañía adquiere otra o cuando se produce una fusión entre dos compañías. Si el equipo de desarrollo debe ser remoto, Scrum es una forma ideal de administrar el trabajo y la comunicación de ese equipo con la organización mayor. Muchos equipos tienen éxito con esta fórmula hoy en día.
Aunque las situaciones varían enormemente, los equipos de desarrollo remotos con frecuencia se sienten desfavorecidos, infravalorados y aislados de la organización principal. Los miembros del equipo remoto pueden sentirse ignorados y alienados por la empresa matriz, que puede considerar (a menudo involuntariamente) que el equipo es menos importante que los que se encuentran en la oficina central de la compañía.
Estos equipos de desarrollo remotos encuentran continuamente razones, excusas y oportunidades para no integrar su trabajo con el de otros equipos. Es fácil justificar por qué la integración de este sprint no es importante, necesaria o posible. El resentimiento crece, haciendo que el equipo de desarrollo vea las solicitudes de integrar el código con la organización mayor como algo “poco razonable”, “alejado de nuestra realidad”, “innecesario” o “insensible a nuestras necesidades”.
El hecho de que todas o ninguna de estas impresiones sean ciertas es irrelevante. El equipo de desarrollo remoto necesita sentirse escuchado y comprendido, al tiempo que entiende su propio valor dentro de la organización mayor. Es fácil olvidarse de que uno forma parte de algo mayor que uno mismo cuando se trabaja en un puesto remoto.
Un scrummaster que trabaja en una ubicación diferente que el equipo de desarrollo solo puede conducir al fracaso. Los scrummasters no pueden llevar a cabo de forma eficaz las tareas de orientación, facilitación de eventos de Scrum eficaces y asistencia al propio Scrum desde la distancia. La distancia entre un equipo de desarrollo y un scrummaster impide la comunicación y supone un riesgo demasiado elevado en el equipo Scrum. Para lograr confianza es necesaria la familiaridad y para el éxito de Scrum es fundamental que haya una confianza mutua elevada.
Los scrummasters trabajan en la misma ubicación que sus equipos de desarrollo.
Para que un equipo de desarrollo atienda bien al propietario del producto, también se necesita una comunicación sin obstáculos y clara. El propietario del producto debe estar disponible para el equipo de desarrollo en cada sprint para responder a las preguntas y proporcionar comentarios sobre un trabajo en curso. Aunque esta interacción frecuente es posible en escenarios remotos, se debe establecer un método confiable para mantener esta comunicación.
Un propietario del producto ausente es una de las fuerzas más destructivas que un equipo Scrum puede experimentar. Un equipo de desarrollo desatendido se ve forzado a tomar decisiones relativas a la funcionalidad y la prioridad. A menudo, este grupo es el menos capacitado para tomar buenas decisiones sobre la funcionalidad, ya que suele estar menos informado sobre las necesidades del cliente que el propietario del producto.
Los propietarios del producto prestan atención y dan su opinión al equipo de desarrollo durante el sprint.
Desgraciadamente, los propietarios del producto ausentes o que raramente están disponibles son una disfunción frecuente en los equipos Scrum, incluso cuando se encuentran en el mismo lugar. Para que Scrum alcance su potencial, el equipo Scrum debe funcionar como una unidad cohesiva, de confianza y colaborativa, y precisa la atención periódica de un propietario del producto dedicado.
El miembro remoto del equipo
Algunos desarrolladores se segregan de sus compañeros de equipo, quienes se encuentran en el mismo lugar y trabajan juntos en una ubicación compartida. El ejemplo clásico es el desarrollador que trabaja en casa y que trabaja diligentemente con un equipo desde su hogar. Aunque los motivos son variados, esta situación es cada vez más frecuente.
Alistair Cockburn acuñó el término comunicación osmótica[3] para identificar un tipo de comunicación intrínseca dentro del salón del equipo.
La comunicación osmótica significa que la información fluye en el sonido de fondo de los miembros del equipo, de modo que recogen la información pertinente como por ósmosis.Esto se consigue normalmente sentándolos en el mismo salón.Entonces, cuando una persona plantea una pregunta, otras personas del salón pueden sintonizar o desconectar, contribuyendo a la discusión o continuando con su trabajo.
La comunicación osmótica no se limita a los equipos de desarrollo de software. Los visitantes de la sala de redacción de un periódico o un medio de comunicación grande se encontrarán a menudo exactamente eso. Incluso las unidades de detectives de los departamentos de policía de todo el mundo utilizan las salas para tomar café con el fin de fomentar el intercambio de puntos de vista colectivos a la hora de investigar crímenes.
La pérdida de comunicación osmótica es la pérdida del conocimiento de la situación dentro del equipo. Cuando un desarrollador de software no está al tanto de los cambios realizados en el software por sus compañeros de equipo a medida que se hacen los cambios, hay una pérdida de cohesión y de contexto compartido dentro del equipo. El miembro del equipo ininterrumpido, concentrado y remoto no oye lo que hay en el ambiente del salón del equipo. Esto le deja fuera de discusiones ad hoc con respecto al diseño y otras decisiones que se toman con fluidez durante un día determinado.
La tendencia a entregar software más rápidamente con menos tiempo entre versiones requiere un conocimiento de la situación aún mayor dentro del equipo de desarrollo. Para el miembro remoto del equipo que no tiene presencia en el salón del equipo, el conocimiento de la situación se pierde por completo.
Las soluciones de telepresencia son cada vez más habituales para resolver este problema. Se pueden crear soluciones simples de telepresencia utilizando un portátil, una cámara y altavoces baratos. La colocación de este sistema en el salón del equipo puede proporcionar un canal abierto de comunicación que el desarrollador remoto que puede dejar abierto todo el día.
El vídeo y la teleconferencia ayudan a salvar la barrera del lenguaje corporal.
He aquí algunos indicios de que el desarrollador remoto tiene dificultades para formar parte realmente del equipo:
Uso de comunicaciones escritas a máquina como correo electrónico o mensajería instantánea para tratar asuntos complejos.
Definición de interfaces fijas como contratos en el código en lugar de tener discusiones periódicas con otros desarrolladores.
Deseo de una bifurcación de código privada, o personal, en el control de versiones.
Al tender puentes entre un desarrollador remoto y el resto del equipo, las visitas periódicas son muy útiles. Las videollamadas son mejores que las llamadas telefónicas. Las llamadas telefónicas son mejores que escribir y el uso exclusivo del correo electrónico es un desastre que tenía que ocurrir.
El equipo distribuido
En un equipo Scrum realmente distribuido, los individuos trabajan conjuntamente para entregar el mismo objetivo del sprint, y cada miembro del equipo trabaja en una ubicación diferente. El ejemplo arquetípico es un proyecto de código abierto en el que los colaboradores residen en diferentes ubicaciones de todo el mundo. Aunque los problemas de comunicación son significativos, este modelo tiene una validez demostrable. La comunicación en un equipo como este supone un desafío necesariamente, pero es cada vez más común a medida que la tecnología continúa reduciendo la barrera del lenguaje corporal.
Cuando los miembros del equipo están sentados en ubicaciones diferentes, es esencial disponer de software de uso compartido de la pantalla para mantener conversaciones eficaces sobre el diseño y el código. Con respecto al código, a menos que ambas partes de una conversación vean lo mismo, la discusión incluye demasiadas suposiciones. Afortunadamente, el software de uso compartido de la pantalla está disponible fácilmente y es muy eficaz. Los miembros del equipo que no están en el mismo salón deben compartir las pantallas con sus compañeros de equipo varias veces al día.
El uso compartido de la pantalla puede ser una herramienta de colaboración muy eficaz.
Buscar excusas para examinar juntos el código, los elementos de trabajo pendiente u otros artefactos es una buena manera de mantener un buen conocimiento de la situación en los equipos distribuidos. Otra técnica eficaz consiste en agregar una regla de comprobación sencilla para cualquier elemento entregado como parte del sprint. La regla consta de dos partes y consiste en lo siguiente:
Cada elemento se debe comprobar en un entorno de integración para que se considere terminado.La persona que realiza la comprobación puede no ser la persona que realizó el trabajo.
Los equipos de desarrollo que adoptan esta regla simple consiguen un mayor conocimiento colectivo del trabajo que se realiza en el equipo.
Nota del autorTrabajé con un equipo de desarrollo cuyos miembros trabajaban en el mismo edificio, pero en despachos diferentes. La compañía estaba orgullosa de proporcionar despachos privados para todos los empleados. El equipo de desarrollo decidió finalmente crear un salón virtual del equipo en el que cada miembro del equipo pudiera aparecer mediante una cámara, un micrófono y altavoces. El salón virtual del equipo estaba abierto siempre y los miembros del equipo entraban en el salón cuando trabajaban en el producto que compartían.En poco tiempo, el equipo llegó a apreciar este salón virtual. Empezaron usando software de uso compartido de la pantalla para ver las pantallas de los demás en lugar de bajar al vestíbulo, porque les resultaba más rápido. El equipo empezó a utilizar el salón virtual todo el día, incluso aunque estuvieran trabajando en despachos separados por una pared. Finalmente, uno de los miembros del equipo intentó no ir al despacho durante unos días y trabajar desde casa. Durante la retrospectiva del sprint, el equipo de desarrollo estuvo de acuerdo en que el salón virtual del equipo hacía irrelevante si una persona estaba trabajando algunas puertas más abajo en el vestíbulo o en casa. El salón virtual del equipo resultó ser más valioso que los despachos individuales.
Herramientas y procedimientos
Han corrido ríos de tinta sobre el hecho de que los equipos ágiles emplean herramientas de baja tecnología y alta fidelidad para administrar el trabajo. Cuando se agrega a la situación la complejidad de la distribución geográfica o la presencia de varios equipos de desarrollo, las fichas de índice analógicas y los marcadores no admiten una ampliación tan buena como una solución basada en software. Esto ha producido una avalancha de herramientas de administración del trabajo diseñadas especialmente para los equipos Scrum o “ágiles”, y hay muchos proveedores de herramientas que prometen básicamente “nuestra herramienta le hará ágil”.
Confundir herramientas con procedimientos
Por supuesto, ninguna herramienta puede hacer que un equipo “sea ágil”. La auténtica agilidad procede de la cultura, las actitudes y los comportamientos de las personas que crean y proporcionan el software. Por eso, el manifiesto ágil[4] expresa el valor de los “Individuos e interacciones sobre los procesos y las herramientas”.
Hay un dicho en la comunidad ágil que dice “Las personas por encima de los procesos y los procesos por encima de las herramientas”.
Entre los pragmáticos se usa el dicho “Las herramientas establecen las reglas”.
Ambos refranes hablan de la relación que tienen las personas con el software que se utiliza para comunicarse, colaborar y administrar el trabajo. Las herramientas de seguimiento del trabajo están pensadas para reducir la complejidad de la comunicación y la comprensión, justo lo contrario de lo que puede ocurrir. No es raro que las personas caigan en la rutina de notificar innecesariamente un defecto en lugar de corregirlo, por ejemplo.
Nota del autorUn buen recurso para aquellas personas interesadas en el equilibrio entre las herramientas, los procesos y los procedimientos son las notas del producto de Kent Beck sobre las herramientas para la agilidad. Dicho documento es hoy tan revelador como cuando lo escribió el Sr. Beck en 2008.
Los scrummasters y los miembros del equipo de desarrollo son propensos a las lamentaciones, “La herramienta está anticuada”, cuando los datos del sistema de seguimiento del trabajo o de las características no están actualizados. Esto pasa por alto lo que quizás sepa de forma intuitiva:
El objetivo es mantener el equipo actualizado, no la herramienta.En ocasiones, la herramienta puede ayudarnos en esto.
Scrum está diseñado específicamente para aumentar el conocimiento de la situación en el equipo Scrum. Scrum no dice nada sobre el formato de los requisitos, el levantamiento de actas, los desgloses de trabajo, las unidades de estimación o el seguimiento del tiempo. A los equipos les puede parecer todo esto útil y pueden funcionar dentro del contexto de Scrum. Pero los equipos que utilizan estos procedimientos adicionales lo hacen además de Scrum, no debido a él.
Respaldar procedimientos con herramientas
Cabe esperar que cualquier herramienta utilizada por un equipo Scrum se haya elegido para respaldar un procedimiento seleccionado antes que la herramienta. Es decir, los equipos Scrum prósperos mejoran deliberadamente. Esto significa que se elige probar un nuevo procedimiento o una nueva técnica porque el equipo desea mejorar en un área concreta. El uso de una herramienta para respaldar el nuevo procedimiento puede venir después de probar lo fundamental. En resumen:
Elija primero personas valiosas.Como equipo que se auto-organiza, seleccionan su propios procedimientos y, finalmente, eligen una herramienta que respalde el procedimiento que han elegido.Las personas valiosas por encima de los procesos y los procesos por encima de las herramientas.
(Para obtener más información sobre las herramientas para respaldar los procedimientos disponibles en Microsoft Visual Studio 2012, vea Colaboración (Profundizar más) [redirigido], Colaborar [redirigido] y la sección Más información del portal de bienvenida de Visual Studio Online).
La forma en que los miembros del equipo trabajan conjuntamente tiene efectos innegables y evidentes sobre el software que crean. Cuando la comunicación es sencilla y eficaz, el diseño de software resultante lo refleja. Por el contrario, cuando los equipos tienen dificultades para comunicarse internamente o con aquellos para los que trabajan, el software que el equipo produce reflejará los problemas que experimenta el equipo.
Los ciclos regulares de inspección y adaptación de Scrum contribuyen mucho a ayudar a los equipos en situaciones distribuidas. Los eventos prescritos de Scrum fuerzan la comunicación, pero no afectan necesariamente a la forma que adopta la comunicación.
Un salón del equipo común sigue siendo la tecnología más básica, la mayor fidelidad y el modo más eficaz en que un equipo puede crear software complejo de forma colaborativa. No obstante, los equipos remotos están aquí para quedarse. Ya se deba a situaciones personales, el beneficio económico o la falta de previsión, cada vez más equipos Scrum trabajan en situaciones en las que los miembros del equipo no están juntos físicamente.
Prestar atención a la comunicación de un equipo traspasando las barreras físicas dará sus frutos en forma de mayor calidad, menos confusión, un rendimiento más rápido e individuos más satisfechos. Cuando se da una consideración especial a las herramientas y los procedimientos dentro del equipo, la distribución puede funcionar bien. Incluso puede funcionar muy bien.
Referencias
Herbsleb, 1999 Architectures, coordination, and distance: Conway's law and beyond. IEEE Software, 7
McConnell, S. (2009). Travel Restrictions and Offshore Development.
Cockburn, A. (2008). Osmotic Communication.
Varios. Agile Manifesto.