Próximos Entrenamientos en Scrum y Leading SAFe

Hola a todos

Les comparto los próximos entrenamientos que estaré facilitando:

• Scrum Master - Octubre 20 y 27 - Ciudad: Medellín - Clic aquí para más información
• Leading SAFe (entrenamiento oficial) - Noviembre 3 y 10 - Ciudad de Medellín - Clic aquí para más información

Si tienes alguna inquietud no dudes en comunicarte a través de la zona de comentarios o al correo jorge.abad@gmail.com

Saludos Ágiles

Jorge Abad

MiniManual para la Gestión por Valor

MiniManual para la Gestión por Valor

1.¿Añade valor construir más alcance?
-si, construye más alcance y pon el siguiente hito lo más cerca posible y regresa a 1
-no, ¿por qué?
-Logramos el valor, resuelto el problema
-no, la hipótesis falló, no tiene sentido continuar#Agile

— Jorge Hernán Abad L. (@jorge_abad) August 23, 2018

Scrum Como Modelo de Auto-Coaching para los Equipos

Hola a todos

Hace unos días en una reunión de Ágiles Ecuador - en la que tuve la oportunidad de ser el facilitador de la Sesión de Migas de Pan(1)-, alguien sugería al cierre de la misma que para ser Scrum Master era necesario hacer un coach profesional como primer paso, y después de debatir un poco, decantábamos que no, que no era necesario, pues tanto un Scrum Master, un Agile Coach de Equipos o un Agile Coach Empresarial tienen más de mentor, de experto, de maestro, de líder, de entrenador de equipos, que alguien que a través de preguntas quiere acompañar a un individuo en su viaje de un estado a otro en su vida (y reconozco que este es un punto que aun no se termina de desarrollar en la comunidad ágil).

Pero también en esa discusión observábamos que un equipo que hace Scrum, tiene un ciclo de mejora continua que esta cuestionando constantemente tres ejes:

• La organización
• El equipo
• La persona que hace parte del equipo Scrum

Cíclicamente un equipo que hace Scrum, se enfrenta a su verdad - gústele o no - pues al principio en el Planning hacen una compromiso de lo que creen que van a construir y al final en la Review están mostrando lo que lograron a los Stakeholders y luego se van a la Retrospectiva con su resultado a filosofar que pueden hacer distinto para ser más exitosos el siguiente ciclo. Este ejercicio de:

• hacer una apuesta basados en su capacidad
• ver el resultado
• mostrar el resultado
• enfrentarse al feedback de sus stakeholders
• indagar por que se obtuvo el resultado
• proponer que mejorar internamente para ser más exitosos la próxima vez
• proponer que mejorar externamente para ser más exitosos la próxima vez

Termina cambiando a las personas, equipos y organizaciones.


Esta dinámica genera un circulo virtuoso transformador, pues:

• te va haciendo responsable de tus compromisos
• te hace revisar tus capacidades y buscar nuevas
• te invita a tener mejores interacciones con tus compañeros para tener éxito
• te invita a cuestionarte, cuestionar respetuosamente a los otros y cuestionar a la organización en la que estas inmerso

En definitiva, no te puedes quedar quieto ante un marco que cada semana, dos semanas o máximo un mes te muestra tu verdad tal cual es, o cambias, o cambias (así lo he visto funcionar cantidad de veces)

Scrum por sus ciclos de PHVA(2) continuos, termina cambiando al Equipo, al Scrum Master y al Product Owner, y al final de su viaje en la construcción del producto terminan siendo personas completamente distintas  y quienes hayan vivido este viaje sabrán darme la razón.

Para cerrar es importante aclarar que no solo Scrum puede darte este beneficio, cualquier modelo de trabajo que en ciclos cortos (de no más de un mes) nos esté enfrentando a la verdad y nos esté retando a salir de nuestra zona confort generará resultado similares.

Bonus Track

Ahora, cuando alguien me pregunta ¿que tiene que hacer para ser Agile Coach? lo invito a que comience este camino con corazón (3) siendo Scrum Master - que es el Agile Coach del equipo Scrum-, y enfrente allí sus verdades, junto con su equipo, y luego de al menos cuestionarse, cuestionar, y retar durante un buen tiempo determine hacia donde seguir avanzando.

Bueno, hasta acá esta corta reflexión y compartir.

