Herramientas - OKR Esquema

Esquema de identificación de OKR

Perspectiva de objetivos y resultados clave gracias a la segregación funcional

¿Estás aprendiendo sobre OKR?, ¿Buscas guía de referencia de como plantearlos?, ¿Te cuestionas sobre la experiencia?. Esta entrada es para ti, donde voy a compartir una "perspectiva de solución aplicada". 

Estamos viviendo momentos difíciles, que para muchos ha implicado el escenario de mayor incertidumbre al cual hayan estado expuestos. Esta percepción ha forzado a las organizaciones a replantear en muchos casos su enfoque estratégico, donde toma fuerza la formulación de iniciativas que soporten la continuidad operativa y la autogestión del usuario final, para lo que muchos llaman una nueva realidad. 

Este escenario, implica adoptar o afianzar un esquema de trabajo de mayor alineamiento entre los intereses estratégicos y la coordinación de capacidades tácticas y operativas, que además se deben desarrollar en un nuevo escenario que cuestiona las habilidades y capacidades personales e interpersonales en la práctica del trabajo remoto. 

Uno de los factores que mayor importancia ha tomado es trabajar por objetivos este es el contexto que me ha motivado a compartir esta entrada, no solo porque "puede representar un pilar en el mindset de las organización y el colaborador remoto", si no además que ayuda a las compañías a resolver el interrogante ¿cómo saber si vamos en la dirección correcta?. 

Este conocimiento está basado en mi experiencia, acompañando a mi más reciente cliente a diseñar su ecosistema de medición, observando y desarrollando patrones de comportamiento durante la definición de objetivos y resultados clave por los cuales se formulan y priorizan iniciativas a ser desarrolladas por equipos ágiles y las expectativas de valor y resultado que entregan mesas ágiles.     

Por lo anterior, he querido compartir esta entrada, con 2 intensiones:

1. Invitar a la reflexión: 

• La correcta mentalidad de medición y emplear OKRs promueve:
• Sentido de pertenencia del colaborar a distancia con la organización
• Mejor planteamiento en la gestión de la demanda
• No caer en conclusiones apresuradas
• Transparencia, inspección y adaptación
• Excelencia empresarial  

• En el ejercicio de establecer OKRs, es importante considerar:
• Cómo alinear las perspectivas de cada nivel de la estructura organizacional
• Cómo los beneficios esperados pueden representar y derivar OKRs por cada perspectiva  
• La única manera de hacerlo no es desde la estrategia a los equipos (top to bottom)
• La segregación funcional permite la formulación de OKR (bottom-up)

2. Compartir una herramienta: Una perspectiva de solución aplicada, donde la segregación funcional permite la formulación de OKRs (bottom-up) lo que posibilita el proceso de aprendizaje, generar la disciplina necesaria, promueve el involucramiento y la relación entre negocio y equipos de trabajo. Sin dejar de resaltar, que el proceso puede hacerse menos dependiente, complejo y costoso.

Para descargar el material de referencia, puedes acceder aquí

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach

https://www.linkedin.com/in/sergiopardo/

Twitter: @Sergio_E_Pardo

Correo: sepg.sergio.pardo@gmail.com

Herramientas - Discovery Product Canvas

Discovery Product Canvas

escuchar "no es lo que el cliente desea", es un problema que persiste

Discovery Product Canvas

Algo debe estar sucediendo, ¿Se están excluyendo los requerimientos no funcionales? durante las conversaciones iniciales de lanzamiento de iniciativas y proyectos, de la definición del Mínimo Producto Viable (MVP) o de la expectativa de una entrega de valor; y es que con cierta frecuencia pareciera así, que características como eficiencia, seguridad, usabilidad (por mencionar solo algunas) fuesen ignoradas sin considerar que son también atributos para determinar la definición de calidad de un producto desde una perspectiva de su operación como sistema. Al final, para remediar nos encontramos con nuevos requerimientos que implican más trabajo, mayor costo y menor percepción de calidad.

