Buscar en Gazafatonario IT

domingo, abril 01, 2018

Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio

4 estacions cicles arbre, por Espai Satvas

(Tiempo aproximado de lectura: 7 minutos, 15 segundos)
“Uno de los principales problemas con las Transformaciones Ágiles es que nosotros, las personas que hacemos estas transformaciones, no estamos realmente cambiando nuestros valores, nuestros corazones. Queremos practicar la Agilidad sin cambiar nosotros mismos. Eso nos impide hacer y liderar la Agilidad”. (Junio 7 de 2017)
Mike Beedle. En su honor…

El marco de trabajo Scrum y mucho menos el pensamiento Ágil o la Agilidad se venden en cajas o se prescriben como recetas en clínicas de coaching.
De allá venimos, de las propuestas de marcos metodológicos “mágicos” que, según sus promotores, funcionaban en cualquier lugar del universo, aun en una galaxia muy muy lejana, sin importar los escenarios locales, la idiosincrasia, la cultura organizacional o las personas involucradas.
Hoy por hoy las áreas de TI y las organizaciones en general saben que necesitan un cambio en su forma de trabajo y han escuchado poco o mucho del enfoque Ágil, este se ha vuelto un objeto del deseo, uno oscuro, pero no están dispuestas a generar el entorno que se requiere para cambiar. ¡Quieren empezar a jugar Rugby pero con las reglas del Fútbol!
El pensamiento Ágil es como un caleidoscopio para las personas, los equipos y las organizaciones del tercer milenio. Debido a la enorme cantidad de factores y al cambio continuado de contexto, dadas la volatilidad y la incertidumbre inherentes a las empresas actuales, una leve vibración del caleidoscopio genera una forma muy diferente a la anterior.
En cualquier caso, una imagen (modelo) apropiada para una organización puede no ser la correcta para otra, aun entre áreas de la misma empresa la estrategia y las tácticas pueden llegar a ser muy distintas. Cuánta agilidad necesita cada quien es una cuestión muy subjetiva que debe abordarse a nivel local.
La agilidad es la capacidad de evolución de las personas y de las compañías. Aquellas y estas deben estar conscientes de que, al igual que la evolución, el viaje de Agilidad no tiene un destino final, es un desplazamiento continuo, un éxodo perenne si así lo queremos ver.
Lo advertía hace siglos Nicolás Maquiavelo: nada más difícil de emprender ni más peligroso de conducir que tomar la iniciativa en la introducción de un nuevo orden de cosas, porque la innovación tropieza con la hostilidad de todos aquellos a quienes les sonrió la situación anterior y solo encuentra tibios defensores en quienes esperan beneficios de la nueva.
Es muy difícil que una persona cambie sus hábitos y mucho más complejo puede resultar si quiere cambiar su forma de pensar. Ni hablar entonces de lo caótico que puede resultar hacer esto para todo un equipo, por pequeño que este sea, y más aún para una organización entera.

