Buscar en Gazafatonario IT

viernes, diciembre 28, 2018

Agilistas Pesados (mean agilists)

Escena de la película Chicas Pesadas (Mean Girls)

Personas y equipos disfuncionales pululan por todo el universo. Agilistas de esta clase también. Son comunes en organizaciones y comunidades de todo tipo, como las nuestras. Basado en un artículo original de Tom Schorsch, capitán de la fuerza aérea estadounidense, escrito en 1996 para CrossTalk Magazine, y que hacía referencia a niveles negativos de CMM, los dejo con esta tipología liviana y fácil de entender pero difícil de llegar a dominar.
El Agilista Certificado
¡Como tenía que ser! Este espécimen siempre comienza su discurso presentando su más reciente certificación y enumerando todas las demás, enfatizando en que los certificados le dan el poder suficiente y necesario para ejercer su papel no solo en la organización sino en la comunidad mundial. Conoce los detalles de todos y cada uno de los marcos de trabajo, prácticas y, sobre todo, de las herramientas que según él son requeridas para una agilidad apropiada e impecable, pero nunca o casi nunca ha participado como miembro de un equipo de campo. Algunos ejemplares de esta colección leen mucho, hablan bastante bien en público y son empáticos. Pero la mayoría solo cree que están por encima del bien y del mal. No necesitan mejoramiento, mucho menos continuo.
Creen y promulgan que son más rentables que quienes no tienen sus calificaciones, independientemente de la calidad del trabajo que producen.
El Agilista Negligente
Es un líder que presta a la organización un servicio muy especial, de hecho, a menudo con excesiva fanfarria, sobre todo para implementar procesos semirígidos y rígidos alrededor de una seudoagilidad enmascarada. Sin embargo, este personaje incluso carece de la voluntad suficiente para llevar a cabo el esfuerzo necesario de cambiar y de hacer cambiar a su equipo y mucho menos a su organización. Generalmente no producen ni ayudan a producir nada y, cuando lo hacen, buscan solo su gloria personal y lo hacen usando procedimientos tradicionalistas de emergencia, argumentando que ya no hay tiempo de hacerlo de la manera “correcta”.
El Agilista Obstructivo
Su lema es: los procesos, aunque sean inapropiados e ineficaces, se implementan con rigor y tienden a obstruir el trabajo. Para esta raza de agilómanos, la adhesión al proceso es la medida universal de progreso y del éxito. Conocen bien los nombres de las secciones de la guía de Scrum y de otros marcos de trabajo y practican aquello de que los roles, eventos, artefactos y reglas del marco de trabajo son inmutables y que el marco de trabajo solo existe como un todo. Cualquier creación real de un mínimo producto viable es incidental. La calidad de cualquier producto no se evalúa, presumiblemente suponiendo que dicha evaluación es innecesaria, ya que si se sigue el proceso adecuado, se garantiza una alta calidad.
Según mis observaciones en la última década, esta es la raza más abundante en el ecosistema ágil universal.
Promueve fervientemente que se sigan las guías oficiales de las prácticas ágiles y los procedimientos definidos, pero al carecer de la voluntad para medir la efectividad de tales prácticas, rara vez tienen éxito en su tarea básica de crear trabajo. Incluso impulsa el que a los equipos se les pague no por el valor de sus productos, sino por la cantidad de horas dedicados a construirlos y fomenta la realización de actividades sin valor agregado pero relacionadas con la adherencia a los marcos de trabajo.
El Agilista Desdeñoso
Los agilistas de esta estirpe se las han arreglado para lograr que los equipos en los cuales están involucrados y la alta gerencia ignoren o intenten neutralizar las percepciones desfavorables suscitadas a raíz de la ineficacia de la organización a la cual pertenecen, asunto que ya se ha hecho evidente para el mercado circundante. Sin importar el impacto negativo a mediano y largo plazo, las métricas de embellecimiento son las preferidas y, sin embargo, las mismas se someten a un proceso de embellecimiento antes de salir a la luz en reuniones de comités primarios y directorios donde se alimenta el ego de quienes no se comprometen.
Con desdén pero con una alta dosis de lisonja, logran que la volatilidad en las especificaciones y los cronogramas se refundan como evidencia de la "agilidad" de la organización. Presentan las certificaciones sobre los "mejores procesos" como evidencia de que la organización está funcionando de manera óptima; comprometen a la organización con la adherencia a la “sección ágil” de los métodos tradicionalistas (léase CMMI Ágil, ISO Ágil, ITIL Ágil y un largo etcétera). Atribuyen los malos resultados a factores fuera del control de la organización. Finalmente, consiguen que la organización se comprometa con los procesos ineficaces, lo que lleva a un ciclo de retroalimentación de creciente desorganización.
El Agilista Roedor
Trabaja habitualmente para minimizar y socavar los esfuerzos de quienes buscan hacer la diferencia, a quienes este ejemplar ve como antagonistas. Rivaliza especialmente con quienes están tratando de hacer la diferencia como agentes de cambio y solo está pendiente de lo que hagan estos para copiarlo y anunciarlo como propio. Abundan en organizaciones que disponen de recursos escasos para cambiar su cultura y solo quieren aprovechar los recursos de organizaciones más efectivas y las habilidades de líderes genuinos.
El Agilista Inocente
Si llegaste hasta aquí, espero que hayas reído al menos un poco. Era el propósito de todo. ¡Pásala por inocente!

