13 Cosas con las que como Product Owner puedes contribuir para lograr una buena planificación
Siguiendo con la secuela que vengo escribiendo, sobre como ayudar a los Product Owner para que puedan ejercer de la mejor manera su rol, teniendo siempre presente la importancia que este tiene como estratega principal del equipo, en pro de generar el mayor valor posible tanto para los clientes como para la organización. En esta ocasión quiero mostrarte (tratando de tener una mirada sistémica) mi querido amigo lector, algunas cosas con las que como Product Owner puedes contribuir para lograr una buena planificación.
Sin duda, que una buena preparación siempre será clave al momento de afrontar dicho espacio. Sin embargo, en medio de esta, también se presentan diversas situaciones que hay que tener presente de cara a lograr una buena planificación. Y si bien, la planificación es un tema de equipo, en esta ocasión quiero enfocarme en como el Product Owner siendo un buen estratega, puede contribuir para lograr dicho objetivo.
Tener clara la Estrategia del Producto/Solución.
No Tener Clara La Estrategia Del Producto/Solución, es un error que muchos Product Owner comenten. Error que se presenta, en muchos casos por la falta de conocimiento del producto/solución que se está desarrollando, en otros por la falta de claridad de las necesidades reales del cliente, lo que desencadena en no tener claro el tipo de valor a generar, el valor real que debe ser generado con cada entregable que ha de ser planificado e incluso no tener claro el costo que tendría generar dicho valor generado, el retorno de la inversión que se obtendría ni tampoco el retorno de la eficiencia obtenida. Sin contar con los indicadores que se moverán o los resultados claves que se esperan alcanzar. Factores claves de cara a los siguientes pasos a seguir.
Motivo por el cual, como Product Owner, es tu responsabilidad, establecer cual ha de ser la estrategia de liberación mas adecuada de cara a maximizar el valor a generar, teniendo presente que esta debe estar alineada al propósito y a la visión del producto. Identificar los distintos indicadores que se van a medir en la post liberación y los resultados claves esperados.
Mapear las entregas mediante un Roadmap o Plan de liberación.
Este punto es clave de cara a visualizar los tiempos en que dichas entregas verán la luz de cara al cliente y así comenzar con las mediciones previstas sobre los resultados esperados. Así como también para alinear expectativas con los Stakeholders y los equipos.
Motivo por el cual, como Product Owner es tu responsabilidad después de tener clara cual ha de ser la estrategia de liberación, generar el roadmap o plan de liberación de dicha entrega. Esto además de lo anteriormente descrito, te permitirá tener mucho más claro, cuales han de ser los objetivos de los sprint que se han de emplear para lograr dicha(s) entregas.
Garantizar que se realice un efectivo refinamiento del Product Backlog
Una de las cosas que hace que un Planning sea desastroso (entre otras cosas), es llegar a este con un Product Backlog que no ha sido efectiva y eficientemente refinado. Este es uno de los grandes problemas que tienen los equipos en la actualidad, ya que no realizan (en muchos casos no saben) un refinamiento adecuado, ya que no realizan un análisis y una examinación precisa de los ítems funcionales, que les permita añadir detalle a dichos ítems, lo que como resultado genera en muchos casos que no se identifiquen los distintos habilitadores requeridos para hacer realidad dichos ítems funcionales.
Pd: Recuerda que el refinamiento del Product Backlog, incluso es mucho mas que solo esto, debes garantizar que los distintos ítems del Product Backlog identificados, sea estimados tanto en tamaño como en tiempo, así podrás realizar junto con la información de los dos puntos anteriores una mejor priorización.
Pd2: Recuerda que el refinamiento no es un evento, en realidad es un proceso continuo por lo que debe realizarse constantemente a lo largo del Sprint.
Gestionar siempre la deuda técnica y funcional generada.
El Product Owner es un estratega, motivo por el cual debe ser un buen gestionador. Y gestionar la deuda técnica, es tu responsabilidad. Garantizar que no solo solo identificada, sino que también sea pagada en los sprint indicados es una buena forma de planificar y de garantizar que los objetivos sean alcanzados. Recuerda: “Quien paga lo que debe, sabe lo que tiene”
Garantizar que siempre exista por lo menos un objetivo en los Sprint
Y no solo que exista, sino que este debe estar alineado al roadmap o plan de liberación de tal modo que el equipo tenga claro a que le esta apuntando alcanzar en cada sprint. En este punto no está demás mencionar que muchos equipos no saben definir correctamente los objetivos del sprint y no solo porque no estén alineados a un plan de liberación, sino que en su concepción, su estructuración, sus componente y escritura por lo regular no quedan bien definidos. En este punto es crucial contar con un buen apoyo del scrum master del equipo ya que una de sus responsabilidades es ayudarte en esto.
NO definir solo el/los objetivos del Sprint
Recuerda que haces parte de un equipo y que si bien tu defines la estrategia de liberación, la construcción del roadmap de liberación depende de dicha estrategia pero también del trabajo que hace el equipo de cara a obtener la información necesaria para crear dicho roadmap. Por lo que el/los objetivo(s) del sprint deben ser definidos por todos los integrantes del equipo y no solo por ti. Es tu responsabilidad garantizar que exista por lo menos un objetivo del sprint y que este/estos esté/estén alineados al roadmap de liberación, además de que sea medible y realista.
Identificar y gestionar los riesgos
Al ser responsable de la estrategia y el plan de liberación, es tu responsabilidad garantizar que se identifiquen constantemente y sobre todo que se gestionen efectivamente los riesgos que se presenten a lo largo del proceso que puedan afectar las distintas entregas que componen el plan de liberación.
Tener una Visión sistémica sobre la gestión de las dependencias
Estratega que no tiene una visión clara sobre las cosas que necesita y las cuales depende otros para conseguir, fracasa en su estrategia. Si bien es responsabilidad de todo el equipo, identificar y gestionar las dependencias que se puedan presentar a lo largo del proceso de desarrollo de productos/soluciones. Para el Product Owner, es un factor clave de éxito de la estrategia establecida, tener dicha visión, ya que según como estas dependencias se gestionen, estas pueden o no afectar no solo su estrategia de liberación sino también su plan de liberación, lo que repercutirá directamente en la consecución de los objetivos trazados.
Garantizar la inclusión en la planificación los ítems de Mejora Continua
Como buen estratega el Product Owner debe saber que si el equipo no mejora, tanto el producto/solución que se esta desarrollando como la forma en que se hace no mejora. De una u otra forma están directamente relacionados la mejora del equipo con los resultados del equipo. Por lo que exigir al Scrum Master que facilite la identificación de experimentos o acciones de mejora del equipo debe ser una constante. Pero aun mas que esto, como Product Owner debes garantizar la existencia de dichos espacios, también la gestión efectiva de dicha mejora (lo que es responsabilidad del Scrum Master) y lo más importante la inclusión de esto en cada planificación que el equipo realice. De tal modo que dicha mejora sea realmente continua.
Pd: Recuerda que tu como Product Owner haces parte del equipo, por lo que debes participar de los espacios de mejora y de los experimentos y/o acciones de mejora que se planteen.
No forzar al equipo a comprometerse a mas de lo que realmente puede
Este es un error que comenten muchos Product Owner, y es influenciar en el equipo (incluso hasta determinar) lo que el equipo debe planificar, recuerda como Product Owner eres un estratega y como estratega defines la estrategia (Propósito, visión, estrategia y plan de liberación) pero no la forma en que se hacen las cosas y mucho menos lo que el equipo debe y tiene que comprometerse a hacer sprint tras sprint. Forzar esto no solo es un síntoma de desconfianza en el equipo sino también de autoritarismo lo cual afecta directamente la salud del equipo como tal. En este sentido ha de ser el Scrum Master o Agile Coach asignado al equipo quien debe ayudarlo a identificar sprint tras sprint cual ha de ser su capacidad de cara a la siguiente planificación a realizarse.
Medir, Analizar y tomar las decisiones que se deben de tomar
Un Product Owner debe estar en constante análisis y medición de los resultados obtenidos, esto con el fin de mantener tomar las decisiones que le permitan tener actualizada la estrategia y el plan de liberación. Para esto debes tener presente los indicadores y las métricas necesarias que te permitan tener una orientación a resultados (Outcomes) por encima de actividades (outputs). Recuerda siempre que un argumento sin números es solo una opinión.
Empatizar con el equipo
Recuerda que no es negocio pidiéndole cosas a tecnología, tampoco negocio y tecnología, es negocio más tecnología unidos por un solo propósito. Motivo por el cual debes sentirte y ser parte de un todo llamado equipo con el cual has de convivir, relacionarte y sobre todo empatizar a lo largo de todo el proyecto o a lo largo de toda la evolución del producto o solución. Has visible tus miedos, temores y expectativas, alinéalas con el equipo, busca como ayudarlos siempre y déjate ayudar ya que son un equipo no tú y ellos. Respeta sus decisiones, sus temores, sus miedos y busca siempre como crecer juntos.
Gestiona eficientemente los nuevos requerimientos
Recuerda si todo es importante, nada es importante. Y cuando el estratega coloca todo como urgente, todo pierde sentido. Y si todo pierde sentido, nada será alcanzado. Procura proteger al equipo de esto y así no se afectara tu estrategia, tener esto visible y medido, te permitirá saber el impacto que esto esta teniendo y al saber esto sabrás que tanto se cumplirán los objetivos trazados.
Como vez mi querido amigo lector, como Product Owner es mucho lo que puedes hacer o contribuir para que se tenga una buena planificación. Recuerda tu como Product Owner debes ser un buen estratega y como estratega debes construir al máximo en la planificación del equipo al que perteneces, para que alcancen grandes resultados tanto para los clientes como para la organización.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Quisiera empezar mencionando, que es muy común encontrar Product Owner que piensan de la siguiente manera: “Si tengo un/unos usuario(s) que tiene(n) un problema, se lo planteo al equipo de desarrollo, el cual desarrolla una nueva funcionalidad, una mejora o un cambio en el sistema y listo resuelvo el problema.” Déjame decirte algo mi querido Product Owner, no pienses que por el solo hecho de entregar una funcionalidad, mejora o cambio, el problema se resolverá. O incluso más importante aún, que por realizar dicha entrega, se causó el impacto deseado en el comportamiento del usuario y/o se generó un impacto financiero o de posicionamiento positivo para la compañía. Sin duda, nada mas ajeno de la realidad que esto y nada más desacertado para ti, el tener este tipo de pensamiento.
En el post anterior, estuve mostrándote las cosas que deberías evitar hacer para ser un buen Product Owner (el post lo puede leer aquí). En esta ocasión, quiero mostrarte los dos enfoques que hay en el desarrollo y la gestión de productos y/o soluciones, cuáles son las consecuencias de llevar cada uno de ellos y por lo tanto cual es el enfoque que tu como Product Owner deberías tener.
Enfoque de gestión y desarrollo de productos y/o soluciones orientado a entregas.
¿Alguna vez has tenido que preparar una presentación para tus superiores, con una hoja de ruta que muestre cuando van a ser entregadas las distintas funcionalidades que han sido planificadas? Y ¿las discusiones en los espacios de presentación, han estado centradas en estas? Si tu respuesta es sí, quiere decir, que las funcionalidades, mejoras o cambios a realizar en el sistema, están en el centro de nuestra estrategia de organización del Product Backlog. Por lo tanto, nuestro enfoque de gestión y desarrollo de productos y soluciones está orientado a entregas, es decir a Outputs. Lo cual es muy común cuando las personas (en especial los jefes que no cuentan con un Mindset agile) necesiten/quieran ver cuándo y qué se entregarán para comprender dónde y cuándo se obtendrán los resultados para el usuario o la empresa.
La consecuencia de tener este tipo de enfoque, es que tanto los gerentes/jefes de las organizaciones, así como desafortunadamente los Product Owner, terminan enamorándose y/o preocupándose más por las soluciones que por los problemas en sí. Lo que conlleva entre otras cosas a estar mas pendientes de la productividad que de analizar los resultados de negocio obtenidos. Lo correcto sería (aunque es más difícil) enamorarse más del problema que de la solución. Esto significa, que se debería invertir más tiempo en la etapa inicial del proceso, para conocer más sobre el problema, comprender sus complejidades y razones, y luego pasar a una solución. Esto les haría ver, que la cantidad de entregas que se realicen de nada importan, si estas no están afectando el comportamiento del usuario, lo que a su vez afecta los indicadores del producto, lo que a su vez debería afectar los indicadores comerciales.
Enfoque de gestión y desarrollo de productos y/o soluciones orientado a resultados.
Tener un enfoque de gestión y desarrollo de productos y/o soluciones es organizar el Product Backlog para orientar a los equipos y su planificación, a alcanzar un determinado objetivo, teniendo como referencia el avance obtenido en el tiempo de determinados resultados (comerciales, de marca, de comportamiento, etc.). Dichos resultados, deben estar alineados con los objetivos de los Sprint que tienen los equipos y las presentaciones a realizar en los distintos comités organizacionales. Sin duda pensarás, que esto es mucho más fácil decirlo que hacerlo, pero es el mejor enfoque que puedes tener como Product Owner, para que los equipos logren generar los mejores resultados para la organización y para los clientes.
Pero ¿Cuál es el impacto no tener un objetivo para el Sprint o tenerlo pero que este no esté alineado a la estrategia de liberación?
Cuando los equipos no tienen un objetivo de Sprint, se vuelve imposible controlar las tres fuentes de fricción identificadas por Stephen Bungay, que influyen en la determinación de tener una estrategia con un enfoque orientada a resultados por encima de una orientada a hacer cosas (en este caso a entregas). De hecho, se presentaran cada vez a mayor escala. Dichas fuentes son:
Brecha de conocimiento. Cuando esta se presenta, las personas dedican aún más tiempo a grandes análisis y planificación inicial para tratar de cerrar la brecha (¿te recuerda algo?).
Brecha de alineación. La respuesta típica a los problemas de alineación es emitir instrucciones más detalladas. Todos estos detalles adicionales terminan obstruyendo la claridad y generan aún más confusión.
Efectos gap. La respuesta habitual es imponer controles y métricas más estrictos en los equipos para tratar de garantizar que estén entregando los resultados correctos.
Y adicionalmente a esto, cuando se cuenta con un objetivo, pero este no está alineado a la estrategia de liberación se presenta lo siguiente:
Se desperdicia mucho tiempo en la planificación y el análisis. Sin objetivo del Sprint, los planes se vuelven rígidos e inflexibles, y no será posible incorporar nueva información a medida que se aprenda más y se avanza en el desarrollo del producto o Solución.
El equipo de desarrollo no puede autoorganizarse y definir lo que debe hacer. Por lo que, lo que se debe hacer, se define por adelantado sin una relación con un objetivo claro.
Cada elemento del Backlog, se convierte en un compromiso. Como resultado, el alcance ya no es flexible. Cuando aparece la inevitable complejidad imprevista, la única forma de terminar lo planeado eliminado ítems e introduciendo deuda técnica.
Ahora, un Objetivo de Sprint, establecido de manera centrada en los resultados, hace posible que el equipo se alinee a la estrategia de liberación establecida por el Product Owner, con la cual se busca alcanzar los resultados establecidos, y así podremos saber si se están alcanzado los objetivos. Adicionalmente a esto, un objetivo de Sprint, establecido de manera centrada en resultados, reduce el efecto provocado por las tres fuentes de fricción identificadas por Stephen Bungay.
En este orden de ideas, hay que decir que:
La brecha de conocimiento se reduce por la correcta definición y comunicación del Objetivo Sprint. Es decir que tener claro el ¿Por qué y qué queremos lograr?, los equipos pueden incorporar una mejor información para determinar como lograr dicho objetivo. Y tu como Product Owner, tendrás mejor información para construir el plan de liberación.
Para cerrar la brecha de alineación, la organización debe tener una alineación clara y transparente sobre los objetivos que deben alcanzarse. De esta manera, el equipo puede decidir cómo impactar al usuario para lograr objetivos globales. En este sentido tu responsabilidad como Product Owner, es instigar el liderazgo para definir y crear una alineación con los objetivos que deben lograrse.
Para minimizar la brecha de efectos, es importante dar a los equipos la libertad de ajustar sus acciones en función del objetivo del Sprint. Esta es la razón por la cual el Sprint Backlog de Sprint es flexible durante el Sprint siempre que no ponga en peligro el/los Objetivo de Sprint.
Ahora, mi querido amigo lector como Product Owner, debes definir lo que serán los entregables (outputs), solo después de definir Resultados (Outcomes). Sin embargo, ten presente que, la definición de los resultados que se deben lograr, llega solo después de haber identificado, comprendido y entendido los problemas y las necesidades de los usuarios. Por eso es tan importante conocer bien el tipo de valor y la propuesta de valor que se ha de generar.
Por lo tanto, cuando una empresa trabaja con un marco (como los OKR), o un Product Owner tiene un enfoque de gestión y desarrollo de productos/soluciones orientado a resultados, prioriza primero los objetivos y los resultados, por encima de las entregas. Entonces, definir, medir y monitorear lo que se hará, será mucho más fácil.
Si quieres aprender más, te invito a que le des una lectura a mi libro: Product Backlog, una mirada sistemica(Aqui). En donde te ofrezco una visión completa de lo que es el Product Backlog y su importancia en el desarrollo de productos y soluciones que generen valor al cliente. Ademas de mostrarte como crear, organizar y gestionar product backlog orientado a outcome (resultados) por encima de output (entregables).
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Ser un buen Product Owner es un tema complejo, dado que unas de sus grandes responsabilidades es organizar y gestionar el Product Backlog con una mirada sistémica que tenga una orientación a resultados tanto para el negocio como para los clientes.
Pero, ¿Por qué es tan importante saber organizar y gestionar el Product Backlog?, mi querido amigo lector, quiero decirte que la importancia radica precisamente en el objetivo principal de éste(el del Product Backlog), el cual podríamos decir que es: “brindarnos esa visión sistémica y transparente del problema a resolver, de la solución que estamos desarrollando y de la mejora continua que debemos aplicar”. Es decir, que el Product Backlog define la dirección por parte del equipo que está desarrollando el producto o la solución. Por lo tanto, hay cosas que como Product Owner deberías evitar hacer, mientras se gestiona este artefacto tan crucial.
Ahora, partamos de la definición oficial del Product Backlog que se encuentra en la guía de Scrum:
«La Lista de Producto (Product Backlog), es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a realizarse en el producto, el Product Owner es el responsable de la Lista de Producto (Product Backlog), incluido su contenido, disponibilidad y ordenación.”
Sin embargo, aun en la guía de scrum, no solo se queda corta la definición, dada la importancia que este (el Product Backlog) tiene. Sino que además, acota al producto su contenido e incluso limita su gestión al Product Owner, dándole la responsabilidad de su contenido, disponibilidad y ordenación.
Es por eso, que una definición propuesta (la cual expreso en mi libro – Product Backlog, una mirada sistémica) de lo que es un Product Backlog, podría ser:
“El Product Backlog, es un artefacto vivo, compuesto por una serie de ítems que representan una visión sistémica, de lo que ha de ser una solución y de lo que las personas involucradas en el desarrollo de dicha solución deben hacer, para garantizar su crecimiento como equipo y la entrega temprana, constante y continua de valor.”
Ahora, adicionalmente a la definición, la guía plantea:
«Una Lista de Producto (Product Backlog) nunca está completa. El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al principio. La Lista de Producto (Product Backlog) evoluciona a medida que el producto y el entorno en el que se usará también lo hacen. La Lista de Producto (Product Backlog) es dinámica; cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Lista de Producto (Product Backlog) también existe.”
«La Lista de Producto (Product Backlog) enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras. Los elementos de la Lista de Producto (Product Backlog) tienen como atributos la descripción, la ordenación, la estimación y el valor.”
«A medida que un producto es utilizado y se incrementa su valor, y el mercado proporciona retroalimentación, la Lista de Producto (Product Backlog) se convierte en una lista más larga y exhaustiva. Los requisitos nunca dejan de cambiar, así que la Lista de Producto (Product Backlog) es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del mercado o la tecnología podrían causar cambios en la Lista de Producto.”
Mi querido amigo lector, quiero decirte que en muchos casos, la mala interpretación de los párrafos expuestos, hace que se presenten las cosas que te invito a evitar como Product Owner:
Creer que el Product Backlog está compuesto solo de Historias de Usuario, o en su defecto solo de ítems funcionales
Este es uno de los grandes errores que se presentan en muchos equipos, como ya pudimos ver en un post anterior (el cual puedes leer aquí). El Product Backlog esta compuesto por una serie de ítems que permiten que se logre esa mirada sistémica que se espera de este importante artefacto de cara al cumplimiento de su objetivo.
Creer que el Product Owner, es el único que puede crear los ítems del Product Backlog
Si miramos los tipos de ítems que contiene un Product Backlog, vemos que al no tener tiene solo ítems funcionales, roles como el del Arquitecto de la solución, los lideres Técnicos, los UX, desarrolladores e incluso los Scrum Master, tienen la responsabilidad de contribuir en la creación de los ítems del Product Backlog cada uno desde su área de acción. Con el fin de contribuir el lograr esa mirada sistémica que se espera tenga el Product Backlog.
Creer que el Product Owner es el único responsable de gestionar los ítems del Product Backlog
El paradigma con el que normalmente venía trabajando el Product Owner, puede ser la razón de este malentendido. Dado que, en las metodologías tradicionales, los requisitos no se gestionan en colaboración, por lo general era una única persona la encargada de la gestión de requerimientos, sin embargo en un entorno ágil, teniendo presente los distintos tipos de ítems que contiene el Product Backlog, no tiene sentido continuar con este tipo de paradigma. Ya que una gestión permite establecer una mejor estrategia de cara a la consecución de los objetivos trazados.
Pretender crear todo el Product Backlog al inicio del proyecto
En este sentido hay que recordar siempre se un proyecto o el desarrollo de un producto o solución bajo un enfoque ágil, parte de la premisa que se desarrolla en un entorno empírico y que mediante la continua inspección y adaptación se va ajustando el camino a seguir. por lo que pretender crear todo el Product Backlog al inicio, es comenzar con un enfoque de agilidad cosmética.
No tener el Product Backlog Organizado
Este es otro de los grandes errores que comenten muchos equipos, ya que al no tener el Product Backlog organizado, se mantiene un enfoque a entregables (outputs) mas no a resultados (Outcomes), motivo por el cual, toma relevancia organizar el Product Backlog, teniendo una estrategia de liberación y un plan de liberación claros y que se puedan ir ajustando con el paso del tiempo según los resultados obtenidos.
No tener claro el tipo y el valor que se espera generar
Si no tener el Product Backlog organizado, es no tener un enfoque a resultados, no tener claro el tipo y el valor que se va a generar, podría considerarse una irresponsabilidad con la organización. Dado que, al no tener esto claro, la organización no solo no tendría información del beneficio real entregado a los clientes sino que además tampoco podrá determinar temas como el retorno de la inversión (ROI), el Retorno de eficiencia (ROE) entre otros. Es decir seria como estar invirtiendo en una solución, que no se sabe si es o no rentable.
Desarrollar un Plan de liberación con estimaciones de alto nivel
¿Te imaginas comprarle un par de zapatos a tu esposa, sin llevarla a ella a que los escoja y se los mida?, del mismo modo imagínate pretender entregar algo sin contar la estimación de tiempo de quien realmente va ha realizar la labor esperada. Este es un problema que se presenta en muchas organizaciones por su afán de iniciar proyectos y de tener esa sensación de falsa seguridad y control que te brinda una fecha dada por lo general por un jefe o un gerente de proyectos. Un buen Product Owner, sabe que las estimaciones de alto nivel brindan esa falsa sensación de seguridad y control, que al pasar el tiempo terminan siendo efímeras, por lo que para la construcción de su plan de liberación este tiene en cuenta el refinamiento y la estimación realizada por el equipo de desarrollo, quienes son los que realmente van a desarrollar el producto o la solución, de tal forma que entendiendo que la estimación es un tema relativo, construye un plan de liberación acorde a la realidad del contexto.
Contar con múltiples Product Backlog, por ejemplo, uno funcional, uno técnico, uno de mejora continua, etc.
En un enfoque ágil, el trabajo colaborativo es un punto muy importante, por lo que, a pesar de que un Product Backlog contiene distintos tipos de Ítem, este es al final un único artefacto valido que contiene el amalgama de todos estos, de tal modo que logre darnos esa visión sistémica, de lo que ha de ser una solución y de lo que las personas involucradas en el desarrollo de dicha solución deben hacer, para garantizar su crecimiento como equipo y la entrega temprana, constante y continua de valor. Y no fomentar así, los ahora tan presentes silos agiles.
No realizar revisión y refinamiento frecuente de los ítems del Product Backlog
La misma guía de Scrum nos lo indica, el refinamiento del Product Backlog es un proceso continuo. Por lo tanto, este no debe considerarse una ceremonia o evento, de tal modo que se incurra con esto en el error de realizar la revisión y el refinamiento solo un par de días establecidos en la semana, recordemos que la realización constante de la inspección, nos brindará las herramientas necesarias para la adaptación y por otro lado, el refinamiento continuo permitirá un mayor conocimiento, entendimiento y comprensión de las necesidad a resolver, así como también del trabajo necesario a realizar.
Tener los ítems del Product Backlog sobre refinados, lo que crea un Product Backlog tamaño XXL
Si bien el refinamiento en un proceso continuo y que debe realizarse a todos los ítems del Product Backlog, hay que tener cuidado en plasmar en este hasta el más mínimo detalle de cada una de las tareas que se deben realizar, las cuales si bien son importantes de identificar, el poblar el Product Backlog con estas, podrá acarrear problemas en la gestión de este, así como también confundir el mensaje que este debería trasmitir a quien intente leerlo.
Pretender ser el único que debe de participar en la creación de la Historias Funcionales
Hay que tener presente que “Una Historia de usuario es una corta declaración de intención que describe algo que el sistema necesita hacer para el usuario. Y se describe desde el punto de vista de quien usará la funcionalidad”. Pero sobre todo que esta, es el resultado de una conversación en la que se busca el conocimiento, entendimiento y comprensión de la necesidad a resolver. Por lo que lo importante no es quien la escriba, sino que se logre precisamente entender esa necesidad a solucionar. Ahora, los distintos roles del equipo pueden realizar aportes importantes, como por ejemplo los analistas de QA de cara a una mejor definición de los criterios de aceptación, incluso si tomamos en cuenta un enfoque TDD, esto permite aun mejor resultado. Por lo que como Product Owner enfócate en que existan las Historias de Usuario necesarias para solucionar el problema, y que en su construcción participen todos aquellos que aportan valor a lograr dicha comprensión del problema.
Presentarse solo el día del Planning y posteriormente el día de la Review
En este sentido hay que tener presente que como Product Owner, haces parte del equipo, por lo que es de suma importancia que recuerdes el principio ágil que dice: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Si, así como lo lees, juntos, de forma cotidiana, a lo largo de todo el proyecto, NO solo en unos eventos específicos. Con el fin de lograr estar sintonizados, empoderados y alineados en todo lo referente. Recuerda que entre otras cosas no se esta construyendo o desarrollando un producto o una solución, también se esta buscando construir un equipo de alto desempeño que logre grandes resultados.
No participar de la Daily del Equipo
Una vez más, debes tener presente que tú haces parte del equipo, por lo que es importante que participes en la sincronización diaria (entendiendo que NO es un espacio de seguimiento, sino de sincronización y definición de los objetivos del día). Y que por sobre todo, lo que te permitirá tener información, para si saber los riesgos presentados, o los posibles ajustes que se deban hacer a la estrategia, o información relevante que deba ser elevada a los Stakeholders, entre muchos otros.
No participar de la retrospectiva del equipo
Por ultimo y una vez más, aunque suene cansón, tú haces parte del equipo y debes participar en el proceso de mejora continua, sería muy egocéntrico pensar que no tienes nada que mejorar… Como haces parte del equipo tu contribuyes a su mejora en todas sus dimensiones, por lo que tu participación aquí debe ser precisamente eso participativa, propositiva, mas no impositiva ni observativa.
Por último, mi querido amigo lector, quiero dejar un par de frases para tu reflexión:
“El empirismo afirma que el conocimiento proviene de la experiencia y toma decisiones basadas en lo que se conoce.” – La guía Scrum
“Individuos e interacciones sobre procesos y herramientas.” – Manifiesto ágil
Por lo tanto involúcrate y compenétrate con el equipo, ya tu haces parte de él. Recuerda, que la gestión del Product Backlog en un proceso continuo y colaborativo. Y que un Product Backlog orientado a resultados, genera mayor valor a los clientes y a la organización, lo cual refleja la existencia de un buen Product Owner. De tal modo, que ten cuidado, y no vivas en una agilidad cosmética.
Si quieres aprender más, te invito a que le des una lectura a mi libro: Product Backlog, una mirada sistemica(Aqui). En donde te ofrezco una visión completa de lo que es el Product Backlog y su importancia en el desarrollo de productos y soluciones que generen valor al cliente. Ademas de mostrarte como crear, organizar y gestionar product backlog orientado a outcome (resultados) por encima de output (entregables).
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
La importancia de organizar el Product Backlog (Video, Charla en el Agile Help)
Por si te la perdiste, a continuación te comparto mi charla realizada en el marco del Agile Help 2020, en el cual estuve compartiendo la importancia de organizar el Product Backlog, dada la importancia de este y el enfoque orientado a resultados que este debe de tener para lograr productos/soluciones que generen gran valor a los clientes y a la organización.
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Los tipos de Ítem que debe tener un Product Backlog para que sea Sistémico y pueda facilitar su organización
Mi querido amigo lector, una de las cosas con las que mas me he encontrado en estos años de acompañamiento en sus viajes de habitación de la agilidad a distintos tipos de organizaciones, son equipos (y hasta estructuras virtuales como tribus, trenes, squads) con Product Backlog que no reflejan de manera sistémica el producto/proyecto que están desarrollando. Lo cual refleja que son equipos (o estructuras virtuales) que tienen un enfoque a entregas mas no a resultados. Por lo cual, quiero decirte, que de ahí nació mi iniciativa de escribir mi libro Product Backlog una mirada sistémica, con el fin de brindarles a los equipos, organizaciones y sobre todo a roles como Product Owner y/o Product Managers una guía de como crear, organizar y gestionar sus Product Backlogs orientados a resultados.
En el post anterior (La importancia de Organizar el Product Backlog), estuve compartiendo un poco sobre la importancia que tiene saber organizar el Product Backlog de tal modo que este tenga esa orientación a resultados esperada cuando hablamos de agilidad. En esta ocasión quiero mostrarte los ítems (mínimos) que debería tener el Product Backlog para que este tenga una mirada sistémica y así sea más fácil realizar la organización planteada en el post anterior.
Para iniciar, recordemos la definición oficial (del Product Backlog) que se encuentra en la guía de Scrum:
“La Lista de Producto (Product Backlog), es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a realizarse en el producto”.
Sin embargo, dicha definición se queda corta, dada la importancia que este (el Product Backlog) tiene. Además, acota al producto su contenido e incluso limita su gestión al Product Owner, dándole la responsabilidad de su contenido, disponibilidad y ordenación. Es por eso por lo que en mi libro planteo una definición un poco mas completa, para darle precisamente el reconocimiento y la importancia que tiene una correcta creación, organización y gestión de este artefacto (la cual te invito a conocer).
Ahora, si analizamos los principios agiles encontraremos la clave de lo que te planteo para este post, el cual es el hecho de identificar esos tipos de Ítems (mínimos) que deberá tener el Product Backlog para lograr su objetivo. En ellos logramos identificar diferentes factores que nos permitirán, abordar lo que veremos a continuación. Entre los puntos a resaltar, vemos como ellos tenemos:
• Una visión conjunta, conformada por la amalgama entre negocio y tecnología.
• Un enfoque múltiple conformado por la mejora continua, la excelencia técnica, el diseño, la calidad y la entrega continua de valor.
• El devenir de una estrategia y un plan que permitan esa identificación y entrega sostenida de valor en ciclos o iteraciones cortas.
• La orientación a la inspección y adaptación para realizar los ajustes pertinentes en la estrategia y los planes establecidos.
En ese orden de ideas, para que un Product Backlog alcance su objetivo de brindarnos una visión sistémica y transparente del problema a resolver, de la solución que estamos desarrollando y de la mejora continua que debemos aplicar, deberá contener una serie de tipos ítems o de elementos que así lo indiquen, entre los que tenemos:
• Ítems Funcionales: Los cuales son llamados a brindar claridad sobre el problema o la necesidad que se busca resolver con la solución que se está desarrollando. Así como permitirle a los equipos y las organizaciones, concentrarse en el valor que se busca generar a lo largo de la solución. Dentro de los ítems funcionales tenemos las Épicas, los Features (o características) y las Historias de Usuario.
• Ítems Habilitadores: Los habilitadores son elementos que respaldan el desarrollo de las funcionalidades, ya que ayudan a estabilizar la arquitectura, la infraestructura y el mantenimiento de las necesidades del cliente, entre otros factores. Entre los tipos de habilitadores existen: los arquitectónicos/técnicos, los de infraestructura, los exploratorios y los de cumplimiento.
• Ítems de Deuda técnica: Una de las expresiones más utilizadas para estas es: “La deuda técnica es el coste y los intereses que se deben pagar por hacer mal las cosas”. Es decir, que provocaran afectaciones a futuro en la solución que se está desarrollando. Por lo tanto, solo quiero recomendarte tres cosas que son: la primera no confundir la deuda técnica con Carry-Overs, dos siempre identificar la deuda técnica generada y tres siempre pagar la deuda técnica.
• Ítems de Mejora continua en sus 4 dimensiones: Recordemos que los equipos agiles tienen como pilar fundamental la mejora continua, motivo por el cual, los diferentes experimentos y planes de acción que realizan deben ser reflejados y gestionados en el Product Backlog, a través de los siguientes tipos de Ítems de Mejora continua, que reflejan las cuatros dimensiones básicas de la mejora contina: ítems de mejora del producto, ítem de mejora del proceso, ítem de las interacciones e ítem de la evolución o mejora de la cultura.
• Bugs identificados a resolver
Apunte final
Cada uno de estos tipos de Ítems, deberá tener clara su definición de cuando se podrá empezar a realizar, como también cuando se considerará que está realmente terminado. Estos puntos importantes se conocen bajo los conceptos de Definition of Ready y Definition Of Done. Así como también la prioridad que tiene con respecto a los demás no solo de su especie sino con respecto a los demás.
De igual modo hay que tener claro que no es necesario crear todo el Product Backlog al inicio del proyecto o del proceso de desarrollo y/o evolución del producto. Hay que recordar que es un tema de inspección y adaptación. Y que además el Product Backlog es un artefacto vivo, lo que nos quiere decir que este puede crecer o decrecer con el paso del tiempo.
Ahora, teniendo claro los tipos de ítem que debe tener el Product Backlog, te invito a leer mi otro post: (La Importancia de organizar el Product Backlog) en donde muestro como el tener organizado el Product Backlog, le da a este, un enfoque a resultados, tanto para la organización como para los cliente.
Si quieres aprender más, te invito a que le des una lectura a mi libro: Product Backlog, una mirada sistemica(Aqui). En donde te ofrezco una visión completa de lo que es el Product Backlog y su importancia en el desarrollo de productos y soluciones que generen valor al cliente. Además de mostrarte como crear, organizar y gestionar product backlog orientado a outcome (resultados) por encima de output (entregables).
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Organizar es una palabra que proviene del latín organizare, relacionada con la acción de disponer las partes de un todo de la manera conveniente para un fin determinado. Al organizar algo, nos enfocamos en preparar las cosas pensando detenidamente en todos los detalles necesarios no solo para su buen desarrollo, sino también para la consecución del objetivo determinado. En ese orden de ideas, al organizar se dispone de una estrategia y de un plan. Es decir, se planifica y se ordena, no sólo el desarrollo sino también los detalles de dicha actividad.
Cuando los equipos agiles tienen un Product Backlog organizado, es porque han definiendo una estrategia de liberación (en diseño de productos se conoce como estrategia de producto) y un roadmap (o plan de liberación), los cuales deben estar alineadas a la visión y al propósito del producto, para así garantizar la mayor generación de valor.
Hay que tener en cuenta, que las relaciones entre estos elementos, funcionan en ambas direcciones. El Product Backlog puede causar cambios en Roadmap (o plan de liberación), lo que a su vez puede afectar la estrategia. Por ejemplo, si los comentarios de los clientes y usuarios indican que el producto no responde adecuadamente a sus necesidades, o si el progreso del desarrollo es lento. Esto puede conducir a cambios en roadmap del producto, de manera similar los cambios en el roadmap del producto pueden generar la necesidad, de realizar ajustes en la estrategia de liberación del producto. Ahora bien, si no se logra encontrar una estrategia válida. Es decir, que ayude al equipo a desarrollar un producto alineado con la visión, entonces es probable que se tenga que modificar la visión o diseñar una nueva. Mas lo que no debe variar, es el propósito del producto.
La estrategia de producto o estrategia de liberación es un plan de alto nivel que ayuda a los equipos a hacer realidad el propósito y la visión del producto. Esta debe ser capaz de explicar para quién es el producto y por qué la gente querría comprarlo y usarlo. Como también, qué es el producto y cuáles son los objetivos comerciales o la propuesta de valor para los clientes o usuarios. Y por qué vale la pena que la organización invierta en él. Ahora, para que la estrategia cumpla con su objetivo, deberá tener presente las necesidades del cliente, la propuesta de valor para suplir esas necesidades y los objetivos de negocio.
Adicionalmente a esto, la estrategia deberá representar la forma en que se va a validar la hipótesis, o se va a adquirir el conocimiento necesario para el desarrollo del producto, o si por el contrario se procederá a entregar valor al cliente.
En este sentido hay que mencionar las distintas formas de representarlo como son:
El Minimum Viable Product (MVP). El cual se utiliza para realizar una «prueba de concepto» o experimento, y mediante ésta validar una hipótesis o adquirir un conocimiento.
LaMinimum Marketable Feature (MMF). La cual representa, una característica real que proporciona un valor tangible a los clientes. Mediante la cual, se aborda una necesidad específica o resuelve un problema determinado
Minimum Marketable Product (MMP o MMR1). Es la agrupación de varias funcionalidades o MMFs que entregamos en el primer release. (desafortunadamente comúnmente se confunde con MVP).
Ahora, el Roadmap o plan de liberación. (conocido también como plan de release), es una herramienta increíblemente útil para implementar la estrategia del producto y alinear las exceptivas tanto de los equipos como de los Stakeholders. Además, también se utiliza para planificar los hitos, que servirán para comunicar los resultados de la solución. En este sentido, el roadmap o plan de liberación describe cómo se ejecutará la estrategia
En su forma más simple, un roadmap o plan de liberación, comunica cómo es probable que evolucione un producto al mapear sus respectivos lanzamientos (o entregables) en una línea de tiempo.
Cada release (entregable o lanzamiento), es una versión del producto que crea valor para los clientes o usuarios. Por ejemplo, mejorar la experiencia del usuario o proporcionar nuevas funcionalidades.
Otras de las razones por la que es importante contar con un roadmap (o plan de liberación), es que refleja una continuidad del propósito del producto, por lo que ayuda a los Product Owner o Product Manager, a tomar decisiones de priorización. Por este motivo, el roadmap o plan de liberación, se convierte en una herramienta para expresar decisiones estratégicas.
Como puedes ver mi querido amigo lector, la gran importancia que tiene el tener un product backlog organizado, radica en que permite tener un product backlog orientado a resultados por encima de solo entregables. Ya que se alinea el propósito y la visión del producto con la estrategia y el plan de liberación de cada entregable.
Si quieres aprender más, te invito a que le des una lectura a mi libro: Product Backlog, una mirada sistemica(Aqui). En donde te ofrezco una visión completa de lo que es el Product Backlog y su importancia en el desarrollo de productos y soluciones que generen valor al cliente. Además de mostrarte como crear, organizar y gestionar product backlog orientado a outcome (resultados) por encima de output (entregables).
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Aumentando la efectividad de los equipos en tiempos de cuarentena (Historia de un experimento real)
La situación actual que estamos viviendo a nivel mundial, es sin duda un contexto que no habíamos vivido antes ni como personas, ni como sociedad. Por lo que está claro, que nunca algo nos había exigido tanto como la actual pandemia del covid-19.
Precisamente hace poco mas de un mes tuve una conversación al respecto (de modo virtual), con el gerente de una fabrica de software que funciona en la ciudad de Medellín (Colombia) en donde me consultaba como era el tema de agilidad en este tiempo de la pandemia del Covid-19. En la conversación, me planteaba su preocupación por los distintos escenarios en los que estaba su empresa (que sin ser grande) si estaba generando buenos réditos antes del inicio de la pandemia. Entre sus preocupaciones (que no eran pocas), estaba por ejemplo el hecho de que es la primera vez que se le presenta el tener a todos los equipos en teletrabajo. Y, aunque tenia varios contratos en curso, su mayor preocupación radicaba en que al estar en ese contexto, como lograría tener a las personas en un nivel de enfoque y productividad que le permitiera cumplir con las entregas pactadas con sus clientes.
En este sentido hay que mencionar que en esta empresa han logrado desarrollar un entorno en donde la agilidad se ha desarrollado de buena forma, por lo que el problema en sí no era un problema de cumplimiento de fechas. Dado que, por la agilidad que han desarrollado, han logrado cerrar contratos en modo de contratación de capacidades orientada a entregables de valor (un gran avance), que no tiene fechas fijas, sino rangos de fechas para los entregables.
Después de escuchar su preocupación le plantee la mía, en la cual, le manifestaba que si bien lo felicitaba (una vez más) por lo grandes avances que han tenido en su proceso de habilitación de la agilidad, me preocupaba el hecho de que él como gerente, aún conservara ciertos paradigmas en iban en contra del gran avance que ellos han tenido. Entre esos paradigmas, le indicaba el hecho que estuviese preocupado por la productividad, dejándole claro que en estos momentos era mas imperioso tener un foco mas fuerte en la efectividad. Para esto, le manifestaba que entendía que no se sintiera cómodo con el tema de teletrabajo (algo que algunos llaman tele confianza, claustro trabajo y hasta telecontrol), ya que era un tema nuevo en su empresa (por lo menos de modo tan masivo), era cuestión precisamente de hacer que las personas tuviesen foco en la efectividad. Por lo que le plantee realizar un par de experimentos (inicialmente con un equipo) y que analizara los resultados de estos periódicamente, de tal modo que pudiera ir ajustando el proceso.
El primer experimento que le plantee fue que aplicara Okr en sus Sprint. Es decir, que mas que tener solo objetivo(s) del Sprint, definiera dichos objetivos bajo el enfoque de Okr. Es decir, que para cada objetivo que definiera en el sprint, definieran unos resultados claves, que le permitiera no solo a él sino también al equipo, saber si iban avanzando correctamente a la consecución de dichos objetivos. Eso sí, le explique la importancia en la participación de todo el equipo en dicha definición. (hay que mencionar que el tema de Okr, no era ajeno para ellos, solo que lo utilizaban para ciclos de 3 meses y dentro de la compañía, no orientado a proyectos en particular)
El segundo experimento que le propuse fue que en las Dayli el equipo, orientara las conversaciones hacia los resultados claves, de tal modo de determinar las actividades diarias a realizar que estuviesen encaminadas a conseguir dichos resultados claves.
Un tercer experimento fue que hicieran la retrospectiva, no solo al final del sprint. Sino que las realizaran semanalmente y cuyo enfoque fuese la mejora continua enfocada en mejorar la efectividad.
Le explicaba entonces, que con estos pequeños experimentos, la idea era enfocar al equipo en los Outcomes por encima de outputs (su preocupación inicial).
Han pasado poco mas de cuatro semanas desde nuestra conversación inicial y quiero compartir contigo mi querido amigo lector las reflexiones que me expreso esta mañana cuando converse nuevamente con él. (en el transcurso de este tiempo hablamos varias veces, así como también hable con sus Scrum master y sus Product Owner).
Dentro de las reflexiones que me comentó, estaba el hecho que comenzó a notar mas empoderamiento de los integrantes del equipo en cada una de las actividades que tenían que hacer de cara a los resultados claves. Otro punto fue que después de hacer varias pruebas de ensayo y error, le informaron los scrum master que las Dayli ahora son más provechosas, ya que las personas se enfocaban en las actividades que debían realizar y los problemas que pudiesen llegar a tener, de cara a alcanzar los resultados claves. Otro punto fue que les ha gustado mucho hacer retrospectivas cada semana ya que según se percató personalmente (luego de que el equipo lo invitara) podían definir experimentos de mejora aun mas pequeños, lo que hacia que se vieran más rápido los cambios. Esto llevo a que realizaran experimentos como por ejemplo realizar también las Review con el cliente no al finalizar el sprint sino semanalmente y orientada a los resultados claves, lo que en sus palabras les había permitido (no en la primera, ni segunda semana, pero si en la tercera) realizar un paso a producción más limpio. Además, experimentaron cambiando la forma en que realizaban las estimaciones, ahora realizan estimaciones bajo el sistema de cubos e incluyeron en las Review la ejecución del modelo de kano para determinar las siguientes características a desarrollar. Un ultimo experimento que me llamo la atención es la orientación que le están dando al refinamiento, ya que también quieren orientarlo a objetivos y resultados claves (le dije que me gustaría aprender de los resultados que obtengan con ese experimento).
Ahora, un poco mas tranquilo, esta mañana me comentaba que quiere replicarlo a los demás equipos, teniendo en cuenta las lecciones aprendidas. Sin duda, otro gran paso que van a dar y que seguro les traerá grandes resultados.
Como podemos ver mi querido amigo lector, tres pequeños experimentos que les funcionaron (si duda se que tuvieron que haber realizado ajustes en el proceso) pero lo importante es que ahora sienten que están mas enfocados en los resultados que espera el cliente (a pesar de estar en tele trabajo), mas que en la cantidad de actividades que realizan las personas del equipo a diario o las horas en que esta conectadas a la plataforma o creando código. Lo cual me deja bastante contento por ellos.
En este punto solo te puedo invitar también a que experimenten, ya que estamos en un contexto que es nuevo para todos.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
