Frase: El mayor riesgo de todos sería no aceptar ninguno

"The biggest risk of all is not taking one." - Mellody Hubson

"El Mayor riesgo de todos sería no aceptar ningunto" - Mellody Hobson

La Transparencia, el Burndown Físico, el Kanban Fisico y el Efecto Hawthorne - Si me observas me comporto diferente

Tomado de 1

Hola a todos

Quisiera compartirles una conversación que constantemente sostengo con scrum masters, agile coaches, project leaders y diferentes de personas encargadas de equipos ágiles al momento de explicarles los beneficios de la transparencia y del sprint burndown chart físico y el kanban del sprint físico versus las herramientas digitales.

Y por qué no una herramienta

Siempre al abordar la forma de conocer el avance del equipo, hay una preferencia a sugerir Jira, o cualquier otra herramienta para tener registro de la finalización de ítemes de backlog (por lo general historias de usuario) y sus tareas durante un sprint.

Y la verdad eso no le veo lío, una herramienta digital me permite recolectar datos, saber estadísticas, concluir sobre comportamientos o problemas comunes.

Lo que observo es poco útil para facilitar la transparencia, pues siempre necesitaré hacer ingreso a una herramienta para saber el estado (tal vez me tome unos segundos, o alguien me pregunte algo y me distraiga o se me olvide), cosa muy distinta si tengo un burdown físico o un kanban físico al lado del equipo, siempre será facil ver y reconocer el estado sin preguntarle a nadie.

Tomado de 2 - Sugerencia de un Scrum Board 

Adicional que se genera el efecto Hawthorne, que es más efectivo el "RC - léase Erre Ce", es decir, la Respiración en el Cuello (4) o la pregunta frecuente:

"¿y cómo van?"

Pues el burndown y el kanban alcanzan a generar ese nivel de transparencia y compromiso.

Por lo tanto, es importante conocer el propósito de cada herramienta

• la información digital me proporciona estadísticos 
• y la información física transparencia 

es importante pues comprender esto y hacerle entender al equipo que no se está duplicando información, ambas tienen propósito distinto.

El Efecto Hawthorne

"El término fue creado en 1955 por Elton Mayo cuando analizaba antiguos experimentos realizados entre los años 1924 y 1932 en Hawthorne Works (una fábrica de la Western Electric a las afueras de Chicago). Los experimentos fueron coordinados por Elton Mayo, con la colaboración de Frist Roethlisberger, la Universidad de Harvard y el ingeniero de la Western Electric, William Dickson. En Hawthorne Works encargaron un estudio para comprobar la posibilidad de aumentar la productividad de sus trabajadores aumentando o disminuyendo las condiciones de iluminación ambiental. La productividad de los trabajadores pareció aumentar en el momento en el que se instauraron los cambios, y no sólo se produjo en los casos en los que los niveles de iluminación eran aumentados, sino también en aquellos casos en los que la iluminación se reducía. Al momento de terminar el estudio, los niveles volvieron a los niveles normales. La explicación sugerida fue que la mejora en la productividad no se debió a los cambios operados sobre los niveles de iluminación, sino al efecto motivador que supuso entre los obreros el saber que estaban siendo objeto de estudio." (2)

Por lo tanto podríamos concluir:

"si me observas me comporto diferente"

Los beneficios de la Gestión Visual

Adicional, contar con la información física nos permite obtener los beneficios de la gestión visual (5)

• El 90% de la información transmitida al cerebro es visual
• Las imágenes son procesadas 60.000 veces mas rápido que el texto
• La gestión visual mejora la habilidad de aprender/comprender por encima del 400%

Cerrando

Bajo todo lo anterior mi recomendación sigue siendo,

"A pesar de que tengas un sistema para registro de avance de tu sprint, genera un burndown chart físico y un kanban de manera de que exista transparencia y todos podamos ayudar y conocer el estado del sprint de manera fácil"

Ventajas

• No tengo que ingresar login y password
• Es público
• Es transparente
• Implica foco, coraje y compromiso tanto al interior del equipo como hacia la organización
• Todos sabrán si requerimos o se requiere ayudar
• Si alguien nos pregunta como va el sprint le señalamos el tablero y seguiremos en lo nuestro (obvio cordialmente)
• y por último (desde mi punto de vista) es más efectivo que el "Erre Ce"(4)

Sprint Burndown Chart Físico o en Papel

Sugerencias y Advertencias

