lunes, agosto 29, 2016

Gráficas para Facilitación de Retrospectivas y Reuniones




Hola a todos

Hace un tiempo luego del uso de Retromat (http://plans-for-retrospectives.com/index_es.html) (1) me he hecho muy amigo de la visualización de información en forma gráfica durante las retrospectivas (u otras sesiones de trabajo), a continuación les compartiré el conjunto de gráficas que he usado y me parecen interesantes.


Gráfica para evaluar la calidad de los canales de comunicación durante el sprint

Gráfica para clasificar el valor y riesgo de las historias de usuario o ítemes de backlog 
Gráfica para clasificar y priorizar historias según impacto y esfuerzo

Gráficas para "armar el escenario" y calificar el sprint al inicio de la retrospectiva


Gráficas para "armar el escenario" y calificar el sprint al inicio de la retrospectiva
Gráficas para calificar la eficacia de la retrospectiva





Si tienen más gráficas, bienvenida la retroalimentación y la mejora de este listado.


Saludos ágiles
Jorge Abad

Notas, aclaraciones, comentarios y referencias

  1. Retromat es una aplicación o repositorio de actividades de retrospectivas que te permite generar una amplia variedad de combinaciones para tus sesiones de mejora con tu equipo


Temario Curso Scrum - Duración 16 horas o 24 horas.




Hola a todos

Les comparto información del curso de Scrum de 16 horas (opcionales 8 horas más para el Rol de PO) , que tiene como objetivo principal proporcionar los fundamentos para Scrum Master, Product Owner y Team Member para un equipo Scrum.


Objetivos:
Compartir con los asistentes el espíritu de las Metodologías Ágiles, el Framework de Scrum y su aplicación a proyectos de software, desde una óptica teórico-práctica, basada en la experimentación y en juegos para habilitar la aprehensión del conocimiento, proporcionando los fundamentos para ser Scrum Master, Product Owner o Team Member de un equipo Scrum.

Dirigido a:
Profesionales del sector de TI involucrados en la construcción, gerenciamiento, dirección, ejecución de proyectos de software. Aplica para quienes se han desempeñado como Analistas, Desarrolladores, Testers, Arquitectos, Gerentes de Proyectos, Consultores Comerciales, Consultores de Preventa de Proyectos de Software, Gerentes de Áreas relacionadas con Tecnología, Líderes Funcionales de Áreas Usuarias de Software o similares, y se encuentren interesados ejecutar sus proyectos de una forma menos riesgosa, más exitosa y que se genere más valor, con equipos autogestionados y en ciclos cortos de trabajo.

Prerequisitos;
Uno muy sencillo: haber desarrollado software o haber estado involucrado en un proyecto de software, o estar próximo a comenzarlo.

Inversión 2 días: $600.000 
Inversión 3 días: $800.000 (incluye ROL Product Owner y Retrospectivas)

Agenda

  • Día 1
    • Sensibilización al Agilismo
    • Complejidad y Framework de Cynefin
    • Manifiesto Ágil
    • Explicación del Framework de Scrum
    • Elaboración de la Visión
    • Creación del Product Backlog empleando un User Story Map (parte 1)
  • Día 2 
    • Creación del Product Backlog empleando un User Story Map (parte 2)
    • Planificación de Releases y Elaboración del Presupuesto del Proyecto
    • Historias de Usuario
    • Taller de estimación y Planning Poker
    • Simulación de Scrum
    • Simulación de exámenes de certificación y pasos a seguir para lograr estar certificado
    • Cierre del Curso - Primera Parte
  • Día 3  (Opcional por $200.000 - sujeto a completar el cupo mínimo de asistentes- )
    • Tópicos del Product Owner
    • Agile Inception
      • Product Box
      • Product Vision Board
      • Product Backlog board
      • Cierre del Inception
    • Cómo se hace un Planning
    • Como se hace un Review
    • Dojo de Retrospectivas
    • Cierre del Curso - Segunda Parte

Ejemplos de Entregables Generados
La idea a través del curso es experimentar con ejemplos que nos permitan aprender y comprender mejor el conocimiento, haciendo honor a la frase "¡Dime algo y lo olvidaré, enseñame algo y lo recordaré, hazme participe de algo y lo aprenderé!". Ejemplos de los entregables generados son:


Fechas programadas
  • Grupo 2
    • Fecha inicio: Octubre 22 de 2016 
    • Cierre de Inscripciones y fecha límite de pago: 14 de Octubre de 2016
    • Ciudad: Medellín - Antioquia - Colombia
    • Días:  Octubre 22, 29 y 5 de Noviembre de 2016
    • Horario: 7 a 4 pm (1 hora de almuerzo, Almuerzo no incluido)
    • Cupo máximo: 25 asistentes
    • Descuento: 10% para grupos de 5 personas en adelante
    • Registro -  clic aquí - .


domingo, agosto 28, 2016

Comenzando con un equipo scrum: Personal Maps - Mapas Personales

Hola a todos

He notado en la vida que pequeñas acciones generan gran impacto, y hoy quiero compartirles algo que cumple estas características, que habilita la generación de equipo (1) entre quienes regularmente son compañeros de trabajo o integrantes de un grupo, esta sencilla herramienta son los Mapas Personales - o Personal Maps -(2), técnica en la cual empleamos un mapa mental para contar quienes somos (3). Este mapa mental se construye poniendo nuestro nombre en el centro y alrededor se complementa con diferentes aspectos que son detallados según se requiera, estos aspectos pueden ser.

  • Educación
  • Familia
  • Trabajo
  • Valores
  • Objetivos - metas
  • Hobbies
  • Casa
  • Amigos
  • Tres momentos importantes de la vida (4)
  • entre otros

Realizando este sencillo mapa todos sabrán mejor quienes somos y nos ayudará acortar la transición  entre ser compañeros de trabajo a un verdadero equipo.


Mapa Personal / Personal Map - Elaborado para el Taller de Energizando Equipos con Técnicas de Management 3.0 (5)


Sugiero que el Mapa Personal se elabore cuando estamos comenzando a crear un equipo de trabajo, y para su construcción sugiero dos técnicas:

  1. Cada cual elabora su mapa y lo explica a sus compañeros
    • Elaboración 10 minutos
    • Explicación 20 minutos (suponiendo un equipo máximo de 10 personas, tal vez tome más o menos tiempo dependiendo de la cantidad de integrantes)
  2. Otro elabora y explica mi mapa
    • Las personas que van a conformar el nuevo equipo se dividen en parejas 
    • cada pareja se entrevista mutuamente, elabora el mapa de su compañero (tiempo 10 minutos)
    • Cada persona explica el mapa de su compañero a todo el equipo (tiempo aproximado 20 minutos)
Luego estos mapas se pegan en la pared para que estén disponibles para todos y de esa manera se ayuda a mejorar las interacciones pues comprendemos que detrás de cada uno hay una vida, un otro, y no solo un cargo o rol con el cual interactuar.

Bienvenido el feedback y los resultados de esta experiencia

Saludos ágiles

Jorge Abad




Notas, aclaraciones, comentarios y referencias

  1. Esta técnica la conocí gracias a mi gran amigo Lucho Salazar - @LuchoSalazarC, agilista y apasionado por el Management 3.0 - lugar de donde viene esta técnica - .
  2. Management 3.0 Practice: Personal Maps
  3. Quienes somos es muy ambicioso, pero presenta algunos rasgos principales 
  4. Sugerido por mi
  5. Taller facilitado por Lucho Salazar y Mi persona (su servidor)

martes, agosto 23, 2016

Inceptions, con Lucho Salazar



¿Cómo nacen los productos grandiosos? De esos cuyos componentes hacen resonancia entre sí e impactan el 'modus vivendi' de quienes los usan o consumen.

¿Cómo defines su alcance?

¿Cómo estableces el Producto Mínimo Viable - MVP?

¿Cuáles son las distintas técnicas y prácticas ágiles para hacer Inceptions de gran calidad y que motiven al equipo a empezar un trabajo fabuloso?

¿Qué es eso del Elevator Pitch?

¿Y el Product Box?

Además:

El User Story Mapping

+ El plan de entregas

+ El plan de iteraciones

+ Otras técnicas y herramientas que nos ayudan no solo a entender lo que queremos construir (lo que quieren nuestros usuarios o clientes), sino también a lograr consenso entre los miembros del equipo y los interesados en el proyecto y producto o servicio que queremos diseñar y construir.

Estas y algunas otras cuestiones son las que compartí con mi gran amigo Lucho Salazar, con ejemplos concretos y prácticos, durante el Webinar del mismo nombre. El video lo pueden encontrar en:



Pueden descargar la presentación de:




Nota:
Este post lo podrás encontrar también en el blog de mi estimado amigo c@LuchoSalazarC (Inceptions, con Jorge Abad)

lunes, agosto 01, 2016

Leído y Redomendado: Coaching: Todo lo que necesitas saber del Coach

Hola a todos

Siguiendo con el tema del coaching, les comparto este post de  Maria Morales en el blog de Javier Garzas,


http://www.javiergarzas.com/2016/07/coaching-lo-necesitas-saber-del-coach.html

Saludos ágiles

Jorge Abad

Leído y recomendado. 4 Keys to Maximize Your Coaching

Hola a todos

Les comparto este post de coaching, excelente para sus sesiones como Scrum Master o Agile Coach.

https://jennifermounce.wordpress.com/2016/07/07/4-keys-to-maximize-your-coaching/


Saludos ágiles

Jorge Abad

Video Recomendado: Meetup Agilidad a Escala con Ángel Medinilla

Hola a todos

Les comparto excelente video de Angel Medinilla - @angel_m donde nos habla desde el core de agile como afrontar la transformación ágil, hablando desde SAFE, LESS, NEXUS, y cambiando el enfoque en vez de montar frameworks, ¿cual es problema que quiero resolver para: entrega de valor, colaboración, mejora continua, adaptación, de forma empresarial.?

saludos ágiles

Jorge Abad


domingo, julio 31, 2016

viernes, julio 29, 2016

Video: Tips de Kanban por integrantes de la comunidad ágil de latino américa

Hola a todos

Hoy quiero compartirles este excelente video de la comunidad ágil latinoamericana dandonos tips sobre kanban, a continuación presento los tips, pero es mejor el video.


Tips

  1. Mauricio Strione
    • Caballo de troya de la agilidad que nos permite seguir trabajando como veniamos e ir introduciéndonos poco a poco con ciertas pocas reglas a la agilidad
  2. Soledad Pinter
    • El tablero kanban fisico como radiador de información, permitiendo mejorar el procesos y observar cuellos de botella
  3. Ricardo Colusso
    • Un equipo siempre se adueñe del tablero, (no es impuesto), ir mejorandolo poco a poco con colores.
    • Usar una bolsa despues del DONE, para ver cuanto se logro revisarlo en una retroespectiva
  4. Carlos Peix
    • Forma para representar el proceso actual - Gemba -(que no sea el proceso ideal, ni mentiroso)
  5. Thomas Wallet
    • Foco (limitar el wip) para que no se hagan muchas cosas a la vez, para que el equipo colabore y encuentre la mejor forma de hacerlo
    • si hay tiempo muerto debido a limitar el wip usarlo para mejorar y pensar ideas de mejora
    • Kanban nos permite ser agiles pues nos permite, explorar, inspeccionar o adaptar, mejorando el proceso
    • Poner colores, puntos rojos
    • El tablero evoluciona para que el equipo interactue mejor
    • si entre dos columnas las transición no es clara, tal vez se puedan unir
  6. Jader Rojas
    • Instrumento para energizar al equipo, debemos estar alineados a un impacto que alegre el equipo
    • Si hacemos mucho y no hay felicidad es importante revisar
  7. Jose Sandoval
    • Lead time = tiempo de salida del tablero - tiempo de entrada al tablero
    • revisar el lead time para 
      • obtener acuerdos de niveles de servicio (ANS o SLA), con base en los promedios del lead time
      • o como optimizar
      • o poner ANS o SLA como meta o identificar si hay ANS inviables

Saludos Ágiles

Jorge Abad

domingo, julio 24, 2016

Leído y Recomendado: La metáfora de la deuda técnica

Excelente post de Javier Garzás @jgarzas en genbetadev sobre la deuda técnica



Saludos ágiles

Jorge Abad

Leido y Recomendado: El Efecto Dunning-Kruger o cómo descubrir a un incompetente.

Tomado de: http://disenosocial.org/el-efecto-dunning-kruger/

(recomiendo leer el original, tiene excelentes videos y comentarios, lo copié por aca para no perder el registro)

Este sesgo, es atribuido a una inhabilidad meta-cognitiva del sujeto de reconocer su propia ineptitud. Debido a que su habilidad real debilitaría su propia confianza, ya que los individuos competentes asumen, falsamente, que otros tienen una capacidad o conocimiento equivalente al suyo.
“La pasión asociada a una discusión es inversamente proporcional a la cantidad de información real disponible.” Ley de la controversia de Benford.
El fenómeno fue demostrado en una serie de experimentos realizados por Justin Kruger y David Dunning, de la Universidad de Cornell (Nueva York, EE. UU.). Sus resultados fueron publicados en el Journal of Personality and Social Psychology de diciembre de 1999.
En relación a ella, David Dunning y Justin Kruger de la Universidad de Cornell concluyeron:
«Esa incompetencia les impide a su vez darse cuenta de la ausencia de esa habilidad en ellos mismos así como reconocerla en otros individuos.».
Dunning-Kruger-disenosocial
Las investigaciones confirman que el patrón de persona “incompetente e inconsciente de su incompetencia” se replica en situaciones de la vida real, no sólo en pruebas abstractas de laboratorio”.
“Uno de los dramas de nuestro tiempo está en que aquellos que sienten que tienen la razón son estúpidos y que la gente con imaginación y que comprende la realidad es la que más duda y más insegura se siente”. Bertrand Russel
Dilbert_-_Los_ingenieros_y_su_empatia_social
Kruger y Dunning investigaron cierto número de estudios previos que tendían a sugerir que en diversas habilidades como la comprensión lectora, conducción de vehículos de motor, y juegos como el ajedrez o el tenis, “la ignorancia frecuentemente proporciona más confianza que el conocimiento” (como dijo Charles Darwin). Su hipótesis es que, en una habilidad típica que los humanos poseen en mayor o menor grado:
  1. Los individuos incompetentes tienden a sobrestimar su propia habilidad.
  2. Los individuos incompetentes son incapaces de reconocer la habilidad de otros.
  3. Los individuos incompetentes son incapaces de reconocer su extrema insuficiencia.
  4. Si pueden ser entrenados para mejorar sustancialmente su propio nivel de habilidad, estos individuos pueden reconocer y aceptar su falta de habilidades previa.
>> Te puede interesar: Formación en comunicación y Diseño Social
dilbert-disenosocial-leyes
CONCLUSIONES
El Dunning-Kruger nos enseña que antes de valorar la opinión de alguien negativamente hay que considerar la posibilidad de que no se de cuenta de que está errado porque psicológicamente no puede hacerlo.
Y eso nos lleva a otro problema: Los equivocados podemos ser nosotros y no ser conscientes de ello.
Porque este efecto nos sucede a todos en función de cada habilidad.
Es decir, alguien puede ser un experto en un tema o el más capaz del mundo en una determinada habilidad, y sin embargo no estar capacitado para darse cuenta de que no lo es en otros temas o habilidades.
En todo caso, cuando hay una divergencia seria que impide avanzar, siempre hay que tener en cuenta que se puede estar produciendo y actuar en consecuencia.
disenosocial-Dunning-Kruger-equivocado-internetSe trata de comprender que probablemente es un tema de formación. Hay que formar al individuo tanto para que pueda entender el problema como para que se dé cuenta de verdad de que antes no lo entendía.
Son dos las soluciones que se proponen para evitarlo en equipos de trabajo: No conformarse sólo con el propio juicio sobre un tema. No olvidemos que si no estamos preparados para tomar la decisión tampoco estaremos preparados para darnos cuenta de que no lo estamos.
Nuestro consejo es apostar por la formación continua y de calidad para mejorar el conocimiento del capital humano y la capacidad para reconocer las carencias propias que tenemos que solucionar.
En todo caso, saber que existe nos debe enseñar a ser humildes. A saber que en nuestro cerebro hay algo que nos lleva en ocasiones a ver con total nitidez que estamos en posesión de la razón en un tema y sin embargo tratarse de una ilusión.
Y eso, cuando alguien dirige un equipo o una empresa puede llevar a tomar decisiones muy perjudiciales.
Por eso, te invito a que en la próxima discrepancia que tengas con alguien, en la empresa o en tu vida particular, pares un momento y reflexiones… ¿realmente estás más preparado que tu interlocutor en ese tema o lo que pasa es que tus conocimientos de la materia no son los suficientes para que puedas comprender que el otro tiene razón?.


APROVECHAMOS PARA DEJAROS, YA EN TONO DE HUMOR,
OTRAS LEYES MENOS “CIENTÍFICAS” PERO IGUAL DE CURIOSAS:
Si mezclamos el principio de Pareto con el Efecto Dunning-Kruger, el cual afirma que personas con escaso conocimiento tienden a pensar sistematicamente que saben mas que los demás, obtendremos el principio de meta-Pareto:
“Al menos el 80% de la población piensa que esta entre el 20% más inteligente.”
Principio de Meta-Pareto.
Arthur Charles Clarke, el autor de la novela “2001 Odisea en el espacio” establecía una acertadísima primera Ley de Clarke en 1962:
“Cuando un anciano y distinguido científico afirma que algo es posible, casi seguro esta en lo cierto. Cuando afirma que algo es imposible, muy probablemente se equivoca.” Primera Ley de Clarke.
El principio de Hanlon también es llamado la navaja de Hanlon, muy similar al concepto de la navaja de Occam:
“Nunca atribuyas a la maldad lo que puede ser explicado por la estupidez”
Principio de Hanlon.
¿Podría explicar el Principio de Halon, por ejemplo, la Crisis en España?Una de las leyes mas conocidas en Internet es la Ley de Godwin dice así:
“A medida que avanza una discusión en Internet, la probabilidad de que aparezca una comparación en la que se mencione a Hitler (o a los nazis) tiende a uno.”
Ley de Godwin
El Principio de Peter hace referencia a lo fácil que es encontrar empleados que son totalmente incompetentes en un puesto de trabajo:
“En una jerarquía, todo empleado tiende a ascender hasta llegar a su nivel de incompetencia”. Principio de Peter.
tiradilbert_disenosocial_leyes
Existe una variación sarcástica de este principio, creada por Scott Adams: El principio de Dilbert (basado en sus tiras cómicas), en la que explica que los empleados mas incompetentes suelen estar en cargos directivos para limitar el daño que pueden hacer.
La Ley de Danth es particularmente destacable en entornos en los que los usuarios no aceptan críticas:
“Si en una discusión tienes que insistir en que ganaste, es probable que hayas perdido miserablemente.” Ley de Danth.
Las Leyes de Wilcox-McCandlish son un conjunto de leyes, corolarios y excepciones sobre las discusiones que se salen de su tema principal. Aquí una de ellas:
“Si una discusión se ha caldeado lo suficiente (flame), todos los cambios de tema o de dirección de la discusión serán a peor.” Excepción al primer corolario de McCandlish.
La Ley de Hofstadter, creada por Douglas Hofstadter, hijo del científico que dio nombre al personaje de Leonard en la serie Big Bang Theory:
“Una actividad siempre lleva más tiempo del esperado, incluso si tienes en cuenta La Ley de Hofstadter.” Ley de Hofstadter.
La Ley de Parkinson (1957), en relación con la productividad en la realización de trabajos, fue enunciada por Cyril Northcote Parkinson:
“El trabajo se expande hasta llenar el tiempo de que se dispone para realizarlo”.
Primera Ley de Parkinson
Corolarios Ley de Parkinson




Scrum vs Tradicional / Scrum vs Traditional


Hola a todos

Hace unos meses me encontré la siguiente imagen en internet (no encontré la fuente)






y no me gustaba a mi y a varios de mis amigos agilistas (Lucho Salazar @luchosalazarc y Leonardo Agudelo @sweepnoise ) porque pareciera que en Scrum comenzamos perdidos, aspecto falso, pues nos mantenemos repriorizando dirigidos por la visión del producto y valor de negocio.  

Debido a esta reflexión había quedado con el pendiente interno de proponer otra distinta, la cual comparto a continuación.




Bienvenido el feedback.

Saludos ágiles

Jorge Abad



Nota:

  • Si alguien conoce el autor de la imagen original por favor me lo comparte por este post para dar los debidos créditos-

sábado, julio 23, 2016

¿Como luce la EDT para un proyecto Ágil / Scrum?





Hola a todos

Cuando desde la gerencia de proyectos tradicional (PMP) nos enfrentamos a un proyecto ágil creemos que todo encaja y que podemos emplear los mismos artefactos, entregables y estrategias para ambos tipos de proyectos, esta aproximación nos lleva "gerenciar" de forma equivocada y en consecuencia a fallar, es necesario reconocer que gerenciar un proyecto tradicional o de gestión predictiva es diferente a gerenciar un proyecto adaptativo - como son los ágiles, y en especial los que adoptan scrum como marco de trabajo-. En este post quiero compartirles la diferencia entre una EDT tradicional y una EDT ágil (si es que se le puede decir así)


Comencemos

Recordemos que la línea base del alcance para proyectos tradicionales esta constituida por tres artefactos.
  • Enunciado del Alcance
  • EDT (esquema de desglose de trabajo) (1)
  • Diccionario de la EDT
Donde la EDT reflejará TODO Y SOLO TODO EL ALCANCE A SER CONSTRUIDO. A continuación presento un ejemplo de una EDT correspondiente a un proyecto de software tipo RUP con alcance fijo.
EDT de un proyecto de software realizado empleando RUP
Y justo en la palabra alcance es donde comienza la fricción entre tradicional y ágil, pues en software nos interesa es generar valor, no alcance, y es probable que la solución encuentre el resultado esperado del negocio antes (o después (2)) de haber construido todo el alcance planteado

Diferencia entre tradicional y Scrum

Aun así, si de obstinados fuéramos a realizar la EDT del proyecto en Scrum  resultaría en algo como:



EDT de un Proyecto en Scrum
Y la fracción a correspondiente correspondiente a cada sprint sería similar a la siguiente imagen
EDT correspondiente al Sprint 1


Donde, para acabar de ajustar no tenemos certidumbre sobre:
  • si el producto en cuestión requerirá todos estos releases
  • o si un release requerirá todos los sprints planteados
  • o si un sprint contendrá todos las historias planeadas pues la continua repriorización del backlog no nos permite predecirlo(3)


Es por tanto que en un artefacto como la EDT no quedaría registrado todo el alcance a ser construido y podría llegar a verse de la siguiente manera
Propuesta de EDT para proyectos Scrum

Este artefacto - la EDT - , como vemos. se queda corto para la gestión del valor y del alcance del proyecto scrum, es por eso que para este tipo de proyectos se emplean otro tipo de herramientas para la gestión del alcance y por ende del Product Backlog (que es en donde reside el alcance y el valor del producto y del proyecto), una de esas herramientas es el mapa de historias de usuario (user story map), el cual permite:
  • Identificar y gestionar los releases
  • Identificar y repriorizar las historias épicas a construir
  • Visualizar los objetivos de negocio a cumplir




Para saber más del User Story Map  hacer clic aquí.

Bueno hasta acá esta disertación y lo que quería compartirles, bienvenido el feedback.

Saludos ágiles

Jorge Abad



Notas, Aclaraciones, Comentarios y Referencias

  1. También conocida como WBS - Work Breakdown Structure - en inglés
  2. Dependiendo del product owner.
  3. La constante repriorización agotaría cualquier gestión rigida del proceso de control de cambios.

El compromiso del Sprint mal entendido

Hola a todos

En scrum durante el planning del sprint se establecen varias premisas para poder avanzar bajo el escenario de la incertidumbre:
Y durante todo el sprint, el equipo trabajará en:


Pero no todos lo entienden así

Existen implementaciones de scrum donde:
  • el compromiso TIENE que ser cumplido
  • el compromiso es IMPUESTO
  • se considera al sprint como una mini-cascada
  • existe un microcontrol durante todo el sprint
  • y la gerencia se "montó" en scrum sin entender como funcionaba y solo por moda
Es allí donde se observan escenas como la siguiente


Aunque es cómica la exageración, se que varios de los que leemos este blog (incluido yo) hemos estado en situaciones así, les confirmo, este no es el espíritu de Scrum, esto no es lo que se busca, además esto no es Scrum.

Respecto a la escena, si al final del ciclo si la cantidad de ítemes identificada no es cumplida, pues se realizará una retrospectiva y se mirará como mejorar tanto en lo técnico, táctico como en en las relaciones para ser exitosos el próximo ciclo.

Ojo, no se trata de que si no logramos el objetivo, no nos importe (2), pero tampoco se trata de imposiciones al equipo, se trata de poder trabajar de forma autogestionada, táctica,  profesional y con foco durante el periodo del sprint para hacer lo más que se pueda, con calidad y valor.

Espero haber ayudado un poco al entendimiento de este aspecto.

Saludos ágiles y bienvenido el feedback

Jorge Abad

Notas, aclaraciones, comentarios y referencias

  1. "Posible" se refiere a que dados los impedimentos, la incertidumbre, las habilidades técnicas, el equipo, se construirá lo más que se pueda bajo el escenario que se presente.
  2. Recomiendo ver este post para entender mejor esta afirmación -Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado- .
     

sábado, julio 16, 2016

¿Cuáles son las fronteras de un scrum master como coach?

(1) Esta imagen muestra el área de influencia y trabajo del Scrum Master (solo el trabajo de equipo y el proceso scrum), el resto es área de trabajo personal


Hola a todos

Hace unos días reflexionaba sobre ¿hasta dónde debería llegar el Scrum Master en su rol de Coach del Equipo y del Product Owner?(2)(3), pues muchas veces observo compañeros que estoy acompañando en este proceso de ser Scrum Master  en líos cuando aparecían personas dentro de sus equipos que:
  • no querían o no les interesa trabajar en equipo
  • son lobos solitarios
  • son perezosos 
  • incumplen frecuentemente sus compromisos ante el equipo
  • maltratan constante a sus compañeros con su comportamiento y palabras
  • son tóxicos
  • o que con su dinámica de día a día afectan de forma negativa al equipo de trabajo

Estas personas se convierten en un reto tanto para el equipo como para el scrum master, ni con las retrospectivas, ni con sesiones personales de feedback se logra que las condiciones mejoren, es allí donde el Scrum Master debe reconocer que este no es su área y debe delegar esto en talento humano organizacional (o recursos humanos - como se llama en algunas empresas -), en este caso es posible que se activen varios caminos:
  • el team member comience un trabajo de mejora acompañado por talento humano
  • el team member comience un trabajo sicologico
  • el team member no continue trabajando con el equipo
  • el team member no continue en la organización

No son caminos fáciles, pero en Agile las disfunciones se evidencian más rápido pues los ciclos cortos de feedback habilitan que los problemas salgan mas pronto a flote.

Espero este post sea de ayuda, bienvenido el feedback


Saludos ágiles
Jorge Abad


Notas, aclaraciones, comentarios y referencias

  1. Esta imagen muestra el área de influencia y trabajo del Scrum Master (solo el trabajo de equipo y el proceso scrum), el resto es área de trabajo personal
  2. Realicé esta pregunta al foro de ágiles latinoamérica  para ver las respuestas  hacer clic aquí
  3. También realice a Martin Alaimo @MartinAlaimo (autor y agilista de renombre en Latinoamérica) y esta fue su respuesta: "Desde el punto de vista del Coaching, uno debería darse cuenta cuándo alguien está fuera de las posibilidades del coach y ahí entra en juego la humildad para decir "con esto yo no puedo" y derivar el caso a un profesional"

Dos buenas prácticas para el daily

Una dinámica para aprender escucha activa - escucha inactiva




Hola a todos

Hace poco me di cuenta (me hice consciente) de que estaba en una reunión pero que no estaba 100% presente, no estaba 100% en actitud de escucha activa, tenia un discurso interno en unos temas personales que no me dejaba:
  • entender que estaba pasando
  • entender lo que estaban hablando y como me estaba aportando
  • poder aportar cuando sea necesario
  • poder preguntar cuando no entendiera algo.
También me he dado cuenta que esto mismo sucede cuando en una reunión
  • alguien lleva un computador (cosa que yo he hecho, mea culpa) para hacer otra cosa (contestar correos, o chatear con alguien de la oficina) o  mientras los otros hacen definiciones o se toman decisiones, la persona del computador solo asiente (mueve su cabeza) y sigue en lo suyo.
    • pasara como si algo que escucho "le pareciera","le sonara" pero no pudo absorberlo y aportar
  • Lo mismo sucede con quienes usan su celular durante la reunión  (cosa que yo he hecho, mea culpa) para responder un whatsapp, revisar facebook o distraerse y llega al punto que estan completamente aislados y lo único que hacen es asentir, o cambiar la cara, sonriendo o poniéndose serios según lo que leen, pero realmente no esta conectados.
Dado este escenario me dí a la tarea de crear una sencilla dinámica para ilustrarle a los equipos lo ineficiente que es este tipo de multitasking, lo que es la escucha activa y la escucha inactiva, a que impacto tiene en el entendimiento de nuestro entorno, Es simple:
  • Insumos
    • Tres participantes
      • Uno que será EL FACILITADOR
      • otro será EL NARRADOR quien contará algo
      • otro será EL MATEMÁTICO que trate de hacer multitasking o escucha inactiva
    • Un cronometro
  • Actividad
    • El Facilitador tendrá el cronómetro vigilando que no se superen los dos minutos
    • El Narrador durante dos minutos contará al detalle exhaustivo algo de su vida diaria ejemplo: ir al trabajo, regresar a la casa, lo que hace un domingo normal
    • El Matemático estará realizando mentalmente los múltiplos de 7, ej: 7, 14, 21, 28, incrementalmente hasta que terminen los 2 minutos, y pero tratará de poner atención a la historia del Narrador pues luego este le realizará preguntas sobre su narración
    • El Facilitador estará tocando el hombro del Matemático para que diga en voz alta en que multiplo va
  • Al finalizar los dos minutos, el narrador hará preguntas sobre detalles de su narración al matemático validando que haya entendido la narración y detectando que tanto comprendió.
  • Luego entre los tres participantes concluyen acerca de la actividad

Variaciones
  • Variación 1: Matemáticamente más dificil
    • El facilitador le puede decir al matemático que sume algún numero de un dígito a la serie, ejemplo, va en 63 y se le pide que sume 5, entonces seguirá en 68, 75, 82 etc
  • Variación 2: Practicando escucha activa
    • Repetir la sesión de 2 minutos pero esta vez el matemático hará preguntas, y parafraseará al narrador para entender lo que dice 
    • Luego el Matemático repite la narración y el narrador la califica
  • Variación 3: El matemático narrador
    • Se le pide al matemático que realice la narración y el narrador la califica
  • Variación 4: De matemático a revisor de facebook, whatssapp y correo
    • En vez de realizar las multiplicaciones se le pide al Matemático que revise honestamente  su smartphone ya sea facebook, whatsapp o su correo mientras el otro habla.
Estas variaciones pueden usarse según desee el facilitador.

Hasta acá la dinámica, recomiendo ver este video para aprender más de la escucha activa http://www.lecciones-aprendidas.info/2016/04/saber-escuchar-escucha-activa.html

Bienvenido el feedback y compartir las experiencias empleándola.



Saludos ágiles
Jorge Abad

Charla de Agustin Pichot sobre motivación y liderazgo

Excelente charla de motivación de Agustín Pichot


miércoles, julio 13, 2016

Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad

Hola a todos
Muchas veces veo a los equipos, scrum masters y product owners enfrascados en discusiones sobre la puntuación de los ítemes de backlog y la forma de obtenerla, este no debe ser el foco (desde mi punto de vista)

Pongamos las cosas claras, según la guía lo más importante del sprint planning es definir el objetivo que se quiere lograr (o la capacidad de negocio que vamos a proporcionar con el trabajo de esas máximo 4 semanas - prefiero pensar que son 2 semanas, que es un tamaño más sano de sprint - ), en segundo lugar tenemos:
  • qué vamos a hacer
  • cómo lo vamos a hacer

Ese ¿qué? tiene como entrada clave la pregunta

¿que capacidad tenemos?,

basado en esta pregunta el equipo determinará a cuantos ítemes de backlog se compromenten.

Si los ítemes de backlog (historias de usuario, casos de uso, requisitos en prossa o lo que sea) se estiman en:
  • Días productivos (un punto = 1 dia productivo)
  • basados en una funcionalidad pivote ( 1 punto = la construcción de una funcionalidad pequeña que agrega valor)
  • basado en cantidad de historias de usuario (´por ejemplo: somos capaces con 6 historias de usuario en promedio por sprint)
  • en ojo de buen cubero (creemos que somos capaces de hacer esta cantidad de historias, por que una vocecita interior nos lo dice), o
  • en Garrapatandamandapispuntos, donde un Garrapatandamandapispunto equivale a 3 escaramanditabitas

Es perfecto, pues llega un momento donde el equipo dice (independiente del método que elijan):

!No más¡, creemos que somos capaces de hacer hasta acá en este sprint.

Se que es dificil soltar nuestro afán de medir, pero dada la incertidumbre que tiene asociado el software ¿qué ganamos con ser más precisos?, ¿gastar más tiempo en estimaciones que igual van a fracasar?

Hasta acá esta pequeña reflexión

Saludos Ágiles
Jorge Abad

martes, julio 12, 2016

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