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

¿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

Dos acciones simples para eliminar la sensación de que el daily se extendió. Via @sila_zenufana #Agile #scrum pic.twitter.com/g68dDBCBNV

— Jorge Hernán Abad L. (@jorge_abad) 14 de julio de 2016

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

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

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

Un ejemplo de artefáctos ágiles

Un ejemplo de artefáctos ágiles desarrollado por los estudiantes

• John Sebastian Assa Bolaños
• Jeremy Antony Bolaños Vasquez

De la Especialización en Construcción en Software de la Universidad de Nariño, Contiene:

• Elevator Pitch
• User Story Map
• Estimación top-down de costo y tiempo
• Historias de usuario
• Mockup de las historias de usuario

Del sistema S.R.E.D. (Sistema de Reserva de Escenarios deportivos) para acceder haga clic aquí.

Presentación: Hablemos de Deuda Técnica

Hablemos de Deuda Técnica from Jorge Hernán Abad Londoño

Algunos Tweets sobre Agilidad

"¿Si la organización no realizara este proyecto / producto, que impacto tendría?"@pmejia73 #ProductOwner #PreguntaPoderosa #AgileInception

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

---

"todo agilista debe preguntarse cada día
¿si hoy se interrumpe el proyecto, que producto de valor le dejé al negocio?" @pmejia73

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

---

This is so brilliant :) Really awesome :) “The Enemies of Adaptability” #agile #hr #leadership pic.twitter.com/f7bv5qxHmr

— Luis Gonçalves (@lgoncalves1979) 28 de junio de 2016

---

Implementa historias de 1/10 a 1/6 máximo de la velocidad del equipo https://t.co/b2DBcLJaUC#Ágil #Incremento #Scrum #HistoriaDeUsuario

— Lucho Salazar (@luchosalazarc) 28 de junio de 2016

---

The currency of Agile should be working software, not a velocity of story points. #agile #lean ^ @troytuttle pic.twitter.com/tI8XSQp0ra

— AgileFortune (@AgileFortune) 26 de junio de 2016

---

---

a coach is responsible for identifying and inducing productive discomfort ^ @KentBeck pic.twitter.com/8QWIdn49Cr

— AgileFortune (@AgileFortune) 23 de junio de 2016

---

"Responding to Change" is impossible unless code is easy:
to change
to maintain
to fix
to enhance. ^ @WoodyZuill pic.twitter.com/USVMuwwSSe

— AgileFortune (@AgileFortune) 21 de junio de 2016

---

Cambio de paradigma para el Testing Ágil
por @henrikkniberg #Agile #Scrum #Testing #AgileTesting pic.twitter.com/aBipD4wyJl

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

---

Definitivamente #TodoCambia y mucho más el sw
El problema radica en como responder al cambiohttps://t.co/ANeUFZ2taC pic.twitter.com/AT66hGzwI3

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

---

Tip para un Equipo #Scrum

Planear cada sprint la remoción de la #DeudaTécnica#TechnicalDebt #Agile pic.twitter.com/HP3rVP3GU1

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

---

#Agile es una cultura no un proceso
Pero la cultura Agile si generará un estilo #LEAN de procesos
Es crítico entonces hackear la cultura

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

Una Propuesta de Definición de Deuda Técnica

Mi propuesta de definición de #DeudaTécnica #TechnicalDebt pic.twitter.com/IjezTvRd2R

— Jorge Hernán Abad L. (@jorge_abad) 2 de julio de 2016