• Si tu equipo Scrum desde su creación registró su avance en herramientas digitales, haz el experimento del burndown físico, saca tus conclusiones y compártelas.
• Esta práctica es muy útil en equipos coubicados, es decir todos en el mismo lugar
• Si tu equipo es remoto, esta práctica es difícil de implementar, mas no imposible.

Hasta acá este compartir

Saludos ágiles
Jorge Abad

Notas, Observaciones, Comentarios y Referencias

1. Photo on Visualhunt.com
2. https://agiledigest.com/agile-digest-tutorial-2/preparing-working-scrum-board-sprint-board-n/
3. https://es.wikipedia.org/wiki/Efecto_Hawthorne
4. RC - Erre Ce. Acrónimo que simboliza el micromanagement y su preguntas constantes y frecuentes como: ¿y cómo van? ¿les falta mucho? ¿cuánto les falta?, etc.
5. https://ernestoolivares.es/pensamos-90-en-imagenes/

Frase: Que sucede cuando nuestro trabajo depende del logro de objetivos

"People with targets and jobs dependent upon meeting them will probably meet the targets - even if they have to destroy the enterprise to do it." - W. Edwards Deming

"Las personas con objetivos y trabajos que dependen de cumplir estos objetivos seguramente los alcanzarán, aunque tengan que destruir a la empresa para ello" - W Edwards Deming

Una Conclusión: Como me midas me comporto

Hola a todos

Basados en esta frase de Deming (les recomiendo que busquen sus frases)

"Cambia la regla y usted obtendrá otro número." - W. Edwards Deming

Quisiera compartirles dos conclusiones a las que he llegado en este compartir con organizaciones y equipos

Cambia el número y obtendrás un nuevo comportamiento Cambia la métrica y obtendrás un nuevo comportamiento

o mejor

Como me midas me comporto

Tener esto presente me ha ayudado bastante para lograr alinear fuerzas y tener foco de los equipos y organizaciones en la generación de valor.

Hasta acá este corto compartir

Saludos Ágiles




Jorge Abad

Conferencia: Agile Marketing - Para Hacer Frente a los Cambios

Conferencia "Agile marketing para hacer frente a los cambios"

Todo el mundo busca ser ágil. Ahorrar tiempo, minimizar recursos y duplicar los resultados. Sin embargo, ¿es algo que nace innato o se puede entrenar?

En la mayoría de los casos la agilidad puede trabajarse. Y en marketing en concreto, existe una tendencia que aporta las claves para hacerlo: el Agile Marketing.

Día: miércoles 13 de noviembre de 2019

Hora: 9:30 a 11:00 a.m.

Lugar: auditorio OtroMundo

Conferencia: Agile Marketing - Para Hacer Frente a los Cambios from Jorge Hernán Abad Londoño

Algunas frases sobre planificar y los planes

Hola a todos

Las frases son muchas veces puntos de quiebre que nos hacen reflexionar, reafirmar o reformular nuestras creencias, paradigmas o prejuicios.

A continuación les comparto unas frases e ideas sobre planeación, planificación y planes.

“If you fail to plan, you are planning to fail!” Benjamin Franklin "Si fallas planeando,estan planeando fallar"  Benjamin Franklin

Otras versiones derivadas de la anterior:

"Al no planificar, se esta planeando fallar" "la gente no planea fracasar, fracasa por no planificar"

También tenemos estas más contundentes

"No battle plan survives contact with the enemy" "Ningún plan sobrevive al contacto con el enemigo"

"In preparing for battle I have always found that plans are useless, but planning is indispensable" “En la preparación para la batalla siempre he encontrado que los planes son inútiles, pero la planificación es indispensable” Dwigth D. Eisenhower

En marcos ágiles

"Valoramos más respuesta ante el cambio sobre seguir un plan" www.agilemanifesto.org

Y por experiencia propia en marcos ágiles

En marcos ágiles se hace planeación y se revisa el plan frecuentemente debido a que la planeación es adaptativa, muy diferente que en que en gestión tradicional que es más orientada a cumplir el plan que fue trazado desde inicio.

Saludos Ágiles

Jorge Abad

Cómo Promover la Autoorganización Empleando OKR

Imagen tomada de (2)

Hola a todos

Este es uno de esos post que tenía en mi deuda de publicación, pues llevo aproximadamente 2 años trabajando con OKR (1) pero no había sacado el tiempo para compartir sobre este comportamiento que he observado en las empresas, equipos y áreas al implantar esta técnica de alineación organizacional basado en objetivos y resultados.

