La columna izquierda en proyectos de transformación

Hace tiempo, en un proyecto, empezó a suceder una de esas cosas tan habituales: uno de los agentes involucrados empezaba a actuar de forma… incoherente. De palabra, todo era compromiso con el proyecto, apoyo a tope, al 100% de acuerdo. Pero la realidad de sus actos no cuadraba con su discurso.

Decir si, pensar no

Algo pasaba. Quizás debíamos abordarlo antes de continuar. Y así lo planteé a los responsables del proyecto. Su respuesta: “no podemos ponernos ahora a cuestionarnos esas cosas. En un Comité ya dijeron que estaban de acuerdo… así que hay que seguir avanzando”.

Por supuesto, seguimos avanzando… para nada. Porque las declaraciones en los comités se las lleva el viento, y lo que quedan son las acciones en el día a día.

La columna izquierda

En el ámbito del coaching se usa una herramienta llamada “la columna izquierda”. Digamos que tomamos una hoja y la dividimos en dos columnas. En la derecha ponemos lo que una persona hace o dice; sus comportamientos observables. Y en la izquierda, ponemos su discurso interno: todas las ideas, creencias, miedos… que a veces de forma consciente y otras de forma inconsciente son el origen de su comportamiento observable.

What I say

El problema, claro, es que mientras la columna derecha se puede observar, la columna izquierda está oculta: solo la conoce la otra persona, y eso en el mejor de los casos. Lo más que podemos hacer es plantear hipótesis e indagar, tratando de descubrir y entender qué hay en ella. Y es que cuanta más luz arrojemos sobre esa columna izquierda, más fácil será dar con la tecla que realmente movilice la acción de la otra persona.

Volviendo al ejemplo del proyecto que planteaba, era evidente que había algo no declarado en la columna izquierda. Algo que hacía que lo que se decía y lo que se hacía no coincidieran. Era necesario indagar en qué era ese algo, entender por qué estaba sucediendo esa incoherencia. Solo desde ahí se podía hacer algo al respecto.

Abriendo el melón de la columna izquierda

El problema es que indagar en la columna izquierda… no es cómodo. Requiere tiempo, trabajo, confianza, mano izquierda. Las cosas que están en la columna izquierda suelen tener un componente emocional. Suelen ser ideas y creencias arraigadas, susceptibles de generar rechazo cuando se verbalizan. Por eso nos cuesta sacarlas, o dejar que otros las vean.

¿Y si nos dicen algo inconveniente? ¿Y si nos obliga a replantearnos las cosas? ¿Y si descubrimos algo que no nos gusta, o algo que no sabemos manejar, incluso algo que directamente pone en riesgo el proyecto? Quita, quita.

Por eso mucha gente no quiere “abrir ese melón”, “reabrir viejos debates”, “remover la mierda” o “abrir la caja de Pandora”. Mejor actuar como si eso no existiese

Caja de Pandora

Pero claro, la cuestión es que sí existe. Enterrar la cabeza como un avestruz no hace que desaparezca. Y tarde o temprano acaba reventando.

Los cimientos de un proyecto de transformación real

Como la parábola de la Biblia, podemos edificar nuestros proyectos con cimientos sólidos, o hacerlo sin cimientos. Aparentemente los proyectos sin cimientos avanzan sin problemas; y de hecho más rápido. Desde un punto de vista superficial, es más que suficiente. Mucha gente se conforma con eso, con proyectos que avanzan en apariencia.

La prueba de fuego vendrá, claro, cuando vengan las tormentas. Entonces, el proyecto sin cimientos caerá como un castillo de naipes. ¿Por qué las cosas no funcionan como se suponían que tenían que funcionar? ¡Si lo hicimos todo bien! ¡Si todo el mundo estaba de acuerdo! ¿Por qué ahora resulta que no hacen lo que deben?. Y ahí tendremos, después de invertir esfuerzo, tiempo, dinero, energía… un proyecto frustrado más.

Casa en roca

