Reflexión: Empático mas no complaciente

tomado de (4)

En estos tiempos de VUCA (1) todos los líderes somos agentes de cambio, buscamos como generar valor mientras respondemos a un entorno cambiante. Es necesario entender que nuestras organizaciones (y las que estamos interviniendo) llegaron hasta donde están debido a las estrategias tradicionales, pero estas estrategias cada vez son menos eficientes.

Es necesario que todo líder, presidente, vicepresidente, director, gerente, gerente de proyectos, scrum master, agile coach sea:

Empático mas no complaciente

Empático, desde el punto de vista que comprende los paradigmas desde los cuales están ubicadas las personas de su entorno, cuales son los motivadores de sus decisiones, cuales son los elementos de juicio usados por ellos, siendo amable, condescendiente temporalmente, comprendiendo, hasta disculpando actitudes que no son exitosas actualmente tales como:

• planeaciones rígidas, donde es requerido planeaciones adaptativas
• gestión comando-control, donde es requerido un liderazgo servicial
• documentación extensiva, cuando lo que se requiere es interacción entre los involucrados
• uso excesivo de la comunicación jerárquica
• procesos rígidos que rara vez son actualizados y no reflejan la forma de trabajo
• y así muchos más casos

y No Complaciente (o Retador), aunque entiende el contexto, traza rutas cortas o a mediano plazo hacia entornos más adaptativos, siendo constructor de puentes, tales como:

• generando procesos intermedios que luego retarán para que sean más Lean-Agile (2)
• enseñando a otros como liderar el cambio desde el liderazgo servicial o liderazgo situacional
• creando experimentos que demuestren como hacer mejor las cosas
• proporcionando datos y hechos de que los paradigmas actuales deben ser cambiados
• proporcionando datos y hechos de que los paradigmas adaptativos (lean-agile) generan valor más rápido y con menos costo en su entorno
• retando a todos a su alrededor, generando un paradigma de mentalidad de crecimiento dejando atrás la mentalidad fija de procesos y formas establecidos
• liderando con el ejemplo
• haciendo de la mejora continua un hábito a enseñar a los demás
• buscando como hacer a las organizaciones y equipos más adaptativos y colaboradores
• usando herramientas del paradigma tradicional para comunicar expectativas, pero retando la búsqueda de mejores herramientas (3)
• comunicando y demostrando constantemente que la generación de valor hacia el cliente final es más importante que la excelencia operativa de un area funcional

Hasta acá este corto compartir, bienvenidos sus comentarios.

Saludos ágiles,

Jorge Abad

Notas, Aclaraciones, Comentarios, Referencias y Observaciones

1. VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en https://es.wikipedia.org/wiki/VUCA
2. Lean-Agile
• Lean es la forma como Jame Womack acuño la esencia del Toyota Production System. Más información en https://en.wikipedia.org/wiki/Lean_thinking
• Agile es la forma como es conocido el Agile Software Development, comprende varios enfoques para el desarrollo de software bajo los cuales los requisitos y las soluciones evolucionan a través del esfuerzo colaborativo de equipos autoorganizados y multifuncionales y sus clientes / usuarios finales, es representado condensado en cuatro valores y doce principios. Ver más en https://en.wikipedia.org/wiki/Agile_software_development.
3. Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales (http://www.lecciones-aprendidas.info/2019/09/como-evitar-la-ingenuidad-agil.html)
4. Vector de Negocios creado por freepik - www.freepik.es

Antipatrón: Solo liderar la primera línea y no gestionar la red

Hola a todos

Quisiera compartir uno de las disfunciones que he observado en la gestión de equipos y de las redes vinculadas a los mismos, convirtiéndose en uno de los obstáculos en los esfuerzos  de cambio cultural y de liderazgo hacia ambientes de más colaboración, adaptación al cambio, innovación, mejora continua, y generación de valor.

Utilizaré el esquema de antipatrón para compartirlo.

Antipatrón: El líder solo exige y promueve un alto estándar a su equipo y no gestiona la red  de personas y el ecosistema a cargo.

Problema: El líder solo gestiona su equipo adyacente exhibiendo y demandando valores de alto estándar pero no valida si su equipo y su entorno lo está haciendo, infiriendo o suponiendo que su equipo hará lo mismo con las personas a cargo.

Consecuencias:
existen varias consecuencias

• positivas: que todo su equipo exhiba y demande estos valores de alto estándar generando una cultura altamente positiva.
• negativas: 
• que parte de su equipo exhiba y comparta hacia la red un alto estándar de valores y otra parte del equipo no lo haga generando una cultura desigual y heterogénea
• que su equipo no exhiba los valores con los que son tratados y se generen resultados maltratando a las personas, con una cultura de presión, irrespeto y miedo.

Causas:

• Inocencia del líder
• Tolerancia del líder de cualquier estilo de liderazgo sin importar el trato que se le da a su red

Solución

En caso de que el líder este interesado en que su cultura de alto estándar se propague por el resto de su red se sugiere:

• no confiarse de evaluaciones 360
• realizar reuniones o conversatorios con cierta cadencia (mensual, bimestral o trimestral) con los equipos de la red para validar estilos de liderazgo

Se me vienen a la mente dos citas relacionadas con este tema:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar."- Gruenter and Whitaker, School Culture Rewired

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar"- Jurgen Appelo

Con base en lo expuesto en este post se le podría precisar algo a ambas citas:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar en su equipo de trabajo y toda la red de personas a cargo"

----

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar en su equipo de trabajo y toda la red de personas a cargo"

y como dice Deming:“Todos ya están haciendo lo mejor que pueden; los problemas están con el sistema ... solo el management puede cambiar el sistema", pero el sistema somos nosotros (1) y como nos relacionamos, ahí se encuentra la clave para generar el cambio o promover un alto estándar de cultura y valores.

Hasta acá este compartir, bienvenidos sus comentarios.

Saludos Ágiles

Jorge Abad

Referencia

1. De Colección: Culpamos el sistema, pero el sistema somos nosotros  http://www.lecciones-aprendidas.info/2019/07/culpamos-el-sistema-pero-el-sistema.html

Tip sobre Proyectos y Contratos Ágiles

"Hacer un Producto/Proyecto Ágil con un contrato tradicional (alcance, tiempo y costo fijos) es un completo dolor de cabeza para todos -cliente y proveedor-. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance."

_

Hacer un producto/proyecto #Agile con un contrato tradicional (alcance, tiempo y costo fijos) es un dolor de cabeza para todos. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance https://t.co/M2FkrzODN2

— Jorge Hernán Abad L. (@jorge_abad) October 24, 2018

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

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2)