Los OKR al trabajarlos organizacionalmente desde el CEO e ir propagándolos de forma progresiva sobre todas las áreas, portafolios, porgramas y equipos, no solo un generan una fuerte alineación estratégica, sino que logran que los equipos y áreas estén retados y animados con tener una meta común o diferentes metas que logran que como organización se generen resultados coordinados.

Tomada de (3)

Partiendo de la base de que un equipo es un grupo de personas con un objetivo común, y al este objetivo (OKR) convertirse en el reto trimestral, del cual ellos pueden monitorear y ser responsables de su progreso, genera el compromiso y el marco de decisión para avanzar en la dirección asiganda o propuesta por ellos mismos para área, portafolio, programa o equipo.


Para garantizar esa alineación y autoorganización recomiendo:

1. Los OKR de cada equipo deben ser públicos
2. Se debe fomentar el tener gráficas de progreso, tipo burnup o burndown que sean actualizadas cada dos semanas o máximo un mes
3. El equipo debe ser responsable de actualizar constantemente estas gráficas o delegar en alguien su actualización
4. El líder coordinador de los diferentes equipos o áreas debe promover la actualización de las gráficas de los OKR y realizar reuniones de mejora continua y remoción de impedimentos con miras a lograr el objetivo
5. En la medida que los equipos van haciéndose responsables de los OKR pueden autoasignárselos con la colaboración o validación del equipo de management.
6. Es importante que los equipos o áreas se coordinen con otros de manera que "garanticen" la colaboración coordinada en objetivos comunes o que los relacionen.

Bajo este esquema:

• Los líderes se liberan de la microgestión y de la operatividad
• Los equipos y áreas tienen un marco para toma de decisiones, por lo que no están preguntando constantemente si algo debe o no realizarse
• la organización deja de percibirse tanto como una construcción piramidal y en caos, sino se percibe como un conjunto de áreas y de equipos que colaboran con los demás para lograr grandes resultados

Hasta acá este compartir

Saludos ágiles

Jorge Abad

Notas, Comentarios, Aclaraciones y Referencias

1. Ver más sobre OKR en 
•  Un ejemplo de OKR  http://www.lecciones-aprendidas.info/2019/10/un-ejemplo-de-okr.html
• Un tip para escribir mejores OKR  http://www.lecciones-aprendidas.info/2019/10/un-tip-para-escribir-mejores-okr_12.html
2. Imagen tomada de: Designed by jcomp / Freepik
3. http://www.applitude.se/2011/05/self-organizing-teams-the-most-debated-agile-principle/

Sobre La Mejora Continua

La Mejora Continua no tiene como propósito ser cumplida por el proceso, esta ahí para hacernos inalcanzables.

Retrasar el realizar una mejora es reducir la probabilidad de supervivencia de la organización

Reflexión: La empatía y Jugar a Ganar

Una Reflexión


De las cosas que más me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR, incluso tu me lees o estás suscrito a este blog por que consideras que en alguna medida lo que publico te puede ayudar a ganar en tu contexto.

La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo, es simplemente otra). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más simpático y a generar mejores resultados, generar abundancia para todas las partes.


Saludos

Jorge Abad

Dos frases sobre Ágil, Valor y Alcance

Ágil es sobre Gestión de Valor, no sobre gestión de alcance.

En Ágil, el alcance es un medio para generar valor

De Colección: El pez rápido se come al pez lento

"En el nuevo mundo, no es el pez grande el que se come al pez pequeño, es el pez rápido el que se come al pez lento" Klaus Schwab

Presentación: Gestionando el Valor del Product Backlog

Gestionando el Valor del Product Backlog from Jorge Hernán Abad Londoño

De Colección: ¿Y tus retrospectivas cuándo van a ser de tipo Élite?

Tomado de (1)

Hola a todos

Uno de los informes que más ha tomado fuerza dentro del mundo Ágil y de DevOps es el elaborado por DORA (DevOps Research and Assessment): "Accelerate: State of DevOps", en la versión de 2018 "Accelerate: State of DevOpsStrategies for a New Economy 2018"(1)(clic aquí), en su capítulo "Influencing culture through learning" se encuentra este interesante texto