Así que si quieres abordar un proyecto de transformación real, con voluntad de impacto y permanencia… hay que dedicar tiempo a los cimientos. A tener conversaciones francas, tanto al inicio del proyecto como durante su desarrollo, que permitan poner tanta luz como sea posible a las columnas izquierdas de todos los implicados. Y a abordar todas las cuestiones que sean necesarias, por difíciles o incómodas que puedan ser, antes de seguir avanzando.

Porque si no lo hacemos, si hacemos “como si nada”… correremos mucho; pero no llegaremos a ningún sitio.

PD.- Como ves, he añadido un episodio del podcast Diarios de un knowmad dedicado a este tema. Si te gusta, puedes suscribirte en iVoox y en iTunes, comentar, recomendar, compartir…

El management y los huevos

Hace no demasiado tiempo comer huevos era algo que había que hacer con prudencia. Que si demasiada proteína para el hígado, que si ojo con el colesterol… Luego no, luego resulta que comer huevos es estupendo y no causa problemas. Salvo que tengas enfermedades coronarias, que entonces bueno, mejor no. Entonces… ¿es bueno o es malo comer huevos? Y más concretamente, ¿cuántos huevos puedo comer a la semana? Pues depende. Porque comer huevos tiene cosas buenas, y tiene cosas malas. Y a lo mejor no depende tanto de los huevos, como de ti.

Me venía esto a la cabeza leyendo la noticia de que IBM, que en su día fue pionera en la política de trabajar de forma remota, está ahora dando un giro y promoviendo (a la fuerza ahorcan) que los equipos trabajen juntos de forma presencial. Hace no mucho leía algo parecido referido a si es bueno trabajar en “open spaces” o si es malo. Y podemos aplicarlo a casi cualquier decisión de gestión. Hay quien dice una cosa, hay quien dice lo contrario. Lo que antes era bueno, ahora resulta que no. Y a lo mejor pasado mañana sí. Entonces… ¿qué hago yo?

Los humanos, y las organizaciones, lidiamos regular con la incertidumbre. Queremos certezas. Queremos que nos digan qué tenemos que hacer para que nos vaya bien. Buscamos las recetas infalibles, los consejos que no fallen, los benchmarks que nos aseguren que por lo menos no estamos haciendo nada distinto de los demás, las metodologías impecables, los gurús del momento que bendigan nuestras iniciativas. Y con toda seguridad que, sea lo que sea lo que nos estemos planteando, encontraremos algún experto que afirme lo que queramos, un “estudio” de alguna “universidad americana” (aunque sea pequeñito y poco significativo y cogido por los pelos, pero estudio científico al fin y al cabo), un libro editado por algún brillante escritor de management, un curso donde nos enseñaran a hacer las cosas “de forma correcta”, una cita de algún autor clásico (¿real o inventada?), una encuesta que diga que es una buena idea (aunque se haya hecho a cuatro amigos), un consultor que te diga que él lo ha hecho con varios clientes y les va de fábula, unos cuantos “casos de éxito” contados a bombo y platillo, varios artículos en las revistas del ramo y una miríada de contenidos en redes sociales (refritos de refritos) que apoyen esa idea…

Bueno, qué alivio. Ahí tenemos nuestras certezas. Ya podemos gestionar, ¿verdad? Lo malo es que esas “certezas” no son tales, por mucho que queramos darles la apariencia de que lo son, y sirven solo para apaciguar nuestra inquietud. De hecho, casi con toda seguridad, podríamos encontrar un buen número de “certezas” similares que apoyasen la tesis contraria. Porque la realidad es que cualquier curso de acción que emprendamos tendrá sus cosas buenas, y sus cosas malas; y no hay forma de saber a priori cuál de las dos pesará más. Porque encima, en un mundo complejo, las interrelaciones son tantas que lo que puede ser bueno para mí puede no serlo para ti, y viceversa. O lo que funciona hoy puede que no funcione mañana. Pero eso, a quien te vendió la certeza, le va a dar igual; ellos no van a estar ahí cuando apliques sus recetas y no funcionen.

