Buscar en Gazafatonario IT

miércoles, abril 08, 2015

Presentación sobre Transformación Sostenible



Este martes 7 de abril, nos reunimos participantes de las Comunidades del Próximo Capítulo del PMI Antioquia y de Ágiles Colombia a hablar sobre Transformación Organizacional Sostenible. Al margen de la sesión, creo que es una excelente idea que se realicen este tipo de encuentros entre Comunidades ya que el objetivo que buscamos todos es el mismo: hacer las cosas bien y encontrar formas de mejorar continuamente.

Facilité la sesión alrededor del trabajo que realizáramos el magnífico equipo de coaches del que hice parte durante el Scrum Coaching Retreat Latin America  (#SCRLA15) en marzo de 2015, en Buenos Aires, Argentina. Se trata de un marco para Sostenibilidad de las Transformaciones Organizacionales que publicamos al final del encuentro. Un trabajo en progreso.

Los dejo con el material de la presentación: Transformación Sostenible

Más información sobre el trabajo del equipo y de los demás equipos en el Scrum Coaching Retreat Latin America 2015, puede encontrarse en:


Sobre Adopción y Transformación pueden leer mi artículo en:


Sobre el cambio a ágil, temores infundados y penas frívolas, pueden leer mi artículo en:


miércoles, abril 01, 2015

Sobre Adopción y Transformación

“Todos los modelos son útiles, pero algunos fallan más rápidos que otros.” [Jurgen Appelo]
Me llamó la atención uno de los números del recién salido ‘State of Agile Survey’ de la consultora VersionOne [1]. Se trata de las barreras que encuentran las compañías a la hora de realizar la adopción Ágil. Revisando los tres últimos informes (2012, 2013 y este último correspondiente a 2014), encuentro que los principales obstáculos para adoptar Ágil son:
  1. (Falta de) Habilidad para cambiar la cultura organizacional
  2. Resistencia general al cambio
  3. Intento de introducir elementos ágiles en un framework no ágil
  4. (Falta de) Disponibilidad de personal con las habilidades necesarias
  5. (Falta de) Apoyo de la dirección
Figura 1. Fuente: VersionOne 7th State of Agile Survey 2012. Haga clic en la figura para ampliar.

Mientras que las tres últimas causas que menciono se mantienen en porcentaje más o menos estable, aunque me interesa hablar más delante de la cuarta (falta de personal idóneo), quiero concentrarme en la dramática reducción que hubo en los números de las dos primeras.

Mientras que en 2012 y 2013, el peso de la inhabilidad para cambiar la cultura organizacional fue se mantuvo más o menos constante, 52% y 53%, en 2014 este número descendió a un 44%. Es decir, menos de la mitad de los encuestados dijo que ese es el parapeto más fuerte por derribar a la hora de adoptar métodos y prácticas ágiles en las organizaciones.

Figura 2. Fuente: VersionOne 8th State of Agile Survey 2013. Haga clic en la figura para ampliar.

Algo similar ocurrió con la Resistencia general al cambio, natural por demás en la gran mayoría de las organizaciones y personas. De un 41% y 42% en 2013 y 2013 respectivamente, bajó hasta un 34% este último año. Es una encuesta al fin y al cabo, basada en la percepción y, como esperamos todos, en la experiencia de quienes respondieron las preguntas, entre ellos yo mismo.

Aunque el estudio no presenta ni analiza las causas de esos cambios porcentuales, quisiera especular un poco al respecto. Se trata precisamente de lo que hemos aprendido y experimentado durante los últimos tres años. Hasta principios de esta década, había “una confusión entre adopción y transformación. Tristemente, los agentes de cambio hablaban acerca de adoptar Ágil y no acerca de transformar la cultura de una compañía para que esta soportara la mentalidad ágil” [2] y todo lo que ello significaba. Sahota lo llamó “miopía de los agentes de cambio”. En definitiva, muchas de las fallas en la adopción Ágil radicaban entonces o eran el resultado de no entender la cultura organizacional.
 
Figura 3. Fuente: VersionOne 9th State of Agile Survey 2014. Haga clic en la figura para ampliar.

Pero creo que hemos aprendido que para ser ágiles necesitamos conformar equipos con personas que sean capaces de estar juntas a través del tiempo, que se conviertan en equipos de alto desempeño y que construyan escenarios de confianza con sus usuarios/clientes. Si no lo tienes claro, lo que debes hacer es crear equipos ágiles alrededor de los objetos persistentes en tu organización, es decir, los proyectos. Usa Scrum o Kanban o XP (aunque según el estudio que he citado, eXtreme Programming se usa cada vez menos –menos del 1% de los encuestados dijeron que usaban XP en 2014) o cualquier otro método ágil que permita llevar tu organización a puerto seguro a nivel de equipos.

Tus equipos ágiles deben enfocarse en validar continuamente sus hipótesis y en generar valor lo antes posible. En mi artículo “Cultura ágil: ese oscuro objeto del deseo” decía que esta es la base para formar equipos de alto rendimiento que enfrentan alta incertidumbre, como la presente en los proyectos de software. En estos equipos cambiamos la planificación basada en especialidades por un enfoque en la propagación de conocimientos, de experiencia. Además, en los equipos ágiles invocamos continuamente energías innovadoras para encontrar formas mejores de aumentar la productividad y el entusiasmo de los participantes.

Eso es lo que creo que está pasando. Como dice VersionOne en el estudio, “Ágil está ganando momento” y lo que no dice es que quienes lo estamos haciendo, quienes somos ágiles también. Ágil es algo que eres, ágil es algo que soy.

Una nota final sobre la falta de personal con las habilidades necesarias en Ágil

Aunque ligeramente, fue mayor el porcentaje de encuestados que respondieron a esta barrera en relación con los dos años anteriores, en los que el número fue del 33%. Esta vez, 35%. En este sentido es vital entonces no solo aumentar el entrenamiento sino también mejorarlo. Y valga aquí la pena decir que no es suficiente con obtener certificaciones, sea cual fuere la casa o escuela certificadora. Ya sabemos que en Ágil, sobre todo en Scrum, es extremadamente fácil obtener un certificado de Scrum Master o de Scrum Developer, pero, al igual que el propio marco de trabajo, es considerablemente difícil hacerlo valer en proyectos reales.


El certificado conseguido después de un  Scrum nos asegura que sabemos construir ciudades con piezas del set #6177 de Lego y que hicimos 240 puntos en el Ball Point Game y que quizás nuestro próximo proyecto con Scrum será exitoso, pero nada más. La experiencia es fundamental para una verdadera transformación. Lo menciono porque me sigo encontrando con personas, colegas, amigos y hasta familiares que insisten de manera agotadora en este asunto de la certificación y no en ir directamente al fondo de las cosas: al hacer ágil y al ser ágil.


Ciclo Sensei - Senpai - Kohai


Es necesario que haya más ciclos “sensei – senpai – kohai”[3], para aprovechar el conocimiento y, sobre todo, la experiencia de otros. Es necesario hacer Comunidad, algo que seguimos insistiendo con amigos como Jorge, Wilmar, Leonardo, Carlos, Robinson y Lucho y tantos otros en Ágiles Colombia y Ágiles Latinoamérica, con quienes nos reunimos constantemente. El autoaprendizaje también ayuda. Más allá de todo esto, tener el coraje de decir que necesitamos ayuda, que no podemos hacerlo solos.




Referencias

[1] VersionOne. 9th State of Agile Survey. 2015.

[2] Sahota. Michael. “An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture”. 2012

[3] Ciclo Sensei – Senpai – Kohai, algo que aprendimos en el último #SCRLA15 del amigo Hiroshi y que usáramos en nuestro trabajo sobre Sostenibilidad de la Transformación Organizacional, algo de lo cual les hablaré más adelante. El ciclo se refiere a los estudiantes nuevos (Kohai) aprendiendo de estudiantes más avanzados (Senpai) y estos a su vez aprendiendo y practicando con maestros experimentados (Sensei).

jueves, marzo 05, 2015

De historias de usuario, culturas y del arte de narrar historias

“Yo no sé muchas cosas, en verdad,

Digo tan solo 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.
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 ...”
[León Felipe, Aguaviva.]

La vida es una alegoría, los seres humanos no solo estamos configurados como cuerpos biológicos abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más universal, con nuestros semejantes. Pero además poseemos una visión personal para interpretar nuestra cotidianidad, tenemos ideales y pensamientos, emociones y aversiones que nos hacen actuar  de formas particulares al interpretar nuestra realidad.

En todo esto, la narración de historias juega un papel muy importante  en la construcción de conocimiento. La narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias permite a las culturas sobrevivir y progresar; es el camino más simple y más efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en el sistema sobre los mismos objetivos.” [1]

Las historias (de usuario) establecen una manera de organizar y comunicar experiencias. Las personas usan instintivamente la narración de historias para organizar un cúmulo de ideas que consideran disperso; además, gracias a ellas pueden organizar lo que saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las personas nos invitan de una forma u otra  a investigar sus pensamientos, sus sentimientos y sus intenciones. Finalmente, como oyentes y más tarde como lectores de las historias de usuario, adherimos a los acontecimientos, como una exploración de la experiencia de los usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre todo, comprendiendo su valor real.

Quienes transitamos a diario por el vasto universo del diseño y construcción de productos de software sabemos que es importante enfocarnos en el valor que estos prestarán a sus dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo se usará el sistema que en las largas listas de funciones o características que ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la completitud de las historias y estas, a su vez, facilitan filtrar las formas potenciales de usar el sistema que ofrezcan poco o ningún valor real a los usuarios. Este foco constante en el valor permite asegurar que cada entrega del sistema sea tan pequeña como sea posible, a la vez que tenga valor real para los usuarios del sistema y para los interesados que financian el desarrollo.” [3]

Cuenta las historias, no las escribas

En su libro “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo mejorar el desempeño del equipo ágil usando la técnica de las historias de usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés actual sobre las historias y la supervivencia de las culturas. Esta idea es precisamente la del título de esta sección: cuenta historias, no las escribas.

Uno de los errores más comunes de las personas que empiezan a usar prácticas ágiles es creer que las historias de usuario son requisitos livianos. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos. Este malentendido conduce a situaciones en que las historias sean recolectadas en herramientas de gestión de actividades, con muchos detalles escritos o proporcionados por representantes del negocio.

Nada más alejado de una buena práctica. Las historias de usuario implican un modelo totalmente diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde la transferencia de conocimiento vía documentos “pesados” se reemplaza por involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos que la conversación cara a cara es la forma más efectiva de comunicar información y que una buena discusión entre los interesados y el equipo ágil lleva a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los requisitos se escriben, aun si los llamamos historias de usuario, estas discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo de experiencia en esto, pasé dos décadas escribiendo requisitos de software, todo tipo de requisitos, todo tipo de productos de software.

La recomendación es simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de tiquetes electrónicos, pero solo como recordatorios de esa conversación que tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles de las historias con anticipación. Compromete a los interesados del negocio e involucra a los miembros del equipo en una discusión, busca distintas perspectivas de la historia y explora opciones. Esta es la forma de acceder a los beneficios reales de trabajar con historias de usuario.

Beneficios clave de contar historias

Las discusiones permiten a los representantes del negocio, no solo explicar lo que quieren, sino también asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de los mayores problemas en los modelos tradicionales son los malos entendidos entre los distintos roles en el equipo y entre los interesados, entre quienes existen niveles heterogéneos de conocimiento acerca de las necesidades de cada uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento sobre la historia.

El segundo beneficio, apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo se involucra en una discusión, los vacíos funcionales, las inconsistencias y los requisitos no claros se descubren más rápidamente que cuando una sola persona (léase Analista del Negocio o similar), escribe los detalles.

Pero el beneficio más importante de la comunicación cara a cara, comparada con el paso de información vía documentos, es que la primera produce mejores soluciones, mejores productos. Para ser capaz de construir buenas soluciones, las personas necesitan conocer los planes y las oportunidades del negocio, entender el dominio del problema, tener un conocimiento profundo de las restricciones técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan servir. Involucrar a un grupo de personas en el análisis desde diferentes perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.

Como lograrlo

La excusa más común para llenarnos de documentación es la insistencia del negocio en la aprobación formal, las regulaciones legales o gubernamentales o las dependencias con terceros. Si es necesario “firmar” las historias hazlo a medida que las discutes. Es más, si el alcance final debe ser aprobado por varios interesados en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la reunión de planificación del Sprint donde se van a construir las historias. En cualquier caso, el Dueño de Producto juega un papel muy importante en la consecución de tales aprobaciones. Es una de sus responsabilidades directas.

Como siempre, ensaya distintos acercamientos y en cada retrospectiva analiza como le fue a tu equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el tema, recomiendo amplísimamente los libros que usé como referencia

Referencias

[1] [2] [3] Ivar Jacobson et all. Use Case 2.0. Ivar Jacobson International. 2011. Traducción de Luis Antonio Salazar y Carlos Mario Zapata.

[4] Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP

[5] Conocido también en algunas culturas o regiones como el fenómeno o el juego del “teléfono descompuesto”

Para saber más de historias de usuario puedes leer mi serie de artículos en este mismo Gazafatonario:

http://goo.gl/iJvj7
http://goo.gl/NZv4vj
http://goo.gl/e1DSVh
http://goo.gl/eGHQQU

lunes, febrero 16, 2015

“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

Sobre el cambio a ágil, temores infundados y penas frívolas
“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

“Las masas humanas más peligrosas son aquellas en cuyas venas ha sido inyectado el veneno del miedo... del miedo al cambio.”
[Octavio Paz (1914-1998) Poeta y ensayista mexicano]

Todavía me encuentro con muchas personas que creen que ‘saltar al ecosistema ágil’ es como en las películas donde después de un ataque al gobierno, a veces por parte de alienígenas, a veces por parte de un gobierno enemigo, se dan a la búsqueda de los jóvenes y niños ‘genios’ de las universidades para que les resuelvan el misterio o le decodifiquen el mensaje cósmico. Lo bueno de esas historias es que siempre hay alguien que lo logra, a veces solo, a veces en compañía de alguien que para lograrlo viola un sinnúmero de leyes y comete muchos delitos en simultáneo. Otros son más facilistas y quieren usar la máquina del tiempo para ir al momento justo antes de que los modelos y enfoques tradicionales salieran a la luz pública y borrarlos de la historia. ¡Eso ya no es posible! Al menos no con una máquina.

Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas. También es cuestión de pensar un poco, de entender cuáles son los problemas mayores de las organizaciones y de las personas cuando intentan dar el salto a una nueva forma de ver e interpretar el mundo. Hay dolores superficiales, pero también hay enfermedades crónicas cuyos síntomas no son tan evidentes; para completar el cuadro clínico, hay penas que traspasan lo físico y se quedan en lo puramente espiritual, son difíciles de detectar y mucho más de erradicar, de sanar.

Conocer los miedos no solo de los interesados sino también de los patrocinadores, de quienes toman las decisiones, por ejemplo, es un buen comienzo. He encontrado que muchos de ellos/ellas temen no alcanzar el éxito en el proyecto de transformación y quienes no, imaginan o sospechan que pueden perder su lugar en la organización una vez se dé el cambio, asunto que está bastante alejado de la realidad a no ser que la persona no se adapte al nuevo entorno. En este último caso, tendríamos que preguntarnos si en realidad ya estamos en el punto que queremos.

Quizás entonces el entrenamiento y el soporte no ha sido el adecuado. A veces nos quedamos en las áreas de tecnología, cuando ‘Ágil’ es un asunto de toda la organización. El papel del Scrum Master es fundamental en este aspecto y no nos digamos mentiras (al menos no entre nosotros), los buenos Scrum Masters, los verdaderamente buenos, son difíciles de encontrar: ellas o ellos necesitan tener lo que llamamos comúnmente ‘don de gentes’ y también habilidades en lo ágil y también conocimiento técnico y todo esto junto es muy difícil de encontrar en una sola persona.



Algunas otras dificultades ya son ‘clásicas’: cambiar de un enfoque de ‘comando y control’ tradicional a un enfoque de autoorganización, al mejor estilo Scrum, es una tarea espinosa por no decir algo indecible. Este es un aspecto que impacta a los mandos medios de una compañía, por ejemplo, a la habitual oficina de proyectos o PMO que llaman en algunos entornos. Es precisamente en esta oficina donde comienza el cuestionamiento de lo que puede ser y no es: ¿entonces qué hago con todos los gerentes de proyecto que tengo? He escuchado decir. Encontrar una justificación válida para esto es arduo, imposible dirán algunos. Pero en general, todas las personas tienden a sentir miedo, por aquello de los equipos multifuncionales, donde el poder de la especialización de una persona se pierde. En este mismo orden de ideas, abandonar la falsa seguridad que dan los planes a mediano y, sobre todo, a largo plazo, que nunca han funcionado, en pro de planes a corto plazo, es algo que enciende las alarmas de más personas en la organización de las que quisiéramos contar. Miedo al cambio, natural por demás, es el tema de fondo.

Algunos otros obstáculos que he encontrado:
  • Conseguir que las áreas del negocio y la alta dirección se involucren efectivamente
  • Lograr la confianza y la autonomía que requieren los equipos ágiles y, sobre todo, el equipo de transformación
  • Qué hacer con la jerarquía existente en las organizaciones donde el escalafón de las personas es algo ‘valioso’, es una pregunta que deberíamos responder al iniciar el cambio
  • Crear, preparar y promover un equipo ‘colonizador’ o mejor aún, un equipo ‘conquistador’, punta de lanza, que se atreva a hacer las cosas, a ir más allá de donde nadie en la compañía ha llegado. Este es un asunto vital.
  • Desaprender los hábitos del desarrollo en cascada, del comando y control, del esperar a que me digan qué hacer, del llenar documentos por llenar y todos esos aspectos que aborda el manifiesto ágil en toda su extensión. Sobre este asunto, los invito a leer: ‘Respuesta al cambio sobre seguir al plan: no planearás’, aquí mismo en este Gazafatonario.
  • No intentar cambiar a las personas que no quieren cambiar. La naturaleza humana evade el cambio o se resiste a este cuando alguien intenta cambiarla. Cuando la dejan en paz, cambia por sí misma… ¡si quiere!
  • Finalmente, pero no menos importante, cambiar la cultura de la compañía, en ágil todo es acerca de la cultura. Pero sobre esto pueden leer mi artículo: ‘Cultura ágil: ese oscuro objeto del deseo’, aquí mismo en mi Gazafatonario.
  • Más allá de todo, recordar que ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Cambia... Hay un gran chance de que el nuevo día sea radiante.



martes, diciembre 16, 2014

Antipatrones Scrum: definición de la estructura


Sobre ScrumButs, seres humanos y otros menesteres terrenales de lo Ágil

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

Estamos de acuerdo en que Ágil es más acerca de las personas y sus interacciones, la comunicación cara a cara y la cultura, que acerca de los procesos, las prácticas y las herramientas, aunque nunca debemos cansarnos de repetir esto. Sí, las prácticas de Scrum son importantes y nos proporcionan guías inteligentes que nos ayudan a mejorar nuestra productividad y la calidad de lo que hacemos, pero son los principios – la parte difícil – los que hacen que Ágil sea sostenible en el largo plazo y los que nos permiten maximizar los beneficios que el método nos ofrece.

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”. [4]

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”’