Trabajar Hacia Atrás Para Avanzar (Con Jeff Gothelf De Gothelf.co)

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts usando un programa de software. Por favor disculpa cualquier error tipográfico, ya que el bot no es 100% preciso todo el tiempo.

Ben Aston:

Para ser honesto. ¿Tus proyectos realmente entregan lo que esperabas que harían? ¿Lo que podrían o deberían? Ahora, ¿por qué es eso? ¿Es porque quizás no planeaste? Bueno, porque no gestionaste bien a tu equipo. O tal vez porque luchaste por gestionar y alinear a tus interesados. Quizás sea todo lo anterior. Quizás es porque no estaban todos completamente alineados en el resultado final y la visión de los proyectos. Así que sigue escuchando el podcast de hoy. Si quieres aprender cómo puedes trabajar hacia atrás para avanzar con más confianza con buenos proyectos, reducir el riesgo de fracaso e incrementar tus chances de éxito en proyectos.

Gracias por sintonizar. Soy Ben Aston, fundador de The Digital Project Manager. Bienvenido al podcast de DPM. Estamos en una misión para ayudar a los gestores de proyectos a tener éxito, para ayudar a las personas que gestionan proyectos a entregar mejor. Estamos aquí para ayudarte a llevar tus proyectos al siguiente nivel.

Visita thedigitalprojectmanager.com para aprender sobre nuestra formación y recursos que ofrecemos a través de la membresía. Este podcast es traído a ti por Clarizen, el líder en software de gestión de proyectos y portafolios empresariales. Visita Clarizen.com para saber más.

Hoy me acompaña Jeff Gothelf y Jeff enseña a ejecutivos y equipos a través de asesoramiento remoto, talleres de coaching, ponencias y libros a centrarse en los clientes, aprender de los errores y crear una cultura ágil que mejore continuamente sus productos y servicios y la forma en la que trabajan.

Es coautor de varios libros que has leído o al menos probablemente has escuchado, "Sense and Respond", Lean UX siendo el más famoso. Lean versus agile vs. design thinking. Recientemente cofundó Sense and Respond Press, una editorial de libros modernos de transformación empresarial. Así que, hola Jeff, muchas gracias por acompañarnos hoy.

Jeff Gothelf:

Hola, Ben, gracias por invitarme al programa.

Ben Aston:

Y quiero comenzar hablando de proyectos, sé que eres una persona muy orientada a productos, pero para nosotros los PM que gestionamos proyectos, eso puede ser parte de un programa más grande de trabajo o de la hoja de ruta de un producto.

Y tengo curiosidad, ¿cómo piensas que es? Como nosotros como líderes de proyectos, podemos orientar a nosotros mismos y a nuestros equipos hacia un enfoque más iterativo. Y sé que acabas de escribir un post sobre las 10 mayores objeciones a Agile y por qué no funcionará aquí. Así que quiero hablar sobre algunos de los desafíos a los que creo que nos enfrentamos como gestores de proyectos digitales y por qué.

Fundamentalmente, creo que los clientes con los que trabajamos, todos los stakeholders, les gusta la idea de trabajar agile. Podemos discutir sobre lo que significa agile, pero ya sea que hablemos de un marco de entrega o más ampliamente de una mentalidad. Y creo que vamos a centrarnos más en esa mentalidad para el enfoque ágil.

Pero creo que hay un desafío que necesito mencionar, de hecho tres desafíos. Primero, quiero hablar sobre la desconfianza del cliente, luego sobre requisitos demasiado definidos, y en tercer lugar el desafío del déficit de presupuesto y tiempo. Así que clientes deseando ser ágiles, pero realmente sin tener el presupuesto o el tiempo para hacerlo.

Clientes con requisitos demasiado definidos y también desconfianza del cliente. Así que los clientes realmente no confían en la agencia o el equipo para soltar el control y solamente confiar en el proceso. Así que esos son tres desafíos. ¿Sobre cuál quieres hablar primero?

Jeff Gothelf:

¿Qué tal si hablamos primero del cambio de mentalidad? Porque creo que es el punto más crítico, especialmente para los gestores de proyectos digitales que realmente deben comprenderlo. Creo que si vamos a tener éxito creando buenos equipos, productos, servicios, empresas, clientes y usuarios exitosos, es importante notar la diferencia fundamental en el desarrollo de productos digitales hoy en día.

