El cambio es difícil, aceptar el cambio es aún más
difícil, pero cambiar una cultura organizacional, arraigada en la estructura de
las organizaciones y en el ADN de las personas, es quizás la tarea más compleja
que un ser humano, o un grupo de personas, pueden emprender. Pero los cambios
son necesarios y con estos vienen los sinsabores de la toma de decisiones
erróneas, las que, en el caso de los métodos de desarrollo de software, son el
equivalente de errores en la adopción de prácticas y métodos nuevos para la
organización.
Durante la transición al enfoque ágil de construcción
de software, muchas veces las organizaciones y las personas encargadas del
cambio en las organizaciones deciden no seguir la línea descrita por las guías,
los expertos o las prácticas documentadas por la industria, y se apartan de
ello simplemente para adecuar su “nueva” forma de trabajo a las antiguas
costumbres, a lo que es conocido y que costó tanto (tiempo, dinero, personas,
recursos) implementar y que de alguna manera ha funcionado en la organización.
El término ScrumBut
(ScrumPero) se usa para referirnos a
los cambios a Scrum que se hacen para ocultar disfunciones y problemas que un
Scrum no modificado revela a la luz del contexto donde suceden los hechos. Un
ejemplo típico, de algunos presentados en [1], es: “Usamos Scrum, pero no podemos
construir una pieza de funcionalidad en un mes, así que nuestros Sprints tardan
6 semanas” (o más). En este ejemplo, El ScrumBut es el uso de sprints de 6
semanas debido a la inhabilidad de la organización para dividir los requisitos
en historias de usuario (o cualquier otra pieza que se use para representar
funcionalidad del software) lo suficientemente pequeñas y simples.
El término (ScrumBut)
implica que el cambio al método Scrum se debió a problemas en la organización,
en vez de a problemas con el propio método Scrum. Pero ojo, no todos los
cambios al método Scrum se consideran ScrumButs.
Se considera aceptable cambiar las prácticas de Scrum si los cambios se basan
en una necesidad real y en un entendimiento profundo de los mecanismos que
hacen que Scrum funcione. Este último asunto es lo que constituirá la parte de “Excepción”
del antipatrón.
Personas
y sus interacciones sobre el mismísimo proceso Scrum y las herramientas que proporciona
.jpg)
Así que cuando decimos que una mala práctica, un ScrumBut, es este de los sprints
demasiado extensos, no vamos a arremeter contra la práctica en sí, lo que nos
interesa es ir a los principios ágiles, esos del mismísimo Manifiesto Ágil y
mirar que podemos hacer. ¡Eureka! Hay un principio que dice: “Entregamos
software funcional frecuentemente…” [2], esto es lo que nos interesa. La
entrega de productos, de alto valor para el cliente/usuario, priorizado por
este, es lo que nos va a permitir obtener una mejor y más objetiva retroalimentación
del estado de las cosas, nos hablará del grado de satisfacción del usuario, de
su felicidad y de la calidad de ese producto.
Y esta entrega de software debemos hacerla desde el
inicio del proyecto y manera frecuente, ¿cómo nos suena ‘cada 2 semanas’? De
esta forma, si nos equivocamos, lo hacemos rápido, en 2 semanas, y barato,
mucho más económico que si hubiésemos invertido meses de trabajo y muchas
personas en esa porción del producto y del proyecto. Si nos equivocamos,
todavía hay tiempo para reaccionar, decidir sobre acciones que nos hagan volver
al “camino correcto”, que mejoren el estado de salud del producto/proyecto y de
todos los interesados en el mismo.
Estudio
a fondo de un Antipatrón: la estructura y el contenido
Todo este preámbulo, necesario por demás, para llegar
al meollo del asunto. Vamos a intentar definir una primera versión de
Antipatrón con el ejemplo que hemos venido mencionando a lo largo de este
estudio. Es precisamente lo que me interesa porque en todo este recorrido de
consulta sobre el tema he encontrado que la gran mayoría de los autores sobre mencionan
el antipatrón, el scrumbut o la práctica dañina, algunos dan un paso más y
mencionan una o dos recomendaciones de como curar la enfermedad. Pero en
general, todos se quedan en el camino, no van más allá de mencionar una lista
de prácticas incorrectas. Ahora que recuerdo, eso mismo hice yo en el primer
artículo (acercamiento) de esta serie sobre antipatrones Scrum [3].
Pero muchas veces ayuda conocer el porqué del por qué,
el problema detrás del problema, la causa raíz y con ello en la superficie, es
un poco más liviano encontrar el camino de salida. Así que vamos al fondo de
las cosas. Hagamos un acercamiento más detallado a un antipatrón, mejor dicho,
entremos al núcleo de una mala práctica común.
Nombre
del Antipatrón: ‘Sprint demasiado extenso’
Recomendación
de Scrum: Realizar sprints de 2 semanas (o menos). Más
específicamente, para equipos de menos de 5 personas, sprints de 2 semanas
están bien: si el equipo es de 5 personas o más, es posible hacer sprints de
menos de 2 semanas. En definitiva, los sprints no deberían tardar más de 3 a 4
semanas. Este último lapso, quizás solo para equipos pequeños de 3 personas.
Contexto:
Experimentación temprana con Scrum, legado Cascada de ciclos de producción extensos,
clientes/usuarios reacios a participar en intervalos cortos.
Esta situación es bastante común cuando el equipo venía
trabajando con Cascada o con RUP o WaterRUP o similares. También, cuando
el equipo intenta hacer/entregar muchas funcionalidades o funcionalidades muy
grandes o complejas, o cuando el equipo es muy pequeño (1 o 2 personas) y para
entregar Valor extienden los sprints
Solución
(este es el antipatrón): Establecer sprints de 4 semanas o
aún más largos.
Consecuencias:
en vez de un trabajo más extensos para los sprints, las tareas planeadas
tienden a no finalizarse al final del sprint, posiblemente porque las primeras
semanas no son usadas los suficientemente eficientes y se establecen tareas muy
largas en los sprints. Disminuyendo consecuentemente el compromiso del equipo a
entregar elementos al final del sprint. El ciclo de retroalimentación llega a
ser tan extenso que parte del trabajo podría no llegar a necesitarse más.
La productividad no es la misma al inicio del sprint
(normalmente más baja), que al final del mismo. Algo similar ocurre con el “paso
sostenido” que debería mantener el equipo durante todo el proyecto: en este
caso, al principio del sprint, los miembros del equipo inician con el ritmo que
quisieran tener durante todo el sprint y, por extensión, durante todo el
proyecto; sin embargo, hacia la segunda parte del sprint y sobre todo hacia el
final del mismo, el equipo regularmente trabaja más de la cuenta, tratando de alcanzar
el objetivo del sprint. Lamentablemente, muchas veces es demasiado tarde.
Excepciones:
Si el equipo de desarrollo debe sincronizarse con trabajo externo que tiene un
ritmo más lento (por ejemplo, desarrollo de hardware), sprints más prolongados
podrían justificarse. En este caso, se debe prestar especial atención a la “Definición de Preparado
Hasta allí esta versión. ¡Funciona para mí!
Terminemos
con una sugerencia
Ya he dicho en otras ocasiones que debemos empezar con “Scrum
al Natural”, Scrum orgánico si se quiere. Cuando sea hora de hacer alguna
adaptación, motivada por el hábitat organizacional, debemos evaluar estos cambios
a las prácticas Scrum en su contexto, con el fin de separar los cambios dañinos
de los necesarios o benéficos requeridos por ese hábitat organizacional y
evitar así una crisis mayúscula en el mediano o en el largo plazo.
Ágiles, nos vemos en la Red.
Referencias
[1] Un breve artículo: ‘ScrumButs and Modifying Scrum’, lo encuentran en
[2] http://www.agilemanifesto.org/iso/es/principles.html.
El principio completo dice:
“Entregamos software funcional frecuentemente, entre
dos semanas y dos meses, con preferencia al periodo de tiempo más corto
posible.”
¡Nunca está de más darse una pasadita por el Manifiesto
Ágil!
El primer artículo de esta serie sobre Antipatrones Ágiles/Scrum,
donde hago una introducción al asunto que nos ocupa. La dirección completa es:
[4] Un artículo sobre este asunto de la Definición de
Preparado fue publicado hace poco por el amigo y colega Johnny Ordoñez, se los recomiendo ampliamente:
‘La
Definición de “Ready” es tan importante como la Definición de “Done”’
Lo encuentran en: http://johnnyordonez.wordpress.com/2014/12/12/la-definicion-de-ready/