Imagen de la película: ¿Dónde está el piloto? - Idea de mi amigo Wilmar Hincapie

Hola a todos

En el pasado Ágiles 2017 en Chile, hablando con Leonardo Agudelo (@sweepnoise) sobre los proyectos piloto, me hacía ver que no solo eran importantes los puntos del artículo anterior (mira la primera parte de este artículo - Clic aquí):

• 3 a 4 meses de duración
• Con 1 a 4 equpos de trabajo
• Importante para la organizaicón
• Patrocinio ejecutivo
• La gente correcta
• Dominio de la tecnología

Sino que era necesario revisar el manifiesto ágil buscando los elementos para cumplirlo y para generar el ambiente propicio para que germine la agilidad, a continuación les comparto este análisis y algo de mi experiencia:

• Crear un contrato que permita la agilidad, seamos sensatos un contrato con todo fijo -alcance, tiempo y costo fijo- no nos permitirá tener éxito. (ver sobre contratos agiles - clic aquí- )
• No usar las tipicas métricas de cascada (CPI, SPI) para medir el proyecto (es un desastre tratar de acomodar ágil a esto - se los digo por experiencia)
• Permitir el cambio como parte natural del proceso (he observado que en proyectos que quieren hacer ágil, siguen con la política de control de cambios --¡¡OMG!! NO SE IMAGINAN EL DOLOR DE CABEZA. es necesario archivar este proceso para poder hacer el piloto)
• Cambiar las métricas de la evaluación de desempeño de las personas que participaran (es decir, en cascada a un analista le daban una buena calificación si tenía pocos controles de cambio, si este analista se va para el piloto de ágil, las historias de usuario las grabará sobre piedra - y me ha pasado -)
• Requerir que el negocio este involucrado y contar con su participación al 100% (con el ROL de Product Owner o de Interesado clave)
• Que exista la comunicación cara a cara (todos en el mismo sitio , co-location)
• Crear las excepciones - válidas a los procesos organizaciónales - que permitan la agilidad
• Prioridad en los despliegues
• Prioridad en los controles de cambio de ambiente
• Prioridad en las autorizaciones
• etc

Cerrando

Ya hemos perdido mucho tiempo y dinero haciendo proyectos en cascada, démosle la oportunidad a ágil, pero bajo las condiciones para que este tenga éxito, sino no tiene sentido.



Alguna otra recomendación

No dudes en compartirla en la zona de comentarios.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Mira la primera parte de este artículo - Clic aquí

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.

Hola a todos

Hace poco leí un gran post de Mike Cohn relacionado con como elegir el proyecto piloto: (ver el post  aquí) en donde reforzaba 4 variables (más un bonus):

• Duración: 3 a 4 meses
• Tamaño: Entre 1 y 4 equipos de trabajo (un equipo de máximo 9 personas)
• Importancia: Importante para la organización
• Patrocinio y Compromiso Ejecutivo: Alto
• y un Bonus: Contar con las personas correctas para hacer el proyecto (las que nos garanticen ganar esto funciona para cualquier escenario - agile o tradicional-).

El punto que quiero agregar (como fuente de mi experiencia) a esta lista de 5 puntos es:

• La Tecnología: la tecnología debe ser dominada por el (los) equipo(s) de trabajo

y ahí es donde va aporte, no tiene sentido (adicional a los 5 puntos anteriores) hacer un piloto en agile, o Scrum donde:

• la tecnología es nueva en el mercado, es decir, el proveedor nos están brindando la "valiosísima oportunidad" de ser de los primeros que la usan o implementan (¡OMG!),  o
• el equipo de trabajo no conoce la tecnología, es decir:
• no se domina la arquitectura
• no se conocen los componentes
• no se conocen los retos subyacentes, las características, 
• las premisas y supuestos no se dominan, 
• no se conoce como hacer el tunning del sistema, entre otros.
• y aunque el equipo recibió una "muy buena capacitación" y les funcionaron "todos los laboratorios" sabemos que eso no los hace expertos en algo nuevo (que al menos requeriría seis meses de trabajo continuo para comenzar a tener cierto dominio)

Sabiendo que el propósito es generar una victoria temprana y un gran impacto en la organización, de forma que sea comparable con los proyectos en cascada de similares condiciones.