La principal diferencia hoy en día respecto de hace 10 o 15 años es que el software hoy en día es continuo. Ya no vamos a la tienda a comprar una caja de software. Ahora, simplemente nos suscribimos o lo instalamos y luego lo descargamos y se actualiza constantemente.

Así es. Sigue mejorando. Ya no vas a la tienda a comprar la siguiente versión de Facebook. No vas a la tienda por la siguiente versión de Pinterest o Amazon o lo que sea. Simplemente mejora continuamente o cambia con el tiempo. Esa es la diferencia fundamental entre pensar en proyectos y pensar en productos. Los proyectos y productos no son lo mismo.

Y hoy realmente estamos construyendo estos sistemas, estos sistemas continuos donde tenemos una decisión en cada ciclo. Puedes llamarlo sprint, iteración, como quieras. Pero tenemos una decisión sobre cómo mejorar ese sistema: ¿Le agregamos cosas? ¿Optimizamos lo que ya tiene? ¿Quitamos cosas? Así es.

Hay muchas cosas que pueden hacerse, pero a grandes rasgos son esas tres categorías. Y ese es el punto clave a retener, porque estas cosas no terminan. Esta idea de gestionar el proyecto hasta el lanzamiento exitoso... Está bien, pero el lanzamiento es solo el comienzo de la conversación con tu audiencia objetivo. No es el final del producto.

Ben Aston:

Definitivamente, sí. Una de las cosas a las que creo que nos enfrentamos como gestores de proyectos digitales cuando intentamos hablar con los clientes para involucrarlos en una forma de trabajo más ágil donde les decimos: "oye, solo páganos por un equipo dedicado durante un periodo de tiempo y colaboremos juntos". Digamos que hemos lanzado tu... Hemos lanzado tu web. Y ahora vamos a iterar sobre ella.

Es como hablas del software y su actualización continua. Tal vez su página web haga lo mismo. Pero depende de la confianza, ¿verdad? Que la persona que paga va a recibir buen valor al final del proceso. ¿Cómo crees que nosotros como gestores de proyectos, como personas que guiamos a nuestros clientes por este proceso, podemos guiarles a superar esa desconfianza cuando los entregables son desconocidos?

Jeff Gothelf:

Sí. Hay mucho por analizar aquí. Así que empecemos con la pieza fundamental, la base. La base aquí es, ¿en qué negocio estás? De verdad tienes que hacerte esa pregunta pensarla desde el punto de vista del proveedor de servicios o del cliente.

¿Estás en el negocio de asociarte con tus clientes para ayudarlos a lograr resultados, o estás en el negocio de entregar una lista estricta de requisitos? Porque, como dijiste, hay un desacuerdo fundamental entre "aquí están los requisitos, pero por favor sé ágil con ellos".

Eso no tiene sentido. Esa afirmación no tiene sentido. Hay un espectro que aprendí de mi amigo y colega Jeff Patton que ayuda mucho a aclarar el pensamiento sobre esa cuestión. En un extremo está la palabra "doctor". Y en el otro extremo está la palabra "mesero".

Y les desafío, como organización de prestación de servicios, a pensar en dónde se ubican en ese espectro. Si están en el lado del mesero, su trabajo es traerme exactamente lo que pedí.

Ben Aston:

Claro.

Jeff Gothelf:

Y si te lo comes o no, o si te gusta o no, no es mi problema. Pediste un filete con ensalada y una Coca-Cola. Eso es lo que te traigo. Así es. Hay muchas organizaciones que hacen eso. Dame 100 mil. Te construyo el arca. Pero en el otro extremo está el doctor.

Un doctor. No le dices al doctor, "quiero este medicamento, esta vacuna y este tratamiento", y el doctor dice, "ok, te lo doy". El doctor trabaja como consultor para ayudarte a mejorar, al final para mejorar tus indicadores, tus métricas. Así que la cuestión es, ¿dónde te ubicas en ese espectro? Es mucho más fácil ser ágil en el extremo del doctor que en el del mesero porque las medidas de éxito son fundamentalmente diferentes. En el extremo del mesero, la medida de éxito es el resultado: ¿entregaste lo que pedí a tiempo y dentro del presupuesto? Sí. Te traje el filete, la ensalada y la Coca en 15 minutos, y el precio es lo esperado, ¿verdad? Esa es una medida de éxito. No hay agilidad en eso. En el otro extremo están los resultados: cambios en el comportamiento de tus clientes, cambios en las mediciones de esos comportamientos.