Entre los desafíos que implica la ejecución de un proyecto software, está comprobada la imprecisión al realizar el levantamiento de requerimientos. Una problemática que desde hace mucho y desde diferentes enfoques, se ha buscado resolver con promover prácticas que logren reducir la complejidad de definir las necesidades del usuario y la ambigüedad de su entendimiento; situación que pareciera ser aún más complicada si consideramos que además de determinar el comportamiento específico, debemos prestar atención a las restricciones, condiciones y criterios que impone el cliente sobre la operación del producto que necesita y espera recibir.  

Hay muchas maneras que podemos explorar para realizar un levantamiento de requerimientos. mi propuesta de este DISCOVERY PRODUCT CANVAS brinda una alternativa donde de forma gráfica y sencilla se pueda promover el desarrollo de conversaciones y recabar así de manera efectiva la información más relevante asociada a los requisitos no funcionales del producto a desarrollar o la solución sobre la cual se realizará implementación de nuevas funcionales.

Por lo anterior, he querido compartir esta entrada, con 2 intensiones: 

1. Invitar a la reflexión:

• Ignorar, posponer o subestimar los requerimientos no funcionales pone en riesgo la aceptación del producto o los cambios realizados a una solución.
• Remediar las definiciones no consideradas o el desarrollo no realizado en el momento oportuno, implica mayor trabajo y costo. 
• En la gestión asociada a los requerimientos, entonces te invito a considerar:


• ¿Se identifican estos atributos en etapas tempranas?
• ¿Se incluyen en la definición del Backlog?
• ¿Son discutidos en ceremonias de refinamiento y planificación para considerar la estimación?
• ¿Se definen precisos criterios de aceptación?
• ¿Son verificados previos a un despliegue y validados durante o después de la liberación?
  

2. Compartir una herramienta: Una perspectiva de solución, para promover una conversación sobre las características técnicas a las cuales se atribuye el desarrollo de un producto o solución de calidad, DISCOVERY PRODUCT CANVAS un medio para considerar los requerimientos no funcionales, como aspectos relevantes para generar una definición compartida de calidad de un producto.

Para descargar el Canvas, puedes acceder aquí

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach

https://www.linkedin.com/in/sergiopardo/

Twitter: @Sergio_E_Pardo

Correo: sepg.sergio.pardo@gmail.com

Herramientas - Entendiendo la segregación funcional

ENTENDIENDO LA SEGREGACIÓN FUNCIONAL

Particularidades para detallar
Épicas, Características e Historias de Usuario

Ficha informativa - Segregación funcional

(link al final para descarga)

¿Y tú cuantas veces has escuchado que la capa estratégica y táctica parecen no tener el mismo entendimiento de la visión de la compañía?, ¿qué entre áreas no logran conciliar frente a sus intereses particulares?, ¿qué las necesidades del usuario superan la capacidad del proyecto para ser abordadas?; son muchos los comentarios de este tipo, que terminan desvirtuando el valor de una iniciativa o el beneficio de un producto a ser construido.  

Ante esta problemática es importante considerar, que realizar la definición de alcance de un proyecto para entender la descomposición funcional de un producto, implica asegurar una efectiva especificación y además administración por capas de los artefactos asociados a una iniciativa (Épicas, Características e Historias de usuario), ardua labor de interpretar y alinear, cómo el contexto de los intereses estratégicos - "para el direccionamiento de la organización",  logran ser abordados desde las expectativas funcionales que son clave - "para así buscar la orientación sobre la situación deseada de los procesos de negocio", que conduzca a encontrar y justificar las funcionalidades específicas sobre un producto por las cuales vale la pena invertir - "definiendo la solución que mejor satisface las necesidades de un usuario".

hablar sobre Épicas, Características e Historias de usuario implica abordar cuando menos los siguientes 4 focos de información, que permiten desarrollar un ejercicio de segregación funcional de forma transversal a las capas de la organización, estos focos son:

1. La perspectiva: ¿Cuáles intereses se pretenden satisfacer? ¿Cómo varía cada punto de vista, según la capa organizacional que lo expone?
2. El asunto: ¿Bajo que contexto (intereses, expectativas, funcionalidades) se debe analizar la intensión o problemática expuesta?
3. El lenguaje: ¿Cómo desde un enfoque funcional y según el contexto (estratégico, negocio, producto) son resueltos los puntos 1 y 2?
4. El beneficio: ¿Cómo desarrollar opciones que generen en cada involucrado la percepción de valor?