Además, nuestro cerebro es muy bueno esgrimiendo argumentos de por qué no salir de su zona cómoda. El “siempre lo hemos hecho así” y otras razones corporativas para no cambiar.
Las organizaciones del siglo XXI quieren mejorar pero no quieren cambiar. Se mantienen en un estado de inmovilidad colmado de voluntades de cambio fingidas. A lo largo de mis años como agente de cambio me he encontrado con entidades cuyo propósito de renovación es simplemente un disfraz con el que ocultan su ánimo de permanecer estáticas en el tiempo. Lo que no saben estas compañías es que de no cambiar se exponen a su desaparición o al trágico rezago del que difícilmente podrán volver.
Para ninguno de nosotros es desconocido que la visión de la mayoría de las empresas es obsoleta en este siglo que apenas comienza. Las evidencias abundan: Blackberry, Xerox, Kodak, Nokia y Blockbuster, solo para mencionar algunas cercanas a nuestro sector. En general, el 88% de las compañías Fortune 500 de 1955 habían desaparecido de la lista o de la faz de la Tierra en 2014 (ver referencia). Lo que no están dispuestas a hacer estas corporaciones o no quieren hacer o simplemente no saben cómo, es cambiar su forma actual de trabajar, sus procesos y procedimientos. Por ejemplo, quieren medir el progreso de los cambios como miden sus proyectos tradicionales.
En general, este tipo de empresas no está interesado en sacrificar su “modus vivendi”. Las personas que pone a conducir la iniciativa de cambio no están allí exclusivamente para ello. Lo que ocurre casi siempre es que les asignan trabajo adicional al que ya realizan. Son personas que inician su nueva labor desmotivadas y cansadas, muchas veces sin entender del todo lo que está por suceder.
Lo que sí sabemos los agentes de cambio es que al iniciar una transformación no podemos ir contra ese “statu quo” de manera frontal o “guerrerista” como anuncian algunos, tratando de cambiar todo de una buena vez. Esto es así porque en un entorno complejo, altamente volátil y vulnerable, incierto y ambiguo, como el que rodea a las empresas hoy, no sabremos qué acciones conducirán al resultado deseado.
Primero tenemos que conocer la cultura organizacional, hacernos a una percepción de las personas, los escenarios, los equipos, su forma de trabajo vigente y una vez adentro iniciar la transformación de manera natural u orgánica, en pequeños pasos, sin violentar las estructuras o procedimientos actuales pero con paso firme y con determinación.
Curva de adopción/innovación de Rogers
Esta será útil para dispersar aquellas conductas que, inevitablemente, seguirán exhibiéndose hostiles incluso cuando el cambio se encuentre en un estado avanzado, esos comportamientos de los grupos de la mayoría tardía y de los rezagados identificados por nuestro amigo Everett Rogers en su muy referenciada curva de adopción/innovación.
Otra cosa que ocurre es que nuestras organizaciones están sobrecargadas de gestión y de gerentes en todos los niveles y siguen sin desarrollar su capacidad de ejercitar el liderazgo de sus miembros. Recordemos que los líderes de hoy son todas las personas que puedan transformar su contexto o generar nuevos y mejores espacios para los demás y cuya confianza, eficiencia y alcance combinados sirvan de base para la cultura de la organización.
Y bueno, mientras preparo más apuntes, cuéntanos amigo lector, sobre tus vicisitudes y rendimientos durante el proceso de cambio en el que estás comprometido. Puedes dejar tus propios apuntes en el foro, más abajo.
Coletilla de los apuntes:
Cada quien debe encontrar su significado de Valor y de Temprano y de Frecuente, para aquello de “entrega temprana y frecuente de valor”.
Lucho Salazar, Ciudad de los Reyes, marzo 30 de 2018
Referencias
http://www.aei.org/publication/fortune-500-firms-in-1955-vs-2014-89-are-gone-and-were-all-better-off-because-of-that-dynamic-creative-destruction/
*************************************************************
Parte 2 de los apuntes:
La segunda parte de esta serie de apuntes está en:
http://www.gazafatonarioit.com/2018/07/apuntes-sobre-transformaciones-agiles.html

Puedes descargar la presentación complementaria del siguiente enlace:

jueves, febrero 01, 2018

Diferencias en el tratamiento de los requisitos entre los enfoques Cascada y Ágil