"We found that learning reviews help contribute to a climate for learning and also impact organizational culture. It is important to note that this is true when teams conduct them to learn from their mistakes and failures and then turn these into opportunities to improve how they work. In particular, teams that leverage findings from retrospectives to implement changes to tooling, processes, or procedures see the strongest impacts.

Our analysis found that elite performers are 1.5 times more likely to consistently hold retrospectives and use them to improve their work. When we asked respondents about their most recent retrospective, we see common themes around outages, failures, performance, and deployment."

Traducido

"Descubrimos que las revisiones de aprendizaje ayudan a contribuir a un clima para el aprendizaje y también impactan la cultura organizacional. Es importante tener en cuenta que esto es cierto cuando los equipos los conducen para aprender de sus errores y fracasos y luego los convierten en oportunidades para mejorar su funcionamiento. En particular, los equipos que aprovechan los hallazgos de las retrospectivas para implementar cambios en las herramientas, procesos o procedimientos ven los impactos más
 fuertes.

Nuestro análisis encontró que los Jugadores de Élite tienen 1.5 veces más probabilidades de tener retrospectivas consistentemente y usarlas para mejorar su trabajo. Cuando preguntamos a los encuestados acerca de su retrospectiva más reciente, vemos temas comunes sobre interrupciones, fallas, rendimiento y despliegue."

Luego comparten esta nube de temas que se discuten en los equipos élite en el mundo

Tomado de (1)

El listado de palabras en orden alfabético las encuentras al final del post(3).

Invitación

Una de las recomendaciones e invitaciones que hago a los Scrum Masters, Facilitadores, Líderes Ágiles y Equipos de Desarrollo que tienen cierta madurez haciendo Scrum o cualquier otro marco es:

"tarde o temprano tus retrospectivas tienen que hablar del tema técnico, o ¿vas a seguir perfeccionando la comunicación y el proceso en el sprint 20 y siguientes?, es urgente que veas el elefante en el cuarto si quieres llevar a tu equipo al alto desempeño"

No estoy afirmando que: "no sea necesario mejorar el proceso y el trabajo en equipo", si hay que mejorarlos se hace, pero el tema técnico es un tema obligatorio a tocar en las retrospectivas, y más si deseas alcanzar alto desempeño.

Scrum Master y Equipo evitando hablar del tema técnico

Basado en la sugerencia anterior he escrito y compartido post similares en el pasado:

• Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo (clic aquí)
• Presentación: Los puntos ciegos del Scrum Master (clic aquí)

Quedan entonces dos preguntas

• ¿de qué tema hablaron en la última retrospectiva de tu equipo?

• ¿y tus retrospectivas cuándo van a ser de tipo Élite?

Hasta acá este compartir.

Bienvenido el feedback

Saludos ágiles
Jorge Abad

Notas, Referencias, Aclaraciones y Comentarios

1. Accelerate: State of DevOps. Strategies for a New Economy 2018 - https://inthecloud.withgoogle.com/state-of-devops-18/dl-cd.html 
2. Accelerate: State of DevOps 2019- https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
3. El listado de palabras de la nube en orden alfabético es el siguiente:
   

able access analysis api app application architecture automated automation availability aws bad behavior breach broken bug bugs build business capacity cases cause caused certificate change changes client cloud cluster code collaboration communication communications config configuration container cpu crash critical customer customers data database deadlines defect defects degradation delivery dependencies deployed deployment

deployments design development devops disaster disruption dns documentation done dont downtime due efficiency email environment environments error errors external failed failing failure failures feature features feedback firewall functional functionality gaps hardware high human implementation improve improvement improvements incident incidents incomplete incorrect infrastructure integration issue issues kafka know knowledge

lack last learning lessons load loss major management manual many migration mismatch missed missing mistakes monitoring mortems needed network networking new none nothing one operational outage outages party patching performance planning poor post postmortems power problem problems procedures process processes prod product production project projects push quality recovery regression

regular related release releases requirements resource retrospective retrospectives review reviews rework root scope security server servers service services slow software sprint sql stability steps storage support system systems tasks team teams technical test testing tests time tool tools unexpected unplanned updates upgrade upgrades use user value vendor version went work working wrong

La Cultura Organizacional del Miedo