Si tienes algún comentario bienvenido el feedback en la zona de comentarios

Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Actividad que le aprendí de mi gran amigo Carlos Gil
2. El ciclo Planear - Hacer - Verificar - Actuar, promovido por E. Deming

3."...Cualquier cosa es un camino entre cantidades de caminos. Por eso debes tener siempre presente que un camino es sólo un camino. Si sientes que no deberías seguirlo, no debes seguir en él bajo ninguna condición. Para tener esa claridad debes llevar una vida disciplinada.Sólo entonces sabrás que un camino es nada más un camino, y no hay afrenta, ni para ti ni para otros, en dejarlo si eso es lo que tu corazón te dice.

Pero tu decisión de seguir en el camino o de dejarlo debe estar libre de miedo y de ambición. (...) Mira cada camino de cerca y con intención. Pruébalo tantas veces como consideres necesario.

Luego hazte a ti mismo, y a ti solo, una pregunta: ¿Tiene corazón este camino?

Si tiene, el camino es bueno; si no, de nada sirve. Todos los caminos son lo mismo, no llevan a ninguna parte. Son caminos que van por el matorral. Ningún camino lleva a ninguna parte, pero uno tiene corazón y el otro no..." Uno hace gozoso el viaje; mientras lo sigas, eres uno con él. El otro te hará maldecir tu vida. Uno te hace fuerte; el otro te debilita."

El problema es que nadie se hace la pregunta, y cuando por fin se da cuenta de que ha tomado un camino sin corazón, el camino está ya a punto de matarlo.Un camino sin corazón nunca se puede disfrutar. Hay que trabajar duro tan sólo para tomarlo. En ese punto pocas personas pueden parar a pensar y dejar el camino...

En cambio, un camino con corazón es fácil: no te hace trabajar por tomarle gusto. Para mí existe solamente el viajar por caminos con corazón, en cualquier camino que pueda tener corazón. Por ahí viajo, y el único desafío que vale la pena es atravesarlo en toda su longitud. Y por ahí viajo, buscando, buscando, sin aliento". (“Las enseñanzas de Don Juan” de Carlos Castañeda.)

Hablemos de Deuda Técnica “Cómo la Deuda Técnica puede acabar tu proyecto ágil”

Hablemos de Deuda Técnica “Como la Deuda Técnica puede acabar tu proyecto ágil” from Jorge Hernán Abad Londoño

Un Método Adicional de División de Historias de Usuario: Criterio de Equipo o Hasta Acá Llegamos

Hola a todos

Existe un método adicional de división (splitting) de historias de usuario al presentado en Leído y Recomendado: División de historias de usuario -clic aquí- y es el usado por el Criterio del Equipo o al que yo llamo "Hasta acá llegamos" y la situaciones en las que he observado que se presenta son las siguientes:

Situación 1: El equipo observa una historia de usuario muy grande

• El Product Owner (PO) explica una historia de usuario
• El Equipo la estima y la ve muy grande (ver post) o muy riesgosa,
• Entre PO y Equipo se estima hasta donde llegan en esa historia (dependiendo si la dividen por valor para el Sprint o Riesgo) y si el resto será en otra historia de usuario que posiblemente se construya en este sprint o se decida realizar el siguiente.

Situación 2: El product backlog esta casi listo y se quiere añadir una historia de usuario

• Se tiene el sprint backlog casi listo, queda un poco de capacidad libre para una nueva historia de usuario.
• El PO explica una historia de usuario
• El Equipo observa que no hay capacidad para asumir esta historia de ese tamaño y las subsiguientes historias también parecen ser de tamaños similares o superiores.
• El Equipo con el PO dividen la historia de forma que se logre incluir lo que más genera valor en el planning actual y se deja para otro sprint el resto (pero en una nueva historia).

Espero haya sido útil este corto compartir.

Saludos ágiles

Jorge Abad

Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario

Hola a todos

Como alguno de ustedes saben, muchas veces uso mi blog como referencia cuando comparto entrenamientos y charlas, es mi repositorio oficial en el que recopilo y comparto información, conocimiento y experiencias.

Quiero en este post dejar referencia del interesante artículo que comparto constantemente en los entrenamientos sobre división de historias de usuario publicado en Agileforall.com.

Espero les sea de gran utilidad como lo ha sido para mi.

Link del post -1: How to Split a User Story - Clic aquí
Link del post -2: New Story Splitting Resource - Clic aquí
Link del poster en pdf en inglés: clic aquí.
Link del poster en pdf en español:clic aquí.

