Leído y Recomendado: Retrospectivas, No sólo Accionables

Hola a todos

Les comparto este excelente post de Damian Buonmico @dbuo, sobre los resultados de la resultado de las retrospectivas en las cuales propone que no son solo accionables sino también acuerdos.


http://www.caminoagil.com/2016/07/retrospectivas-no-solo-accionables.html

Saludos ágiles
Jorge Abad

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

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

http://m.genbetadev.com/trabajar-como-desarrollador/la-metafora-de-la-deuda-tecnica

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.».

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

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

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.

Se 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.

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

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-

¿Cómo 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í.

La "EDT" podría verse así:

"EDT" Proyecto Ágil considerando un MVP y varios Releases (en negro están los elementos con incertidumbre a ser construidos)

Nota importante: Para complementar el entendimiento de cómo se construye un "proyecto" o mejor un producto ágil te sugiero estos dos post:

• Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor - clic aquí -
• De Colección: De la Idea hasta las Historias de Usuario del Sprint Backlog - Un Ejemplo Completo - 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:

• La primordial: Cual es objetivo del sprint, ¿qué capacidad de negocio queremos proporcionar al final del ciclo?
• Las secundarias:
• Entender qué se va a construir (parte estratégica)
• Decidir dada la capacidad del equipo cuantos ítemes de backlog cree el equipo que es capaz de llevar al DONE / COMPLETADO / TERMINADO (recomiendo este post Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad )
• Decidir cómo se va a construir (parte táctica)

Y durante todo el sprint, el equipo trabajará en:

• cumplir el objetivo del sprint
• Construir la mayor cantidad de producto posible(1) (software) que tenga calidad y valor durante el tiempo laboral del sprint y según las prioridades establecidas en el planning. (ver poster de responsabilidades de los diferentes roles durante el sprint - clic aquí)

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- .