No recomiendo hacer el primer piloto en agile con tecnología desconocida (y para ser sincero tampoco en cascada), pues no se verían resultados en el mediano plazo ni de la tecnología nueva ni del método.

Mi recomendación general sería:

• hagamos un proyecto piloto en agile con que cumpla las seis premisas:
• 3 a 4 meses de duración
• Con 1 a 4 equpos de trabajo
• Importante para la organizaicón
• Patrocinio ejecutivo
• La gente correcta
• Dominio de la tecnología

• y si, aun así desean el proyecto de la tecnología nueva y retadora, pues que sea otro proyecto adicional al primero, pero:
• que "este no sea el de mostrar" que Agile funciona (pero eso sí estoy seguro que si en este proyecto hacen correctamente Agile o Scrum les aseguro que avanzará más rápido que en cascada)
• que tenga e alcance pequeño 
• que cuente con alto acompañamiento al equipo de parte de expertos o personas conocedoras de la tecnología
• que la organización tenga paciencia este proyecto y su presentación de resultados,  
• y que los patrocinadores tengan alta tolerancia a la frustración pues este problema no corresponde a un escenario complejo (ni mucho menos predictivo) sino a una caótico donde es difícil tener victorias tempranas (1).

Hasta acá esta corta recomendación, reflexión y lección aprendida.

Saludos ágiles

Jorge Abad

(ver más en : Mira la segunda parte de este artículo - clic aquí )

Notas, aclaraciones, comentarios y referencias

1.  Ver el framework de Cynefin para entender el contexto de esta afirmación (clic aquí)

El Planning, el Tasking, el Tablero Kanban, la Guía de Scrum y un Tip Poderoso para “Oler” Impedimentos

Hola a todos, este es uno de los post que hace tiempo tenía pendiente por escribir y por fin se alinearon los astros y pude escribirlo.

Empecemos, según la Guía Oficial de Scrum (1) el planning consta de dos partes:

• Tema Uno: ¿Qué puede hacerse en este Sprint? (conocido como “El Qué”): El cual consiste en la identificación del Objetivo del Sprint y la lista de ítems de backlog que hacen parte del producto que si se completan lograrían el Objetivo del Sprint

• Tema Dos: ¿Cómo se conseguirá completar el trabajo seleccionado? (conocido como “El Cómo”): El cual consiste  que el Equipo de Desarrollo decide cómo construirá esta funcionalidad para formar un Incremento de producto “Terminado” durante el Sprint que cumpla con el Objetivo y contenga los ítems seleccionados en el paso anterior más el plan para terminarlos.

Adicionalmente, para el tema 2 dice claramente:

“El Equipo de Desarrollo por lo general comienza diseñando el sistema y el trabajo necesario para convertir la Lista de Producto en un Incremento de producto funcional. El trabajo podría ser de tamaño o esfuerzo estimado variables. Sin embargo, durante la Planificación del Sprint se planifica suficiente trabajo como para que el Equipo de Desarrollo pueda hacer una proyección de lo que cree que puede completar en el Sprint que comienza. Para el final de esta reunión, el trabajo planificado por el Equipo de Desarrollo para los primeros días del Sprint es descompuesto en unidades de un día o menos.” (Esto último es conocido en el mundo de Scrum con el Tasking, o la descomposición en tareas de los ítems de backlog - como la palabra misma lo sugiere-)

Aquí vemos dos cosas:

• Se sugiere que el trabajo se descomponga de forma gradual en unidades, o sea, NO SE DESCOMPONGA TODO A PRIORI  en el planning del sprint (ya sea por timebox o conveniencia), sino que se identifique claramente las tareas próximas de lo próximo que se va a hacer y luego se descomponga el resto cuando estemos cercanos a construirlo (esto es conocido en el mundo de gerencia de proyectos como Planeación Gradual o Rolling Wave Planning – la cual empleamos nosotros ampliamente en el mundo ágil –). Acá quiero hacer una precisión, nunca lo he hecho así, siempre sugiero o hago la descomposición de todas las historias de usuario en tareas durante el planning  –y nos ha ido bien –, haré el experimento y lo compartiré.
• Lo segundo que me parece MUY PODEROSO es descomponer el trabajo en unidades de UN DÍA O MENOS.

Y es en esto último donde uno dice: “Claro, tiene sentido, de esa manera todos los días se finalizará algo y de esa forma se sentirá el progreso y se identificarán fácil los impedimentos y puntos de atasque".

Basado en lo anterior vienen los siguientes puntos

Cómo he trabajado el tasking o cómo lo he visto

Este ejercicio de descomponer las historias de usuario en tareas de un día o menos (léase Tasking), y me he encontrado con equipos que han decidido manejarlo de diferente manera, el punto no es discutir cuál es la mejor, es mejor pensar, con cual se siente más cómodo mi equipo, adicionalmente puede que lo hagan de una forma durante un tiempo y luego cambien a otra (recordemos el principio básico de la gestión empírica “Inspección y Adaptación”), volviendo al tema las formas de tasking que he observado son:

Forma de tasking	Observación
·         Dividir la historia de usuario en tareas de tamaños de unidades entre 1 y 8, así: 1h, 2h, 3h, 4h, 5h, 6h, 7h, 8h	La verdad esta no me gusta, lo que he encontrado es que no somos buenos estimando en esta forma, pues la precisión aun a nivel de tareas aún es baja en desarrollo de software, adicional abre el espacio a la microgestión que limita al equipo y no permite que el equipo aprenda.
·         Dividir historia de usuario en las tareas de tamaños de 2h, 4h, 6h, 8h	Esta forma me gusta, brinda amortiguación si se falla en la estimación.
·         Dividir la historia de usuario en las tareas de tamaños de 2h, 4h, 8h	Esta es la que más me gusta, por la misma razón de la anterior, adicionalmente permite que falles, aprender, mejorar, da más libertad al equipo.
·         Dividir la historia de usuario en tareas sin horas pero garantizando que cada tarea es menor a un día	Esta forma la he visto en equipos muy maduros en los cuales la confianza y transparencia son una constante presente en su día a día.