Una Cultura Organizacional basada en el miedo: No se permite fallar Se inhibe la innovación La mejora continua debe ser predecible y da poco lugar a experimentos No asume riesgos (observación: "El mayor riesgo es no arriesgarse") Es ególatra La iniciativa es vista como insubordinación Se pide permiso para avanzar, incluso para hacer lo correcto Es compatible con la planeación predictiva Es compatible con una mentalidad fija Es compatible con estructuras fuertemente jerárquicas Es compatible con el estilo de liderazgo "Comando y Control" Conduce a la inmovilidad

Una Reflexión sobre Hacer Ágil y Ser Ágil

La brecha entre Hacer Ágil y Ser Ágil nunca será cubierta con entrenamientos, se requiere del cambio en el Mindset de los líderes y de la Cultura de la Organización.

Unas Imágenes sobre Transformación Ágil, Transformación Digital y Transformación Cultural

Imagenes sobre transformacion agil, digital, cultural from Jorge Hernán Abad Londoño

Métricas para Product Owners

Hola a todos

Uno de roles que más cuesta entender dentro del mundo de Scrum y de los marcos ágiles es el de Product Owner (PO), pues su área de dominio se encuentra dentro del mundo del negocio y de la gestión del producto y no específicamente el mundo del desarrollo de software.

Traducido de (1)

Hoy quisiera compartir algunas métricas útiles durante:

• la construcción del producto y 
• el uso del producto, 

que ayudarán a la correcta gestión del producto por parte del PO, algunas de interés exclusivo por parte del mismo, otras serán compartidas con el equipo de desarrollo y otras áreas.

Durante la Construcción

Las métricas a continuación son tanto de interés del Product Owner como del Equipo que está construyendo el producto

• Desarrollo del producto
• Burndown Chart del Sprint
• BurnUp Release* (también puede ser útil el Bundown del Release pero sugiero el BurnUp, ustedes sacarán sus conclusiones)
• Velocidad del Equipo
• Control del LeadTime
• Flujo Acumulativo
• Deuda de Valor o Valor no Liberado (5)*
• Tiempo promedio entre liberaciones o releases
• Calidad del Producto
• Defectos encontrados en desarrollo
• Defectos encontrados después de cada liberación
• Defectos postergados para una versión futura
• Tickets de soporte por día o semana
• Deuda Técnica
• Cobertura de pruebas unitarias
• Cobertura de pruebas funcionales automatizadas

(*)Métricas de gestión exclusiva del PO

Durante el Uso

Estas métricas son de interés del PO, muy posiblemente otros equipos de trabajo en la organización le ayuden a obtener estas métricas, pero siempre será más útil no depender de otras áreas y que esta información haga parte del tablero de control del producto.

• Uso del Producto
• Tráfico
• Tasa de Retención
• Duración de la sesión
• Número de acciones del usuario por sesión
• Proporción de usuarios activos diarios / usuarios activos mensuales 
• Tráfico (fuentes de tráfico)
• Porcentaje de rebote (porcentaje de usuarios que encontraron el producto y se fueron)
• Tasa de Rotación (Clientes perdidos / Clientes totales)
• Número de sesiones por usuario
• Usuarios por función o por volúmenes de transacción (semanal, mensual)
• Desempeño del Producto en el Negocio
• Satisfacción del cliente (el NPS es una buena opción)
• Hipótesis validadas/Hipótesis planteadas
• Valor liberado (interna y externamente)
• Ingreso mensual
• ROI mensual
• Ingreso promedio del usuario (Average revenue per user -ARPU)
• Customer Lifetime Value (CLTV or LTV)
• Costo de adquisición del cliente (CAC)

Cerrando

No todas las métricas son necesarias, pero se puede ir creciendo orgánicamente sobre ellas en la medida que el producto y el entorno nos van proporcionando más información.


Hasta acá este compartir

Saludos ágiles
Jorge Abad

Notas, Comentarios, Aclaraciones y Referencias

1. Creating Success – A Guide to Product Manager KPIs.  https://www.toptal.com/product-managers/product-management/creating-success-a-guide-to-product-manager-kpis
2. Qué es el Product Owner en el marco de Scrum y cuáles son sus áreas de atención? - http://www.caminoagil.com/2019/08/13/product-onwer-cuatro-areas-atencion/
3. Five agile metrics you won't hate - https://www.atlassian.com/agile/project-management/metrics
4. 15 Key Product Management Metrics and KPIs - https://www.altexsoft.com/blog/business/15-key-product-management-metrics-and-kpis/
5. Scrum: Una herramienta para el PO, ¿cuanto costo he convertido en valor? - DEUDA DE VALOR - http://www.lecciones-aprendidas.info/2013/10/scrum-una-herramienta-para-el-po-cuanto.html