Por lo anterior, he querido compartir esta entrada, con 2 intensiones: 

1. Invitar a la reflexión:

• Al existir diferentes perspectivas de quienes están involucrados con una iniciativa, en muchas ocasiones estaremos frente a la necesidad de realizar procesos de negociación, entonces te invito a considerar:
• ¿Tenemos claros que criterios son suficientemente objetivos e independientes a las voluntades para llegar a un acuerdo efectivo? 
• ¿Tenemos una visión clara de los intereses que determinan la posición de cada una de las partes?
• Un tema en la conversación adecuada y las personas adecuadas, para el tema en conversación

2. Compartir una herramienta: Una perspectiva de solución, para realizar la segregación funcional de una iniciativa en Épicas, Características e Historias de usuario (con el desarrollo de los 4 focos de información) enseñando una propuesta de 3 pasos y los cuestionamientos más relevantes para su desarrollo.

Para descargar la ficha, puedes acceder aquí

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach

https://www.linkedin.com/in/sergiopardo/

Twitter: @Sergio_E_Pardo

Correo: sepg.sergio.pardo@gmail.com

Herramientas - Táctica y Estrategia - Valor de Producto

Táctica y Estrategia para la administración del Backlog

¿Qué tanto valor aporta tú producto?

Si en esa etapa donde realizas el levantamiento de alcance de un proyecto, o en ese instante que trabajas la formulación de una iniciativa o durante la planificación del trabajo de una iteración,  haz asegurado un enfoque táctico de cómo abordar la iniciativa – “entonces sabes con claridad de la viabilidad de la solución y que esta conduce a los resultados esperados”, pero además, haz formulado la estrategia que logre los resultados esperados – “entonces tienes confianza que la solución si retribuye al objetivo propuesto”. Dicho esto podrás responder de manera objetiva ¿Qué tanto valor aportará tú producto?

Sabemos que la definición del Backlog, implica cerciorarse de la identificación y relación de componentes que representan la visión del producto, dado el contexto particular de las capas estratégica, táctica y operativa, que te permite tener la correcta identificación de ítem de Backlog que mejor solventan las hipótesis de oportunidad, la hipótesis de beneficio y la respectiva necesidad funcional que materializa dichas hipótesis.

Por lo anterior, he querido compartir esta entrada, con 2 intensiones: 

1. Invitar a la reflexión:

• ¿Qué tanto tiempo dedicas para plantear la táctica de cómo abordar una iniciativa? 
• ¿Te aseguras con suficiente detalle de analizar una estrategia que permita alinear las expectativas y el contexto estratégico, táctico y operativo? Desde una perspectiva de producto.

2. Compartir una herramienta: Una perspectiva de solución, de la identificación de elementos esenciales y su respectiva relación, para entregar soluciones que generen valor.

Considera que la percepción de valor de un producto estará determinada, por la correcta definición de una hipótesis de beneficio que mejor (aquí considera el Time to Market) satisface la hipótesis de oportunidad o necesidad de la organización frente a un objetivo estratégico; la visión compartida de los objetivos propuestos para la especificación y priorización de funcionalidades de valor y la especificación de criterios de aceptación que te guían para abordar la necesidad o la idea de producto de la forma correcta y entregar la solución requerida.  

Para descargar la ficha, puedes acceder aquí

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach

https://www.linkedin.com/in/sergiopardo/

Twitter: @Sergio_E_Pardo

Correo: sepg.sergio.pardo@gmail.com

Metáforas en el contexto de la agilidad - #2 El Espejo

#2 El ESPEJO