¿Vendimos más? ¿Gastaron más? ¿Pasan más tiempo? ¿Le contaron a sus amigos? ¿Compraron más de un producto? Ese tipo de cosas. Es ahí cuando la agilidad brilla, cuando hay incertidumbre y no está claro qué logrará el resultado de negocio. Y ahí es cuando operar como doctor es mucho más valioso, y la agilidad solo puede jugar un rol real si empiezas a moverte del lado mesero hacia el lado doctor del espectro.

Ben Aston:

Eso, para mí, implica hacer esa transición para que el cliente o interesado se vea como... se trata de control y confianza. Así que cuando asesoras organizaciones, ¿cómo animas a la gente a mirar más allá o tener apetito por lo desconocido y más allá de los requisitos, sabiendo que existe un objetivo de negocio para el proyecto o la iteración de producto?

Y a menudo podemos saltar a la fruta más fácil de alcanzar, y eso se convierte en el proyecto o la siguiente cosa en la iteración. ¿Pero cómo ayudas a las personas a entender el valor de una mentalidad más ágil y cómo ayudarles a que tengan apetito por ese tipo de enfoque consultivo más de doctor que de mesero?

Jeff Gothelf:

La forma de hacerlo es encontrar una manera respetuosa y no limitante de hacer la pregunta del "por qué". Así que cuando alguien te dice: "necesito estas diez funciones para el viernes, ¿cuánto costará?", debes poder preguntar respetuosamente, "¿por qué quieres esas funciones?"

Y lo haces ayudando a tus clientes a transformar esos requisitos fijos en un enunciado de problema. El enunciado del problema que la organización o el equipo intenta resolver. Si el equipo dice, "necesito la app móvil para el viernes, ¿cuánto costará?" tú preguntas, "¿por qué necesitas la app móvil?" Y responden, "pues nuestras ventas móviles han bajado y necesitamos aumentarlas". Ok. Así que el problema que estamos tratando de resolver es aumentar las ventas móviles. ¿Cuánto? Un aumento del 15% sería significativo. Ok, genial.

¿Ves lo que hicimos ahí? Transformamos "haz una app móvil" en "aumenta el comercio móvil un 15%". Y lo que has hecho es quitar el requisito específico de la conversación, así que ahora el equipo explícitamente tiene que ser ágil en probar, experimentar, aprender, iterar y mejorar su solución hasta lograr ese aumento del 15%. Esa es la medida de éxito, no desplegar la app. Hay un gran riesgo en asumir que tu conjunto de funciones logrará los resultados que crees; la mayoría de las veces te equivocarás sin importar qué tan bueno seas.

De hecho, si hablas con los expertos en producto, te dirán que un buen gestor de producto acertará el 30% de las veces. Eso es un buen gestor de producto.

Y eso aplica para stakeholders, clientes, como los quieras llamar. Así que si vas a equivocarte el 70% de las veces, ¿no preferirías usar un proceso que permita descubrir la mejor manera de lograr tus objetivos lo más rápido posible, en vez de decir a ciegas, "hazme una app azul que haga estas cinco cosas" antes del jueves?

Esa es la diferencia clave aquí.

Ben Aston:

Sí. Creo que eso es muy sabio, y pensar en replantear la solicitud del cliente en esos enunciados de problema y profundizar en el por qué es vital para cambiar la conversación de una lista de requisitos a algo que permite explorar el problema e identificar soluciones. Así podemos probarlas, aprender y luego iterar, y eso nos ayuda a tratar con esos requisitos tan definidos, que era el segundo asunto que mencioné. Solo quiero tocar el tercer desafío. De nuevo, en tu post sobre Agile, mencionas "es genial pero aquí no funcionará", ¿crees que la falta de presupuesto y tiempo puede ser un motivo por el que Agile no funcione aquí?

Jeff Gothelf:

