En su discurso en la conferencia Prácticas de Desarrollo Ágil, Brian Marick describe los valores que faltan en el Manifiesto Ágil. Su opinión es que el Manifiesto era esencialmente un documento de marketing, con el fin de obtener que las propias empresas le dieran una oportunidad a la agilidad. Ahora que gran parte de ese objetivo se alcanzó, un amplio conjunto de valores son necesarios para ayudar a los equipos a cumplir las promesas del manifiesto.
Los valores son los que nos mantienen en el camino recto y estrecho antes de caer en la tentación. Los equipos que tienen fuertes valores interiorizados se mantienen fieles a las buenas prácticas ágiles -y obtienen buenos resultados ágiles-, mientras que los equipos sin los valores necesarios para su orientación van a estar a la deriva.
Las ideas que Brian expresa en su discurso son las mas recientes evoluciones de un tema que compartió en el 2007 XP Day Toronto, y más tarde escribió acerca de ello. En ese momento, había una lista de 4 nuevos valores que pensó que serían necesarios:
Habilidad
No existe ningún sustituto para desarrolladores y testers cualificados. La habilidad viene de prácticar y aprender los fundamentos del desarrollo de software.
Disciplina
Sucede que practicar bien la agilidad requiere un poco de disciplina. Inicialmente es mas rápido no refatorizar el código, o incluso dejar de escribir las pruebas. Inicialmente es más fácil y más rápido, pero a la larga esto sólo te demorará. Se necesita disciplina para actuar de esa manera todo el tiempo.
Facilidad
Hacer que las cosas que hacemos a menudo sean más fáciles. Brian describe cómo esto se relaciona con el concepto de habilidad. Así como una casa es adaptada por sus habitantes con el fin de hacer su vida más fácil y más confortable, el código y nuestros entornos de trabajo también pueden ser modificados para que sea más fácil 'vivir'.
Alegría
Ahora, yo podría decir que un empleado feliz es un empleado productivo, y que la falta de alegría en un proyecto es como un canario limpio en una mina de carbón: un gran signo de que algo está mal y es mejor prestar atención.
En aquella época, Brian estaba preocupado por donde la falta de estos cuatro valores nos llevarían.
Creo que la Agilidad está sufriendo hoy, porque estos valores fundamentales no se han escrito y se han olvidado muy fácilmente. Si esto continúa, me temo que la Agilidad será la moda de la década que no cambia nada. Eso sería triste.
James Shore, recientemente expresó preocupaciones similares sobre el movimiento ágil siendo perjudicado por los equipos que están implementando agilidad pobremente.
Más recientemente, Brian agregó algunos valores más a su lista, incluyendo: coraje, ser reactivo, feedback y visibilidad que aumenta el nivel de exhibicionismo.
Coraje
Este es el coraje de hacer lo que es mejor para el equipo, para el proyecto o incluso para el negocio, a pesar de las presiones en la dirección opuesta. Brian comparte un ejemplo que dice que es de Ken Schwaber, de un Scrum Master que desmontó los cubículos del equipo, para que ellos puedan tener el área de equipo que querían. Esto no le cayó muy bien al área que maneja el mobiliario y le comunico al Scrum Master que cuando ellos se fueran los cubículos tenían que ser restaurados.
Ser reactivo
Brian considera que, a pesar del mal significado que la palabra "reactivo" tiene, es totalmente adecuado para un equipo ágil, y sus miembros son reactivos en algunos aspectos. Cuando estamos codificando, a veces es mejor escribir código y, a continuación, reaccionar sobre cuan bien o no ese código funciona. Cuando tomamos las decisiones, esperando hasta el último momento por la respuesta puede ser visto como un enfoque reactivo.
Feedback Rápido
Tomando un enfoque para el desarrollo de funcionalidad por funcionalidad, en lugar de un enfoque infraestructura en primer lugar, es una forma de obtener feedback rápido. La gente de las empresas rara vez es capaz de proporcionar sus comentarios sobre la infraestructura cruda (Ej, Muy buen diseño de su base de datos!), Pero las empresas son fácilmente capaces de proporcionar información útil sobre las funcionalidades que están listas. Otro ejemplo aún más rápido de feedback se ve en la prueba impulsada por el diseño.
Visibilidad
Hacer la mayor parte de la información lo más visible como sea posible ha sido considerada una las mejores prácticas entre los profesionales de la agilidad hace mucho tiempo. Es la motivación detrás de los "grandes mapas visibles" y " difusores de información". Esto no sólo es útil para mantener a todos informados, también puede ayudar a emeger problemas rapidamente de forma que estos serán tratados, naturalmente.
Basta hacer que los malos hábitos lleguen a ser muy visibles. La presión de la visibilidad constante nos hará colocar estos hábitos, y - a través del tiempo - aquello que haces de bueno se convierte en buenos hábitos. Y, con el tiempo, este conjunto de cambios puede formar buenos miembros del equipo y grandes equipos, exactamente de manera que el producto crezca sin problemas a partir de algo poco funcional a algo que realmente da orgullo.
El texto del discurso de Brian puede ser encontrado aquí.
Como su equipo aplica o no aplica, estos valores? La lista de Brian está completa o existen otros valores que guían a los equipos ágiles que deben ser considerados?