Link de backup por si los anteriores no funcionan - inglés: clic aquí.
Link de backup por si los anteriores no funcionan - español: clic aquí.

Saludos ágiles

Jorge Abad

Dos ideas sobre Agile

Dos ideas

- No seas ilus@, #Agile no va a resolver tus problemas, lo que si va a hacer es a evidenciarlos más rápido.

- Si tu gestión es basada en la falta de transparencia, no uses #Agile pues rápidamente te pondrá en evidencia.

— Jorge Hernán Abad L. (@jorge_abad) August 7, 2018

Datos, Hechos y Beneficios de Agile+DevOps en una Empresa Pública de Colombia

Hola a todos

Aunque cada vez es menos frecuente la incredulidad hacia Agile, siempre es bueno contar con casos de éxito y en especial con una colección de métricas capturadas en un entorno empresarial, para compartirlas con personas y empresas que se están acercando al concepto.

A continuación les comparto este Tweet de Claudia Toscano quien trabaja en área de TI de Empresas Públicas de Medellín (empresa con sede en Medellín - Colombia), con una hermosa colección de métricas como resultado de aplicar Agile y DevOps en su entorno.

Aunque parece obvio, importante resaltar que corresponden a datos de una Empresa Pública.

---

Cuando son ellos quienes te buscan para trabajar con esos marcos ágiles y automatizar pruebas y despliegues, sabes que hiciste bien la tarea! #epmagile @ricardorq85 @sperezj @RoseRestrepoV @EPMestamosahi @kleer_la @Intergrupo @10pines @techandsolve @CeibaSoftware pic.twitter.com/HJyodXFDAP

— Claudia Toscano Varg (@claudytoscano) July 31, 2018

---

---

---

Nota Importante: Si como empleado público (o empleado privado) insistes en contratar proyectos de desarrollo de software en cascada (waterfall, o tradicional, es decir: una fase larga de levantamiento de requisitos, luego otra de desarrollo, luego una tortuosa de pruebas y por fin una entrega tardía y un contrato con alcance, tiempo y costo fijo) es muy probable que estés incurriendo en algo que en Colombia le llamamos Detrimento Patrimonial - es decir, estas haciendo mal uso de los recursos del Estado - o de tu organización - y estas probablemente derrochando probablemente un valor cercano al 50% del valor del contrato-, pues existen numerosos estudios que demuestran que hacer proyectos en cascada genera desperdicios en funcionalidades que no serán usadas cercanos al 50%. Anexo resultados de un estudio muy conocido "el Manifiesto del Caos  del 2013(ver Página 6)":

Te comparto algunos links que aun funcionan:

• http://fliphtml5.com/scht/mwde/basic
• https://es.scribd.com/document/198550543/Chaos-Manifesto-2013

Saludos ágiles

Jorge Abad

[Preguntas y Respuestas] ¿En mi producto no hay un MVP de quien es la responsabilidad de que este exista?

Hola a todos

Hace poco publiqué en LinkedIn una pregunta (ver links al final):

"¿Soy #ScrumMaster y no hay un MVP (producto mínimo viable) definido para el producto de quien es la responsabilidad de que este exista? 

Del SM, muchas veces el PO es la primera vez que ejerce el rol, y de pronto ni ha sido capacitado, mi deber como sm es ser el Coach del PO y enseñarle a como ser un gran PO, priorizar el product Backlog por valor, encontar el MVP, escribir historias de usuario etc. "

en su clarificación se compartieron varios aprendizajes que han servido

• El Scrum Master es el experto en el marco
• El Scrum Master esel Agile Coach del Product Owner y del Equipo
• El Scrum Master como experto y coach si observa que su Product Owner no entiende ciertos conceptos, lo formará y apoyará hasta que este se haga responsable de los mismos
• La guía oficial -scrumguides.org - presenta al Scrum Master a estar al servicio de Product Owner de la siguiente forma:
• Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum de la mejor manera posible;
• Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
• Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
• Entender la planificación del producto en un entorno empírico;
• Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
• Entender y practicar la agilidad; y,
• Facilitar los eventos de Scrum según se requiera o necesite
• Se invitaba a que los Scrum Masters fueran proactivos en vez de esperar que sus Product Owners vengan preparados y listos con todas las técnicas de facilitación y gestión de producto, los acompañaran y formaran hasta que estos fueran Product Owners Grandiosos (recomiendo este post Guía Supernumeraria para un Dueño de Producto Virtuoso - de Lucho Salazar- clic aquí-)
• Este post tambien aplica para la pregunta: ¿En mi producto no hay un Plan de Relaeases de quien es la responsabilidad de que este exista?
• Es probable que un producto con salidas frecuentes a producción, cada fin de sprint o varias veces durante el sprint, no requiera un plan de releases,