Para mí, hay un malentendido fundamental sobre lo que aporta Agile. No es cuestión de presupuesto o tiempo. Es cuestión de mitigación de riesgos. Se trata de decir: en vez de trabajar tres meses en lo que alguien cree que es el éxito, vamos a empezar a aprender si vamos por el camino correcto lo antes posible. Y si no, ajustaremos el rumbo. Eso es todo. Si el equipo ajusta el rumbo según la evidencia del mercado, ese equipo está siendo ágil. Y eso no tiene nada que ver con presupuesto o tiempo, porque la alternativa es: "costará setenta y cinco mil dólares hacer la app en un mes, ¿vale?".

¿Es una buena estimación? ¿Es mala? Nadie lo sabe. Harás lo mejor posible en ese tiempo y el presupuesto se agota. ¿Y si no funciona? Ese es el riesgo al trabajar con una gestión "cascada" predictiva y prescriptiva desde arriba: asumes que ya sabes qué debe ser, cómo debe verse y lo que debe hacer, y lo necesitas para tal fecha. Es un punto de vista tremendamente arriesgado. Y como dije, un buen stakeholder/cliente/jefe de producto lo acertará una de cada tres veces.

Ben Aston:

Sí. Pero eso depende de quién esté haciendo la solicitud, ¿no? Volviendo a tu ejemplo del filete, ensalada y Coca en 15 minutos, pongamos que tengo treinta dólares. Quiero filete, Coca y ensalada.

Aunque no sea lo mejor para mí, es lo que quiero porque así lo he pedido. Y puede que no sea lo correcto, pero solo busco a alguien que me dé filete, ensalada y Coca.

Jeff Gothelf:

Exacto. Y en esa situación vas a un mesero, ¿verdad? Si vas a tu doctor, y el doctor mide tus indicadores—índice de masa corporal, peso, presión, colesterol—y le dices, "quiero filete, ensalada y Coca", el doctor responderá: "no". No te lo va a dar, porque su trabajo no es darte eso, su trabajo es hacerte más saludable.

Eso es el resultado que persiguen. Al mesero no le importa tu salud. El mesero te da lo que pides porque ese es su trabajo y es el rubro en el que está. Y creo que la mayoría de los proveedores de servicios no comprenden que Agile no es solo un proceso, sino un modelo de negocio distinto. Y es muy difícil para los proveedores tradicionales comprenderlo y hacer la conversión.

Ben Aston:

Sí, y exige madurez de parte de quien hace el trabajo para adaptarse, ¿no?

Jeff Gothelf:

Exacto. Exacto.

Ben Aston:

Así que realmente se trata de la madurez necesaria. Y para quienes trabajamos en agencias y con clientes que solo quieren filete, ensalada y Coca para el jueves que viene y entonces serán felices, es un gran reto para nosotros.

Creo que hay que reformular la solicitud y ponerse el sombrero de doctor en vez del uniforme de mesero. Es un buen reto. Jeff ha escrito un gran post sobre centralidad en el cliente y cómo planificar proyectos con esta técnica de nota de prensa del futuro, que toma la técnica "trabajar hacia atrás" de Amazon y se enfoca, como hemos hablado, en los resultados.

Se trata de gestión de riesgos, se trata de colaboración. No voy a spoilear la historia del post, pero puedes verla en thedigitalprojectmanager.com. Pero tengo curiosidad, en tu experiencia, ¿crees que este enfoque ayuda? Porque hay muchas técnicas posibles y parece una actividad divertida. Pero en tu experiencia real, usando esta técnica, ¿qué ha ocurrido en términos del proceso para escribir esa nota de prensa futura y cómo ayuda?

Jeff Gothelf:

Lo primero es que realmente ayuda a imaginar un futuro en el que has tenido éxito y te obliga a pensar qué fue lo que te hizo exitoso. Ahora, la variación que está en el artículo en la web pone al cliente en el centro, no solo "lanzamos este sistema nuevo, todos lo amaron y ganamos mucho dinero", sino "lo lanzamos y esto es el cambio de comportamiento que hemos visto, estos son los resultados, y para llegar allí no solo tuvimos que considerar el éxito en términos del cliente sino también pensar cómo íbamos a dar ese valor a ese cliente a lo largo de la organización".

