“Scrum es como el ajedrez. O lo juegas como lo
dictan sus reglas, o no lo juegas. Scrum y el ajedrez no fallan ni aciertan. O
los juegas, o no.” Ken Schwaber [1]
Presentación,
o de la relación que tiene Bruce Lee con un arquitecto de apellido Alexander,
una banda de los cuatro, Chuck Norris y Kent Beck
Las
llaman ‘malas prácticas’, a mí me gusta llamarlas ‘prácticas fuera de contexto’;
en el entorno ágil, algunos incluso hablan con humor de ‘Scrum Norris’, refiriéndose a aquel actor de Hollywood, Chuck
Norris, quien apareciera por primera vez en 1972 en una película del legendario
Bruce Lee, La Furia del Dragón, y que se hiciera popular por allá en los años
80 con películas de acción como Ojo por Ojo, Perdidos en Acción y Fuerza Delta
y donde, a pesar de la incesante acción, no sufría ni un rasguño, ni siquiera
se espelucaba. Los más técnicos y aventajados penetran la barrera científica y
las llaman ‘Antipatrones’. Pero para usar este último término, primero
definamos qué es un patrón, en
nuestro contexto.
Quizás todos recordamos los súperarchipopulares
‘patrones de diseño’ [2] de los también súperarchifamosos ‘banda de los cuatro’
(Gang of Four), compuesta por Erich
Gamma, Richard Helm, Ralph Johnson y John Vlissides, quienes
a su vez basaron su investigación en el trabajo de un Arquitecto (no de software), Christopher Alexander, quien
por allá a finales de los 70, dio origen al tema como un concepto
arquitectónico. Lo curioso de este asunto es que no fueron Gamma y su banda
quienes primero tomaron ese concepto de Alexander: fueron los mismísimos Kent
Beck y Ward Cunningham quienes en 1987 comenzaron a experimentar con la idea de
aplicar patrones a la programación de computadores y presentaron sus resultados
en el OOPSLA de ese año.
Toda esta historia, que siempre me ha parecido
fascinante, porque es en la que se basarán los antropólogos de la TI en el
futuro para descubrir al resto del universo de donde proviene la inteligencia
artificial: las máquinas que piensan, los robots que hablan mejor que los
humanos y los computadores ópticos, toda esta historia, simplemente para
entender que un ‘patrón’ es una solución
reusable a un problema común y recurrente dentro de un contexto. Pero ojo,
un patrón no es una solución terminada,
en cambio, es una descripción de cómo solucionar un problema.
Finalmente, hay patrones de Análisis (Fowler), patrones
de diseño (Gamma et all), patrones de programación (Beck), patrones de pruebas
(Binder), etcétera. Por supuesto, están los patrones en los métodos y en las
prácticas y en los procesos. Pero de todo esto hablaremos en otra oportunidad.
Lo que me ocupa esta vez son precisamente los Antipatrones Ágiles, en general, y los
de Scrum, en particular.
Antipatrones
Scrum: una primerísima aproximación pragmática
Un
Antipatrón es, entonces, la antítesis de una solución a un problema recurrente.
En el caso de los métodos y prácticas (ágiles), son actividades, procedimientos
o rutinas, usos o hábitos, que personas dentro de una organización o entorno
adquieren o ejecutan, con la idea de que son la forma ‘correcta’ de hacer las
cosas. Estas malas prácticas se dan por múltiples razones. Aquí algunas de las
respuestas más frecuentes que escucho en mi trasegar ágil:
- Siempre lo hemos hecho así
- Nuestras condiciones son únicas, entonces debemos
hacerlo de esta manera (¡la madre de todas las entelequias!)
- Hay temor al cambio (la más natural de todas estas
especulaciones, el miedo es algo inherente al ser humano. Es quizás este miedo
el que infunde los demás motivos expuestos aquí. No en vano León Felipe dice: “el
miedo del hombre…ha inventado todos los cuentos.” [3])
- La teoría, lo que dicen los libros y los manuales
(léase Guías) no nos aplica
- Tenemos regulaciones que nos impiden hacerlo de otra
forma
- No hemos tenido entrenamiento ni acompañamiento (de
expertos en la materia)
Quizás esta última sea la razón cardinal de que las organizaciones
se desvíen de las prácticas propuestas en Scrum por distintos motivos y de que las
implementaciones prácticas de Scrum rara vez sigan los ideales de los libros de
texto y mucho menos de sus autores. Es probable que algunos de esos porqués
estén bien respaldados y sean sensatos, como lo hemos abordado en algunos
ambientes, sin embargo, la gran mayoría de las veces las organizaciones no
alcanzan a distinguir netamente las secuelas que se derivan de tomar esas
desviaciones y se sienten tentadas a ajustar, a ‘acomodar’ Scrum y otras
prácticas ágiles para ellas.
He estado allí: muy tarde se dan cuenta estas
organizaciones que han caído en un sinfín de malas prácticas o en unos hábitos
inadecuados para las personas, para los equipos y para la organización misma. Los
resultados infaustos empiezan a aparecer cuando tratamos de ir un poco más
allá: ‘bueno, ya que hacemos Scrum, agreguemos TDD y refactoring’ o ‘ya que hemos gestionado dos o tres proyectos con
Scrum, llevemos esto a nivel corporativo’. Personas quemadas, clientes/usuarios
que no ven la diferencia con métodos anteriores (léase Cascada, WaterRUP, etc.)
o modelos de calidad como CMMI, COBIT, PMI y familiares.
Ahora bien, es cierto que en un lapso de tiempo
relativamente breve, desde el ascenso de los arquetipos, poéticos por demás,
del Manifiesto Ágil, muchas organizaciones se han afiliado a alguna forma de
trabajo ágil. Pero lo que realmente está sucediendo cuando alguien dice “somos
ágiles”, es “estamos usando algunas prácticas o ideas de Scrum y de otros
métodos o prácticas ágiles”, algo que se conoce ordinariamente como ScrumBut (en español, ScrumPero –algo así como: ‘sí, usamos
Scrum pero…’, donde este ‘pero’, quiere decir muchas veces: no tenemos Dueño de
Producto, o no hacemos reuniones diarias, o el Scrum Master es el mismo
Arquitecto de software o el gerente del proyecto, o no tenemos ‘definición de
terminado’, entre muchas otras cosas y, con frecuencia, un compuesto de varias
de estas).
Primera
lista no exhaustiva, incompleta, de antipatrones Scrum
Hasta
aquí la perorata, a manera de introducción. Lo que sigue es una lista de esas
prácticas fuera de contexto, o antipatrones.
- “Nuestro Scrum Diario tarda 30 minutos o más, hablamos
mucho de todo”, emparentado con “no hacemos Reunión Diaria porque no le vemos
sentido”. Ya sé, tus tareas tardan 20, 30 o más horas y cada día que se reúnen,
tus actividades siguen “en progreso”. Por eso no tiene sentido reunirse cada
día.
- “Hablamos con el Dueño de Producto cada 2 o 3 semanas,
durante la reunión de planificación”
- “Nuestro Sprint 0 es de nunca acabar, estamos
detallando todos los requisitos”, también conocido como el ‘contraataque de la
Cascada’
- “No sabemos donde está el Backlog del Producto”, o del ‘extraño
caso del backlog de producto misterioso’
- “No tenemos definición de terminado”, familiar de
“nuestro ‘trabajo en progreso’ es ilimitado”
- “No hacemos retrospectiva porque todo funciona muy bien
con Scrum” o “nuestras retrospectivas son una oda a la autolaceración”. Me sé muchas otras con nuestra reunión favorita de
regresión y análisis. Una, a propósito de Scrum Norris: ‘Cuck Norris no
necesita Revisiones ni Retrospectivas. No hay espacio para el mejoramiento en
los procesos de Chuck Norris’.
- “Nuestros Scrum Masters están en piloto automático”. A
estos los ascendieron en esta década a zombis. ¡Estamos llenos de Scrum Masters
zombis! Necesitamos un proyecto ‘Alice’ que acabe con esa disfunción.
- “Sí, hacemos sprints de 2 semanas, pero no entregamos
valor al negocio”. Estos son los del enfoque iterativo e insustancial. El
producto resultante es una colcha de retazos
- “Nuestros equipos son elásticos: sus miembros entran a
y salen del equipo en cualquier momento del sprint y en cualquier sprint”
- “En la organización cambiamos el modelo de gestión del
PMI por Scrum, pero el resto del proceso lo dejamos tal cual estamos
certificados CMMI”
Suplemento
- “Nuestros Scrum Masters están asignados a 4, 9 y hasta
17 proyectos simultáneamente”, mejor conocido el Pulpo Ágil
- Nuestros clientes aceptan que usemos Scrum pero los
proyectos son tiempo fijo-costo fijo-alcance fijo y el cronograma lo debemos
entregar el primer día”
Por ahora solo la lista, pero mi análisis irá mucho más
allá. Cuál es el contexto donde típicamente ocurre la mala práctica, cuál es la
recomendación de Scrum/Ágil para cada eliminar el antipatrón de la faz de la
tierra (bueno, al menos, del entorno donde se presenta), cuáles son las
consecuencias de insistir en el mal-uso de la práctica, cuál es la solución (al
menos, parcial) y, quién sabe, quizás alguna que otra excepción en la que el
uso del antipatrón se justifique. ¿Es esto último posible? Yo no lo sé de
cierto, lo supongo.
Colofón
Finalmente,
quiero referirme a la frase inicial que usé para abrir este primer incremento
sobre el tema: tiene razón Schwaber al hacer la analogía de Scrum con el
Ajedrez. Las reglas de este juego son pocas y bastante simples, sin embargo,
las estrategias existentes para jugarlo son diversas. Y hay un momento en el
juego de la ‘Torre’ y el ‘Alfil’, llamado el ‘juego medio’ por los estudiosos,
que se parece mucho a cuando los equipos de construcción de software juegan al
diseño y a la programación usando las maniobras de Scrum: es cuando se requiere
de creatividad, innovación, anticipación; es cuando precisamente nos damos
cuenta que el desarrollo de software, como el Ajedrez, es jugado por personas,
no por procesos ni herramientas.
Volveré con más antipatrones… ¡pronto! Mientras tanto, cuéntame
cuáles malas prácticas o antítesis de excelencia, te has encontrado al ingresar
a este apasionante pero complejo universo del desarrollo de software con
métodos y prácticas ágiles.
Referencias
[1]
Blog de Ken Schwaber: abril 7 de 2011:
https://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
[2]
Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design
Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN
0-201-63361-2.
[3] Felipe Camino Galicia de la Rosa,
conocido como León Felipe (Tábara,
Zamora, 11 de abril de 1884 - Ciudad de México, 18 de septiembre de 1968), fue
un poeta español. Este es su poema “Sé
todos los cuentos”:
Yo no sé
muchas cosas, es verdad.
Digo tan
sólo lo que he visto.
Y he
visto:
que la
cuna del hombre la mecen con cuentos…
Que los
gritos de angustia del hombre los ahogan con cuentos…
Que el
llanto del hombre lo taponan con cuentos…
Que los
huesos del hombre los entierran con cuentos…
Y que el
miedo del hombre…
ha
inventado todos los cuentos.
Yo sé muy
pocas cosas, es verdad.
Pero me
han dormido con todos los cuentos…
Y sé todos
los cuentos.
Cuando el Equipo Scrum incorpora y vivencia los valores de compromiso, coraje, foco, apertura y respeto, los pilares Scrum de transparencia, inspección y adaptación se materializan y fomentan la confianza en todo el mundo. Los miembros del Equipo Scrum aprenden y exploran estos valores a medida que trabajan en los eventos, roles y artefactos de Scrum.