Ahora el Super Tip

Este tip me lo enseño Silvia Lozano (@sila_zenufana) – y me ha servido montones con los equipos que he tenido la suerte de estar y acompañar –, quien me sugirió en el tablero kanban poner UN PUNTO por cada día que permanece la tarea en la zona del WIP (“Work In Progress” o “Work in Process”) de esta manera se identificará que una tarea requiere ayuda si tiene más de DOS PUNTOS, pues recordemos que como tenemos por regla (o sugerencia) que las tareas no deben durar más de un día, si las tareas en el tablero kanban tienen DOS PUNTOS O MÁS significa que:

• Existe un posible impedimento
• Existe una posible dificultad en desarrollar la tarea
• Existe una posible falta de foco o de habilidad por parte de desarrollador que esta trabajando en ella
• Se estimó de una forma muy optimista o con falta de conocimiento del real tamaño
• Existe un desbordamiento de alcance
• O es un punto de mejora para discutir en la retrospectiva

En cualquiera de los anteriores es un punto donde tanto Scrum Master como Equipo observan un punto en el que hay que hacer intervención.

OJO: Lo anterior funciona muy bien si tenemos la buena práctica que siempre haya en el tablero una tarea por persona del equipo – recordemos que solo somos capaces de hacer una cosa a la vez, o sea en el WIP una persona no puede tener más de dos tareas –  o sea, que en el WIP si el equipo tiene 4 integrantes a lo sumo existirán 4 post-it (o pósit (2)) a la vez que representan una tarea por cada uno de ellos.

Cerrando

Espero que lo compartido sea de utilidad en tu equipo Scrum, y para terminar tres preguntas

• ¿Cuándo fue la última vez que leíste la guía oficial de Scrum?
• ¿Qué descubrimiento has hecho?
• ¿los puedes compartir?

Bienvenida la retroalimentación y sus comentarios.

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1.  La que se encuentra en Scrumguides.org
2.  Es correcta esta forma de escribirlo, la RAE lo permite ver acá  Pósit  http://dle.rae.es/?id=TnfXVsj

Tengo un proyecto en cascada y quisiera agilizarlo (1)

Hola a todos

Muchas veces cuando comparto en entrenamientos sobre Scrum o Agile, o en conversaciones con gerentes, gerentes de proyecto, sale la siguiente pregunta a relucir:

- [Cliente] Ok, genial, podemos adoptar esto de ÁGIL o SCRUM en el siguiente proyecto, pero 

¿que hacemos para agilizar los proyectos existentes que tenemos en cascada?