¿Cuáles fueron los desafíos de colaboración que tuvimos que resolver? ¿Y cómo ayudó eso al negocio? Lo clave es que esto obliga al equipo—aunque es una especie de premortem— a decir: cuando finalmente lancemos esto y tenga éxito en el mercado, ¿cómo sabremos que fue exitoso? ¿Y qué creemos que hemos tenido que superar para lograrlo?

Es una conversación que raramente se da al inicio de una iniciativa. Normalmente dices: ok, construye esto, éxito es entregarlo a tiempo y en presupuesto. En este caso, estamos diciendo que el éxito es tener un proceso que nos permita impactar positivamente a los clientes, hacerlos más exitosos y por tanto al negocio. Si tienes esa conversación al principio, te obliga a pensar durante la iniciativa usando esa nota de prensa futura como filtro: ¿esto ayuda a conseguir ese objetivo? Si no, o no concuerda con los valores o ideales del documento, no lo hacemos, buscamos otra cosa. Eso es muy poderoso.

Ben Aston:

Para los que no han leído el post, estamos imaginando el futuro, el estado futuro, y mirando en nuestra bola de cristal. De cierta forma, estamos pensando en el encaje producto-mercado. ¿Hay gente que realmente necesita esta solución? ¿Es viable? ¿Funciona el modelo de negocio? ¿Es factible? ¿Podemos hacerlo? Así que miramos el encaje producto-mercado. Es un buen lente para riesgos, supongo, ¿lo hará, cumplirá? Usamos empatía para mirar adelante y decidir: ¿cumplirá con lo que buscamos?

Pero tengo curiosidad, porque usamos nuestra imaginación, ¿se puede realmente validar? Porque decías que un jefe de producto solo acierta el 30% de las veces. ¿Qué ocurre con ese 70%? ¿Cómo influye esa niebla de guerra en lo útil o certero que es esto como herramienta?

Jeff Gothelf:

Esto nos da una meta, es aspiracional, es el objetivo como equipo. Intentas predecir el futuro, así que te vas a equivocar con partes de él. Pero en conjunto intentas predecir qué es el éxito, cuáles son los obstáculos y cómo los superaste. Intentas contar una historia convincente sobre eso.

Luego tienes que mantener esa historia según avanzas durante la iniciativa. Habrá elementos que inevitablemente no se cumplirán, y eso está bien siempre que claramente puedas explicar por qué esa parte no se cumplirá y la historia cambiará. Pero esta es nuestra meta, es nuestra aspiración para cómo trabajará el equipo y qué éxito logrará.

Y filtramos nuestras decisiones a través de eso hasta que la realidad del mercado nos muestra que, al filtrar por estos criterios, los resultados han sido subóptimos. Así que cambiamos ese aspecto.

Ben Aston:

Cambiamos el enfoque. Aprendimos que esa parte de nuestra meta aspiracional ya no es válida ni valiosa, así que la ajustamos y seguimos. Pero comienza siendo esa meta y aspiración. Por eso puedes ajustar a medida que avanzas: no es mover la meta, es ajustarla según la realidad que antes desconocías.

Sí. Ok. Y al pensar en cambiar la meta para alinearse mejor, usando este enfoque, ¿hay algo que no funcione bien? ¿Puede esto entorpecer la creatividad del equipo? ¿Has visto problemas o desafíos usando esto?

Sé que mencionaste que es una iteración de la técnica original de Amazon. ¿Quieres explicar por qué la iteraste y los posibles desafíos?

Jeff Gothelf:

Sí, mira, el mayor desafío que he visto es que los equipos no son suficientemente creativos ni aspiracionales con este ejercicio. Hacen un documento muy seguro. Hay un término americano para esto: 'sandbagging'. Es poner una meta que sabes que vas a alcanzar. Y para mí, este es el mayor riesgo aquí: no anticipar los grandes problemas, no establecer criterios de éxito suficientemente ambiciosos. Esa es la principal dificultad. Amazon lo ha usado con éxito según muchos artículos. Yo modifiqué dos cosas: el modelo original no se enfocaba en los resultados medibles del cliente, sólo en beneficios de negocio. Lo que queremos es ver comportamientos en los clientes que indiquen que entregamos valor. El template original hablaba de ingresos, pero no de qué cambio de comportamiento queremos ver si esto resulta exitoso.