¿Qué te pareció la charada? Por favor, dejámelo saber en el foro.
Lima, 28 de diciembre de 2018

sábado, diciembre 01, 2018

Las mejores o buenas prácticas ágiles no existen


¡Las peores o malas tampoco!
Veamos la historia de cómo es esto.
Hace quince años escribía un artículo que dio pie a mi primer libro Asuntos de la Ingeniería de Software (clic aquí), se trata de las muy comentadas hace un par de décadas: Seis Mejores Prácticas (clic aquí), las mismas que promulgaba el Proceso Unificado (UP o RUP, dependiendo de la edición que hayamos usado de la metodología - clic aquí).
Lo nuestro ahora son los experimentos, usamos lineamientos “tipo Scrum” basados en la teoría del control empírico de procesos, planteamos hipótesis y las probamos en períodos muy cortos de tiempo, tratando de aumentar el número de experimentos por unidad de tiempo. De esta manera, si fallamos, lo hacemos rápido y barato; pero si tenemos éxito, entregamos valor igual de rápido y de barato.
De esta forma, toda práctica, toda idea es bienvenida. El hecho de que una práctica no le funcione a un equipo o a una organización no quiere decir que no le servirá a otro equipo o a otra organización, incluso entre equipos de la misma empresa esto puede suceder. Los escenarios y las variables del entorno son diversos, es por ello que dejamos atrás las recetas predefinidas tipo RUP, CMMi y similares. Pero el sentido inverso de esta afirmación también se cumple: el que funcione en un contexto no es garantía de que una práctica funcione en otro.
Hoy por hoy aprendemos por experimentación, descubrimos por experimentación (por ejemplo, descubrimos el software que escribimos), innovamos por experimentación, diseñamos por experimentación, cambiamos por experimentación. En este apartado quiero referirme precisamente a lo que Jason Little llama Gestión Lean del Cambio (clic aquí).
 Gestión Lean del Cambio