Bienvenido el Feedback

Saludos Ágiles
Jorge Abad

---

Link de la conversación en Linked in: https://www.linkedin.com/feed/update/urn:li:activity:6412122454839357440

Link de la conversación en Facebook: https://www.facebook.com/jorge.abad/posts/10160545277655788

Aclarando Sobre Historias de Usuario

Hola a todos

Existe una página de Facebook que pone excelentes temas de cuestionamiento sobre testing llamada "Señor Tester" - clic aquí para verla -, lo cierto es que esta semana publicaron algo que comenté pues hace parte de los malentendidos relacionados con las historias de usuario.

A continuación les comparto el post y mi respuesta

Saludos Ágiles 

Jorge Abad

------------------------

El Post: https://www.facebook.com/elseniortester/photos/a.863366253809076.1073741828.826564797489222/1457673961044966/?type=1&theater

mi respuesta fue:

Esta es la transcripción

genial...es lo mejor que puede suceder.. y observo varias cosas:

• las historias de usuario no se envían, se explican en el planning
• entre más ambiguas mejor...pues implicará que el #ProductOwner, se haga entender por todo el equipo
• Al tester no lo estan invitando al planning mal #Agile, mal #Scrum o #FrAgile -- tiene que estar allí con todo el equipo, hace parte del equipo
• te recomiendo este post   - Algunas Ideas Claves sobre Historias de Usuario - clic aquí..-
• las historias de usuario NO SON ESPECIFICACIONES.. su creador argumenta que si hubiera querido que fueran especificaciones, se llamarían ESPECIFICACIONES DE USUARIO, pero se llaman historias por que deben ser contadas y explicadas
• Al Señor Tester  le esta tocando un equipo que hace mal #Agile, mal #Scrum o #FrAgile

un abrazo Señor Tester  y espero algún días hagas parte de un verdadero equipo ágil

Dedicación del Scrum Master y el Product Owner en el tiempo

Hola a  todos

Hace algún tiempo compartí este artículo "El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo", con su link hacia la referencia original en inglés "The goal of a Scrum Master is NOT to make herself unneeded", el punto es que noto que sigue siento cierto, la experiencia me lo sigue confirmando, pero como dato adicional quiero compartir hoy una gráfica atribuida a Mike Cohn sobre la dedicación del PO y el SM en el tiempo.

¿De qué factores corresponderá esa inflexión en la curva?

• Del Scrum Master
• Del Product Owner
• De la madurez del Equipo
• De la estabilidad del equipo
• Del tiempo (8meses, un año, dos años)

No hay respuestas definitivas o contundentes, como siempre nos tocó recurrir a "Inspección y Adaptación"

Saludos Ágiles

Jorge Abad

Unos tweets sobre agile y management

Un mensaje que continuamente comparto:

"Gerente si en el pasado tu forma de generar valor era controlar gente,en #Agile la gente se autocontrola y es autónoma, por lo tanto debes encontrar otra forma de aportar a la organización"#Agileleadership

— Jorge Hernán Abad L. (@jorge_abad) July 25, 2018

---

Segun como termines esta frase te diré que tan #agile eres:
"Lo que no se mide no se...
.
.
.
.
.
.
.
.
.
,
.
.
.
.
.
.
...Mejora"

Aclaro, el propósito en #Agile no es el control, sino la mejora continua que nos hace inalcanzables.#agileleadership

— Jorge Hernán Abad L. (@jorge_abad) July 25, 2018

---

"No se puede gestionar lo que no se ve" - Jim Benson

Evolución (niveles, o tipos) de Product Owner

Hola a todos

Buscando una información relevante respecto al Product Owner, quisiera compartir estos niveles, tipos, evolución del PO y el beneficio que generan, que me encontré en este excelente artículo -http://roneringa.com/evolution-product-owner/ -

Saludos ágiles

Jorge Abad

Desperdicio Generado por la Pérdida de Contexto o "Switcheo" entre Proyectos