¡Una pregunta de un viejo amigo me llevó una vez más por este sendero!
Es un hecho. Muchos profesionales trabajan actualmente en circunstancias desafortunadas y, sin embargo, no toman la iniciativa de cambiar su situación porque están condicionados a un formato de seguridad, conformidad y conservación, donde todo puede parecer tranquilo pero, en realidad, nada es más perjudicial para el espíritu innovador y de transformación que requerimos hoy quienes vivimos en los tiempos del VUCA*.
En particular, durante la transición de un enfoque en cascada a uno Ágil tenemos que lidiar con la búsqueda de medios y maneras para acortar el tiempo de salida al mercado y entregar productos de alta calidad y de más valor, más temprano y más frecuente y, si es posible, a un costo menor. Sin embargo, el camino hacia la Agilidad puede ser escabroso, con baches riesgosos y con personas deambulando por allí erráticamente y hasta en dirección opuesta, incluso con temor a o sin saber cómo avanzar.
Y uno de los aspectos que empiezan a diferenciar en profundidad el uso de uno u otro enfoque es este de los requisitos. Abordamos este asunto con Carlos Gil, Johnny Ordoñez, Carlos Quiroga, Luis Mulato y el grandioso equipo de coaches del Scrum Coaching Retreat Cartagena y, como siempre, llegamos a algunas conclusiones que se mueven en el terreno de los principios y, más en el fondo, de los valores Ágiles, la cultura ágil, el Ágil es algo que eres:

  • En Ágil no hablamos de requisitos, más bien de respuestas a necesidades y, en otros casos, de hipótesis de cosas que queremos aprender. Cambiar el enfoque de “requisito” a “necesidad” o respuesta a necesidad, genera un sentido profundo de empatía entre todos los interesados, es decir, equipo de desarrollo de producto y usuarios o clientes finales.
  • A propósito de clientes finales, en Ágil, el cliente siempre es el centro de atención. Esto habilita a los equipos a buscar las mejores formas de suplir esa necesidad o de comprobar las hipótesis. Estas en últimas son necesidades de aprendizaje.
  • Creemos que esta es la distinción más grande entre las dos propuestas: el requisito te lleva a algo preestablecido, definitivo o definible claramente. Hablar de necesidades o de hipótesis abre la puerta al cambio.
  • En el enfoque Cascada se definen experiencias orientadas al proceso, con momentos de interacción preconcebidos por los formularios y procesos definidos en los requisitos, y aun hablamos de interacciones y no de conversaciones con las soluciones tecnológicas. En Ágil, aspectos como la experiencia de usuario, momentos de verdad, conversaciones, son esenciales para la definición de la historia de usuario que guía el desarrollo de producto.
Vamos con las disparidades entre uno y otro enfoque cuando de requisitos se trata
Son muchas las diferencias que existen en la forma de abordar los requisitos de un producto cuando usamos (o usábamos) la forma Cascada y lo que hacemos ahora, motivados por el pensamiento Ágil. Estas que describo a continuación son apenas algunas de ellas, algunas más relevantes que otras pero significativas todas al fin y al cabo.
Al principio del proyecto o del esfuerzo de desarrollo