Un modelo no lineal, basado en la retroalimentación, para gestionar el cambio
Algo que nos ocurre muy seguido es que fallamos al tratar de identificar el problema correcto a resolver, lo que confluye en la insalubre generación de desperdicio. Toda práctica que nos posibilite el evitar esa falla se convierte en una sinfonía para nuestros oídos.  Los experimentos nos ayudan a reconocer a gran velocidad si el problema que tenemos entre manos es el oportuno, es el que debemos resolver a continuación.
De hecho, los experimentos están en el corazón de la innovación. También, las mejoras incrementales a los productos y servicios que desarrollamos requieren que hagamos experimentación continua. Para todo esto es necesario:
  • Trabajar en equipo: el trabajo colaborativo, en equipo, la inteligencia colectiva es lo que permite el éxito. El ejercicio de la colaboración siempre está en la cima de mis prioridades.

  • Simplicidad: no se trata solo de no generar desperdicio, sino también de refinar el problema, dividirlo en problemas cada vez más pequeños.

  • Dar un paso a la vez: no tratemos de experimentar con todo y de todo de una sola vez. Esto casi siempre es un camino al abismo. Lo que quizás sí podemos hacer es realizar varios experimentos al tiempo. ¡Funciona para mí!

  • Obtener conocimiento pronto y con frecuencia: hay que recorrer rápidamente todo el camino. El objetivo son los consumidores finales, no grupos controlados de clientes o usuarios.  Los MVP funcionan pero no todos pueden quedarse en el laboratorio.

  • Estar preparados para fallar y aceptarlo: nos va a ocurrir. ¡Me ha ocurrido! Simplemente levántate mañana con más energía, con una gran sonrisa y con una nueva idea. En esto de la agilidad siempre sale el Sol, radiante, así que vuelve a invitar a tus amigos e inicia un nuevo experimento.

  • Cerciorarse de que tu organización considere la seguridad como un prerrequisito valioso (agilidad moderna – clic aquí – donde, de hecho, experimentar y aprender rápidamente es otro principio).
 Agilidad Moderna

De todo esto he logrado:
  • Ahorrar dinero: tanto para mí como para las organizaciones para las cuales he trabajado y no hablo solo de mis empleadores, sino de los clientes también.

  • Fallar de forma positiva: y también a evitar que se produzcan fallas más significativas que produzcan resultados desastrosos, grandes pérdidas de tiempo, dinero, oportunidad, marca y hasta de felicidad de todos los comprometidos.

  • Desarrollar mejores productos y servicios: o ayudar a diseñarlos, descubrirlos y ponerlos en funcionamiento, al servicio de miles o de millones de personas.

  • Aprender más y más rápido: la experimentación nos permite estar más informados y tomar mejores decisiones sobre nuestras ideas y proyectos. Muchas cosas parecen de sentido común, pero he aprendido que el sentido común muchas veces no es la práctica común.

  • ¡Ser más feliz!

Y esta es la historia del porqué no existen las buenas, mejores, malas o peores prácticas en agilidad.
Por ello, la próxima vez que alguien te diga (incluso a veces levantándote la voz) que algo no se puede hacer bajo el manto de la agilidad o al usar Scrum o algún otro marco de trabajo ágil, indaga primero los hechos, los datos que dieron origen a tal aserción. O no lo hagas del todo. Simplemente realiza tu propio experimento y déjanos saber de los resultados. 

martes, noviembre 13, 2018

¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?

Por:
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)



Aunque en varios foros hemos compartido que contratar en Cascada (o tradicional, o con alcance, tiempo y costo fijos) un proyecto (o mejor, producto) ágil es completo dolor de cabeza para ambas partes, es como querer jugar rugby con las reglas del fútbol, en este post, quisiéramos compartirte unas ideas claves de por qué no te conviene hacer esto tanto desde el punto de vista del Cliente como del Proveedor, vamos pues:

Problemas desde el punto de vista del Cliente

  • El alcance no puede ser fijo en estos tiempos de alta disrupción  (VUCA (1)) y es un error tratar de definir los requisitos a priori dada esta misma volatilidad(2)
  • El proceso de control de cambios (no te agregaría ningún valor)haría muy lenta las decisiones, y retrasaría el Time to Market, considerando que en ágil existe una continua repriorización y modificación de los requisitos en función del valor.
  • Tal vez  (la verdad, muy seguramente) te obligues a construir lo innecesario.
  • Como la responsabilidad no es compartida, se genera una relación de competencia en vez de una relación de colaboración, impidiendo maximización del valor del producto. 
  • Las estimaciones y costos con seguridad estarán inflados debido a la incertidumbre 
  • Quemarás al proveedor y al equipo de trabajo, pues estos fallarán continuamente en sus estimaciones.
  • Los contratos tradicionales se basan en la desconfianza. Esto aumenta la incertidumbre y maximiza los riesgos. La incertidumbre y los riesgos nunca son buenos para el cliente, generan presión y desgaste. Se pierde el foco en lo que es realmente importante: el valor para la organización y la oportunidad.
  • Los planes se basan la percepción y no en la realidad. Lo que conduce a que haya una dedicación exclusiva a "cuidar" esos planes. Esto es desperdicio. Pérdida de dinero. Dinero del cliente.
  • La realidad es lamentable: con un contrato tradicional siempre o casi siempre hay desviación por sobrecostos, esto “hiere” mortalmente la confianza interna del cliente, es decir, entre las áreas involucradas.
  • Los continuos cambios pueden ocasionar modificaciones en las cláusulas en el contrato. Allí surgen roces entre las partes, proveedor y cliente.


Problemas desde el punto de vista del Proveedor

Nota: este tipo de espantajos metodológico-contractuales por lo general se contratan bajo la siguiente forma: un alcance definido o que se define durante los primeros dos o tres meses y luego se hace una estimación que se parte en sprints.


  • De entrada sabes que la estimación es fallida, que debes incrementar costos y tiempos y no tienes como justificarlo, y aunque lo justifiques el cliente no te creerá haciendo reducir costos y tiempo (pues el alcance lo dejan fijo) y exponiéndote a un riesgo financiero, reputacional o de penalidades.
  • Aunque estimes a priori el proyecto y ejecutes por sprint, te atrasarás debido a la incertidumbre de reinante en el mundo del software, incrementando la presión sobre el proyecto y la ejecución
  • Te la pasarás reunión tras reunión justificando por qué no estás cumpliendo el plan (sabiendo que trabajas en scrum con sprints) y tratando de reacomodar el plan
  • Los controles de cambio son un dolor de cabeza que no te permite realizar priorización por valor que le conviene más al cliente y al proyecto (producto)
  • Las métricas de seguimiento cascada aplicadas al proyecto (o producto) en ágil generan un desgaste pues no hacen match con las métricas de seguimiento ágil.
  • Quemarás a tu equipo tratando de ponerte al día con el cronograma de sprints comprometido al principio del proyecto.


Soluciones

  • Contrata en ágil los proyectos ágiles (ver nuestro video sobre contratos ágiles - https://www.youtube.com/watch?v=872uF0dPYd8) 
  • Pon cláusulas de terminación anticipada, que te sirvan cuando decidas no continuar con el cliente o con el proveedor según el caso.
  • En un contrato ágil nunca pongas el alcance fijo.
  • Si te preocupan los ANS o SLA, en Scrum tienes software funcionando cada dos semanas lo que permite validar si el proveedor está construyendo el producto de forma satisfactoria.


Si tienes alguna otra disfuncionalidad a compartir, no dudes en hacerlo en la zona de comentarios.

Saludos Ágiles,

Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)


Referencias, comentarios, notas y aclaraciones
1. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
2. Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software - http://www.lecciones-aprendidas.info/2015/04/radioactividad-de-los-requisitos.html 

3. Este artículo fue escrito a cuatro manos y fue publicado en las Lecciones Aprendidas en http://www.lecciones-aprendidas.info/2018/11/por-que-no-contratar-en-cascada-un.html 


viernes, noviembre 02, 2018

La soportable levedad del ser ágil

La pubertad cercana a las Pléyades”, del artista surrealista Max Ernst.


“El hombre nunca puede saber qué debe querer, porque vive solo una vida y no tiene modo de compararla con sus vidas precedentes ni de enmendarla en sus vidas posteriores”.
[Milan Kundera, La insoportable levedad del ser. 1984]