Lo que recomiendo es ensayar AGILIDAD ORGÁNICA (http://www.lecciones-aprendidas.info/2015/08/scrum-organico.html), que consiste en promover la agilidad de una forma natural y con feedback del entorno en que se encuentra inmerso el equipo o el proyecto.

Una posible secuencia de pasos a seguir para la agilidad orgánica sería:

1. Existe un agente de cambio ágil - facilitador(2) - (que luego será el scrum master, o como deseen llamarlo)
2. Propone al equipo hacer retrospectivas semanales o máximo cada 2 semanas (ver acá una guía de como realizar un retrospectiva - http://www.lecciones-aprendidas.info/2016/11/agenda-scrum-pasos-para-realizar-la.html - )
3. En la retrospectiva el facilitador se enfoca en lo que más le duele al equipo (este enfoque se basa en encontrar dolores e ir sanándolos - Pain Driven Facilitator) y proponer un cambio, un experimento, y en la siguiente retrospectiva revisar el resultado del experimento.
4. Un ejemplo, el facilitador en un momento apropiado propone como experimento para el próximo ciclo incorporar el Daily, y pregunta en luego del ciclo beneficios que observaron en este.
5. Luego se preguntan sobre más dolores y se van incorporando prácticas, procesos o acuerdos  que el equipo las va "amando" pues fueron soluciones a sus problemas, que ellos mismos encontraron.

luego me dicen

- [Cliente] Perfecto, ¿y que hacemos con las entregas y los entregables?

mi propuesta ante esta situación es:

1. Reprioricen las funcionalidades que están solicitando o esperando (3) en orden del valor que le pueden dar al negocio
2. Hagan cascada de máximo dos meses, es decir, traten de generar u obtener valor lo antes posible de forma que se minimice el riesgo, esto lo logran reduciendo los tiempos de entrega de software con valor (software en el ambiente que será entregado el producto, ya sea en ambiente de calidad o preproducción, según el caso) al menor tiempo posible, 1 mes, 2 meses (exagerando 3 meses), de forma que ustedes puedan dar o recibir feedback sobre el producto y reaccionar sobre el mismo.
3. Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.

y la última pregunta

- [Cliente] ¿y los proyectos que tenemos muy adelantados?

respondo

1. El punto final anterior se conserva igual: Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.
2. Realicen agilidad orgánica, pues la retrospectiva siempre será el motor de la mejora continua sin importar en que punto estemos del proyecto
3. Y dentro de la agilidad orgánica habiliten el Daily que es valioso para dejar de trabajar como islas y comenzar a ser equipo.

Hasta acá este pequeño compartir, bienvenido el feedback.

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Este post podría llamarse también: "AGILIZANDO PROYECTOS EN CASCADA"
2. Es importante que este facilitador conozca de prácticas ágiles para ir orientando al equipo en su proceso de agilización, recordemos El Paciente se Enferma de lo que el Médico Sabe
3. Esto es, dependiendo si es cliente o proveedor quien hace la pregunta.

[Tip Scrum]: Slack o el Tiempo para Afilar el Hacha en Scrum

Hola a todos

Comencemos con una historia para ilustrar el concepto

"Dos hombres determinan hacer una competencia en la cual deben lograr derribar un árbol en el menor tiempo posible. Ambos se lanzan a la obra, llenos de energía y convencidos de que el premio pronto estará en sus manos.

Al blandir sus hachas, vuelan las astillas y los espectadores miran con asombro como el corte en ambos árboles se va profundizando con cada hachazo.

De repente uno de los dos competidores se detiene. El público queda sorprendido al observar que saca una pequeña lima de su bolsillo y comienza a afilar su hacha con toda calma.

Su oponente está feliz. Sigue golpeando con aún mayor fuerza su árbol y muy pronto el corte que está haciendo llega a ser tan grande que su victoria parece ser evidente.

Hasta el momento en el cual el hombre que afiló su hacha vuelve al trabajo. Un, dos y tres. Con solo un par de golpes acertados su árbol comienza a crujir y, ante la sorpresa de todos los espectadores, se derrumba a los pies del hombre sabio, quien supo lo importante que era contar con una herramienta en óptimas condiciones."(1)




Ahora sí...

Entre mis compañeros coaches con los cuales comparto actualmente, es muy común un término que ellos acuñan como "afilar el hacha", yo lo conocía como Slack ( referido en el post  Seis (6) estrategias de lograr mayor velocidad de los equipos en Scrum - clic aquí- )  y es un tiempo que se separa durante o entre sprints para que los equipos o las personas afilen el hacha y mejoren su forma de trabajo.

Dentro de las formas de seleccionar este tiempo están técnicas como:

• dejar un tiempo pequeño entre sprints de 1 a 2 días 
• 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
• El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
• Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
• ver más en Cutting Slack in Scrum

Hasta acá este pequeño pero poderoso compartir.

Preguntas poderosas para ti y tu equipo

• ¿hace cuánto no afilas el hacha en tu equipo?
• ¿qué te lo impide?
• ¿qué es necesario hacer para lograr afilar el hacha en tu equipo con frecuencia?
• yendo un poco más allá, ¿en tu empresa, en tu relación de pareja, en tu vida hace cuanto no afilas el hacha?

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Tomado de : http://www.grandespymes.com.ar/2011/04/17/el-concepto-de-afilar-el-hacha-para-lograr-ser-mas-efectivo/

Algunos Tips para Brindar un Buen Entrenamiento o Ser un Buen Trainer o Faculty

Hola a todos

Hace poco para la organización en la que trabajo me solicitaron dictar un curso de "Cómo ser un buen Faculty",o un "Train de Trainers", pues sin quererlo mis cursos y entrenamientos se han convertido en punto de referencia para los otros entrenadores.

Bueno, dado este requerimiento quisiera aprovechar para compartirles algunos tips para que impartan capacitaciones, entrenamientos o cursos exitosos, no antes sin aclarar  que soy el fruto de muchos maestros(1), de fallar mucho, aprender mucho y del feedback de mis compañeros y estudiantes, y ahora sí volviendo al tema les comparto los tips, espero les sirvan tanto como a mi:

• Preparación

• Aunque sea obvio, garantice el entendimiento y dominio del tema, los estudiantes - y usted y yo lo sabemos -  sabemos cuando alguien no esta lo suficientemente preparado para compartir un tema, materia, entrenamiento o cátedra específica.
• Siempre piense:
• ¿Cómo le gustaría que le enseñaran el tema que va a impartir?
• ¿Cómo lograría que sus estudiantes aprendieran y comprendieran más? y 
• ¿Cómo mantenerlos despiertos y activos durante la clase, entrenamiento o capacitación?
• tenga presente la siguiente frase:

Frase atribuida a Benjamín Franklin o a un Proverbio Chino,
sin importar la fuente es efectiva y real.

• Envíe a sus estudiantes un material introductorio que garantice una sensibilización previa.
• Sea humilde, en el auditorio hay personas de las cuales tiene mucho que aprender y sus preguntas le ayudarán a enfocarse donde más profundizar más para que la próxima vez el curso sea más exitoso..

• Durante el entrenamiento

• En lo posible apréndase los nombres de los asistentes, recuerde que la palabra más dulce para una persona es su nombre, para lograr esto use una actividad de:
• una presentación individual 
• una dinámica de presentación y memorización
• Durante el entrenamiento hacer preguntas y validar nombres
• Pregunte por las expectativas de los asistentes al curso y lo que ellos quieren lograr, si lo desea cree un tablero de expectativas:

• Comparta los objetivos del curso (2) y el resultado esperado al final todas las sesiones, y con base en lo anterior determine si puede variar el programa.
• Comparta el objetivo de la sesión que va a impartir el día de "hoy"
• Invierta 20 minutos en que todos discutan cuales son las reglas que van a respetar conjuntamente, - el resultado es mejor cuando las reglas las formulan los asistentes en vez del facilitador -.

• Presente el temario en un tablero kanban,  y a medida que avance mueva los posit por cada una de las columnas:
• To-Do (por hacer) 
• WIP (en progreso)
• Done (terminado)
• También sugiero tener un burndown y mostrar el avance en esta herramienta. Para esto sugiero que a cada tema se le ponga un peso en la función del tiempo que se requiere invertir en cada tema.

Kanban y Burndown de un Entrenamiento

• Enfóquese en lograr una dinámica interactiva con el tema de manera que garantice apropiarse del conocimiento antes con una actividad o después con un taller o similar. basada en:
• tema - dinámica (juego o taller)
• dinámica (juego o taller) - tema

• Respecto a las pausas
• Trate de que hayan pausas cada 50 minutos de al menos 10 minutos que permitan al estudiante volver a concentrarse.
• Al menos cada 2 horas realice una actividad en la cual estén todos interactuando o jugando, sea que tenga que ver o no con el tema ayuda a conservar la atención de la misma.

• Después del almuerzo realice una actividad que energice a los asistentes, esta hora es pesada y se requiere de actividad para vencerla
• Si alguien se está durmiendo invítalo a que escuche la sesión de pie o realiza una actividad para energizar - dependiendo del tiempo y lo que estés tratando - 
• Tenga un manejo "impecable" del tiempo con horas de inicio claras para temas, descansos, actividades, etc. esto le dará credibilidad y mostrará su profesionalismo.
• Tenga una zona de preguntas o parking lot y resuélvalas al final de la sesión o máximo cada 4 horas

• Tenga un rincón de los famosos o referencias, allí sabrán sus estudiantes a donde seguir avanzando en caso de querer profundizar

• Minimice el uso del video beam y de videos, 
• Incentive el hecho que se tome nota en papel y no en computador aumentan el aprendizaje.
• Use presentaciones exitosas(3) basadas en poco texto y baja saturación de imágenes e información.
• Facilite gráficamente o escriba en pliegos de papel, y déjelos pegados en las paredes los estudiantes volverán sobre cualquier tema sin necesidad de buscar diapositivas, solo con mirar un concepto en la pared.

Observar las paredes con los temas facilitados

• Si su curso dura varios dias, al principio de cada día haga recorderis de lo visto el día anterior. (visite las paredes del día anterior).
• Traiga ejemplos del mundo real al curso, son de alto valor para los asistentes del curso.
• Trate de crear un ejemplo que sea hilo conductor a lo largo de todo el entrenamiento 
• Elabore talleres que sigan el mismo hilo conductor del ejemplo del curso.
• Recuerdan que en la universidad o colegio teníamos un compañer@ que tomaba muyb buenas notas, para maximizar este beneficio realice el ejercicio de qué aprendi y que aprendi de mi compañero, es una recapitulación que se realiza cada cierto tiempo y donde las personas ponen los temas centrales que aprendieron luego comparten estas notas con un asistente y el compañero toma nota de lo que le llamó la atención o le hizo "clic".

• Elabore talleres que ayuden a inferir el conocimiento o a remarcarlo

• Cerrando

• A pesar de que por lo general hay encuestas que se hacen al final, realice un ejercicio de Feedback al final, donde obtengas respuestas sobre la satisfacción del auditorio 

• Elabore un examen al final del curso que lo resuelvan individualmente o en grupos y que luego usted resuelva para todos y explique las razones de cada respuesta.
• Por último, valide con los asistentes si el resultado final fue el esperado.

Este es el resumen de mi experiencia y la forma como dicto cursos, no dudo que tengan referencias a expertos en gestión del conocimiento y enseñanza pero la verdad los desconozco, yo soy alumno de sus alumnos.

Bienvenidos los aportes y el feedback.

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. La mayoría de mis maestros son del mundo de la agilidad (Luis Mulato, Martin Alaimo, Claudia Sandoval, Pablo Tortorella, Ingrid Astiz, Ricardo Colusso, Lucho Salazar, Leonardo Agudelo, Juliana Betancur, Johnny Ordoñez, entre muchos otros)
2. De ahora en adelante llamaremos curso al entrenamiento, materia, tema, o cátedra con el fin de hacer más fácil la lectura.
3. Ver esta interesante recomendación de Johnny Ordoñez - Desecha tus antiguas presentaciones, es una orden del Doctor - Clic aquí

Tip de Scrum: La calificación del Product Owner al finalizar el Sprint

Hola a todos

Scrum es un framework que se va enriqueciendo en un equipo sprint tras sprint de prácticas y tips , hoy quiero compartirles una pequeña práctica(1) de bajo costo y alto impacto para el equipo, la cual detallo a continuación.

Al finalizar el Review el Scrum Master solicita al Product Owner (PO) que califique el Sprint en términos ¿Qué tan útil y de valor fue el incremento entregado? o ¿Qué tanta alineación tiene el incremento entregado con el objetivo del sprint?

 "sin importar cuantos puntos o historias se entregaron, sino centrándose en el valor recibido", 

el PO lo podrá calificar en un escala de 1 a 5 (o la que elijamos) de la siguiente manera:

5 - El incremento estuvo genial, asombroso
4 - El incremento estuvo bien y satisfactorio
3 - El incremento no era todo lo que esperaba
2 - Al incremento le faltaron elementos importantes
1- El incremento lamentablemente no fue satisfactorio

y luego que nos explique la razón de este valor, esta última parte es de mucho valor para el equipo para que este comprenda el norte hacia el cual se dirige el producto.

Estos dos aspectos calificación y explicación, le sirve de motivación, dirección y feedback al equipo y es un importante insumo para la retrospectiva, pues se pueden dar los siguientes escenarios:

• Hacer menos puntos o historias de los esperados pero generar mucho valor al PO,
• Hacer muchos puntos o historias pero no hacer lo que le genera valor al PO, o
• Cumplir las expectativas del PO para el sprint.

Hasta acá esta sencilla y poderosa práctica, espero me compartan los resultados de usarla y todo feedback será bienvenido.

Saludos ágiles y hasta la próxima

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Escuche esta práctica en el DevHangout  "Técnicas para formar equipos ágiles #devHangout 133 con @chuzzete" donde Jesús Méndez - @chuzzete habla de su libro "Técnicas para formar equipos ágiles" y días después me la recordó mi estimado amigo y agilista Carlos Gil - @cafegifo en la actividad de Migas de Pan.

Presentación: Hablemos de Agilidad, Scrum - Razones, Fallas y Tips

HABLEMOS DE AGILIDAD, SCRUM - RAZONES, FALLAS Y TIPS from Jorge Hernán Abad Londoño


Razones para adoptar ágil, fallas y tips para hacerlo de forma correcta.

- Hasta la diapositiva 51, introducción a la agilidas
- de la 52 a la 80 por que los equipos ágiles son más "rápidos" y efectivos
- de la 81 a la 94 errores en la adopcion agile
- de la 95 en adelante mitos y tips en la adopción ágil

Saludos ágiles

Jorge Abad

Muchas veces lo más importante del daily ocurre después

Hola a todos

El daily (Scrum Diario o Daily Scrum ) es una reunión de sincronización del equipo que es facilitada por el Scrum Master, que se hacen de pie y donde cada miembro del equipo responde tres preguntas poderosas:

• ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint? (según la Guía de Scrum)

O más simple

• ¿Qué hice ayer?
• ¿Qué voy a hacer hoy?
• ¿Qué impedimentos tengo?

Esto se contesta rápidamente dentro de los 15 minutos del timebox establecidos, eso si,  evitando los antipatrones (clic aquí), pero a los scrum master y a los equipos que comienzan con scrum les realizo las siguientes sugerencias y ellos determinan si las adoptan o no.

• Al equipo
• Tomar nota o tratar de recordar los temas que les llamen la atención de sus compañeros para ser resueltos luegos del daily
• Al Scrum Master:

• Tomar nota de los impedimentos con fecha en que se originan ya sea en notas adhesivas (post-it) para el kanban de impedimentos o en alguna otra parte para ser resueltos. Ojala lo más visible posible, para poder reaccionar rápido.
• Tomar nota de temas que le estén haciendo "ruido"-(llamando la atención o smells) del daily para ser resueltos para preguntarle a alguien o al equipo, después del daily.
• Apenas el último miembro de equipo  finaliza el daily, decir abiertamente 
• "FINALIZÓ EL DAILY" o "AQUÍ TERMINA EL DAILY" (o algo similar)
• y luego decir (permitiendo el incomodo silencio cuando sea necesario):
• los impedimentos identificados son este y este, ¿están de acuerdo?
• ¿alguien quiere compartir algo, u observó que puede ayudar a alguien o necesitar ayuda?
• ¿algo que necesite ser resuelto de primero?
• Y después de un silencio decir por ejemplo:  "listo equipo vamos a trabajar" o esperar a que otro lo diga.

Es por eso que yo digo que:

Muchas veces lo más importante del daily es lo que ocurre un segundo después de finalizada esta conversación #Scrum #agile

— Jorge Hernán Abad L. (@jorge_abad) 21 de junio de 2016

Sin excelencia técnica no hay agilidad

Hola a todos

Hace unos días me encontré con este excelente post de Michael Sahota @MichaelSahota - Agile vs Waterfall en donde compara rápidamente Agile y Waterfall

Y donde se presenta que al final de cascada lo que se genera es un lío para por fin entregar el producto.

Pero he visto este mismo lío en la entrega en muchos equipos Scrum cuando no se pone atención a la excelencia técnica, con prácticas como:

• estándares de codificación
• buenas prácticas de programación
• revisión por pares
• TDD
• ATDD
• refactoring
• propiedad colectiva de código
• integración continua
• pruebas unitarias
• revisiones estáticas de código
• pair programming
• mob programming (4)
• pruebas funcionales automatizadas
• principios de diseño OO (SOLID)
• clean code
• etc

Termina sucediendo que los bugs en producción van en aumento (incrementando la deuda técnica (1)) y lo que inicialmente se usaba como el patrón de desenfoque o interrupción (5)

Que por buena práctica debería tomar aproximadamente el 10% al 20% del sprint backlog, termina por acaparar ciclo tras ciclo toda la capacidad del equipo durante un sprint.

Y en definitiva el tiempo del sprint que inicialmente se iba a emplear para crear incrementos de valor para el negocio termina usándose para corregir bugs y deuda técnica.

Así las cosas, por más que tengamos:

• retrospectiva (2)
• mejora continua
• sprints
• dailys 
• reviews 
• cultura ágil/agile
• scrum
• etc, 

No servirá de nada sino entregamos software de valor y bien construido cada sprint, pues esta sencilla omisión se vendrá en nuestra contrá

la deuda técnica siempre se paga

Cerrando

Hasta aquí este deber social de poner foco sobre este tema que como principio ágil, reza:

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

Y por experiencia me atrevo a corregir una parte de ese enunciado de la siguiente manera:

Sin excelencia técnica no hay agilidad

La parte del diseño si la dejo igual.

Sin excepción

Sin excelencia técnica no hay agilidad #agile #scrum pic.twitter.com/T7AtdaT5xK

— Jorge Hernán Abad L. (@jorge_abad) 28 de abril de 2016

Saludos ágiles

Jorge Abad

Notas, aclaraciones y referencias

1. Deuda técnica un enfoque holistico por Ángel Nuñez - @snahider - http://es.slideshare.net/snahider/software-debt-que-es-y-como-gestionarlo
2. Que debería entre otras cosas, invitar/retar al equipo hacia la mejora técnica, y sería un error del Scrum Master no hacerlo.
3. Ver los principios ágiles aquí - http://agilemanifesto.org/iso/es/principles.html
4.  Mob programming como forma de auto organización de un equipo Agile por Oscar Amelunge - @oscaramelunge (clic aquí)
5. El patrón de desenfoque o de interrupción (expuesto por Jeff Sutherland - @jeffsuhterland en Scrum The Future Of Works (clic aquí) ) tiene por objeto dejar un porcentaje pequeño del sprint (10 al 20%) para atender interrupciones que tienen como fuente temas del ahora como bugs en producción críticos, funcionalidades urgentes para el PO, etc.
6. Unas diapositivas de Israel Antezana Rojas - @israelantezana que invitan también a esta reflexión : SCRUM no es suficiente... (clic aquí)

No esperar hasta la retrospectiva para mejorar

Hola a todos

El corazón de Ágil como lo expone Alistair Cockbourn (clic aquí) es:

• Colaboración
• Entrega temprana y continua de valor
• Adaptación
• y Mejora

Esto debe ser vivido por todo equipo que se identifique como ágil.

Hoy quiero centrarme justo en la mejora, pues identificamos que esta por lo general se da en la retrospectiva cuando el equipo decide que experimentos y mejoras realizar al siguiente ciclo en todos o cualquiera de los siguientes aspectos:

• Personas e interacciones
• Procesos
• Herramientas

o cualquiera de sus variaciones como

• Calidad (corresponde a procesos)
• Felicidad (corresponde a personas)
• Tecnología (corresponde a herramientas)

Volviendo al tema que nos interesa, muchas veces durante el sprint identificamos mejoras (cualquiera dentro del equipo puede hacerlo - todos somos responsables de hacer las cosas mejor - ) y resulta que nos cuestionamos si esperar hasta la retrospectiva para la mejora o podemos implantarla ya.

La respuesta es muy simple

• Si la mejora es fácil de implantar y son obvios sus beneficios, la implementamos (¿que nos impide hacerlo, sabiendo que nos beneficiará?)
• si la mejora es compleja de implantar, lo decidimos en la retrospectiva

Bueno hasta acá esta pequeña reflexión.

Saludos Ágiles

Jorge Abad

Recomendaciones y lecciones aprendidas

-

Lo poco o lo mucho que hagas, hazlo siempre muy bien 

(aplica para cualquier escenario, y debería ser una costumbre)

En el mundo hay dos tipos de personas, las que hacen que las cosas pasen y las que les pasan cosas

(¿cuál eres tú?, ¿de cuáles quieres estar rodeado en tu proyecto?)

-

Tips para el Sprint Backlog: Primero las HU Riesgosas y luego las prioritarias

Hola a todos

Recordemos:

• Sprint backlog: ítemes de backlog (en nuestro caso Historias de Usuario - HU) comprometidos a construir durante el sprint.

De las primeras cosas que aprendí en Scrum, al ver que un sprint fallaba fue:

Hacer de primero las HU más riesgosas y aunque no sean las prioritarias para el Product Owner (PO)

Razones:

• si comienzas muy tarde a hacer la HU es probable que por sus dependencias o complejidad no la termines.
• Obvio después de la(s) riesgosa(s) poner las HU que tengan más prioridad de forma que siempre estemos dando el máximo valor a medida que avanza el sprint.

Sugerencias:

• Hacer ver al PO por que va esta(S) HU(s) de primero.- La verdad no es complejo-.
• Debido a que esta historia va primero solicitar los insumos para hacerla, en caso que no estén,  poner una fecha máxima para la recepción de insumos, en caso contrario,  hacer ver que si no se reciben oportunamente la historia se cae (no se culmina), y esos puntos no se logran.
• Lo ideal y recomendado es comenzar el sprint con los insumos (información, componentes, definiciones, etc) claros y resueltos para que el Sprint avance sin tropiezos.
• Si una es HU riesgosa y se observa que la posibilidad de completarla es casi nula debido a su complejidad:
• Definir un Spike (tarea dentro del sprint) con timebox definido (léase timebox=tiempo fijo) y objetivos definidos
• Ese spike debe tener como objetivo eliminar la complejidad y adquirir el conocimiento necesario para lograr estimar y construir esa HU en el siguiente sprint
• No tener muchas historias de usuarios riesgosas, a lo sumo 2 de un máximo de 7 HU (un sprint debería tener a lo sumo entre 6 y 8 HU), debido a que si son muchas el sprint puede ser un fiasco y no completar nada. (situación que viví y de la cual aprendimos como equipo)
• Enfocarse y enfocar al equipo durante la ejecución del sprint en máximo 2 historias al tiempo de forma que se evacue siempre lo primero. Esto en Kanban se llamaría un limite de 2.

Saludos y abrazos ágiles a todos

Jorge Abad