En Cascada se toman o "levantan" (casi) la totalidad de los requisitos al principio del proyecto, y de muchos de ellos se hace con gran detalle. En Ágil no. Se establece un alcance, sí, una visión, pero de muy alto nivel, muy horizontal, es decir, no se llega a ningún detalle excepto quizás para esas necesidades de los dos primeros Sprints (a lo sumo), la porción de producto que se va a construir durante las primeras de cambio. El llamado Mínimo (o Minimísimo) Producto Viable.
En Cascada nos tardamos semanas y hasta meses haciendo esta primera actividad. En Ágil nos tardamos unas pocas horas, a lo sumo unos pocos días, se establece un bloque de tiempo (time-box) y cuando este se acaba, se acaba.
En Cascada participa una persona del lado del equipo de desarrollo o un "subequipo", el o los analistas funcionales o de requisitos. Quizás en algún momento entra uno que otro rol, como el Arquitecto de Software. En cualquier caso, no participa todo el equipo. En Ágil participa todo el equipo de desarrollo desde el inicio, escuchando a los usuarios e interesados en el producto.
Más adelante, cuando el proyecto está en marcha
En Cascada se refinan los requisitos, hay ajustes, controles de cambios. El sobrevaluado CCC (léase Comité de Control de Cambios) que se reúne el último jueves de cada mes, mientras el cliente ve impaciente cómo su competencia se adelanta y le quita parte del mercado. Mientras tanto, en Ágil se van refinando los requisitos iteración tras iteración. Siempre nos concentramos en lo que se va a construir en los siguientes 2 sprints o iteraciones, a lo sumo. Más tiempo no, porque las cosas pueden cambiar. Los equipos Ágiles aprovechamos los cambios para brindar ventaja competitiva a nuestros clientes.
En Cascada los requisitos siempre los "administra" una persona o un subequipo (analistas), con los usuarios. En Ágil hay un Dueño de Producto (representante de los usuarios), pero la responsabilidad es de todo el equipo.
En Cascada los requisitos se construyen, como sabemos, siguiendo un proceso secuencial donde ellos se tratan aparte y son una entrada al resto de ese proceso; además, el producto se entrega como un todo. En Ágil se construye un incremento del producto en cada iteración (de muy pocos días), esto es, producto probado y funcionando con valor, potencialmente desplegable y que genera retorno de la inversión (ROI) o, al menos, permite recibir retroalimentación, con lo que podemos aprender muchísimo del comportamiento y de la reacción de los usuarios al uso del producto.
En Cascada normalmente el orden de construcción lo decide el equipo de desarrollo (quizás en cabeza de un arquitecto o un subequipo). En Ágil el orden de construcción lo decide el usuario (dueño de producto), es él quien tiene la última palabra sobre esto.
En Cascada, el énfasis en cuanto a requisitos está en la especificación (documentación) de los mismos, en otras palabras, en escribir y escribir requisitos. En Ágil, el énfasis está en la conversación que tienen los usuarios o su representante (dueño de producto) con el equipo de desarrollo. Esta conversación es cara a cara y continua, durante todo el proyecto o esfuerzo de desarrollo.
Esta última característica es lo que nos empieza a volver ágiles, cuando lo logramos nos damos cuenta que estamos usando el pensamiento Ágil y estamos dejando atrás la cascada y otras formas tradicionales de trabajo.
En Cascada se espera que prácticas de aseguramiento de calidad permitan que se entregue un producto que cumpla con casos de prueba previamente definidos y aprobados con el área de negocio. En Ágil damos espacios a prácticas como TDD y BDD para guiar la definición de los criterios de aceptación, identificando de manera temprana la respuesta real que espera el usuario final, la prueba es guiada por la retroalimentación continua, lo cual mejora el uso y por lo tanto la aceptación del usuario.
Y sobre medios o herramientas para “recolectar” y administrar requisitos
Una diferencia en cuanto a los medios o mecanismos para "recolectar" requisitos:
En Cascada se usan medios como los documentos escritos tradicionales llenos de expresiones tipo "el sistema debe hacer esto" o "el sistema debe hacer aquello", o se usan mecanismos como casos de uso, entre otros. En cualquier caso, como mencioné antes, la fuerza está en elaborar grandes cantidades de documentación de requisitos. Escribí mucho sobre esto aquí en el Gazafatonario durante la década pasada y publiqué un libro al respecto. Lo pueden encontrar en Amazon.
En Ágil, por su parte, usamos medios o mecanismos que promuevan la conversación entre los interesados (usuarios y equipo de desarrollo). Las Historias de Usuario se han constituido en el medio esencial para esto. Pueden encontrar una especie de índice de mis artículos y propuestas y las de mi gran amigo Jorge Abad sobre este tema en bit.ly/lashistoriasdelucho.
Ahora sí, cuéntame en el foro de otras diferencias a la hora de recolectar y administrar requisitos o necesidades que consideres importantes.



*VUCA: siglas en inglés de Vulnerabilidad, Incertidumbre, Complejidad, Ambigüedad

miércoles, enero 17, 2018

Revisión a la Guía de Nexus 2018