Pero entonces… ¿qué hacemos? ¿Cómo vamos a tomar decisiones, sin tener ninguna certeza? ¡Qué angustia! Y sin embargo creo que, una vez aceptamos esa incertidumbre, nos encontramos ante un panorama liberador. Como no hay un “camino correcto”, no tenemos la presión de elegir “bien”. Podemos apostar por cualquier curso de acción, y ver qué pasa. Con prudencia, sí, por si hay que dar marcha atrás. Atentos a los resultados que vamos obteniendo, para corregir el rumbo a medida que avanzamos. Con humildad, conscientes de que podemos equivocarnos, pero también aprovechando las cosas que sí funcionan. No tenemos que ser perfectos, porque de hecho es imposible que lo seamos.

¿Es un curso lo que necesitas?

Hace poco comentaba con un conocido una posible colaboración. Estaban pensando montar un “curso de ventas” para un colectivo bastante grande, y me preguntaban que cómo lo veía yo. Respondí de la forma más honesta que fui capaz, aun sabiendo que mis probabilidades de éxito eran pocas.

Estas son las reflexiones textuales que les trasladé:


  • Para mí el enfoque es más de “cambio de cultura” que de “dar un curso”. Puede (o no) que un curso sea necesario, pero seguro seguro que no es suficiente.
  • Para poder plantear soluciones hay que ir a la raíz del problema. ¿Se ha investigado dónde está el origen del “no vender”? ¿Se ha trabajado con el colectivo, con sus responsables, incluso con los clientes…? ¿O directamente se ha hecho una presunción? “No venden porque no saben; si les damos un curso, venderán”.
  • Parte de la implantación de “soluciones útiles” pasa por la co-creación: es decir, trabajar con los colectivos afectados (el propio colectivo, en este caso; quizás clientes, y responsables, etc) y que sean ellos los que propongan cosas para hacer. Quizás propongan un curso. Pero quizás propongan otras muchas cosas que desde un despacho ni se nos ocurren, porque no estamos en su día a día. Y al ser “sus ideas”, la probabilidad de que funcionen se incrementa…
  • Creo que importa mucho el enfoque experimental en la implantación de ideas: pensar una serie de medidas, probarlas de forma rápida y barata con pilotos… y la que funcione se potencia, y la que no funcione se abandona. Si se buscan enfoques masivos/definitivos (“un curso para todo el colectivo”) es más difícil acertar.
  • Del mismo modo, creo que el cambio funciona mejor si se empieza pequeño y luego se crece. Coger a los 20, 50 o 100 individuos más motivados para la venta, y empezar a trabajar con ellos, ver lo que funciona y lo que no. Y cuando esos individuos, y esas áreas, empiecen a obtener resultados… se va generando un efecto bola de nieve que permite ir incorporando a nuevos “fieles”. Usar un “curso masivo” con un colectivo que no tiene interés es tirar el dinero: sí, les has llevado a un aula, puedes justificar que “les has formado”… pero no es real.
  • Hay que pensar de forma sistémica. Queremos que las personas vendan… ¿es la “habilidad para la venta” un rasgo que tengamos en cuenta a la hora de seleccionar? ¿cómo estamos incentivando las ventas? ¿qué información les damos sobre la evolución de sus ventas? ¿Cuál es la actitud de los responsables hacia la venta? Etc.
  • Los esfuerzos de cambio cultural solo tienen sentido si se sostienen en el tiempo, si hay consistencia. Si hoy damos un curso, y mañana pasamos a otra cosa… es tirar el dinero.

En fin, como ves son varias cosas pero todas en la misma línea: si hay interés real en cambiar las cosas, hay mucha tela que cortar. Alguien que se dedique a “vender cursos” no lo va a plantear así (le interesa “colocar” el curso, cobrar… y aquí paz y después gloria)… pero honestamente es como yo lo veo. Si crees que podemos profundizar en todo esto de cara a transformarlo en un proyecto ya sabes dónde me tienes.


Tal y como suponía desde el primer momento, mi enfoque no “cuajó”; y lo cierto es que no sé si acabaron encontrando ese “curso de ventas” que buscaban. Lo que sí me atrevo a pronosticar es que, si lo hicieron, el impacto será, en el mejor de los casos, pequeño y efímero.