Un tip para escribir mejores OKR

Hola a todos

Hace unos días luego de un post de Nadia Zapata (1), Jose Luis Lee exponia un problema común al momento de escribir OKR (2) y que el compartía en su post (3), y es confundir un Key Result (kr) con una tarea, justo en esa misma dirección quisiera poner otro granito de arena, de algo que he compartido en otros escenarios y aporta (desde mi punto de vista) a evitar en e problema

un OKR mal planteado podría ser

Obj2. Investigar y mejorar la satisfacción del cliente (4) kr1. Superar el puntaje neto del promotor (NPS) en más de 8.0 kr2. Obtenga 1000 respuestas a la encuesta de satisfacción anual kr3. Realizar 50 entrevistas telefónicas con los mejores clientes kr4. Realizar 15 entrevistas telefónicas con clientes recientemente abandonados kr5. Presentar un plan de acción de 10 mejoras para el próximo trimestre.

Podríamos decir, que este problema se podría observar en el kr2, kr3 y kr4, pues se observan que son acciones pero tal como están redactadas no se conectan bien con el objetivo.

Una forma de evitar esto es

ver los kr como criterios de aceptación similar a como lo hacemos con las historias de usuario

De esta manera nos enfocamos en satisfacer el enunciado del objetivo (ver 5 y 6) y no caer en el error de identificar las tareas.

Basado en esta sugerencia el OKR quedaría

Obj2. Investigar y mejorar la satisfacción del cliente (4) kr1. Superar el puntaje neto del promotor (NPS) en más de 8.0 kr2. Obtenga 1000 respuestas a la encuesta de satisfacción anual y analizar y obtener cual es el pareto de las causas de insatisfacción kr3. Realizar 50 entrevistas telefónicas con los mejores clientes y obtener cual es el pareto de las causas de insatisfacción kr4. Realizar 15 entrevistas telefónicas con clientes recientemente abandonadosy obtener cual es el pareto de las causas de insatisfacción kr5. Presentar un plan de acción de 10 mejoras para el próximo trimestre.

Nota:

hasta acá este  compartir.


Saludos ágiles
Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Diapositivas de Nadia Zapata sobre OKR compartidas en el Ágiles 2019
2. Para más información de OKR ver http://www.lecciones-aprendidas.info/2019/10/un-ejemplo-de-okr.html
3. Me equivoqué con mis ejemplos de OKRs - de Jose Luis Lee
4. tomado de https://okrexamples.co/support-customer_service-okr-examples
5. http://www.lecciones-aprendidas.info/2013/06/la-magia-de-las-historias-de-usuario.html
6. Reconozco que este ejemplo es fácil entender por las personas de tecnología que están habituadas a trabajar con las historias de usuario, pero ayuda que al momento de facilitar o explicar el concepto, identificando claramente cuando un kr tiene sabor de tarea y cuando a sí tiene sabor a resultado.
7. Porque deberíamos intentar implementar OKRs en una Transformación Agile
8. http://www.lecciones-aprendidas.info/2013/11/como-es-una-historia-de-usuario-un.html

Un ejemplo de OKR

Hola a todos

Existe muy buena literatura y post sobre los OKR (Objectives and Key Results, por sus siglas en inglés).

Si aun no te has aproximado al concepto, es una técnica de alineación organizacional y de equipos desarrollada por Intel y consiste en establecer un objetivo trimestral cualitativo, para determinar si ese objetivo trimestral se cumple o se esta cumpliendo se establecen entre tres y cinco resultados clave que muestren que ese objetivo se esta logrando.

Por ejemplo un OKR, para un Área de Servicio al Cliente, para un trimestre determinado podría ser:

Obj2: Que nuestros usuarios se sientan atendidos como en primera clase

• kr1- Obtener una mejora del NPS del área en un 40%

• kr2- Que no quede un correo pendiente por atenderse más de 2 horas hábiles

• kr3- Reducir las quejas sobre el área en un 90%

Para más detalle sobre los okr sugiero leer:

• Este excelente resumen de Cristina Cortés @cristinacortes - Un vistazo general y algo más sobre el Modelo de OKRs (clic aquí)
• o el libro fuente -Mide lo que importa de John Doerr (link hacia amazon)