Ken Schwaber y Scrum.org anunciaron hoy (enero 17 de 2018) que fue publicada una actualización a Nexus, el marco de trabajo para escalar Scrum. Acorde con los recientes cambios a su marco de trabajo subyacente, los cambios a Nexus aumentan la claridad, enfatizan la criticidad de “Terminado” a Escala y extienden el alcance mundial de Nexus, se anunció hoy en un comunicado oficial.
Las actualizaciones fueron determinadas en parte a través de los comentarios de la comunidad de Scrum a través del sitio web Scrum Guide User Voice, la comunidad de Scrum.org y sus entrenadores profesionales de Scrum (PST). Un énfasis en aumentar las aclaraciones sobre el Equipo de Integración de Nexus y el propósito de su rol, afirmando la importancia de la transparencia a escala para la integración y definiendo qué significa "Terminado" a Escala, son algunos de los principales cambios que los practicantes de Scrum encontrarán en la versión actualizada de la Guía Nexus.
Estos son los cambios más significativos:
1.    Actualizada la descripción de la Guía Nexus de “El exoesqueleto de desarrollo a escala con Scrum” a “La guía definitiva para escalar Scrum con Nexus: las Reglas del Juego”.
2.    Nexus se define ahora como “una relación o conexión entre personas o cosas”.
3.    En el Flujo del Proceso Nexus, la terminología se cambió para hacer foco en los equipos en vez de en los miembros individuales, “Un Nexus consiste de múltiples equipos Scrum multifuncionales que trabajan en conjunto para entregar al menos un Incremento Integrado potencialmente distribuible en cada Sprint”.  También se agregó que basados en las dependencias, los equipos se autoorganizan y seleccionan los miembros más apropiados para hacer un trabajo específico.
4.    Claridad alrededor del rol del Equipo de Integración Nexus:
a.    El Equipo de Integración Nexus está conformado a menudo de miembros de los Equipos Scrum individuales del Nexus. Esta composición soporta la necesidad de inteligencia hacia arriba de los Equipos Scrum individuales en el Nexus.
b.    El Equipo de Integración Nexus no es el encargado de hacer la integración. Los Equipos Scrum individuales realizan el trabajo de integración.
c.    Se eliminó la definición de que el Equipo de Integración Nexus es un Equipo Scrum puesto que esto ha causado confusión, permitiendo creer que sus miembros son un Equipo Scrum separado permanentemente de los demás en el Nexus.
5.    El Refinamiento se movió en los Eventos Nexus hasta la parte superior. Ahora aparece antes que la Planificación del Sprint Nexus.
a.    El Refinamiento ya no está prescrito como un evento de dos partes. La terminología se enfoca en la transparencia en vez de en la visualización.
b.    Se eliminó la referencia al Refinamiento como “reuniones”, en vez de eso solo “Refinamiento”.
c.    Se enfatiza en el Refinamiento como una actividad continua a lo largo del Sprint mientras sea necesario y apropiado.
6.    La Meta Nexus ya no se especifica como una entrada o salida de la Planificación del Sprint Nexus puesto que esto puede variar, en cambio se define como una meta que el Dueño de Producto discute durante la Planificación del Sprint Nexus. Se eliminó terminología sobre la necesidad de estar en el mismo espacio físico.
a.    La Meta Nexus es ahora la Meta del Sprint Nexus y ya no se encuentra en la lista de nuevos artefactos, para ser consistente con el Marco de Trabajo Scrum.
b.    Se eliminó de la Tabla de Contenido.
7.    El Scrum Diario Nexus es una oportunidad para que los equipos busquen impactos entre equipos así como dependencias entre ellos.
a.    El Scrum Diario Nexus no es la única vez que la Lista de Pendientes del Sprint Nexus debería ajustarse. Es al menos uno de los momentos en los cuales los equipos se juntan para ajustar la Lista de Pendientes del Sprint Nexus para reflejar su entendimiento del trabajo y las dependencias entre equipos.
b.    El Scrum Diario Nexus es el momento en el que los Equipos de Desarrollo en el Nexus inspeccionan el progreso hacia la Meta del Sprint Nexus.
8.    La Revisión del Sprint Nexus no es para mostrar algo a la audiencia y contarle sobre eso, como no lo es en Scrum – se agregó terminología que la clarifica como una oportunidad de adaptar La Lista de Elementos del Producto si es necesario. También se menciona la necesidad de retroalimentación en la descripción de la Revisión del Sprint Nexus en el “Flujo del Proceso Nexus” en la página 5.
9.    Se agregó que la Retrospectiva del Sprint Nexus es una oportunidad formal para que el Nexus se inspeccione y adapte y cree un plan de mejoramiento que se ejecute a partir del próximo Sprint.
a.    Similar a la actualización de la Guía de Scrum, la Retrospectiva del Sprint Nexus existe para asegurar el mejoramiento continuo para el Nexus.
10. El Incremento Integrado representa el estado actual del trabajo integrado.
11. La Definición de “Terminado” especifica que el Incremento Integrado debe estar integrado.
12. En “Transparencia de los Artefactos” se eliminó la definición “la prueba de deuda técnica inaceptable es cuando la integración ocurre y sigue sin estar claro que todas las dependencias están resueltas”. Se reemplazó con “El software debe ser desarrollado de tal forma que las dependencias sean detectadas y resueltas antes de que la deuda técnica sea inaceptable para el Nexus”.
13. Se eliminó el párrafo sobre las prácticas de software. Aunque importante y relevante, el tema requiere de mayor elaboración para que agregue valor.
14. Se adicionó la cláusula de Creative Commons, lo que permitirá a los equipos y organizaciones, a nivel mundial, reutilizar el contenido de la guía y ampliar su alcance.
Como siempre, con mis grandes amigos Jorge Abad (@jorge_abad) y LeonardoAgudelo (@sweepnoise), hicimos la traducción de los cambios y mejoramos también algunos aspectos de la terminología en español.
La guía actualizada puede descargarse ya en español (2018) desde el sitio Web:  https://www.scrum.org/resources/nexus-guide.
Para conocer más de Nexus, pueden leer mi artículo:
En el que también podrán ver y descargar una presentación al respecto.