#2 – El Espejo, es la idealización del “Yo quiero verme”. Representa la VOLUNTAD de evaluar desde nuestra propia perspectiva, algo en nosotros mismos y sobre lo cual esperamos DECIDIR si la queremos ACEPTAR o MODIFICAR de acuerdo con "lo que vemos y queremos ver". La pregunta es la siguiente, cuando decido acercarme a El Espejo ¿qué tan consciente soy, que la decisión de hacerlo y el criterio con el cual resuelvo que postura tomar ante esa PROYECCIÓN, obedece a mi intención de valorar un resultado como mecanismo de descubrimiento?, la cuestión de estar frente a El Espejo es, que puedo aceptar el hecho lidiar con eso que no puedo cambiar dando por aceptado mi propio juicio de IMPOSIBILIDAD o en cambio, actuar para buscar en recursos una POSIBILIDAD que transforme eso que veo reflejado.

La proyección también comprende una relación con el sentido de RESPONSABILIDAD, “Soy el Scrum Master y sirvo como guía en la adopción del marco”, “Soy el Product Owner y represento los intereses del negocio”, “Soy integrante de un equipo al que aporto para ser auto gestionado y multifuncional”; son algunos ejemplos de posibles idealizaciones de quienes desempeñan dichos roles, que al estar frente a un Espejo tienen la posibilidad de reconocerse como tal y cuestionar, ¿qué tan cómodo me siento frente a mi proyección, la daría por aceptada o preferiría modificarla?, y para responderlo desde su perspectiva, puede basarse en criterios (valores, principios, objetivos, acciones, propósitos, otros.) para decidir si eso que ve, es tal como quiere y debe ser visto.

Metáforas en el contexto de la agilidad - #1 La Varita mágica

#1 - La Varita mágica

#1 - La Varita mágica, es la idealización de un recurso para conseguir un efecto de cambio. “Quiero un equipo auto gestionado”, “Quiero una historia de usuario INVEST”, “Quiero tener incrementos terminados al cierre de toda iteración”; La varita mágica se puede percibir de dos maneras opuestas y ligadas al principio de RESPONSABILIDAD. La primera, desde una posición de VICTIMA, ¿Dónde está la varita mágica?, donde la justificación está en factores ajenos que hacen que en consecuencia, un equipo no sea auto gestionado porque son las personas que conforman ese equipo las que no cooperan o no se hacen responsables, que una historia de usuario no cumpla con el acrónimo INVEST porque el Product Owner realiza una mala especificación, que no se logren incrementos terminados al cierre de toda iteración porque las dependencias del proceso de negocio impiden historias de usuario independientes. En los escenarios expuestos, el individuo que expone dichos deseos no se siente parte de la explicación de los hechos, ve entonces la necesidad de un recurso que transforme su realidad en eso que idealiza.      

La segunda desde una posición de RESPONSABLE, ¿Haré algo al respecto?, donde la causa está dada por acciones propias que infieren en el resultado, mi equipo no es auto gestionado porque no me había preocupado por enseñarlo, una historia de usuario no cumple con el acrónimo INVEST porque no había anticipado un refinamiento, no logramos incrementos terminados al cierre de toda iteración porque no refinamos las historias de usuario con la suficiente rigurosidad. Ahora, en los escenarios expuestos, el individuo que expone su punto de vista, se siente parte de la explicación de los hechos, dejando ver su VOLUNTAD, ve entonces la oportunidad de ser y actuar como instrumento para llevar a cabo dicho cambio. 

Herramientas - El tablero de refinamiento - RefinementBoard

EL TABLERO DE REFINAMIENTO

RefinementBoard

Ese momento: Antes de facilitar, una ceremonia de refinamiento

La idea: Enseñar al equipo Scrum, un retrato simbólico que refleje el resultado de su trabajo al cierre de la ceremonia, buscando platearles preguntas como ¿Qué historias están suficientemente clarificadas, para decir que están listas para la ceremonia de planificación?, ¿Qué historias aun no tienen refinamiento suficiente?, ¿Donde hace falta refinar?.  

Emplear ayudas visuales, son un medio que genera valor importante en la facilitación de ceremonias Scrum. En este caso les comparto lo que diseñé para la sesión de refinamiento, como instrumento para el equipo, donde al expresar "visualmente" la atención del Backlog, les dará claridad de haber seguido los pasos correctos y les muestre el panorama de las historias de usuario y la preparación requerida para afrontar la ceremonia de planificación.

