jueves, noviembre 02, 2023
miércoles, noviembre 01, 2023
El lado oscuro de la agilidad - Frase
_
"El lado oscuro de la agilidad no es medir, es no mejorar" - Jorge Rafael Aristizabal - Agile Coach
_
lunes, octubre 30, 2023
domingo, octubre 22, 2023
Leído y Recomendado: To Build a Top Performing Team, Ask for 85% Effort / Para formar un equipo de alto rendimiento, pida un 85% de esfuerzo
Excelente Artículo: To Build a Top Performing Team, Ask for 85% Effort - https://hbr.org/2023/06/to-build-a-top-performing-team-ask-for-85-effort
A continuación el resumen realizado por Bard - https://g.co/bard/share/614d8956a19c:
Resumen del artículo "Para crear un equipo de alto rendimiento, pida un 85% de esfuerzo"
El artículo "Para crear un equipo de alto rendimiento, pida un 85% de esfuerzo" de Ben Horowitz, publicado en la revista Harvard Business Review en junio de 2023, sostiene que la clave para crear un equipo de alto rendimiento es pedir a los miembros del equipo que se esfuercen al 85%.
Horowitz argumenta que pedir a los miembros del equipo que se esfuercen al 100% todo el tiempo es contraproducente. Esto se debe a que el agotamiento y el estrés que resultan de operar al máximo nivel pueden conducir a errores, decisiones pobres y, en última instancia, a un rendimiento inferior.
En cambio, Horowitz sostiene que pedir a los miembros del equipo que se esfuercen al 85% permite a los individuos y al equipo en su conjunto rendir de manera óptima a largo plazo. Esto se debe a que deja espacio para la creatividad, el aprendizaje y la recuperación.
Horowitz ofrece varios consejos para ayudar a los líderes a implementar la regla del 85% en sus equipos:
- Establezca expectativas claras. Los miembros del equipo deben saber qué se espera de ellos en términos de rendimiento y esfuerzo.
- Cree un entorno de confianza y apoyo. Los miembros del equipo deben sentirse cómodos para admitir cuando necesitan ayuda o descanso.
- Facilite el aprendizaje y el crecimiento. Los miembros del equipo deben tener oportunidades para aprender y desarrollarse en sus roles.
- Horowitz concluye que la regla del 85% es una forma efectiva de crear equipos de alto rendimiento que sean productivos, innovadores y sostenibles.
Algunos ejemplos de cómo implementar la regla del 85%:
- En lugar de exigir que los miembros del equipo trabajen horas extras, ofrezca flexibilidad para que trabajen desde casa o en horarios flexibles.
- En lugar de esperar la perfección, acepte que habrá errores.
- En lugar de centrarse en la cantidad de trabajo realizado, concentre su atención en la calidad del trabajo.
La regla del 85% es un enfoque simple pero poderoso para crear equipos de alto rendimiento. Al pedir a los miembros del equipo que se esfuercen al 85%, los líderes pueden ayudar a sus equipos a rendir de manera óptima a largo plazo.
Muy relacionado con este que escribí hace un tiempo: Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización - http://www.lecciones-aprendidas.info/2020/12/de-coleccion-exigir-el-100-de-ocupacion.html
Saludos ágiles,
Jorge Abad.
martes, octubre 10, 2023
domingo, octubre 08, 2023
miércoles, octubre 04, 2023
ebook sobre Evolución Digital
Hola a todos, les comparto esta contribución que hice junto con otros referentes en latinoamérica.
¡Hola! Desde Castor Comunidad, te traemos un 🎁: nuestro nuevo ebook sobre
Evolución Digital en América Latina 📚.
👉 Descárgalo: castor.com.co/ebookevoluciondigital
sábado, septiembre 30, 2023
jueves, septiembre 07, 2023
miércoles, septiembre 06, 2023
domingo, septiembre 03, 2023
Diatriba: ¿Generan o no valor? He ahí el dilema de algunos Scrum Masters y Agile Coaches
Hola a todos,
La agilidad se ha convertido en un elemento fundamental en el mundo empresarial, y los Scrum Masters y Coaches desempeñan un papel crucial en su adopción y éxito. Sin embargo, existe un dilema importante que enfrentan estos profesionales en su búsqueda de transformar equipos y organizaciones hacia la agilidad: ¿Realmente están generando valor? En este artículo, exploraremos en detalle este dilema y analizaremos cómo la entrega temprana y continua de software con valor (primer principio del manifiesto ágil (1)) se convierte en el principio fundamental que debe guiar sus acciones.
El Dilema de la Entrega de Valor
En el contexto empresarial actual, las organizaciones buscan constantemente formas de innovar, mejorar la satisfacción del cliente, reducir riesgos y aumentar sus ingresos. Aquí es donde entran en juego los Scrum Masters y Coaches, cuyo papel es vital para impulsar la agilidad y lograr estos objetivos. Sin embargo, surge una pregunta fundamental: ¿están realmente generando valor en sus equipos y organizaciones? Mucho se dedican a acompañar a sus equipos y a su ecosistema, verificando si hacen o no bien las prácticas ágiles: el daily, la retrospectiva, el Scrum of Scrums; pero olvidan el responder a la necesidad del contexto empresaríal, la razón clave por la cual fueron contratados y fue para cumplir a cabalidad el manifiesto ágil con sus principios en los cuales la palabra software en total aparece cuatro veces:
- Valor 2: Software funcionando sobre documentación extensiva (2).
- Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor (1).
- Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible (1).
- Principio 7: El software funcionando es la medida principal de progreso (1).
Y me pregunto ¿Cuándo rayos olvidamos lo esencial?¿Que parte de todo lo anteior no ha sido clara? Mi afirmación, como lo digo en muchos espacios, no incluye negación, amo los equipos que se divierten, pero amo más los equipos que se divierten y entregan software valor, los primeros son candidatos a ser reemplazados, los segundos son indispensables.
La Agilidad más allá de las Metodologías
La agilidad no se trata simplemente de adoptar una metodología o marco de trabajo ágil, como Scrum, Kanban. LeSS, DAD o SAFe. Si bien estos marcos proporcionan un conjunto de prácticas valiosas, el objetivo principal de la agilidad va más allá. Se trata de proporcionar resultados tangibles que es la entrega de software con calidad y uno de los problemas más comunes es la percepción errónea de que el trabajo de Scrum Masters y Coaches se limita a la facilitación de reuniones, la creación de diapositivas, creación de "awareness" (lo decimos en inglés por que suena cool). Si bien estas actividades son importantes, no deberían ser el enfoque principal. La verdadera esencia de su papel es garantizar que los equipos estén entregando software, software de calidad y de valor.
No en vano, en mi organización, amigos empresarios y líderes de transformación me preguntan:
¿Jorge, no tenes o conoces a un(a) Scrum Master / Agile Caoch, bien bueno(a), orientado al delivery que me recomendés?
La frecuencia con la que me encuentro con esta situación es asombrosa (y suena ilógico que explícitamente lo digan ¿No creen? Pues ese es uno de los objetivos claves del rol). Los individuos que no priorizan el "delivery", lamentablemente, suelen no ser de gran utilidad. Sin un software funcional, de calidad y valioso, se convierten en un lastre costoso que impide que un equipo igualmente costoso logre un impacto significativo. Además, estos líderes bien intencionados tienden a centrarse en la organización de eventos que, desafortunadamente, no conducen a mejoras en el desempeño, ni a nivel de equipo ni organizacional.
El Rol de los Scrum Masters y Agile Coaches en la Entrega de Valor
Los Scrum Masters tienen la responsabilidad de transformar a los equipos en equipos de alto desempeño, ese es su principal entregable. Esto significa mucho más que solo estar presente en las retrospectivas o crear visualizaciones de burndown. Implica medir y demostrar cómo el equipo está generando valor, reduciendo riesgos y mejorando el rendimiento de la organización en su conjunto.
Los Agile Coaches, por otro lado, deben crear un ecosistema de alto rendimiento en toda la organización. Esto no se trata solo de conversaciones con los equipos. Implica medir el impacto de las prácticas ágiles en la organización y dejar un legado de mejora continua.
La agilidad debe generar dinero
es un imperativo inaplazable, donde el concepto de dinero o 'valor' abarca desde la mejora en el tiempo de comercialización (time to market), la reducción de costos y el aumento de ingresos hasta la satisfacción del cliente y la reducción de quejas (con la aspiración de que estas últimas desaparezcan), junto con una mayor participación en el mercado. Todo esto, se traduce en la creación de valor sólido para la organización, sin dejar de lado la importancia de cuidar a las personas, tanto a los equipos internos como a los externos, a todas las partes interesadas y, por supuesto, a los propios clientes.
Asumir esta responsabilidad se convierte en un deber fundamental, algo que destaco constantemente a quienes tengo el privilegio de acompañar. Quiero invitarte, mientras lees este artículo, a que reflexiones sobre tu papel. No puedes simplemente esperar que las cosas sucedan; eres un agente de cambio y tu función principal es dejar a los equipos y a su ecosistema en un estado mucho mejor del que encontraste. La única manera de saberlo es a través de la medición, ya que como bien se dice,
"Lo que no se mide no se mejora"
- atribuida a Lord Kelvin, otros la atribuyen Peter Drucker.
La Importancia de las Métricas en la Agilidad
La clave para superar este dilema radica en el uso adecuado de las métricas. Las métricas ágiles deben ir más allá de la simple medición de la velocidad de entrega. Deben abordar aspectos como la satisfacción del cliente, la calidad del software, la reducción de la deuda técnica y la mejora continua.
Las métricas efectivas permiten a los Scrum Masters y Agile Coaches demostrar cómo su trabajo está contribuyendo al éxito de la organización. Esto no solo proporciona una base para la toma de decisiones informadas, sino que también ayuda a ganar la confianza de las partes interesadas y líderes empresariales.
Algunas métricas sugeridas para Scrum Masters pueden ser:
- Say/Do del equipo (mide lo que se entrega versus lo que se comprometió, ejemplo, en el planning el equipo se compromete con 20 puntos y entrega 16, el Say/Do= 80%)
- Deuda técnica
- NPS (net promote score) del equipo
- NPS del Product Owner
- % de alineación o logro de los objetivos organizacionales que son impactados por el equipo (OKRs o KPIs si es del caso).
Algunas métricas sugeridas para Agile Coaches pueden ser:
- Say/Do del ecosistema de equipos acompañado
- Deuda técnica promedio del ecosistema de equipos acompañado
- NPS del ecosistema de equipos acompañado
- NPS de los Product Owners o Product Managers acompañados
- Impacto en la métricas de negocio del ecosistema de equipos (OKRs o KPIs según el caso)
El Compromiso con el Cambio y la Mejora Continua
Para resolver el dilema de la entrega de valor en la agilidad, los Scrum Masters y Agile Coaches deben comprometerse a hacer una diferencia real. Esto implica no solo seguir un marco ágil, sino centrarse en generar un impacto significativo en la organización. Deben trabajar incansablemente para mejorar la satisfacción del cliente, reducir riesgos, aumentar los ingresos y mantener a los equipos en la búsqueda constante de la excelencia, en lograr ese primer principio para satisfacer al cliente: la entrega tempra y continua de software de calidad y de valor.
Conclusión
La agilidad no se trata solo de seguir procesos y prácticas, sino de crear un cambio significativo en las organizaciones. Los Scrum Masters y Coaches juegan un papel vital en este viaje, y su éxito depende de su capacidad para entregar software de valor y demostrar su impacto. Al abrazar esta responsabilidad y medir constantemente su contribución, pueden ayudar a sus equipos y organizaciones a alcanzar el alto desempeño y la verdadera agilidad, de lo contrario son reemplazables o inútiles para lo que fueron contratados.
En última instancia, la agilidad se trata de generar impacto, y los Scrum Masters y Agile Coaches tienen el poder de hacerlo. La entrega temprana y continua de software con valor es el núcleo de su misión, y al abrazar este principio, pueden llevar a sus equipos y organizaciones hacia un futuro más ágil y exitoso.
Saludos Ágiles,
Jorge Abad.
Referencias
- Principios del Manifiesto Ágil.
- Manifiesto Ágil.
- Recomiendo ver el vide asociado a este artículo: #RespuestasAgiles ¿Generan o no valor? He ahí el dilema con algunos #AgileCoaches y #ScrumMasters
viernes, agosto 25, 2023
El Impacto Transformador de la Inteligencia Artificial Generativa en el Desarrollo de Productos Digitales
Product Discovery
La Visión
Elaborar la visión para un producto digital "Billetera virtual que
facilitan el pago electrónico con tarjetas o códigos QR, sin necesidad de
efectivo o plástico":
Crear una solución innovadora, segura y conveniente que permita a los usuarios realizar transacciones financieras desde sus dispositivos móviles, sin depender de medios físicos de pago. El producto ofrecerá una experiencia de usuario ágil, sencilla y personalizada, que se adapte a las necesidades y preferencias de cada cliente. El producto también contribuirá a la inclusión financiera, al facilitar el acceso a servicios bancarios y comerciales a personas que no cuentan con ellos. El producto aspira a convertirse en una referencia en el mercado de las billeteras virtuales, por su calidad, confiabilidad y satisfacción al cliente.
Business Model Canvas
Elaborar el Business Model Canvas para el producto digital "Billetera
virtual que facilitan el pago electrónico con tarjetas o códigos QR, sin
necesidad de efectivo o plástico"
- Segmento de clientes: personas que buscan una forma segura, rápida y conveniente de pagar por bienes y servicios, sin usar efectivo o tarjetas físicas.
- Propuesta de valor: ofrecer una billetera virtual que permite realizar pagos electrónicos con tarjetas o códigos QR, desde el celular o cualquier dispositivo conectado a internet.
- Canales: aplicación móvil, sitio web, redes sociales, publicidad online y offline, alianzas con comercios y bancos.
- Relación con los clientes: atención al cliente personalizada, soporte técnico, programa de fidelización, incentivos y promociones.
- Fuente de ingresos: comisión por transacción, venta de datos de consumo, publicidad en la plataforma, servicios adicionales (recargas, transferencias, etc.).
- Recursos clave: plataforma tecnológica, equipo humano, base de datos de clientes y comercios, seguridad informática, marca y reputación.
- Actividades clave: desarrollo y mantenimiento de la plataforma, gestión de las operaciones financieras, captación y retención de clientes y comercios, cumplimiento legal y regulatorio, innovación y mejora continua.
- Socios clave: proveedores de servicios financieros (bancos, emisores de tarjetas, procesadores de pagos), comercios afiliados, entidades gubernamentales, medios de comunicación.
- Estructura de costos: costos fijos (personal, infraestructura, licencias, etc.), costos variables (comisiones a socios, marketing, etc.), costos de oportunidad (inversión en I+D).
|
| Fuente: https://en.wikipedia.org/wiki/Business_Model_Canvas |
Las Diez Funcionalidades más Importantes
Identificar y priorizar 10 funcionalidades del producto digital
"Billetera virtual que facilitan el pago electrónico con tarjetas o
códigos QR, sin necesidad de efectivo o plástico"
- Permitir el registro y la verificación de los usuarios mediante el escaneo de documentos de identidad y la validación de datos biométricos.
- Integrar una pasarela de pago segura que acepte diversas fuentes de financiación, como tarjetas de crédito, débito, prepago o cuentas bancarias.
- Generar códigos QR únicos y dinámicos para cada transacción, que se puedan escanear con la cámara del dispositivo móvil o con un lector externo.
- Mostrar el historial de transacciones realizadas y recibidas, con detalles como fecha, hora, monto, concepto y destinatario o emisor.
- Enviar notificaciones instantáneas por correo electrónico o SMS cada vez que se realice o reciba un pago, con un resumen de la operación y un enlace para consultar más información.
- Ofrecer la posibilidad de crear y gestionar tarjetas virtuales, que se puedan usar para realizar compras en línea o en comercios físicos que acepten pagos sin contacto.
- Facilitar el envío y la solicitud de dinero entre contactos, ya sea por número de teléfono, correo electrónico o código QR.
- Implementar un sistema de recompensas y beneficios para los usuarios, que les permita acumular puntos, descuentos o cashback por cada pago realizado o recibido.
- Incorporar un chat de atención al cliente dentro de la aplicación, que resuelva las dudas y los problemas de los usuarios de forma rápida y eficiente.
- Añadir una opción de seguridad que permita bloquear o desbloquear la billetera virtual en caso de pérdida o robo del dispositivo móvil.
Product Development
Las Historias de Usuario Asociadas a una Épica (o Feature)
Identificar las historias de usuario de la funcionalidad "Generar códigos
QR únicos y dinámicos para cada transacción, que se puedan escanear con la
cámara del dispositivo móvil o con un lector externo":
- Como usuario, quiero generar un código QR único y dinámico para cada transacción que realice, para que pueda identificarla fácilmente y evitar fraudes.
- Como usuario, quiero escanear el código QR de una transacción con la cámara de mi dispositivo móvil, para que pueda acceder a los detalles de esta y confirmarla o rechazarla.
- Como usuario, quiero escanear el código QR de una transacción con un lector externo, para que pueda realizar el pago sin necesidad de usar mi dispositivo móvil.
- Como comerciante, quiero generar un código QR único y dinámico para cada transacción que reciba, para que pueda verificar la identidad del cliente y el monto a cobrar.
- Como comerciante, quiero mostrar el código QR de una transacción en una pantalla o en un papel, para que el cliente pueda escanearlo con su dispositivo móvil o con un lector externo.
- Como comerciante, quiero recibir una confirmación o un rechazo de la transacción una vez que el cliente escanee el código QR, para que pueda finalizar la venta o cancelarla.
Una Historia de Usuario con Criterios de Aceptación
Escribir la historia de usuario y los criterios de aceptación de " - Como
comerciante, quiero mostrar el código QR de una transacción en una
pantalla o en un papel, para que el cliente pueda escanearlo con su
dispositivo móvil o con un lector externo."
Historia de usuario: Como comerciante, quiero mostrar el código QR de una transacción en una pantalla o en un papel, para que el cliente pueda escanearlo con su dispositivo móvil o con un lector externo.
Criterios de aceptación:
- El sistema debe generar un código QR único para cada transacción, que contenga la información necesaria para validar el pago.
- El sistema debe mostrar el código QR en una pantalla o imprimirlo en un papel, según la preferencia del comerciante.
- El sistema debe permitir al cliente escanear el código QR con su dispositivo móvil o con un lector externo, y redirigirlo a una página de confirmación del pago.
- El sistema debe notificar al comerciante cuando el pago se haya realizado correctamente.
Una Historia de Usuario con Criterios de Aceptación escritos usando BDD
Escribir la historia de usuario y criterios de aceptación usando behavior
driven development de " - Como comerciante, quiero mostrar el código QR de
una transacción en una pantalla o en un papel, para que el cliente pueda
escanearlo con su dispositivo móvil o con un lector externo.":
Como comerciante, quiero mostrar el código QR de una transacción en una pantalla o en un papel, para que el cliente pueda escanearlo con su dispositivo móvil o con un lector externo.
Criterios de aceptación:
Dado que el comerciante ha iniciado una transacción,cuando ingresa el monto y confirma el pago,entonces se genera y muestra un código QR en la pantalla o se imprime en un papel.Dado que el cliente tiene un dispositivo móvil o un lector externo,cuando escanea el código QR de la transacción,entonces se verifica y procesa el pago.Dado que el pago se ha procesado correctamente,cuando el comerciante y el cliente reciben la confirmación,entonces se finaliza la transacción.
Casos de Prueba de una Historia de Usuario
Escribir 10 casos de prueba para la historia de usuario anterior:
-
- Caso de prueba 1: El comerciante inicia una transacción, ingresa el monto de 100 pesos y confirma el pago. Se genera y muestra un código QR en la pantalla. El cliente escanea el código QR con su dispositivo móvil y se verifica y procesa el pago. El comerciante y el cliente reciben la confirmación y se finaliza la transacción.
- Caso de prueba 2: El comerciante inicia una transacción, ingresa el monto de 50 pesos y confirma el pago. Se genera y muestra un código QR en la pantalla. El cliente escanea el código QR con un lector externo y se verifica y procesa el pago. El comerciante y el cliente reciben la confirmación y se finaliza la transacción.
- Caso de prueba 3: El comerciante inicia una transacción, ingresa el monto de 200 pesos y confirma el pago. Se genera y muestra un código QR en la pantalla. El cliente intenta escanear el código QR con su dispositivo móvil, pero el código QR es ilegible o inválido. Se muestra un mensaje de error y se cancela la transacción.
- Caso de prueba 4: El comerciante inicia una transacción, ingresa el monto de 150 pesos y confirma el pago. Se genera y muestra un código QR en la pantalla. El cliente escanea el código QR con su dispositivo móvil, pero el pago falla por falta de fondos o por algún otro motivo. Se muestra un mensaje de error y se cancela la transacción.
- Caso de prueba 5: El comerciante inicia una transacción, ingresa el monto de 300 pesos y confirma el pago. Se genera y imprime un código QR en un papel. El cliente escanea el código QR con su dispositivo móvil o con un lector externo y se verifica y procesa el pago. El comerciante y el cliente reciben la confirmación y se finaliza la transacción.
- Caso de prueba 6: El comerciante inicia una transacción, ingresa el monto de 250 pesos y confirma el pago. Se genera y imprime un código QR en un papel. El cliente intenta escanear el código QR con su dispositivo móvil o con un lector externo, pero el código QR es ilegible o inválido. Se muestra un mensaje de error y se cancela la transacción.
- Caso de prueba 7: El comerciante inicia una transacción, ingresa el monto de 400 pesos y confirma el pago. Se genera y imprime un código QR en un papel. El cliente escanea el código QR con su dispositivo móvil o con un lector externo, pero el pago falla por falta de fondos o por algún otro motivo. Se muestra un mensaje de error y se cancela la transacción.
- Caso de prueba 8: El comerciante inicia una transacción, pero no ingresa ningún monto o ingresa un monto inválido. No se genera ni se muestra ningún código QR en la pantalla ni se imprime en un papel. Se muestra un mensaje de error y se cancela la transacción.
- Caso de prueba 9: El comerciante inicia una transacción, ingresa el monto de 500 pesos y confirma el pago. Se genera y muestra un código QR en la pantalla o se imprime en un papel, pero antes de que el cliente pueda escanearlo, se pierde la conexión a internet o se apaga el sistema. Se muestra un mensaje de error y se cancela la transacción.
- Caso de prueba 10: El comerciante inicia una transacción, ingresa el monto de 350 pesos y confirma el pago. Se genera y muestra un código QR en la pantalla o se imprime en un papel. El cliente escanea el código QR con su dispositivo móvil o con un lector externo, pero antes de que se pueda verificar o procesar el pago, se pierde la conexión a internet o se apaga el sistema. Se muestra un mensaje de error y se cancela la transacción.
martes, agosto 22, 2023
lunes, agosto 14, 2023
lunes, agosto 07, 2023
lunes, julio 24, 2023
¿Y qué pasó con la Definition of Ready y la Definition of Done?¿Pasaron de moda?
Hola a todos,
Hace rato no escribía, lo cierto es que sigo avanzando en diferentes proyectos con mi gran amigo Lucho Salazar, pero si algunos me siguen asiduamente, saben que continúo compartiendo notas, podcast y videos; pues este aprender y compartir es en doble vía, y siento un deber trabajar con la comunidad ágil para crecer y progresar juntos.
Bueno, quiero compartirles una disfunción que he visto emerger en muchos equipos Scrum y organizaciones ágiles, que uno supondría que está mitigada, pues en ellas se insiste insistentemente en los entrenamientos de Scrum y en los diferentes marcos de escalamiento que lo usan (y que también existe en el mundo Kanban (1)), y que por lo que estoy observando esta siendo ignorada o minimizada su importancia por los Scrum Masters, Facilitadores, Agile Coaches; y como lo "spoilié" con el título del artículo es: el no cumplir con la Definition of Ready (DoR) y la Definition of Done (DoD).
Continuamente en diversos escenarios, Product Owners y gerentes de área se me quejan de que sus equipos scrum no están funcionando, y para entender el contexto hago unas preguntas de rigor, como las del litmus test de la agilidad, y adicional incluyo estas cinco (entre muchas otras según me va llevando la conversación):
- ¿Tienen Definition of Ready?
- ¿La están cumpliendo?
- ¿Tienen Definition of Done?
- ¿La están cumpliendo?
- ¿Y cada cuánto actualizan la Definition of Done?
Siendo estas últimas en las que estoy encontrando mayor reincidencia, y casi todas teniendo como causa raiz la presión del negocio por entregar a como de lugar. Como se pueden imaginar, en estos escenarios de falla y queja, si se incumple en cualquiera de las primeras cuatro preguntas se esta incurriendo en errores de calidad que terminan pagando el producto, el cliente, el equipo y toda la organización, generando retrasos y reprocesos e inconformidad en todos los involucrados en el proceso Scrum; y si se incurre en la última pregunta, se tiene un equipo que no mejora sus estándares con el tiempo y en consecuencia se está desactualizando.
Consecuencias de no tener o no cumplir la Definition of Ready
En Scrum, "Definition of Ready" (Definición de Listo) (2) es un criterio utilizado para determinar si un elemento del Backlog del Producto está en un estado adecuado para ser planificado y abordado en una próxima iteración o Sprint. Aunque ni en tradicional, ni en cascada, ni en ágil, Scrum o Kanban, etc., se recomienda trabajar con requisitos inestables o no definidos, pues¡No tiene sentido! ¡Es desperdicio de comienzo a fin!, veamos algunas consecuencias de no contar ni cumplir con la DoR
"Caminar sobre el agua y desarrollar software basado en especificaciones es fácil si ambos están congelados" - Edward V. Berard
- Entregas inconsistentes: El equipo puede encontrarse trabajando en elementos que no están bien preparados, lo que lleva a resultados inconsistentes y posiblemente de baja calidad.
- Ambigüedad en las expectativas: Si los elementos del Backlog del Producto no están claramente definidos antes de comenzar el trabajo, puede haber confusión en cuanto a las expectativas y los criterios de finalización, lo que puede llevar a malentendidos y retrabajos.
- Mayor tiempo de Sprint Planning: La falta de definición puede conducir a discusiones prolongadas durante la planificación del Sprint, ya que el equipo debe aclarar los requisitos y detalles de cada elemento.
- Riesgo de incluir elementos poco relevantes: Si los elementos no están bien definidos, existe la posibilidad de que se planifiquen tareas que no aporten un valor significativo al producto final.
- Acumulación de elementos no terminados: Si el equipo acepta elementos no preparados en el Sprint, existe una mayor probabilidad de que no puedan completarlos dentro del marco de tiempo del Sprint, lo que resulta en elementos no terminados y afecta la capacidad de entrega. Es frecuente ver que el Product Owner resuelve las inconsistencias o dudas durante el sprint y el equipo al estimarlas o trabajar desbordan la capacidad del equipo impactando otros elementos del sprint backlog o incluso el objetivo del sprint..
- Desperdicio de tiempo y esfuerzo: Trabajar en elementos no preparados puede dar lugar a un desperdicio de tiempo y esfuerzo, ya que el equipo podría descubrir problemas o requisitos faltantes durante el Sprint.
- Falta de transparencia: Una Definition of Ready clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado del proyecto.
- Frustración y desmotivación del equipo: Si el equipo se ve constantemente lidiando con elementos mal definidos, esto puede llevar a la frustración y la desmotivación, lo que afecta negativamente la moral y la productividad.
- Frustración de los interesados: Se genera un producto de baja calidad y no se tienen claras las reglas de interacción con el equipo, generando expectativas que no son cumplidas frecuentemente.
Para evitar estas consecuencias, se sugiere:
- que el equipo Scrum y los interesados trabajen juntos para establecer una Definition of Ready
- cumplir estrictamente la DoR y actualizarla cuando se observe pertinente.
- que los próximos elementos candidatos a ser sumados al sprint backlog se encuentren correctamente refinados y definidos.
- se realicen sesiones de refinamiento previas a la sprint planning.
- las dependencias con otros componentes sean resueltas y construidas al menos con un sprint de antelación.
- se trabajen en ítems de backlog pequeños (historias de usuario), pues esto permite la fácil identificación de áreas, escenarios, o criterios de aceptación, evitando áreas grises o no resueltas en el sprint planning.
- no incluir historias por presión del negocio que no complan la DoR.
Consecuencias de no tener o no cumplir con la Definition of Done
La "Definición de Terminado" (3)(4) es un conjunto de criterios acordados que establece cuándo un incremento del producto se considera terminado y listo para ser entregado. Algunas de las consecuencias de no tener o no cumplir con esta definición son las siguientes:
"Cuando algo esta DONE, no me tengo que volver a preocupar de ello" - Alan Cyment
- Entregas de baja calidad: Si el equipo no cumple con los criterios de la "Definición de Terminado", es probable que los incrementos entregados no cumplan con los estándares de calidad requeridos. Esto puede llevar a problemas de funcionamiento, errores y dificultades para el usuario final.
- Acumulación de deuda técnica (6): Si se permite que el equipo entregue incrementos que no están completamente terminados, es probable que se acumule deuda técnica. La deuda técnica representa trabajo adicional que se requerirá más adelante para resolver problemas y mejorar la calidad del producto.
- Retraso en la entrega: La falta de cumplimiento con la "Definición de Terminado" puede llevar a retrasos en la entrega de incrementos completos y funcionales. Esto puede afectar la confianza del cliente y la capacidad del equipo para cumplir con los plazos establecidos.
- Dificultades en la planificación: Si el equipo no puede estimar con precisión el tiempo necesario para completar los incrementos debido a la falta de una "Definición de Terminado" clara, la planificación de futuros Sprints puede volverse complicada y menos confiable.
- Dificultades en la revisión del Sprint: Durante la revisión del Sprint, los incrementos se evalúan para determinar si cumplen con los criterios de la "Definición de Terminado". Si no se cumple, se pueden generar discusiones y conflictos innecesarios entre los interesados.
- Falta de transparencia: Una "Definición de Terminado" clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado real del producto.
- Desmotivación del equipo: Si el equipo se ve obligado a entregar incrementos que no cumplen con los estándares de calidad, es probable que se sientan desmotivados y frustrados por no poder ofrecer un trabajo de alto nivel.
- Problemas de integración: Incrementos que no cumplen con la "Definición de Terminado" pueden generar problemas de integración con otros componentes del sistema, lo que dificulta el progreso general del desarrollo.
- Desconfianza de los interesados en el equipo y en el proceso Scrum: Al observar que el equipo Scrum no cumple entregando con calidad, se pierde confianza en el equipo y el proceso Scrum.
Para evitar estas consecuencias, se sugiere:
- que el equipo Scrum adopte y cumpla la DoD de la organización.
- en su defecto, el equipo Scrum la defina y todos responsablemente la promuevan, comenzando por el Scrum Master como agente de cambio.
- no contar como Done, algo que no fue finalizado.
- usar la retrospectiva como fuente de indagación para comprender por qué no se cumplió la DoD.
- por presión de agenda o del negocio, evitar a toda costa declarar como DONE algo que no lo es.
Consecuencias de no actualizar la Definition of Done
"Entre más maduro y DevOps sea un equipo, más robusta es su Definition of Done" - Jorge Abad
No revisar y mejorar con cierta frecuencia la "Definición de Terminado" como lo sugiere la guía de Scrum puede tener varias consecuencias negativas que afectan al equipo de desarrollo y al producto final a lo largo del tiempo. Aquí están algunas de las consecuencias de no realizar revisiones y mejoras periódicas:
- Estancamiento de la calidad: Si la DoD no se revisa y actualiza regularmente, es probable que la calidad del producto se estanque. Los criterios pueden volverse obsoletos o insuficientes para mantener el nivel de calidad deseado.
- Deuda técnica: La falta de revisión puede conducir a la acumulación gradual de deuda técnica. A medida que el producto se desarrolla sin mejoras en la DoD, es más probable que se tomen atajos y se sacrifique la calidad para cumplir con los plazos, lo que crea deuda técnica que debe abordarse más adelante.
- Mayor incidencia de errores: Si la DoD no se ajusta a las necesidades cambiantes del producto o del cliente, es más probable que se produzcan errores y problemas que afecten negativamente la experiencia del usuario.
- Dificultades en la entrega: Si la DoD no se actualiza para reflejar las nuevas expectativas o requisitos del cliente, el equipo puede tener dificultades para cumplir con las demandas cambiantes del mercado.
- Conflictos con los interesados: Si la DoD no se revisa en función del feedback de los interesados, puede haber conflictos y desacuerdos sobre el nivel de calidad aceptable para el producto.
- Pérdida de transparencia: Si la DoD no se revisa y comunica de manera efectiva, puede haber una falta de transparencia en el proceso de desarrollo, lo que dificulta que los interesados comprendan el estado real del producto.
- Desmotivación del equipo: La falta de revisión y mejora puede llevar a que el equipo se sienta frustrado y desmotivado, ya que pueden enfrentar problemas recurrentes y dificultades para cumplir con los objetivos de calidad.
- Estancamiento en la mejora continua: La revisión y mejora de la DoD son esenciales para la mejora continua del equipo. Sin esta práctica, el equipo puede dejar de buscar oportunidades para optimizar su proceso de desarrollo y entregar un producto de mayor calidad.
- Trabajar en un producto obsoleto: Sin el ejercicio de revisión frecuente de la DoD, se puede incurrir en trabajar en un producto que se va desactualizando y quedando obsoleto con el tiempo.
Para evitar estas consecuencias, se sugiere:
- que el equipo Scrum revise con cierta cadencia su DoD, al menos una vez cada trimestre en una retrospectiva.
- revisar el entorno del mercado (realizar vigilancia tecnológica) para identificar mejoras al producto, prácticas o proceso que deban ser incluidas en la DoD.
- identificar qué prácticas de calidad se encuentran al final del proceso de desarrollo (por ejemplo: prebas especializadas previos a la salida a producción) que puedan ser includias tempranamente (shift-left) para mejorar la velocidaddel equipo y del producto.
Cerrando
Scrum tiene dos puntos de control de calidad clave, que son: la entrada de lo que se quiere construir y la salida o increments; el compromiso del equipo Scrum en hacer cumplir la DoR y la DoD, garantizan la calidad del producto, menos errores, mayor velocidad, más transparencia, menos deuda técnica, mejor satisfacción de todos los involucrados, planeaciones y ejecuciones más efectivas, en consecuencia un mejor Scrum y una entrega de calidad de impacta positivamente la generación de valor.
Deteriorar el cumplimiento de la DoR y la DoD generará, como lo vimos, desconfianza en el producto, el equipo y el proceso; consecuentemente deteriora el entorno de agilidad que se quiere construir.
"Agilidad sin calidad, son incrementos de desperdicio entregados en ciclos cortos" - Jorge Abad
Volver a lo básico e insitir sobre lo esencial, garantizará una mejor agilidad y desempeño de los equipos construyendo productos exitosos.
Saludos ágiles.
Jorge Abad.
Referencias, notas, aclaraciones y comentarios
- En el mundo Kanban, la Definition of Ready y la Definition of Done conocen como Politicas y consiste en que una tarjeta no mueve hacia la derecha (o en la dirección del flujo) si las políticas no se cumplen.
- Definition of ready (scrumbook) - https://scrumbook.org/value-stream/product-backlog/definition-of-ready.html
- Definition of done (scrumbook) - https://scrumbook.org/value-stream/definition-of-done.html
- Definition of done (Scrum guide)- https://scrumguides.org/scrum-guide.html.
- Deuda Técnica - http://www.lecciones-aprendidas.info/search/label/deuda%20t%C3%A9cnica
- Algunos textos acá presentados fueron curados utilizando IA.
viernes, julio 07, 2023
Lo complejo vende más
“La simplicidad es una gran virtud, pero lograrla requiere trabajo duro y educación para apreciarla. Y para hacer las cosas peor: la complejidad vende mejor”.
- Edsger W. Dijkstra
__
sábado, junio 24, 2023
Frases sobre las métricas
Hola a todos, les comparto algunas ideas sobre las métricas:
“Las métricas moldean la organización”.
- Jorge Abad
__
“Las métricas moldean la organización y en consecuencia la cultura”.
- Jorge Abad
__
“Las métricas reflejan la organización”.
- Jorge Abad
__
“Las métricas reflejan al líder”.
- Jorge Abad
__
“Las métricas reflejan lo que inquieta a los líderes”.
- Jorge Abad
__
“Como me midas me comporto”.
- Jorge Abad
__
sábado, junio 17, 2023
Frase de Juan Andrés Ochoa al hablar sobre OKR
En una conversación que tuve con min gran amigo y empresario Juan Andrés Ochoa, al hablar sobre los OKR y su proliferación, uso indiscriminado y especializaciones "sobredimensionadas" (desde nuestro punto de vista) como el rol de "OKR Coach", entre muchas otras que proliferan en estos días respecto a este tema, Juan afirmó algo que me gustó mucho y que procedo a dejar registro:
“Las organizaciones se quedan mirando el juguete (OKR) perdiendo de vista el juego (la alineación y generación de valor)”. -Juan Andrés Ochoa
Y el llamado a la reflexion que trae esta frase es, que no aplica únicamente para OKR, sino para muchas otras cosas y modas en el mundo empresarial, sucediendo que nos obsesionamos con las herramientas, las técnicas y los métodos, perdiendo de vista el propósito de las mismas y lo que vienen a traernos,
_
lunes, junio 05, 2023
Frase Cambio Cultural y Cambio Organizacional - Yo soy yo y mis circunstancias - José Ortega y Gasset
Hola a todos,
Como muchos de ustedes saben, este blog constituye también mis notas para compartir y revisar. Quiero en este artículo traer un collage sobre esta frase Ortega y Gasset y el comportamiento organizacional.
--o--
Alguna vez hablando con un gran amigo, sicólogo y empresario de la seguridad en el trabajo: Hugo Londoño, me exponía una frase con lo que quedé resonando y que él aplicaba en los procesos de cambio organizacional
“Yo soy yo y mis circunstancias”.
- José Ortega y Gasset
Y me decía (más o menos):
- Sí cambiamos las circunstancias, influenciaremos la cultura y los comportamientos de los colaboradores.
- Las circunstancias son: las métricas, los entornos físicos, los mensajes; en los que esta embebido el colaborador y estos le generan comportamiento y a la par cultura.
----
Luego, en una conversación de Agiles Colombia, aprovechando ChatGPT, generé el
siguiente análisis de la frase para compartirla con el grupo.
https://chat.openai.com/share/75ca8da8-2f62-4818-8839-1d3910275281
https://chat.openai.com/share/75ca8da8-2f62-4818-8839-1d3910275281
"Yo soy yo y mis circunstancias" es una famosa frase acuñada por el filósofo y
ensayista español José Ortega y Gasset. Esta cita resume su concepción
filosófica del ser humano y su relación con el mundo que lo rodea. Para
entender mejor su significado, podemos analizarlo desde diferentes
perspectivas:
- Individualidad: Ortega y Gasset enfatiza la importancia de la individualidad en la comprensión de la existencia humana. "Yo soy yo" se refiere a la identidad personal, a la conciencia de uno mismo como ser único e irrepetible. Cada individuo tiene una perspectiva única y una forma de experimentar y comprender el mundo.
- Relación con el entorno: El segundo aspecto de la frase, "y mis circunstancias", subraya la idea de que la existencia humana está intrínsecamente ligada a las condiciones y situaciones en las que uno se encuentra. Las circunstancias incluyen el entorno físico, social, cultural, histórico y político en el que vive una persona. Ortega y Gasset sostiene que la identidad y el ser de una persona no pueden entenderse por completo sin tener en cuenta estas circunstancias.
- Influencia recíproca: La frase también implica una relación dinámica entre el "yo" y las "circunstancias". No se trata de una simple suma o yuxtaposición, sino de una interacción constante. El individuo es afectado por su entorno, pero también tiene la capacidad de influir y transformar sus circunstancias. La identidad personal y las circunstancias se influyen mutuamente y se moldean en un proceso de constante retroalimentación.
- Libertad y responsabilidad: Este enfoque de Ortega y Gasset destaca la importancia de la libertad individual y la responsabilidad personal. Aunque las circunstancias pueden imponer limitaciones y condicionar nuestras vidas, también tenemos la capacidad de decidir cómo enfrentarlas y responder a ellas. La libertad implica una toma de conciencia de nuestras circunstancias y la capacidad de actuar de manera autónoma.
En resumen, "Yo soy yo y mis circunstancias" expresa la idea de que la
identidad y la existencia humana están inextricablemente vinculadas con el
entorno en el que vivimos. Somos seres únicos con experiencias y
perspectivas individuales, pero al mismo tiempo, nuestras vidas están
moldeadas por las condiciones y situaciones en las que nos encontramos. Esta
frase invita a reflexionar sobre la relación dinámica entre el individuo y
su entorno, la influencia recíproca entre ellos y la importancia de la
libertad y la responsabilidad personal.
----
Más adelante, en ese chat Julián Andrés Prieto aportaba
"Es maravilloso y esta genial, lo que agregaría es que mucho de ese condicionamiento del entorno viene o nos llega en etapas muy tempranas cuando se forma. Los cimientos de los modelos mentales que guiarán en gran medida nuestra interpretación del mundo. En esas etapas tempranas esa formación de cimientos es en varios casos inconsciente. Para la muestra un botón"
Como reacción al artículo Hugo me respondió:
“Yo soy yo y mis circunstancias y si no la salvo a ella no me salvo yo”.
- José Ortega y Gasset
Con esta frase de Ortega y Gasset engloba el mundo entero:
A. El individuo que puede autodeterminarse y
B. La fuerza del entorno que lo condiciona a depender de él para vivir, y si esa dependencia pierde equilibrio la vida de los individuos no es viable.
Y esto no solo en el plano físico y biológico, que es tan obvio como el aire que respiramos o los alimentos que comemos; es también en el plano psicosocial en la configuración de las creencias y la teoría que cada uno de los miembros de una comunidad tiene de la realidad. Sin creencias fuertes, los individuos tienen una existencia débil, y si esas creencias pasan por la autodeterminación o la individuación, la vida posibilitada desde las creencias será más plena y fuerte.
Entonces la frase muestra que:
- si bien el individuo es el centro de las posibilidades existenciales, es el entorno el que hace posible la vida y la calidad de vida.
- lo segundo, que tiene que ver en algo con Ortega, es el desarrollo de Edgar Shein de la cultura, la cual según él tiene 3 capas, como una cebolla:
- Capa 1. Los artefactos y símbolos (que son parte de lo que Ortega llamó las circunstancias, y digo parte porque circunstancia es todo aquello que rodea e influye a un organismo o un individuo).
- Capa 2. Los valores adoptados.
- Capa 3. Las suposiciones básicas y subyacentes (lo que Ortega llamó "las creencias")
En conclusión, salvar las circunstancias es el éxito o el fracaso de la cultura y todo individuo solo podrá autodeterminarse o individuarse con éxito si las circunstancias se lo facilitan.
Espero haber aportado a tu ya muy importante reflexión publicada a tu comunidad.
Un gran abrazo Jorge.
domingo, junio 04, 2023
Frase Cambio Cultural y Cambio Organizacional - Para salir de la inercia organizacional es necesario imprimir una fuerza
A continuación, les comparto otra frase con la cual resueno mucho, de un gran amigo, mentor, y agile coach sobre cambio cultural y cambio organizacional:
“En los procesos de cambio, para sacar a las organizaciones de la inercia es necesario imprimir una fuerza”. -Wbeimar Andrés Vásquez Ramírez
____
domingo, mayo 28, 2023
viernes, mayo 19, 2023
domingo, mayo 14, 2023
Mi Nuevo Podcast: Agilidad desde las Trincheras
Hola a todos
Desde hace más de un mes vengo compartiendo este podcast "Agilidad desde las Trincheras" en las diferentes plataformas, bajo la dirección y edición de mi gran amigo y agilista de Rodrigo Burgos Noceti del podcast de Hormigas Agilistas (donde también participo como otra hormiguita más).
Pueden acceder en las diferentes plataformas de Streaming en https://www.spreaker.com/show/agilidad-desde-las-trincheras.
- Spotify - clic aquí
- iheart - clic aquí
- Google - clic aquí
- Deezer - clic aquí
- Podcastaddict - clic aquí
- Podchaser - clic aquí
- jiosaavn - clic aquí
A continuación, el podcast en Spotify.
miércoles, abril 26, 2023
Cómo TCS Latam logró mejorar su desempeño por medio de su métrica AgilityDebt (TM)
Si eres #AgileCoach o eres parte de un #CoE de #Agilidad te recomiendo ampliamente este artículo.
En este se habla como Tata Consultancy Services mejora su desempeño empleando el índice AgilityDebt (tm), y como se ha conducido la mejora en Tata Consultancy Services LATAM y aunque he dado puntadas en dos posts:
- Video: Moviendo TCS (500.000 personas) a la Agilidad
- Cómo Lograr el Cambio Lean-Agile en Grandes Corporaciones
El nivel de detalle compartido por Roberto Moraga Diaz da una visión completa que puede ayudar a las organizaciones a mejorar de forma significativa su desempeño.
Suscribirse a:
Entradas (Atom)