¿Cómo les ha ido con el uso de Nexus? ¿Tienes alguna pregunta adicional al respecto? Por favor, déjanoslo saber en el foro.

jueves, noviembre 30, 2017

La Conversación Cara a Cara en Tiempos de la Comunicación Digital

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara”.
Manifiesto por el Desarrollo Ágil de Software (www.agilemanifesto.org)

En lo elemental, somos esencialmente seres “sociales”, en el sentido de que pasamos la mayor parte de nuestras vidas con otras personas. Así es que antes de ejercer cualquier otro rol que haya llegado a nuestra conciencia por acción de una profesión o título o experiencia, no debemos olvidar que somos individuos participantes de una comunidad y que debemos aprender a entendernos con los demás y a operar debidamente en el contexto social.
¡O así era hasta hace unos años!
La potenciación de la Internet con su poder de comunicación a escala masiva cambió el rumbo de la historia y, quizás, de la evolución. Sí, es cierto que estamos más conectados que nunca unos con otros, que hoy por hoy somos capaces de saber al instante lo que ocurre a miles de kilómetros de distancia de nuestra ubicación, contado en la voz de los protagonistas de la acción. Pero entre colegas y amigos, en medio de la familia y de nuestros amantes, miramos y tocamos más a nuestros dispositivos móviles que a nosotros mismos.
Admitámoslo sin tapujos: en la actualidad preferimos enviar un mensaje de texto, aun de voz, que comprometernos a una reunión cara a cara o, incluso, a una (video) llamada telefónica. Nos hemos rendido en el desarrollo de nuestras habilidades de socialización, de conversación (cara a cara) en pro de mayor “contacto social” vía artilugios de la era moderna digital. ¿Estamos perdiendo parte de nuestra humanización, de lo que nos hace o nos hacía humanos y nos diferenciaba del resto de especies del planeta?  La historia nos dará la respuesta, aunque el salto cuántico que estamos dando no nos dejará en la incertidumbre por mucho tiempo.
¿Qué podemos hacer para contrarrestar el embate de la tecnología en nuestras vidas?
Volvamos a lo básico. La conversación cara a cara es lo más humano -y humanizante- que hacemos. Es la forma como los seres humanos desarrollamos nuestra capacidad de empatía. Conversando, contando historias es como sobreviven las culturas. Todo ello tiene un componente importante cuya raíz se encuentra en lo puramente social, en la comunicación con muchas otras personas de nuestro entorno y, en ocasiones, de fuera de este. Por ello es que poseer algunas destrezas en la comunicación favorece enormemente el mejoramiento de la calidad de nuestro trabajo e incrementa nuestra creatividad y productividad a todo nivel. Incluso, todavía, mejora nuestras relaciones con las demás personas.
Así es que conversa con personas, incluso con aquellas con quienes no estás de acuerdo. La conversación (cara a cara) se inhibe tanto por nuestros prejuicios como por nuestras distracciones. Por sobre muchas cosas, no evites las conversaciones difíciles. Motívalas. Solo porque estas conversaciones sean difíciles cara a cara, no significa que sean imposibles. Entre uno y otro encuentro cara a cara con otra persona, con tu colega en el trabajo, con tu amigo de toda la vida, con alguien de tu familia y hasta con el amor de tu vida, aprenderás algo nuevo y estarás contribuyendo a la supervivencia de la especie, de la especie humana.
Crea espacios “sagrados” para la conversación cara a cara: busca o diseña tu entorno para protegerte a ti y a tus interlocutores contra las interrupciones innecesarias. Es cierto, a veces parece más simple inventar una nueva tecnología que iniciar una conversación cara a cara pero no por ello vas a dejar de intentarlo. Rodéate de seres “sin tecnología”, de esos para quienes todavía es relevante mantener fija la mirada mientras les hablas, desinhíbite con ellos, aprende de ellos, convive con ellos. En el trabajo, ¿qué tal si cambiamos los “viernes casuales” por “jueves conversacionales”? ¡Jueves o cualquier otro día siempre viene bien para ello!
Una nota especial para Scrum Masters, coaches Ágiles y miembros de equipos
La mayoría de los Scrum Masters, coaches, desarrolladores y, en general, miembros de equipos organizacionales que conozco tienen conversaciones difíciles pendientes, ellos saben que deben tenerlas pero las están evitando, las están posponiendo irremediablemente. Eso no ayuda en el proceso transformacional de las personas y de los equipos y mucho menos de las organizaciones. En este caso, los Scrum Masters, como líderes orgánicos que deben ser, por lo general se muestran reacios ante este deber natural de conversar porque no les gusta la confrontación o sienten un temor intrínseco a vulnerar los sentimientos de la persona o las personas con quienes necesitan conversar. Para ser un líder extraordinario, los Scrum Masters deben equilibrar el cuidado y la sinceridad con la que conversan y tocan ciertos temas, pero están en la obligación de hacerlo tarde o temprano, ojalá más temprano que tarde, esto profundizará y fortalecerá la relación, la interacción entre los individuos, pilar fundamental del pensamiento Ágil.
¡Las conversaciones deben ser genuinas!
En su libro The 5 Levels of Leadership (Los 5 niveles de liderazgo), Jhon C. Maxwell nos recomienda que antes de tener una conversación sincera, es mejor asegurarnos de poder responder a las siguientes preguntas:
  • ¿He invertido lo suficiente en la relación para ser sincero con ellos?
  • ¿Realmente los valoro como personas?
  • ¿Estoy seguro de que este es su problema y no el mío?
  • ¿Estoy seguro de que no estoy hablando porque me siento amenazado?
  • ¿Es el problema más importante que la relación?
  • ¿Esta conversación sirve claramente a sus intereses y no solo a los míos?
  • ¿Estoy dispuesto a invertir tiempo y energía para ayudarlos a cambiar?
  • ¿Estoy dispuesto a mostrarles cómo hacer algo, no solo decir lo que está mal?
  • ¿Estoy dispuesto y soy capaz de establecer expectativas claras y específicas?
Si respondemos a todas estas preguntas, seguramente nuestros motivos son los correctos y tendremos una alta probabilidad de comunicarnos efectivamente.
Finalmente, quiero dejarlos con una idea que aprendí de mi padre, generoso intelectual, “come libros”, empírico por naturaleza, librepensador y de quien heredé este deseo innato de comunicarme en todas las maneras posibles: una frase errática, una expresión salida desde las entrañas del pensamiento humano dice más acerca de algo que cualquier estudio deliberado sobre el mismo tema. ¡Visceral!