Cavilar sobre qué es lo que decidimos ser y hacer implica reconocer que esas decisiones son únicas en su momento. No podemos regresar a ese evento en particular y cambiar de decisión. Lo que sí podemos hacer es reflexionar frecuentemente sobre cómo ser más efectivo… (El resto de la frase ya la conocemos, de lo contrario, la podemos buscar en el Manifiesto Ágil). En la práctica, no hay repetición de nada. Así que podemos darle poca o mucha importancia a esa decisión, recapacitar sobre sus posibles consecuencias e irremediablemente enfrentarlas como sea.

No queremos que los Scrum Masters, coaches ágiles, mentores, facilitadores ágiles, expertos, agentes de cambio, consultores ágiles, habilitadores de agilidad, especialistas Teal, managers 3.0, entrenadores Ágiles certificados, asesores Lean, Senseis de la transformación, peritos en trabajo en progreso y todos los que omito por no hacer interminable este panegírico, pasen a ser simplemente agilistas viejos, de los que ya nadie se acuerde y que desaparezcan en la nada. Pero es un hecho, tan solo unos cuantos, muy, muy pocos, imprimirán su nombre en la memoria de las personas, pero, ya sin testigos fehacientes, sin un solo recuerdo real, quizás pasen a ser marionetas de un movimiento que pudo cambiar el destino de millones de personas en el mundo.

Las decisiones, inevitablemente, implican conseguir información, hechos, pero también involucran sentimientos. Es precisamente por esas emociones que luego las consecuencias de tales decisiones se avistan como ventajosas o como desfavorables. De alguna manera, este constante cálculo entre lo que resulta conveniente para algunos, por interesante, por beneficioso, por experimentar algo distinto, tiene una consecuencia que, en términos de lo que queremos transformar, se podría medir como el peso o como la levedad de esa derivación.

Los agilistas estamos decididos a vivir con una levedad de ser alterada por temas como vulnerabilidad, incertidumbre, complejidad, ambigüedad, ensayos,  valores y principios, eficiencia, entrega de valor, colaboración, mejoramiento continuo y adaptación a los cambios, que nos hacen examinar no solo la naturaleza de las organizaciones actuales, sino también indagar por la naturaleza humana misma. Ese es el motivo por el cual nos estamos cuestionando todo a cada momento, es por eso que tenemos ese apetito insaciable por aprender, por experimentar, por redescubrir quienes somos a cada instante.

Es posible que no seamos capaces de ser ágiles precisamente porque deseamos ser ágiles, porque queremos que los demás cambien (sean ágiles), en lugar de aproximarnos a ellos sin exigencias y querer solo su mera compañía en el proceso de transformación. La agilidad compromete un sinfín de ideas que son como los imperios: cuando desaparece la idea sobre la cual han sido construidos, perecen ellos también. Los agilistas, en cambio, debemos ser más fuertes que eso. Nuestras ideas deben o deberían permanecer más allá de nuestra presencia.

La cultura no es más la forma cómo hacemos las cosas por aquí, es la manera cómo cambiamos las cosas por aquí. Cambiar nosotros y cambiar nuestro entorno para mejorar significa, entre muchas otras cosas, desarraigar, desaprender y aprehender, es decir, olvidar lo antiguo, por obsoleto, por inútil, por falto de valor y entender nuevos modelos de pensamiento holístico, reconocer que la agilidad vive precisamente porque también está presente la posibilidad de su ausencia. Y eso, mis estimados amigos, es lo que nos asusta más.

La carga más pesada es por lo tanto, a la vez, la imagen del más intenso arraigo ágil que puedas encontrar. Cuanto más pesada sea la carga, más a ras de tierra estará nuestra visión, más real y verdadera será, alcanzable, soportable. ¡Es la soportable levedad del ser ágil! El ágil es algo que eres.

A propósito del nombre del libro que originó el título de este artículo, como agilista (en cualquiera de los sabores que he mencionado y en los que no), tu trabajo, tu tarea es crear personas, no recursos (personajes). Si es con pasión, seguramente vas a empatizar tanto con esas personas que al ayudar a transformarlas te vas a preguntar que harás con tu vida más adelante. Ellas no siempre son felices, no siempre saben lo que quieren, no siempre están insatisfechas ni tienen las ideas claras. Es quizás lo mismo que sucede contigo como agente de cambio pero es tu deber, o debería serlo, mostrar los posibles caminos, proponer los experimentos, llevarlas de la mano. 