La segunda mejora, que es importante para una organización grande, es que el template carecía de discusión sobre los desafíos de colaboración. Nada llega al mercado sólo con el equipo de producto trabajando en ello. Hay que pasar por legal, finanzas, marketing, operaciones, cumplimiento, etc. ¿Cómo vamos a colaborar transversalmente en la organización para crear la experiencia y sumar a esos departamentos? Eso es clave, especialmente en empresas de más de 40-50 personas. Eso también faltaba y quiero que los equipos lo piensen, porque nadie va a lanzar esto solo. Por eso deben involucrar a esa gente mucho antes si quieren lograr la meta aspiracional. Eso es lo que espero lograr con esto.

Ben Aston:

Creo que esto es muy potente. No solo es pensar en los resultados, sino en el proceso. Muchas veces identificamos buenas metas, buenos indicadores de éxito, visualizamos el resultado buscado, pero el proceso necesario para hacerlo realidad suele fallar por la comunicación y colaboración. Así que consulten el post de Jeff sobre trabajar hacia atrás para avanzar. Seguro que obtendrás consejos útiles.

Pero quiero cambiar de tema y adentrarme en el proceso, por el que sé eres apasionado. Has trabajado en consultoría, startups y agencias, ahora trabajas por tu cuenta. Esto te expone, seguro, a cosas que funcionan bien y otras que no tanto.

Me pregunto cómo has visto y ves la evolución de los procesos y métodos para entregar proyectos. Obviamente la evolución de Agile, aunque en el fondo es lo mismo, también tenemos lean, agile, design thinking, service design, técnicas con distintas etiquetas.

¿Cómo ves la evolución del proceso, la maduración de Agile, y estas técnicas y marcos de ideación y entrega? ¿Qué ves para el futuro?

Jeff Gothelf:

Creo que inevitablemente, en algún momento, la agilidad—con “a” minúscula—será la norma en las organizaciones del mundo. Y te digo honestamente, la pandemia que estamos viviendo lo acelerará. Las organizaciones que ya son ágiles o están camino a serlo, que incrementan su capacidad de detectar y responder, sobrevivirán.

Las que no pueden hacerlo, o no está en su ADN, acabarán sufriendo mucho o desaparecerán. La agilidad debe ser la norma de aquí en adelante pues la velocidad del cambio y la volatilidad del mercado y del mundo es cada vez mayor. Así que si eres un monolito, te hundirás como uno. Si funcionas como equipos semi-autónomos que detectan, responden, aprenden y comparten, pueden corregir el curso ante crisis como esta y sobrevivir.

¿Creo que en 20 años seguiremos hablando de sprints, velocidad, gráficos de quemado y backlogs? Puede que sí, puede que no. El lenguaje cambiará, las etiquetas de los procesos cambiarán, pero no imagino un mundo próspero, una economía con éxito, donde la centralidad en el cliente, el aprendizaje y la mejora continua no sean la forma natural de gestionar una organización.

Esas son las filosofías que subyacen agile y, más específicamente, la agilidad. Así que así veo el futuro y sospecho que esto se acelerará aún más por la crisis que vivimos.

Ben Aston:

Sí. Volviendo a esos marcos y sus nombres. Obviamente te apasiona Lean, lo has documentado mucho. Y desde entonces ha habido técnicas muy específicas sobre design thinking, service design, algunas bastante prescriptivas en cuanto a técnicas a usar.

Tenemos distintas personas defendiendo diferentes marcos de entrega. ¿Tú, como practicante, crees que necesitamos todos esos marcos? ¿Cuál es tu opinión sobre cómo interactúan? Hay distintos tipos de proyectos, difícil generalizar, pero ¿filosóficamente, qué opinas sobre agile vs design thinking?

Jeff Gothelf:

Sí. Escribí un libro breve titulado "Lean versus Agile versus Design Thinking". La tesis central es que son marcas distintas sobre filosofías muy similares. Los nombres son diferentes, las actividades se llaman distinto, los ritmos cambian un poco, pero filosóficamente son lo mismo. Si puedes conciliarlo en tu organización, debes elegir uno o mezclarlos para crear algo propio. Al final, la meta no es seguir una receta al pie de la letra, es aumentar la agilidad de tu empresa. Así que la receta elegida no importa tanto.