Hola a todos

Hay cosas sobre las cuales no se puede dejar de insistir, y esta es una de ellas.

La dejo por acá para que la usen de referencia.


Saludos ágiles

Jorge Abad

Tweet: La combinación Agile DevOps ya no es opcional

La pregunta ahora NO es ¿si la empresa hace o no Agile-DevOps?
la pregunta es ¿que tan bien lo está haciendo y cómo lo va a seguir
mejorando?

La combinación #Agile #DevOps ya no es opcionalhttps://t.co/FE2Fud0gAO

— Jorge Hernán Abad L. (@jorge_abad) May 4, 2018

Presentación: Las Cinco Disfunciones de los Equipos y el Miembro de Equipo Ideal

Las Cinco Disfunciones del Equipo y el Miembro de Equipo Ideal from Jorge Hernán Abad Londoño

[Scrum] Una queja común en algunos Scrum Masters: Mi Product Owner no es bueno

Hola a todos

En sesiones de mejora con Scrum Masters (SM) con frecuencia me encuentro con las siguientes quejas acerca del Product Owner (PO):

• no tiene tiempo para el equipo
• no escribe bien las historias de usuario 
• no está priorizando el product backlog
• no hay un plan de releases
• no se tiene un Producto Mínimo Viable (MVP).
• no se tiene una herramienta de seguimiento de releases como un Burn Up Release (por ejemplo)
• entre otras preocupaciones

Es allí donde les solicito que me compartan que saben del rol del Scrum Master y me responden palabras más palabras menos, lo que que está a continuación (-que se interpreta en la guía oficial de Scrum- ):

Luego de esto, comienzo una ronda de preguntas y respuestas de más o menos este estilo:

• ¿Quién es responsable de que se tengan buenas historias de usuario, el P.O., el Team o el SM? 
• Rpta/. Es el SM como experto del marco es el encargado de garantizar que el equipo tenga los ítems de backlog adecuados para trabajar, y es su deber como coach del PO de enseñarle y verificar las historias de usuario para que estas cumplan con un estándar mínimo de calidad (las tres CCC e INVEST). ( leer tambiém :El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog - clic aquí)
• ¿Quién es el responsable de que no se tenga un buen Product Backlog, Plan de Releases, Producto Mínimo Viable (MVP), un Burn Up Release?
• Rpta/. Pareciera que inicialmente es el PO, pero similar al punto anterior, el SM como coach del PO debe enseñarle y ayudarle a mantener los artefactos de scrum, hasta que estos sean los adecuados para construir un producto exitoso.
• ¿y que podríamos hacer con respecto a la falta de tiempo del PO?
• Rpta./. El SM debe buscar como lograr más tiempo de la organización para el PO - al menos medio tiempo-, o encontar la forma de que esto se resuelva con otro PO, o un PO Proxy, pero recordemos que el SM es un agente de cambio para la organización y es responsable de que la organización comprenda como funciona Scrum y los requisitos para que sea exitoso.

Es importante comprender que el Scrum Master es el responsable de Framework de Scrum, debe trabajar por su funcionamiento exitoso, que debe convertirse en Responsable en vez de Víctima,  haciendo que las cosas pasen, si su PO, equipo o algo no funciona pues debe moverse para que las cosas sucedan.

Hasta acá este corto compartir

Saludos ágiles

Jorge Abad

Tweet: Agile no gestionar por alcance sino por valor

Entre los grandes cambios que introduce #Agile en una organización es pasar de

La Gestión del Alcance a la Gestión del Valor

Este "simple" cambio de enfoque:
-reorganiza equipos
-cambia métricas
-elimina desperdicios
-conecta más a las personas
-aumenta la felicidad

— Jorge Hernán Abad L. (@jorge_abad) April 17, 2018

Leído y Recomendado: Una petición cara a cara es 34 veces más efectiva que por correo electrónico

Un excelente ártículo del Harvard Business Review


https://www.hbr.es/redacci-n-empresarial/568/una-petici-n-cara-cara-es-34-veces-m-s-efectiva-que-por-correo-electr-nico -clic aquí-.


Saludos

Leído y Recomendado: Por qué la evidencia no logra cambiar lo que pensamos

Excelente artículo


http://www.perfil.com/elobservador/por-que-la-evidencia-no-logra-cambiar-lo-que-pensamos.phtml 



Saludos