Quienes finalmente quieren cambiar se esfuerzan por comprender la levedad de lo ágil y lo que parece una distraída intrascendencia de los conceptos de agilidad, entrega de valor y mejoramiento continuo. Primero a través de una ligera presunción de lo que todo esto puede ser, quedándose puramente en lo cosmético y “lindo” de las emociones ágiles, y después acudiendo a la ayuda de un agente de cambio, que es cuando quieren comprobar si es cierto que ser ágil y hacer ágil – o hacer agilidad – son dos cosas distintas.

No puedo terminar este discurso seudofilosófico (mea culpa) sin dejar de acudir directamente al tratamiento que Kundera hace de sus propios personajes en la novela de referencia y hacer un juego de palabras: «los personajes (ágiles) no nacen como los seres humanos, del cuerpo de su madre, sino de una situación, una frase, una metáfora en la que está depositada, como dentro de una nuez, una posibilidad humana fundamental que el autor (agente de cambio) cree que nadie ha descubierto aún o sobre la que nadie ha dicho aún nada esencial».

Durante mucho tiempo seguiremos retornando a lo esencial, a lo escuetamente fundamental, mientras el movimiento ágil que nos convoca no pare de recibir adeptos en sus filas.



viernes, octubre 05, 2018

Disponible el libro "Historias de usuario: Una visión pragmática"

Prólogo
Con historias y contando historias es como las culturas se hacen más fuertes y sobreviven. Las historias generan conexiones entre los emisores y los receptores y hacen que unos y otros se conviertan en un solo grupo, un solo equipo, un solo ser.
Las historias son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas y las historias de usuario, tal y como las conocemos, no son la excepción a esta condición. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.
Las historias de usuario permiten a los equipos virtuosos construir los productos correctos, incluso antes de pensar en hacerlo de la manera correcta (el método o las prácticas). Nos permiten concentrarnos en el valor de los componentes de cada producto y de cómo estos componentes hacen o harán resonancia unos con otros, en vez de involucrarnos directamente desde el inicio del esfuerzo de desarrollo en los detalles del producto o en los intríngulis de la tecnología que usaremos para construirlo.
En el caso particular del desarrollo de software, las historias de usuario son el primer movimiento de esa sinfonía que es el descubrimiento del producto y de sus características. Las historias de usuario nos ayudan a entender la proposición de valor del producto desde sus inicios, nos ayudan a anticiparnos a la gran incógnita que supone si los usuarios efectivamente usarán o no el producto, nos permiten interactuar no solo con los usuarios e interesados internos, sino también con los consumidores finales del mismo.
En este libro hemos recogido algunas de las formas de hacer las cosas cuando de historias de usuario se trata, es una visión, la nuestra, soportada en la experiencia de muchísimos años no solo en proyectos y esfuerzos de desarrollo con pensamiento Ágil y Lean, sino con otros enfoques y métodos que a estas alturas son considerados tradicionalistas.
Hemos acompañado y ayudado a cientos de equipos en docenas de empresas, en Colombia y en otros países. Han sido cientos o miles de iteraciones en conjunto, cientos de personas con las que hemos experimentado continuamente y hemos encontrado algunos escenarios exitosos, otros no tanto; pero hemos crecido en el proceso. Y sobre este aspecto, que nos haya funcionado a nosotros no quiere decir que les funcione a otros; como siempre, el llamado es a experimentar en cada escenario, en cada momento e ir analizando qué funciona y qué no en sus propios espacios y ambientes.
Al hablar de historias de usuario es necesario hablar de eXtreme Programming (XP), el contexto en el que nacieron; pero también es necesario hablar de Scrum, el contexto en el que más se usan hoy día. Sin embargo, en lo posible trataremos de ser agnósticos al marco de trabajo. Hablaremos indistintamente de iteraciones o sprints para referirnos a lo mismo.
Quienes nos conocen saben que llevamos escribiendo varios años sobre este tema que nos apasiona. De hecho, el libro es una recopilación de todos esos artículos en nuestros blogs:
Pero los hemos enriquecido con numerosos ejemplos, les dimos un hilo conductor en el sentido en que creemos es mejor abordar su lectura, aunque nada evita que se haga en direcciones diversas.
Hemos dedicado mucho tiempo y espacio a tratar el tema de lo que significa tener buenas historias de usuario (INVEST) y hemos hecho énfasis repetidamente en que estas son un instrumento de conversación entre los miembros involucrados en el desarrollo de productos, software o no. En la parte final, incluimos el Lienzo para Conversaciones sobre Historias de Usuario, ampliamente detallado y listo para uso, una herramienta, un medio de comunicación, para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. Una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.
Así es que bienvenidos a este libro y así como lo plasmado acá fue exitoso para nosotros, esperamos sea útil para ustedes, dándole aplicabilidad en su contexto.