La verdad es que por un lado me sentí bien exponiendo mi visión, sin cortapisas. Un poquito de “design thinking”, un poquito de “agilidad”, un poquito de “gestión del cambio”… “Mira, esto es lo que creo, y en esto creo que te puedo ayudar; si no consigo convencerte y no vamos a estar en la misma onda, mejor que busques a otro”. Por otro, claro, siempre te queda la duda… ¿fui demasiado “asertivo”? ¿podría haber modulado mi discurso para “pillar cacho”? ¿hubiera merecido la pena?

Trece ideas de Scrum que puedes aplicar en tu gestión

Scrum por allí, Scrum por allá… llevo oyendo hablar de Scrum mucho tiempo ya, “una metodología de desarrollo de software”, “tiene que ver con el mundo de agile”, “cosas de techies”. En definitiva, oyendo campanas pero sin haber dedicado nunca tiempo a profundizar lo suficiente.

Bueno, ahora ya sé de dónde vienen las campanas :) He puesto foco durante unas horas a entender mejor que es eso de Scrum (gracias a este curso online, y a leer la guía oficial de Scrum), y cómo funciona. Efectivamente, Scrum es una metodología de desarrollo de producto (normalmente vinculado al mundo del software) que se enmarca dentro de la filosofía Agile. Diría (y aquí si algún experto me tiene que corregir que lo haga) que es una forma (¿la que más éxito ha tenido?) de “aterrizar” la filosofía del manifiesto ágil en algo más concreto y funcional.

Ahora bien, es evidente que Scrum tiene su origen y su “caldo de cultivo” en el mundo del desarrollo del software, y se ve claramente que muchas de las cosa que plantea es ahí donde tienen todo el sentido del mundo, y donde los expertos lo explotan mayoritariamente. Lo que me iba cuestionando a medida que leía era: ¿es aplicable Scrum a otros ámbitos, a la gestión de proyectos menos técnicos? Algo me dice que sí, que la dinámica de trabajo puede ser extrapolada (con más o menos “ajustes”).