Tu objetivo es aprender a ser chef. Otra metáfora. En la cocina, si eres principiante, ¿qué harás? Buscarás una receta, la descargarás de internet y seguirás las instrucciones paso a paso. Eso es lo primero que espero de equipos y empresas: dame Lean, Scrum, Design Thinking, XP, lo que sea, y ejecútalo. Después de un tiempo te vuelves bueno siguiendo la receta y la mejoras, agregas ingredientes no originales que la hacen más sabrosa o, en este caso, hacen a tu equipo más exitoso.

Eso está genial, ahora adaptas la receta a lo que te sirve. Finalmente, te vuelves chef profesional. Los chefs no usan recetas; saben operar en cualquier entorno. Ese es el nivel de madurez más alto: cuando un equipo sabe ser ágil en cualquier ambiente, usando metodologías y herramientas variadas. Pero no importa cuál sea la receta, entienden el objetivo y saben cómo usar las herramientas para lograrlo. Esa es la meta.

Pienso que las organizaciones que se casan con una receta específica se condenan al fracaso, porque solo piden “sigue los pasos ciegamente y ya”, y la verdadera meta empieza con la agilidad, no con implementar la receta. El destino es la agilidad.

Ben Aston:

Sí, totalmente. Por eso, cuando se oye el típico "pero esto no es como se debe hacer", salta la alarma, porque la idea es que el proceso se puede iterar y no es cuestión de seguirlo ciegamente. Cuando se empieza ese debate de si hay que hacerlo exactamente como dice la guía o si podemos adaptar reglas, ahí está lo efectivo para lograr resultados. Eso es lo que deberíamos preguntar, no mirar el libro y decir: "aquí dice miércoles, no jueves".

Seguir el proceso ciegamente puede ser un reto real.

Ahora, sé que escribiste el libro "Sense and Respond" sobre organizaciones que escuchan al cliente, crean nuevos productos, algo que ha estado presente en la charla de hoy. Y hablas de técnicas. ¿Hay técnicas que no hayamos mencionado que ves que las organizaciones exitosas están adoptando en este mundo COVID? ¿Qué técnicas ves que tendrán impacto mientras avanzan?

Jeff Gothelf:

Para mí, el área que las organizaciones dejan para el final y es de lo más importante es la estructura de incentivos y los criterios de evaluación de desempeño. Aquí es donde se juega todo, porque puedes aplicar todas las recetas y filosofías, pero si al final me pagan por entregar una función, yo entregaré esa función. Y te da igual si es agile, lean, design thinking, waterfall... porque me pagas por entregar esa función. Y eso es clave.

La clave está en cómo medimos el éxito del personal, y cómo cambiamos lo que medimos para fomentar el comportamiento que queremos, la curiosidad, el aprendizaje, la mejora continua, todo lo que resulta en productos y servicios exitosos. ¿Cómo incentivamos eso? Si no lo incentivamos, no ocurrirá.

Y si no ocurre, toda esa agilidad se va por la ventana. Lo que hacen las empresas que lo entienden es eso. Es difícil y arriesgado, pero vale la pena porque acabas con mejores productos y servicios, clientes más felices y empleados más exitosos.

Ben Aston:

¿Hablas específicamente de OKRs o de algo más amplio?

Jeff Gothelf:

Hablo de vincular tus incentivos a los OKRs o métricas. Si los OKRs se convierten en el criterio de éxito del equipo, parte de la revisión de desempeño y de los incentivos— "¿cumpliste los OKRs? Si sí, así es como te pagamos por eso".

Ben Aston:

Sí, vi hace poco que en vez de descripciones de puestos, se usan scorecards, lo cual puede ser útil para medir hasta el nivel individual y motivarles a entender métricas clave para lograr el cambio.

Sin embargo, escoger esas métricas a veces es difícil. Muchas veces creamos un OKR y luego, al conseguirlo, nos damos cuenta que era la métrica equivocada. Porque se crea trabajo o energía para entregar algo que luego no resulta lo correcto. Pero creo que este enfoque en resultados, en obtener resultados mediante enfoque láser es muy útil. Quiero acabar hablando de tu curso de scrum, hemos hablado de distintos marcos aquí.