Pueden encontrar el libro en Amazon:

Formato Kindle:

https://www.amazon.com/dp/B07HLYX68Z

Formato Tapa blanda:

https://www.amazon.com/gp/product/1723933562

Y como siempre, bienvenida cualquier retroalimentación.
Jorge y Lucho

miércoles, julio 18, 2018

Apuntes sobre transformaciones ágiles: las personas, sus miedos y qué hacer al respecto


(Tiempo aproximado de lectura: 7 minutos, 30 segundos)
***********************************************************
Nota:
Esta es la segunda parte de una serie de apuntes sobre transformaciones ágiles. Encuentran la primera parte en:
http://www.gazafatonarioit.com/2018/04/apuntes-sobre-transformaciones-agiles_1.html
***********************************************************

Las personas son lo más importante de una organización y los gerentes deben hacer todo lo que puedan para mantener a las personas activas, creativas y motivadas, o algo así nos dice Jurgen Appelo a propósito de energizar a las personas en sus ya muy conocidas técnicas de Management 3.0. Los agentes de cambio también tenemos esa obligación con las personas: motivarlos, energizarlos, enamorarlos de las nuevas propuestas, de las nuevas formas de hacer las cosas.
Por ejemplo, promover el uso de herramientas simples que se adapten a las personas puede ser una magnífica idea cuando introducimos nuevas formas de trabajar en una organización. Instrumentos cuyo aprendizaje no tome mucho tiempo y cuyo uso sea natural y hasta espontáneo y que no intimide. Los radiadores de información como los tableros de tareas son un buen inicio.
Ahora bien, la revitalización casi nunca viene de arriba (de la alta gerencia). La revitalización comienza en los suburbios de la organización, conducida por líderes de área que crean planes para solucionar problemas concretos. A través del alineamiento de tareas –dirigiendo las responsabilidades de las personas hacia la tarea competitiva central de la empresa– estos líderes enfocan su energía en el trabajo y no en abstracciones como “empoderamiento” o “cultura”.
Revisar el propósito y la visión de la empresa, publicar la declaración de la misión y lanzar programas diseñados para causar un cambio en la organización, no siempre tienen el resultado esperado. ¿Cuál es el papel de la alta gerencia en este proceso? Establecer en qué dirección irá la compañía, sin necesidad de implantar lo que para el resto de la empresa puede verse como soluciones dictatoriales. Después, simplemente tiene que dedicarse a respaldar y divulgar las lecciones aprendidas de las áreas renovadas en toda la compañía.
Por su parte, los equipos son dueños de su propio destino. Los líderes están allí para suministrarles las piezas necesarias y suficientes y las guías apropiadas para el uso de esas piezas: armar el rompecabezas sigue siendo responsabilidad de cada uno de ellos y de sus miembros.
Durante los procesos de transformación te encuentras con dos tipos de personas: las que quieren el proceso para seguirlo, aquellas que no son capaces de hacer nada sin un proceso riguroso, meticuloso, estricto, universal, absoluto, paso a paso, detallado y definitivo. Y las que quieren ese conjunto de reglas rigurosas, estrictas, detalladas, obligatorias, para no seguirlas. En cualquiera de los dos casos, el pensamiento Ágil no les cae bien porque no establece o prescribe ni lo uno ni lo otro.
Algunos enemigos de la innovación son también enemigos del cambio y generan aprensión, estudia y practica cómo lidiar con ellos:
1.  Cultura de culpa
2.  No hay espacios seguros para experimentar
3.  Deseo de complacer a todos
4.  Grandes egos
5.  Dudas
6.  Microgestión del talento
7.  Miedo al fracaso
8.  Demasiado rigor en los procesos
9.  Impaciencia
10.      Abundancia de recursos
11.      HIPPO (Opiniones de las Personas más Altamente Pagadas en la compañía, muchas veces consultores externos que no conocen el ambiente organizacional actual)
12.      Necesidad de KPI medibles inmediatos
En síntesis, lograr una transformación sostenible requiere de compromiso, coordinación y competencia y nada de eso se logra por decreto. Las ordenanzas, por el contrario, producen más temor en las personas y estas se retraen y terminan alejándose del cambio. Algunos de estos consejos te pueden ayudar a lidiar con este fenómeno[1]:
1.  Haz que el compromiso a la transformación se logre mediante el diagnóstico conjunto de problemas. Sé inclusivo, logra la participación de todos en la organización.
2.  Desarrolla una visión compartida de cómo prepararse y organizarse para la competitividad. Las empresas más exitosas actualmente tienen un alto grado de colaboración y de innovación pero no olvidan el mercado.
3.  Promueve el consenso para la nueva visión, la competencia para promulgarla y la cohesión para avanzar. Esto requiere de liderazgo y de apoyo de la alta gerencia. Sin eso estás perdido.
4.  Energiza todas las áreas de la empresa, empezando por las personas que las integran. Eso sí, no presiones ni busques que la alta gerencia presione. Necesitas crear un entorno cooperativo, no uno coercitivo.
5.  Cuando hayas probado el cambio, cuando hayas logrado que la organización deguste lo que viene, institucionaliza la revitalización a través de políticas, sistemas y estructuras formales.
6.  Monitorea el proceso de energización, ajustándolo en respuesta a los problemas que encuentres, a los escenarios actuales. No trates de copiar una receta o un modelo calificado como exitoso en otra organización, el que obtengas el mismo resultado será apenas una feliz coincidencia.
Influenciar el grado de resistencia al cambio es un esfuerzo colectivo. Cada que puedas, une a más personas, a más áreas en la organización y con todos, haz un nuevo esfuerzo para influir en el resto aun no “convencido”, esta vez con más ahínco que antes. Y sin importar a cuántos logres convencer esta vez, prepara de inmediato la siguiente actividad. Esto es constante, hasta que la transformación sea sostenible.
Finalmente, si dejas de preocuparte por el porcentaje de avance, por el número de historias de usuario que vas a recibir, por el tiempo que te va a tomar recibirlas y por quién es el responsable de hacer qué y cuándo, lo que te queda es atender el valor recibido y con qué calidad lo recibes.
Liderar o fomentar el cambio requiere que las personas enfrenten problemas dolorosos y renuncien a los hábitos y creencias que aprecian. ¿Resultado? Algunas de estas personas intentan eliminar el agente visible del cambio: ¡ese eres tú!
No te desanimes por ello. Aprende a manejar tu entorno y tus propias emociones. Por sobre todas las cosas, mantente fiel a tus principios.
Finalmente, muchos no esperan o no están preparados para hacer la inversión necesaria para cambiar. Un jefe seguirá queriendo ser el jefe, no un líder al servicio de nadie (léase Scrum Master). ¡Es la forma cómo los inspires lo que motivará una real y profunda transformación!

Fuentes:
1-  Why Change Programs Don’t Produce Change. By Michael Beer, Russell A. Eisenstat, and Bert Spector.