Fruto de esa reflexión, y más allá de que se pueda aplicar la metodología de forma más o menos estricta, he extraído estas trece ideas de Scrum que se pueden aplicar a la gestión de cualquier proyecto:

  • Ten siempre el valor aportado al cliente como vara de medir: En Scrum, los elementos del product backlog se priorizan en función del valor que van a aportar al cliente. Lo que más valor aporte, se busca hacer cuanto antes mejor. El objetivo que persigue el “producto incremental” siempre es buscar aportar el mayor valor posible, cuanto más tangible mejor. La definición de requerimientos, el feedback en las revisiones… siempre está orientado a lo mismo. Esta “obsesión por el valor” es algo que no debe perderse de vista nunca en el desarrollo de un proyecto. ¿Cuántas veces, en el fragor de la batalla, nos miramos demasiado el ombligo y nos olvidamos de para qué estamos trabajando, nos enredamos en discusiones bizantinas que no llevan a ningún sitio, o nos emocionamos con detalles que apenas le aportan a nadie? Pues eso, no perdamos la brújula de la aportación de valor.
  • Organiza tus proyectos como sucesión de miniproyectos cerrados: se definen los “sprints” como periodos de una a cuatro semanas de trabajo sobre una serie de elementos del backlog (elementos que se definen al principio del sprint y que no se tocan) que, al finalizar, dan como resultado una “versión funcional del producto”. Este enfoque elimina la incertidumbre, los cambios de prioridades, el pasarse la vida replanteándose cosas… y permite al equipo centrarse en “producir” sin interferencias del exterior durante el sprint. Nos centramos en lo que hemos definido para el sprint, nos aislamos del exterior (la relación con el exterior es cosa del product owner) y sacamos el producto que nos habíamos propuesto sacar. Lo que haya que cambiar, lo que haya que corregir, las nuevas prioridades… ya se abordarán en el siguiente sprint (que, como llegará pronto, en ningún caso nos va a suponer un gran problema).
  • Entrega producto valioso desde el primer momento: además de funcionar como una sucesión de “miniproyectos”, en los sprints el objetivo es que al terminarlo haya un resultado final. Con cada “miniproyecto” el resultado será mejor y mejor (iteraciones), pero desde el primer momento se busca resolución y no hay que esperar a que transcurran n meses para tener algo tangible o darse cuenta de que, oh, no has ido por el buen camino. De hecho, idealmente, podrías abandonar el proyecto al terminar cualquier “sprint” y el resultado sería valioso por sí mismo. De esta forma, todo el trabajo que haces tiene sentido y aporta valor por sí mismo.
  • Feedback, feedback y más feedback: igual que en el caso del design thinking, el objetivo es que tras cada “sprint” se produzca una revisión que permita validar que efectivamente el resultado incremental aumenta el valor, ver lo que funciona y lo que no, y a partir de ahí tomar decisiones para la siguiente ronda. Este ciclo permanente de “producto funcional” y “feedback” permite ir avanzando y adaptándose de forma continua. No olvidemos exponernos al veredicto de los usuarios, no tengamos miedo a recibir sus opiniones: es lo único que nos sirve para mantener el rumbo.
  • Las prioridades las define uno y nadie más: el product owner es la figura encargada de interactuar con los “usuarios/clientes” (stakeholders en general), de identificar sus necesidades, de llegar a compromisos con ellos respecto a sus prioridades… y una vez filtrado todo ello, de trasladarselo al equipo de forma unívoca. Es el único que lo hace, la bisagra que une y a la vez aísla a los stakeholders y al equipo, el único interlocutor válido. Esta figura recupera el principio clásico de la “unicidad de mando”, y evita que haya más gente “metiendo la cuchara” y mareando al equipo, cambiando prioridades y tratando de arrimar el ascua a su sardina.
  • Protege al equipo: el equipo debe centrarse en trabajar, y aislarse en la medida de lo posible de interferencias e incertidumbres. Esto es labor del product owner, que centraliza las relaciones del equipo con los stakeholders (evitando que éstos vuelvan loco al equipo) y cerrando el alcance de los sprints en las reuniones de planificación (proporcionando un escenario de estabilidad al equipo, mientras él absorbe nuevos requisitos, cambios en prioridades, etc… que retendrá hasta llegar al siguiente sprint).
  • Comunicación multidireccional constante: Scrum define en la metodología todas las ocasiones en las que se producen interacciones entre los miembros del equipo. Reuniones de planificación, reuniones de refinamiento, reuniones diarias, reuniones de revisión, retrospectivas. En todos los casos el objetivo es “poner encima de la mesa” las distintas visiones que se puedan tener (sobre dificultades, enfoques, cómo se va a trabajar) y llegar a acuerdos. Coordinación sobre la base de la comunicación permanente.
  • Deja que los que saben se organicen: el product owner es el que define las prioridades, pero a partir de ahí es el equipo de desarrollo el que determina cómo abordar esas prioridades, qué tareas realizar, cómo repartírselas, cómo coordinar sus distintas habilidades. Son los que mejor saben hacer las cosas, y no tiene sentido que venga nadie de fuera a organizarles el trabajo. La autonomía es una clave de la motivación, y la motivación es una de las claves de un trabajo bien hecho.
  • Los equipos necesitan estar equilibrados: el equipo Scrum debe reunir, entre todos sus miembros, todas las capacidades necesarias para resolver las tareas que tiene asignadas. Es decir, no debe depender de nadie externo para avanzar. De esta forma, está 100% en las manos del equipo ejecutar lo que decidan, y no se deben quedar parados esperando a que alguien les resuelva nada. Esta visión suele ser difícil de organizar en los proyectos (y más si pensamos en proyectos transversales, con gente “de distintos departamentos” con “distintos directores”), pero resulta fundamental si queremos que las cosas salgan adelante de forma ágil.
  • Presta atención a cómo trabajas, y corrige si es necesario: las reuniones de retrospectiva se centran, al finalizar cada “sprint”, en analizar el funcionamiento del propio equipo, de identificar qué cosas han ido bien y qué cosas tienen que ir mejor. Este foco tendemos a olvidarlo y más si va a ser fuente de conflictos; para darnos palmaditas todos valemos, pero exponer problemas a la cara de forma constructiva y aceptar nuestras equivocaciones ya nos resulta más difícil. Y sin embargo es fundamental si no queremos que los problemas se enquisten.
  • Respeta los procesos y las herramientas, aunque parezca aburrido : siguiendo con la idea de la autoconciencia, la figura del Scrum Master se encarga de asegurar que el proceso se siga “a rajatabla”, que se celebren las reuniones que se tienen que celebrar y se hagan de la forma adecuada. En los proyectos todo son buenas intenciones, pero es fácil dejarnos llevar por las urgencias, por la rutina, por el “esto ya nos lo sabemos” y el “bueno, esto me lo salto que tampoco pasa nada” y a la que nos descuidamos hemos descarrilado por completo, hemos dejado de aplicar las rutinas y los hábitos que nos habíamos prometido seguir y acabamos en el batiburrillo habitual.
  • No te olvides, trabajas con personas: otra de las labores del Scrum Master es “prestar atención a las personas”. Es decir, vigilar las dinámicas interpersonales dentro del equipo, e intervenir cuando sea necesario para reconducirlo. Esta labor pone de manifiesto algo que ya he comentado en alguna ocasión: somos personas trabajando con personas, es absurdo pretender que nos relacionemos como si fuesen máquinas. Hay filias, hay fobias, hay roces, hay momentos altos y momentos bajos… y tener a una persona cuya responsabilidad es precisamente estar atento a todo eso implica reconocer esa realidad.
  • Cuanta más información tenga el equipo, mejores decisiones podrá tomar: todo el proceso de Scrum se basa en la idea de que todo es compartido por todos. Todos ven el product backlog, todos definen el sprint backlog, todos ven el seguimiento diario, todos hacen las reuniones de revisión y de retrospectiva, todos dan su opinión respecto a cómo ejecutar el trabajo… No hay carpetas privadas, no hay “ángulos ciegos”, todo el mundo tiene toda la información necesaria para hacer su trabajo. Y así, normalmente, las cosas salen mejor.

 