Mi esencia: Me llevo a diseñar un tablero (similar al juego de Ludo o Parques) con tres objetivos específicos. El Primero, mostrar como la conversación entre el equipo SCRUM (Equipo de trabajo y Product Owner), debe permitir que cada historia de usuario antes ordenada por prioridad en el Backlog, siga un recorrido específico que le prepare para hacer parte de la agenda en la ceremonia de planificación. Un Segundo, servir como instrumento de conexión entre el equipo de trabajo, el cómo y el propósito de realizar el refinamiento de las historias de usuario. Por ultimo (al menos visto desde mi perspectiva) el tercer objetivo,  mostrar una fotografía que ejerza como disparador de acciones a tomar, mostrando el efecto que puede causar que, luego de un refinamiento las historias aún estén en camino y no sobre la posición central, "lista para planificación".

¿Cómo se usa?
El tablero no es una herramienta que refina una historia de usuario, tampoco implica dejar que, cada historia de usuario haga un recorrido a la suerte y que el azar lo resuelva.

El tablero, representa el estado o el viaje de las historias de usuario durante una ceremonia de refinamiento y sobre el cual prima como regla de oro, la previa priorización de cada historia de usuario, permitiendo hacer libres representaciones de la administración del backlog, bajo un esquema libre a definir y del cual se deriven hasta 4 posibles puntos de salida, según se desee explorar el recorrido de las historias durante el refinamiento, las variantes propuestas para su clasificación son:

1. Por prioridad de las historias: Express, Fecha fija, Estándar, Intangible.
2. Hasta para cuatro iteraciones 
3. Hasta para cuatro características
4. Hasta para cuatro sistema

Las historias de usuario, simbólicamente representan las fichas que recorren el tablero (para mayor claridad definir a criterio un código o nombre por cada historia y distinguir por color como es sugerido en el tablero) desde un Backlog de punto de partida, para producto de la conversación entre el equipo SCRUM, buscar lleguen la mayor cantidad al punto central.

El recorrido y desplazamiento, es basado en un juicio razonado que hace el equipo SCRUM, premisa de entendimiento y acuerdo por cada asunto (refiriéndome a los pasos que marcan el recorrido del tablero). Además, conduce a tomar decisiones de abortar la discusión de una historia cuando no se resuelven impedimentos o se está dedicando más tiempo del disponible sin conseguir resolver un asunto.

El equipo SCRUM, desempeña el rol de único participante, con lo cual pretendo decir que no se busca necesariamente dividirles para atender cada grupo de historias (lo cual pudiera no ser lo más adecuado al aislar el conocimiento y entendimiento, pero si el contexto es de historias a resolver por personas específicas vale la pena explorar) que tratan en una única conversación.
La dinámica, una a una son tomadas las historias de usuario para ser refinadas (llevarles del punto de partida al centro del tablero), que como antes mencione, es producto de una conversación que entre más efectiva se resuelva, más pronto llegará al punto central objetivo. Si uno de los pasos del recorrido tiene un asunto que no puede ser resuelto, se puede tomar nota (parking Lot) y pasar a la siguiente historia en prioridad, con esto se busca hacer de la ceremonia algo dinámico donde no se pierda tiempo en asuntos que en ese TimeBox no se podrán resolver o terminan afectando la agenda y revisión restante del Backlog.

El cierre,  corresponde a la finalización del TimeBox de la ceremonia, sobre el tablero, cada historia marcará el viaje que fue posible realizar y que tanto se logró refinar cada historia.

Resultado final, sobre el cual, el equipo SCRUM evaluará decisiones y buscará resolver acciones  pendientes sobre el estado de refinamiento del Backlog, aquí un argumento "visual" para resolver la pregunta ¿Qué tan preparados estamos para la ceremonia de planificación?. La dinámica deberá ser continuada en una posterior sesión, una vez resueltos los asuntos pendientes o en medida se van incorporando nuevas historias.

Para descargar el tablero, acceder al siguiente enlace

Si tienes problemas para la descarga, al final dejo mis datos de contacto.

Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.

Cordialmente,

Sergio Pardo - Agile Coach
https://www.linkedin.com/in/sergiopardo/
Twitter: @Sergio_E_Pardo
Correo: sepg.sergio.pardo@gmail.com