Saludos ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Otros post recomendados
• Me equivoqué con mis ejemplos de OKRs - de Jose Luis Lee
• Porque deberíamos intentar implementar OKRs en una Transformación Agile
• Las diapositivas de Nadia Zapata sobre OKR compartidas en el Ágiles 2019

El Manifiesto Ágil está pensado para todo el Ecosistema Software

Tomada de (1)

Hola a todos

Hace poco luego del Evento del Ágiles 2019  - http://agiles2019.agiles.org/ en Rosario Argentina, espectacular por cierto (felicitaciones a los organizadores, nos hizo falta más evento, más Rosario y más Argentina), reflexionaba sobre que aspectos contemplaba el "Manifiesto por el Desarrollo Ágil de Software", el cual es la base del movimiento ágil y los marcos ágiles que han transformado al mundo.

Luego de este evento surgieron críticas  sobre la cantidad de charlas que fueron técnicas y la cantidad de charlas que no lo fueron (cosa buena la crítica  nos cuestiona y nos hace evaluar otros puntos de vista), yo estuve allí y en efecto vi que se dieron charlas de un sabor y del otro, adicional que ninguna charla se prohíbe y existe total apertura que se hable sobre lo que es importante.

Se habló de todo lo que los asistentes quisieron hablar, adicionando que no todo hace parte de la agenda, hubo muchas conversaciones en las mesas, cenas, almuerzos, grupos de a pie, en fin.

Desde mi punto de vista se cumplió el lema “MUCHAS TRIBUS, UNA MISMA AGILIDAD”

Volvamos al Manifiesto

Pero veamos que dice el manifiesto y que pistas nos da para la comunidad ágil:

Tomado de: https://agilemanifesto.org/iso/es/manifesto.html

Tomado de: agilemanifesto.org/iso/es/principles.html

Tomado de: agilemanifesto.org/iso/es/principles.html

Algunas palabras claves agrupadas del manifiesto, son las siguientes

• Conceptos claves
• Desarrollo de software
• Conversación cara a cara
• Cambio
• Ventaja Competitiva
• Trabajamos juntos
• Entorno
• Ritmo constante
• Excelencia técnica
• Buen diseño
• Simplicidad

• Artefactos
• Procesos
• Procesos ágiles
• Herramientas
• Software funcionando
• Documentación (extensiva)
• Plan
• Software de valor
• Negociación contractual
• Requisitos
• Proyecto
• Arquitecturas
• Diseños

• Roles
• Terceros
• Cliente
• Responsables de negocio
• Desarrolladores
• Equipo de desarrollo
• Promotores
• Equipos auto-organizados

De forma similar, según las referencias de como se firmó el manifiesto ágil publicadas por Alistar Cockburn .https://twitter.com/TotherAlistair, (ver imágenes a continuación), se observa que:

• Los principios 1 al 4, están inclinados a los clientes
• Los principios 5 al 8, están inclinados a los gerentes
• Los principios 9 al 12, están inclinados al equipo

Tomado de (2)

Tomado de (3)

Por lo tanto, el manifiesto se encuentra pensado en todo el ecosistema en el cual esta inmerso el desarrollo de software, no excluye a uno o a otros, invita a que trabajemos juntos de forma continua y sostenible y generemos software de valor.

No existe una preferencia, por unos y otros, se requiere de la mejor voluntad de todos los involucrados para generar resultados grandiosos.

Clientes-Gerentes-Desarrolladores nos necesitamos entre sí, y aunque existan aproximaciones Clientes-Desarrollaores, la gran cantidad de productos y proyectos del mundo requieren de gerentes, promotores para garantizar que unos y otros interactuen de forma coordinada.

Cerrando

Bienvenidos los eventos de agilidad, bienvenidas todas las personas y roles del ecosistema software, bienvenida la excelencia técnica, bienvenidos los desarrolladores, promotores, lideres, scrum masters, agile coaches, y hablemos sobre todo lo que nos interesa, duele y queremos mover y promover en el ecosistema


Nos vemos en Uruguay Agiles2020

Saludos Ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Más fotos e información de referencia en https://siamchamnankit.co.th/history-some-pictures-and-pdfs-of-the-agile-manifesto-meeting-on-2001-a33c40bcc2b
2. https://www.facebook.com/photo.php?fbid=10156214339079035&set=a.496846469034&type=3&theater
3. https://www.facebook.com/photo.php?fbid=10156214339084035&set=a.496846469034&type=3&theater