Scrum es un marco ágil y has desarrollado el curso "UX With Scrum": responde cómo hacer diseño e investigación UX dentro del marco Scrum. Esto suele ser un desafío para agencias, ya que Scrum parece prescriptivo para desarrollo y eso va bien, pero al sumar UX y research complica un poco todo, ¿todos van en los mismos sprints de dos semanas? ¿Hay que ir uno o dos sprints por delante? Para quienes enfrentan esto, creen que scrum es el marco ágil ideal pero no saben cómo meter la parte estratégica y de investigación de diseño UX.

Ben Aston:

¿Puedes explicarnos a alto nivel cómo ves que todo funciona junto? Porque este suele ser el mayor reto de las agencias al implementar Scrum.

Jeff Gothelf:

Sí. Y ese es justo el reto que resuelve el curso Professional Scrum with UX (PSU). Ahí damos una visión pragmática y realista de cómo es Scrum hoy y cómo debe ajustarse para soportar prácticas que, honestamente, no se consideraron al inventarse Scrum y que ahora son indispensables para crear buenos productos.

¿Cómo hacemos eso? Nos enfocamos en qué entra al backlog, cómo escribimos historias, quién hace ese trabajo, qué ocurre mientras se realiza, y qué más debería estar pasando. ¿Cuánto del sprint debe ser para aprendizaje y cuánto para entrega? Todo eso se trata en el curso. Resumiendo: lo más importante es la colaboración multifuncional.

Un diseñador debe estar en el equipo a tiempo completo, el trabajo de descubrimiento es igual de importante que la entrega y hay un flujo entre ambos. A veces la investigación UX la hacen personas que no son diseñadores, y eso debe ser aceptado por todos. Eso es un resumen muy alto nivel del curso, pero vale la pena verlo.

Ben Aston:

Bien. Y algo que me despierta curiosidad: mi problema con Scrum es lo prescriptivo que es. Hemos hablado hoy de que solo es un marco, un punto de partida y debería evolucionar. Pero Scrum, con su estructura de pruebas, es bastante rígido. Así que me interesa tu disposición a involucrarte en un marco prescriptivo como este y cómo gestionaste esa tensión entre prescribir el proceso y saber que debe adaptarse a cada organización. ¿Cómo diseñaste el proceso?

Jeff Gothelf:

Mira, lo bueno de hacerlo con scrum.org es que estuvieron dispuestos a ajustar su postura. En el pasado, otros decían: “esto es Scrum, no cambia, así que tú tienes que modificarte”.

Ben Aston:

Claro.

Jeff Gothelf:

Aquí fue diferente, ellos accedieron a ajustar también lo que hacían, lo cual ya es una victoria y un avance. En segundo lugar, esto es una receta. Hablo muy francamente, es una receta. Si no sabes cómo resolver esto con Scrum, empieza con esta receta. Luego la ajustarás para tus necesidades y circunstancias, pero usa esto para comenzar. Así que después, mejora y aumenta la receta acorde a lo que necesites, pero este es un buen punto de partida que nos ha funcionado.

Ben Aston:

Sí, eso es útil y creo que para cualquiera que piense en implementar Agile, saber que esos marcos que describen procesos son solo recetas y no hay que seguirlos ciegamente. Hay libertad para ser flexible y lograr los resultados buscados, no solo por seguir el marco. Nadie te califica por seguir el marco, sino por esos resultados logrados. Ese ha sido el tema de hoy. Así que gracias, Jeff, por acompañarnos.

Jeff Gothelf:

Fue un placer, Ben. Ha sido genial, gracias por invitarme.

Ben Aston:

Genial. ¿Qué opinan ustedes? ¿Cuáles son sus hacks, consejos y trucos para entregar bien? ¿Cómo logran el éxito? ¿Han probado la técnica de la nota de prensa? Déjennos sus comentarios. Cuenten sus historias fallidas. Compartan sus éxitos. Avísennos.

Si quieren aprender más y avanzar en su trabajo, únanse a nuestra tribu con la Membresía DPM en thedigitalprojectmanager.com/membership para acceder a nuestro equipo de Slack, plantillas, talleres, sesiones AMA, horas de oficina, e-books y más. Y si les gustó el contenido, suscríbanse y estén en contacto en thedigitalprojectmanager.com. Hasta la próxima. Gracias por escucharnos.