Aprecio la metodología impulsada por el esfuerzo de SCRUM, pero odio la política de no-paredes para el espacio. ¿Alguien ha podido argumentar con éxito que esta parte del pensamiento ágil apesta?

Algunos pensamientos.

Nada en Scrum dicta una única configuración de sala de guerra.

Mucha gente lo recomienda por varias razones, pero no hay nada en la definición de Scrum que lo requiera.

Si el equipo en su conjunto encuentra que la configuración actual es improductiva, es el tipo de tema que debería aparecer en la Retrospectiva de Sprint.

¿Lo has mencionado en ese contexto? ¿Cuáles han sido las reacciones?

No debería estar lleno de charla y ruido

La sala del equipo no debe estar en silencio, pero tampoco debe ser ruidosa. Si existe una charla fuera del contexto del proyecto que está molestando a las personas que intentan trabajar, entonces ese es un problema importante.

Generalmente encuentro la necesidad de usar audífonos una señal de que algo está mal.

Sin embargo, las oficinas separadas no son la única solución.

Nuevamente, esto es algo que debería mencionarse en la Retrospectiva de Sprint.

Hay mucha evidencia de que las salas de equipo son más productivas

Aquí hay algunas referencias a la investigación (si alguien tiene alguna investigación que contradiga esto, me encantaría conocerla. Especialmente si se trata de métricas de productividad reales en lugar de anécdotas autoinformadas).

—-

“No se necesita mucha distancia para que un equipo sienta los efectos negativos de la distribución: la efectividad de la colaboración se degrada rápidamente con la distancia física. Las personas que se encuentran más cerca de un edificio tienen más probabilidades de colaborar (Kraut, Egido y Galegher 1990). Incluso en distancias cortas, 3 pies frente a 20 pies, hay un efecto (Sensenig & Reed 1972). Una distancia de 100 pies no puede ser mejor que varias millas (Allen 1977). Un estudio de campo de equipos de desarrollo de software con ubicación radical, [… ], mostraron una productividad y satisfacción significativamente más altas que los puntos de referencia de la industria y los proyectos anteriores dentro de la empresa (Teasley et al., 2002). Otro estudio de campo comparó las interrupciones en los equipos de desarrollo de software pareados, de ubicación radical y tradicional, que viven en el cubo, y encontró que en las primeras, las interrupciones fueron mayores en número pero más cortas en duración y más en la tarea (Chong y Siino 2006). La proximidad mejora la productividad en todos los casos “.
– Apoyo al trabajo en equipo distribuido.

“Sobre la base de la evidencia empírica, hemos construido un modelo de cómo la comunicación remota y la gestión del conocimiento, la diversidad cultural y las diferencias de tiempo tienen un impacto negativo en la recopilación de requisitos, las negociaciones y las especificaciones. Los hallazgos revelan que aspectos como la falta de un entendimiento común de los requisitos, en conjunto con un conocimiento reducido de un contexto local de trabajo, un nivel de confianza y la capacidad de compartir artefactos de trabajo, se cuestiona significativamente la colaboración efectiva de los interesados ​​remotos en la negociación de un conjunto de requisitos que satisfaga a los clientes distribuidos geográficamente ”
– Retos de RE en organizaciones de desarrollo de software de sitios múltiples

“Nuestros resultados muestran que, en comparación con el trabajo en el mismo sitio, el trabajo entre sitios toma mucho más tiempo y requiere más gente para un trabajo de igual tamaño y complejidad. También informamos una fuerte relación entre el retraso en el trabajo entre sitios y el grado en que Se percibe que los colegas remotos ayudan cuando las cargas de trabajo son pesadas ”
– Un estudio empírico del desarrollo global de software: distancia y velocidad.

“Nuestros hallazgos revelan que: los desarrolladores de software tienen diferentes tipos de necesidades de coordinación; la coordinación entre sitios es más desafiante que dentro de un sitio; el conocimiento del equipo ayuda a los miembros a coordinar, pero más aún cuando están separados por la distancia geográfica, y el efecto de diferentes tipos de el conocimiento del equipo sobre la eficacia de la coordinación difiere entre los colaboradores compartidos y los dispersos geográficamente “.
– http://kraut.hciresearch.org/sit…

“Un hallazgo clave es que los elementos de trabajo distribuidos parecen demorar aproximadamente dos veces y media el tiempo que los elementos similares donde se ubica todo el trabajo” – Un estudio empírico de velocidad y comunicación en el desarrollo de software distribuido globalmente

“Nuestro estudio de seis equipos que experimentaron una colocación radical demostró que en este entorno produjeron notables mejoras en la productividad. Aunque los compañeros de equipo no estaban ansiosos por trabajar de cerca, con el tiempo se dieron cuenta de los beneficios de contar con personas, ambos para la coordinación, resolución de problemas y aprendizaje. Los equipos en estos salones de guerra mostraron una duplicación de la productividad “- http://possibility.com/Misc/p339.

“A pesar del impacto positivo de las tecnologías de comunicación emergentes en la investigación científica, nuestros resultados proporcionan una evidencia sorprendente del papel de la proximidad física como predictor del impacto de las colaboraciones”. – ¿La Colocación Informa el Impacto de la Colaboración?

“Los grupos con una base común alta y un trabajo débilmente acoplado, listos para la colaboración y la tecnología de colaboración, tienen la oportunidad de tener éxito con el trabajo remoto. Las desviaciones de cada uno de estos crean una tensión en las relaciones entre los compañeros de equipo y requieren cambios en el trabajo o los procesos de colaboración para tener éxito. A menudo no tienen éxito porque la distancia sigue siendo importante “- La distancia es importante

Estoy de acuerdo con Adrian … no hay nada en Scrum que requiera la colocación de un equipo en una sola habitación y eso es muy difícil, si no imposible, de hacer en muchos proyectos en la práctica real.

El principio relevante para esto del Manifiesto Agile es que “el método más eficiente y efectivo para transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara”. Muchas personas podrían interpretar que eso significa que “la forma * única * de comunicación efectiva es la comunicación cara a cara” y esa no es la intención.

Es desafortunado que muchas personas hayan perdido de vista los principios detrás de Agile y lo hagan de manera rígida y mecánica, como si solo hubiera una manera de hacerlo.

Chuck Cobb
Autor de “La guía del gestor de proyectos para dominar Agile”
Echa un vistazo a mi entrenamiento en línea gratuito en http: // agileprojectmanagementaca