Castillos de arena

Verano, “sol, arena y mar” que decía Luis Miguel. Confieso que la playa tiene para mí un efecto hipnótico. Será por aquello de ser de la Meseta, y ser contados los días que puedo disfrutar de ella. O por coincidir esos días en periodos de vacaciones, dados de por sí a la introspección.

Y allí estábamos, rodillas en la arena y palas en mano, excavando y amontonando, dando forma a unos castillos en la arena. Creatividad y trabajo compartido con los niños (benditos niños, que nos dan excusa para hacer determinadas cosas sin temor al “qué dirán”).

Terminamos el castillo. Los castillos, en realidad. Muy aparentes, un trabajo muy satisfactorio. Nos sentamos en la cercana toalla. Y niños ajenos que empiezan a revolotear; algunos para mirar con curiosidad e incluso admiración, pero otros con mirada aviesa. Joder, ¿por qué hay gente que es destructiva casi desde la cuna?. “Tchs, eh, ni se te ocurra”. El niño mira desafiante, pero recula. Bien, hemos salvado el castillo.

De momento. Porque no vamos a estar sentados en esta toalla para siempre. Más pronto que tarde llegará un niño (o un adulto, que los hay muy tontos también) y pisoteará nuestro trabajo, reduciéndolo a un montón de arena. Y en el mejor de los casos será cuestión de horas que suba la marea y las olas lo devuelvan a su estado original.

Mientras recogíamos y volvíamos al apartamento, me dio por pensar en todos los castillos que he construido a lo largo de todos estos años. Los de arena, y los otros; los proyectos, las herramientas, las webs, los documentos. En todos los “niños” que los amenazaban con mirada aviesa, sólo refrenados por mi presencia. ¿Cuánto tardaron en pisotearlos? En el mejor de los casos… ¿cuánto tardó la marea en subir y hacerlos desaparecer?

Puede parecer un pensamiento desolador, y en cierto sentido puede llegar a serlo. Pero quizás lo relevante de ese castillo no radique en su (imposible) permanencia, si no el disfrute que nos proporcionó mientras lo ideábamos y lo construíamos. Lo cual, también, puede ser una lección interesante de cara a abordar futuros castillos.