domingo, enero 24, 2021

Video: Scrum: cambió la guía ¿y ahora qué hago?



Hay que Ahorrar Costos, ya Aprendimos Ágil, Volvamos a la Estimaciones


Hola a todos

El COVID19 generó impactos a todo nivel, el primero y más doloroso de todos en vidas irrecuperables, pero adicionalmente continúa golpeando la economía, la forma en que trabajamos, nos reunimos, interactuamos, entre muchos otros. Hoy quiero poner luz en algo que he observado como Líder Regional Ágil dentro de una gran corporación, y es que muchos clientes en diferentes regiones afirman debido a la pandemia de forma más o menos similar: 


"¡Hay que controlar costos, ya aprendimos Ágil, volvamos a las estimaciones!"

 

Es decir, vamos a hacer estimaciones al inicio del proyecto pero ejecutaremos a tiempo, alcance, costo fijos, scrum con sprints fijos y plan de releases inamovible (te recomiendo leer; ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?), esto siempre me recuerda la citada frase de mi gran amigo Lucho Salazar @LuchoSalazarC) "Exigir los compromisos no los garantiza". Lamentablemente, nada más en contra de los propios intereses de la organización, pues pierde la organización y probablemente también lo haga el proveedor, estas son las razones:

  • Una estimación buena implica conocer "TODO" desde el inicio, cosa que nunca tendrás, en un mundo tan cambiante como este, considerando adicionalmente la distorsión e inestabilidad que ha generado el COVID19.
  • Genera desperdicios al construir producto innecesario que fue pactado a construirse totalmente desde el inicio.
  • Genera desperdicios funcionales y técnicos de partes innecesarias.
  • Nunca se logran identificar todas las dependencias a priori.
  • El plan perfecto no existe, y como lo dice este tweet contestado por Elon Musk con un 100 : "El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad"
  • Siempre que hay dependencias externas hay probabilidad alta de fallo, pues las dependencias no siempre están a tiempo.
  • Implica que se construye algo que se pactó, así sea que se identifique que no va a generar valor
  • Quien estima, extenderá tiempos en búsqueda de cubrir las incertidumbres.
  • Entre más grande el proyecto, más grandes las suposiciones, más grandes los riesgos, más grandes "los colchones", mayor costo, y mayor probabilidad de fracaso.
  • El enfoque en los costos y en el ahorro, pondrá foco en las áreas de gestión en el ahorro, en la maximización del tiempo comprado y en el cumplimiento estricto de lo pactado en etapas tempranas, pero por lo general (y lo he observado muchas veces), nunca se valida la generación de valor, ni se ve con buenos ojos la adaptabilidad a nuevas circunstancias.

Mi recomendación para estos casos siempre es:

  • A nivel de priorización y estimación
    • Priorizar las iniciativas con casos de negocio livianos, es decir, la estimación no podemos evitarla, pero no tiene sentido invertir demasiado tiempo en una actividad en la cual más le inviertas, más desperdicio es. 
    • Usar como método de priorización de iniciativas del Costo del Retraso dividido por la duración (conocido como CD3 - Cost of Delay Divided by Duration - o WSJF -Weighted Shortest Job First -) (http://www.lecciones-aprendidas.info/2020/09/Un-Ejemplo-Practico-de-Gestion-Lean-Agile-de-Portafolio.html ver diapositivas18,19 y 20)
    • Asignar un presupuesto al programa o portafolio de forma que se esten buscando siempre las alternativas de mayor impacto y valor para el negocio.
    • Orientar las áreas de gestión a que se cuestione siempre la generación y validación del valor generado sobre el cumplimiento, ya hemos vivido, que cumplir el plan no implica generar valor, solo cumplir y ya. Son innumerables los casos de proyectos que se engavetan o nadie usa usa.
  • A nivel de ejecución
    • Poner un Product Owner empoderado que:
      • priorice por valor
      • acompañe al desarrollo
      • decida qué construir y qué no sobre el producto
      • asegure que se esté construyendo el producto correcto
    • Validar constantemente la generación de valor, poniendo en producción versiones del producto, de forma que se identifique si se requiere detener el desarrollo o  perseverar para mejorar los resultados.
En resumen, el costo se controla más construyendo el producto correcto y valioso, que desde la estimación, al menos en el mundo de tecnología y desarrollo de soluciones de software.

Saludos ágiles,

Jorge Abad

Tweet: "El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad". - Nicoll Hunt

 

 

"El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad". - Nicoll Hunt


Algunos ciclos en gestión de proyectos, gestión de productos, gestión de equipos en el mundo del software, por John Cutler

 ¿Por qué ese equipo siempre parece asumir demasiado trabajo?

 (Why does that team seem to always take on too much work? )



¿Por qué ese recurso compartido parece estar perpetuamente falto de personal?
(Why does that shared resource seem to be perpetually under-staffed?)



¿Por qué el equipo sigue empezando a planificar grandes lotes?
      (Why does the team keep slipping into planning big batches?)




¿Por qué una óptica miope se concentra en aumentar la velocidad, finalmente daña la calidad?
(Why does a myopic focus on increasing velocity eventually hurt quality?)


¿Por qué las historias del equipo nunca son "suficientemente buenas"?
(Why are the team’s stories never “good enough” ?)



¿Por qué mi equipo me oculta cosas?
(Why does my team hide things from me?)


Bueno ... viste lo que pasó cuando tratamos de asignarles un problema, ¿verdad?
(Well…you saw what happened when we tried to just hand them a problem, right?)



BONO (que envuelve muchas de estas)
{BONUS (that wraps up lots of these)}



Este es el tweet original


lunes, enero 18, 2021

Retrospectivas con Propósito

 


En ocasiones el facilitador puede al principio de la sesión compartir una pregunta o propósito poderoso que requiere resolverse en la retrospectiva.

La idea es que conjuntamente todas las actividades y agenda de la retrospectiva giren alrededor de ese propósito compartido.

Este propósito puede identificarse tanto por el facilitador y los hechos que observó, sugerido por algún miembro del equipo o alguien externo.

Algunas ideas de preguntas o propósitos poderosos pueden ser:

·         ¿Qué tenemos que hacer para ser un equipo de alto rendimiento?

 

·         ¿Cómo vamos a resolver la deuda técnica que nos atormenta?

 

·         ¿Qué nos está apartando de nuestro propósito como equipo?

 

·         ¿Cómo vamos a mejorar las interacciones con “x” área de la organización?

 

·         ¿En qué reprocesos estamos incurriendo? ¿Cómo los estamos generando? ¿Cómo podemos evitarlos?

 

·         ¿Qué actividades nos están desenfocando comúnmente de nuestro objetivo del sprint?

 También puede ser poner una palabra o concepto y conversar alrededor de él, algunos ejemplos pueden ser:

·         Software funcionando sobre documentación extensiva


·         Interacción

 

·         Resultados

 

·         Cambio

 

·         Empatía

 

·         Excelencia

 

·         Respeto

 

·         Comunicación

 

·         Mejora implacable

 

·         Flujo

 

·         Valor

 

·         Desperdicio

 

·         Valores de Scrum

 

·         Valores del Equipo

 

·         Valores de la Organización a la que se pertenece

 

O tal vez, por votación elegir entre varios de estas ideas claves u otras que te llamen la atención. 

Se requiere de lectura del facilitador respecto al equipo, es decir, entender el momento que están atravesando, para saber si el tema debe ser abordado o aplazado.

Una buena finalización de la retrospectiva sería evaluar con los asistentes las siguientes preguntas:

 

·         ¿Logramos el propósito que buscábamos con esta retrospectiva?

 

·         ¿algo que consideren que deba ser compartido?

 

Saludos ágiles

Jorge Abad




Este es uno de los miniartículos del mi minilibro: "Algunas ideas sobre retrospectivas". ¿Querés saber más sobre retrospectivas o cómo desarrollo este concepto en el minilibro?

A continuación te comparto el link en Amazon:

miércoles, enero 13, 2021

Los Dos Movimientos de la Retrospectiva

Una retrospectiva requiere de dos movimientos claves, una mirada para entender el pasado y una para el futuro. Se asemeja a la diástole y la sístole del corazón, los movimientos de la retrospectiva: 


Diástole = ¿Qué pasó?

Sístole = ¿Qué vamos a hacer?


Sin importar el formato, la guía, el esquema que encuentres, si logras resolver estos dos movimientos en tus retrospectivas estarás logrando el objetivo para el cual fueron planteadas en entornos ágiles.





Este es uno de los miniartículos del mi minilibro: "Algunas ideas sobre retrospectivas". ¿Querés saber más sobre retrospectivas o cómo desarrollo este concepto en el minilibro?

A continuación te comparto el link en Amazon:

miércoles, diciembre 30, 2020

Frase: Excelencia a todo nivel

 

Algo que no tiene sentido es que un equipo Ágil o Scrum construya un producto de mala calidad técnica o entregue un producto o servicio peor de como lo encontró - Jorge Abad


“Something that does not make sense is that an Agile or Scrum team builds a product of poor technical quality or delivers a worse product or service than they found it.” - Jorge Abad




Frase: Anyone who keeps learning stays young - Cualquiera que siga aprendiendo permanece joven

He pensado que quizá te guste esta cita de "How Google Works", de Eric Schmidt, Jonathan Rosenberg .


"Henry Ford said that “anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. The greatest thing in life is to keep your mind young.”"

--

"Henry Ford dijo “cualquiera que deja de aprender es viejo, ya sea a los veinte u ochenta años. Cualquiera que siga aprendiendo permanece joven. Lo mejor de la vida es mantener la mente joven.”"


Empieza a leer este libro gratis: https://a.co/dV6TFIK

lunes, diciembre 28, 2020

De Colección: Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización

 


Hola a todos,

Con frecuencia me encuentro dentro de las organizaciones ya sean clientes o proveedores, expresiones en los gestores del personal, tales como:

"La ocupación de las personas debe ser del 100%, para eso se les paga"

o esta otra

"Exíjanles el 120% para que den el 100%"

Luego de esto, se activa el liderazgo egipcio, los látigos, las zanahorias, la microgestión, las acusaciones de distracción, el estrés, la sensación de esclavismo, el inflar las tareas para poder tener espacios para descansar, el ambiente se vuelve tóxico, y cualquier sentido de pertenencia se convierte en desvinculación y ganas de renunciar.

Como te puedes dar cuenta esto termina degradando el sistema, en vez de mejorarlo. El objetivo de este artículo es llevarte a que comprendas que:

"Una persona o un equipo con una asignación del 70% al 80% es mucho más productivo y eficiente que uno con una ocupación del 100%"

Debido a que las personas y equipos tienen espacios para:
  • la mejora continua individual
  • la mejora continua grupal
  • para aceptar la variabilidad
  • hacer con mejor concentración las tareas
  • mejora colaborativa
  • eliminar desperdicios
  • innovar
  • agregarle valor a lo que hacen
Si lo deseas puedes terminar acá de leer, pues lo que sigue es una larga justificación del por qué de esta afirmación, así que comencemos:


No podemos tratar a las personas como máquinas

En esta parte no voy a apelar a la evidencia científica sino a la experiencia personal, actualmente estamos en el 2020, el año en que estalló la pandemia del COVID-19 y muchos de nosotros nos hemos movido al trabajo virtual, adicional al impacto de esto en nuestras vidas,
  • ¿no han sentido lo pesado de tener una agenda completa 100% todos los días, por varias semanas?
  • ¿al final de día no terminan sintiéndose exhaustos y quemados?
  • ¿no les ha hecho falta espacios para café y conversar e interactuar con sus compañeros? ¿tener conversaciones interesantes y conversaciones triviales?
al menos yo sí, llevándome al punto que he tenido que insertar en mi agenda espacios para descansar, pararme, tomarme un café, y estos descansos han permitido que refresque mis ideas, que tenga más fluencia y mejor concentración, que trabajar 100% todos los días.

Ahora, no niego que hay días de sobrecarga y se asumen, pero un ritmo sobrecargado de forma constante termina yendo en contra de las personas y de los equipos.


Dice Sun Tzu en el Arte de la Guerra:
"Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho: "Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces, aunque tengas consejeros sabios, al final no podrás hacer que las cosas salgan bien."

Te recomiendo estos dos artículos:
  • Ritmo Sostenible sobre Ritmo Insostenible - (clic aquí)
  • Recomendaciones sobre el sobreesfuerzo del equipo en un proyecto - (clic aquí)

En el trabajo de conocimiento nuestra aproximación es diferente

En el mundo de la fabricación de objetos físicos, las tareas son repetitivas, las actividades son razonablemente predecibles y los elementos que se crean pueden estar en un solo lugar a la vez. En el desarrollo de productos, muchas tareas son únicas, los requisitos del proyecto cambian constantemente y el resultado, gracias, en parte, al uso generalizado de diseño y simulación avanzados asistidos por computadora y a la incorporación de software en productos físicos, es información que puede residir en varios lugares al mismo tiempo, o que puede ser construida de forma eficiente o ineficiente, generando alta variación en las tareas, las estimaciones y los compromisos. Creer que un grupo de ingenieros de software expertos garantizará el cumplimiento de un cronograma detallado de varios cientos de filas y meses de planeación es cada vez más irreal, los enfoques ágiles permiten validar rápidamente los resultados obtenidos y navegar exitosamente en estos escenarios de incertidumbre. Pero para que esto se lleve a cabo de forma exitosa es necesario que tanto gestores, gerentes de área, gerentes de proyectos directores, líderes, agile coaches, scrum masters, product owners y product managers, comprendan el pensamiento lean-agile, para que cultiven y permitan que funcionen muchas prácticas que van en contrasentido de la gestión tradicional, sin esto, cualquier esfuerzo de cambio será en vano.






100% de la utilización es un desastre económico

Es normal pensar que los proyectos toman más tiempo cuando las personas no están trabajando el 100% de su capacidad, y, por lo tanto, una organización de desarrollo ocupada será más rápida y eficiente que una que no sea tan buena en utilizar a su gente, pero en el mundo Lean y en la práctica eso no es cierto, cuando la ocupación o utilización del tiempo de las personas se aproxima al 100% la eficiencia, la calidad y la velocidad disminuyen (2), existen varias razones:

No se considera la variabilidad de procesos de trabajadores de conocimiento

Los trabajadores de conocimiento no hacen tareas estandarizadas, en un mundo estandarizado un cambio del 7% en el trabajo generará un 7% más en completarlo, algo que no ocurren procesos de TI. En general existen tres fuentes de variación (3) en los procesos:
  • Recursos: 
    • Ejemplos: unas máquinas son lentas y otras rápidas, los expertos realizan las tareas más eficientemente que los novatos.
  • Unidades de flujo (o elementos que fluyen): 
    • Ejemplos: en una fábrica de autos personalizados los vehículos tendrán diferentes características. 
  • Factores externos
    • Ejemplos: los pacientes en una sala de urgencias no llegan de forma fluida, a un equipo comercial la solicitud de propuestas no es un flujo constante.
En el mundo de TI donde a pesar de usar la misma estrategia de construcción de software puede cambiar:
  • la persona que los realiza (incluso la misma persona en distinto tiempo)
  • el estado de ánimo de la persona
  • disponibilidades tanto de personas, áreas, recursos (servidores, comunicaciones, componentes)
  • los requerimientos
  • insumos
  • la calidad de la documentación
  • resultados esperados
  • dependencias
  • transacciones
  • complejidad técnica
  • supuestos y premisas
  • entre otros
se constituyen en fuentes de variación del proceso, y estas fuentes de variación generan un tiempo de flujo diferente según el porcentaje de utilización de los recursos, tal como lo formuló Sir John Kingman, el cual desarrolló la fórmula de teoría de colas que relaciona la variación, eficiencia de recursos y tiempo de travesía (16). Ver gráfica a continuación:

Relación entre variación, eficiencia de recursos y tiempo de travesía - Gráfica de Sir John Kingman (3)


Por lo tanto:
  • entre más cercanos estemos al 100% de utilización del tiempo de las personas más tiempo tomará la travesía del proceso
  • ampliar la utilización del 90 % al 95 % aumenta el tiempo de travesía en un nivel mayor, que el de aumentar la utilización del 80 % al 85 % (3)
  • agregar un 5% más de trabajo puede llevar un 100% más de tiempo (2)
  • cuando el tiempo de travesía aumenta, el flujo (la cantidad de ítems, requerimientos, tickets por unidad de tiempo) disminuye

Es importante anotar que, para TI aplica más la curva fucsia que la gris.

Por lo tanto:
"Cuanto mayor sea la utilización de tu equipo, más largo será el tiempo de travesía, es decir, si tienen un ciclo fijo de trabajo, menos cosas lograrán terminar"

 ----- 

"Cuanto mayor sea la variación en el proceso, más largo será el tiempo de travesía (3)"
Es por eso que en Scrum se insiste
¿Qué ocurre si el equipo es completamente Nuevo y no tienes ninguna estadística? Mira al factor de dedicación de otros equipos en circunstancias similares. ¿Qué pasa si no tienes otros equipos en los que fijarte? Adivina un factor de dedicación. Las buenas noticias son que sólo deberás adivinar para el primer Sprint. Después, tendrás estadísticas que podrás ir midiendo continuamente para aproximar mejor el factor de dedicación y la velocidad estimada. El factor de dedicación “por defecto” que usamos para equipos nuevos es habitualmente el 70%, dado que es ahí donde terminan la mayoría de nuestros otros equipos con el tiempo.
Tomado de: Scrum y XP desde las trincheras por Henrik Kniberg (4).



Digamos que determinamos que el factor de dedicación del equipo es del 50% (bastante bajo, normalmente oscilamos en torno al 70%).
Tomado de: Scrum y XP desde las trincheras por Henrik Kniberg (4).


"Operar un proceso de desarrollo de productos cerca de su plena utilización es un desastre económico" ― Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development

--

 "100% de utilización conduce a la no predictibilidad" ― Donald G. Reinertsen


No permite la atención de imprevistos

El tener un equipo o personas al 100% de su capacidad y con compromisos en ciclos cortos, no permite aceptar la atención a imprevistos, pues cualquier imprevisto afectará el compromiso. En entregas largas la aceptación de imprevistos es tomada más como un favor, pues no se visualiza el impacto del tiempo de desenfoque, pero ya hemos aprendido que las entregas largas no son exitosas en el mundo del software, es por eso que enfoques como Scrum o XP son exitosos hoy en día. Por lo tanto, una estrategia usada por equipos scrum para aceptar los imprevistos es usar el patrón: Illegitimus Non Interruptus (clic aquí), el cual consiste en reservar de la capacidad del equipo un porcentaje para atención de imprevistos en caso de que estos se presenten.

Tomado de (6)




Inhibe la colaboración y la innovación

Frases que nos decimos o nos dicen como:
  • "Te ayudaría, pero ahora no tengo tiempo"
  • "Esto se podría mejorar de esta manera, pero no tengo tiempo"
  • "Cuando tenga tiempo te voy a enseñar a ___________"
Con seguridad lo haríamos, pero estar 100% enfocados no permite ir más alla; es un enfoque del 100% en la tarea encomendada, que ahoga espacios de interacción y mejora que emergen al poder colaborar o al tener una carga menor de trabajo. La mejora y la innovación no ocurren fuera del horario laboral (de 6 pm a 10 pm), tal vez, vengan ideas fuera de este horario, pero la implementación requiere de tiempo laboral.


Tomado de (7)



Tomado de (10)

Una experiencia observable en talleres (y en la realidad)

En talleres donde se ejemplifica como es el mundo Lean y Kanban, se realizan varias iteraciones con equipos constituidos entre 5 y 8 personas, en los cuales construimos hamburguesas ficticias, o pizzas, o retratos o cualquier proceso organizacional, se realizan varias iteraciones del proceso con diferentes porcentajes de utilización y limitando el WIP, una y otra vez demostramos que la utilización cercana o igual al 100% genera desperdicio.

Tomado de (11)



Tomado de (11)
Para este ejemplo tener utilizaciones del 98% produjo: 
  • 7 hamburguesas, 
  • -1170 unidades de valor y 
  • 7 defectos, 
mientras que con utilizaciones del 74% se lograron:
  • 15 hamburguesas,
  • 1340 unidades de valor y
  • 0 defectos
Una y otra vez, concluimos que como gestores nuestro trabajo es maximizar el flujo de valor, no la utilización del recurso tiempo de las personas. Y esto se debe a la paradoja explicada en "Esto es Lean" (3), en la cual muestra que en el flujo de procesos esté en uno de los siguientes cuatro estados:
  1. Baja eficiencia de flujo y baja utilización: desperdiciolandia
  2. Alta eficiencia de utilización y baja flujo: islas eficientes
  3. Alto flujo y baja utilización: océano eficiente
  4. Alta eficiencia y alta utilización: el estado perfecto
Tomado de (3)

Lo cierto es que la perfección no va a ser posible alcanzarla debido a:

Tomado de (3)
variaciones en
  • lo que es solicitado
  • las varaciones en el proceso de lo que es solicitado
  • cuándo es solicitado
  • y la cantidad solicitada
Por lo que siempre estaremos rondando lo que se llama "Frontera de la Eficiencia"




Para llegar a esa frontera, tanto la literatura como la experiencia nos recomiendan
  1. Identificar si estas en el estado de Islas Eficientes o Desperdiciolandia (por lo general estas allí)
  2. buscar primero la eficiencia de flujo
  3. y luego la eficiencia de utilización 
Tomado de (3)

Para esto debes de valerte de:
  • Gestión visual del trabajo
  • Crear ambientes de colaboración
  • Tener una cultura de experimentación y aprendizaje (Toyota Kata (12) puede ser una gran herramienta en este escenario)
  • Visión Sistémica
  • Una cultura con seguridad sicológica en la que no exista temor a fallar
  • Una obsesión por la mejora continua (Kaizen)
Adaptado de (11)

Te invito a ver el siguiente video imperdible de Henrik Kniberg @HenrikKniberg, donde podrás ver el paradigma Lean, en donde se prioriza la generación de valor sobre la "utilización de los recursos" (pongo paréntesis pues constantemente los gestores denominan a sus colaboradores como "recursos", término que termina más destruyendo que ayudando, ver referencia (13)).




El perfil "T" ayuda a lo anterior

Imagina que tu trabajo fuera solo operativo y te dedicaras a hacer lo mismo en una hamburguesería: picar tomates, si picas tomates y estas al 100% dedicado a esa tarea (podemos decir que estas siendo 100% eficiente en tu tarea), pero solo el 60% de los tomates que picas son usados y el resto se echan a la basura pues no hubo hamburguesas a ser consumidas (solo el 60% de tu trabajo agregó valor). Similar a esto ocurre en un equipo donde todos son especialistas: los desarrolladores no pueden estar 100% desarrollando, los tester 100% probando o haciendo casos de prueba, y de igual forma con frontend, backend, automatización, etc., se generará desperdicio, y el flujo de valor estará limitado a la capacidad más pequeña, en el caso de la imagen inferior, en el "Caso 1" corresponderá al especialista 2.


Explicación de mayor flujo de valor con Perfil "T"


Pero si en vez de tener especialistas, existen generalistas (o perfiles T -ver más en (15)-) que son más expertos en unas áreas y en otras tienen suficiente conocimiento y experiencia para apoyar de forma valiosa, el flujo se aumenta, pues todos van a ayudar a los generalistas 2 y 4, como se observa en el "Caso 2" de la imagen superior.

Nota: La práctica de Pair Programming de XP (17), ayuda en la distribución de conocimiento y en asegurar la calidad de lo que se construye.

 

Cerrando 

Muchas de las prácticas de Lean parecen un contrasentido, pero al aplicarlas permiten a las organizaciones, a los equipos y a las personas alcanzar estados de alto desempeño, generación de valor con menor esfuerzo, por lo tanto, cierro este largo artículo con una serie de recomendaciones:
  • Tu trabajo como gestor no es micromanejar a las personas o equipos para que estén al 100% ocupados, tu trabajo es poner un objetivo, proveer los recursos para lograrlo, limitar el WIP, y maximizar el flujo.
  • Prioriza la eficiencia de flujo
  • Prioriza el aprendizaje continuo
  • Luego prioriza la utilización del recurso tiempo
  • Toma métricas y sigue experimentando
  • No satures a las personas o a los equipos de trabajo
  • Planea por debajo del 100% de la utilización crea un ambiente de innovación, colaboración y que permite aceptar la variabilidad
  • Te sugiero realizar una asignación de una persona o equipo del 70% al 80% para lograr altos índices de generación de valor y fluencia
  • Si va a existir sobreesfuerzo que sea por corto tiempo y acordado con el equipo (14) 

ahora que comprendes como maximizar el flujo, la pregunta es:
¿En qué cosas de valor vas a poner a trabajar a tus equipos de desarrollo de productos?



Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios, Observaciones y Agradecimientos

  1. Agradecimientos a mi compañero y amigo Roberto Moraga, Daniel Ramírez y a Adrián Hurtado por sus comentarios y sugerencias
  2. Six Myths of Product Development by Stefan Thomke and Donald Reinertsen https://hbr.org/2012/05/six-myths-of-product-development
  3. Esto es lean: Resolviendo la paradoja de eficiencia - https://www.amazon.com/-/es/Niklas-Modig-ebook/dp/B019E91600
  4. Scrum y XP desde las trincheras por Henrik Knibnerg. (http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf )
  5. Illegitimus Non Interruptus (clic aquí)
  6. Interrupt Pattern (clic aquí) 
  7. Flow Thinking @ Ericsson 3G - https://es.slideshare.net/erikschon/flow-thinking-ericsson-3g 
  8. La cita original decía "operating a product development process near full utilization is an economic disaster"
  9. La cita original decía: 100% utilization drives unpredictability - https://www.scaledagileframework.com/innovation-and-planning-iteration/
  10. 2 Second Lean Book - https://paulakers.net/books/2-second-lean
  11. Fuente Roberto Moraga @RMoraga
  12. Excelente presentación sobre Toyota Kata de Hiroshi Hiromoto (@hhiroshi) (clic aquí)
  13. Diatriba: El tema recurrente de llamar "RECURSOS" a las personas que trabajan en un proyecto (clic aquí)
  14. Recomendaciones sobre el sobreesfuerzo del equipo en un proyecto - (clic aquí)
  15. T-shaped skills (clic aquí)
  16. Fórmula de Kingman - https://es.wikipedia.org/wiki/F%C3%B3rmula_de_Kingman
  17. Programación en pareja o en pares- https://es.wikipedia.org/wiki/Programaci%C3%B3n_en_pareja

Leido y Recomendado: Seis mitos del desarrollo de productos




 

martes, diciembre 22, 2020

New Minibook: Some Ideas for Agile Team’s Retrospectives


More than two years ago, after sharing a meetup on Retrospectives in Mexico City, I observed that were retrospectives, so useful in Agile frameworks, was not being conducted in a way that would generate the desired impact, which is: ACHIEVING THE IMPROVEMENT OF TEAM PERFORMANCE.

Due to the above, the idea of ​​this minibook entered my backlog of pending to build, and today I am finally sharing it with the Agile community and with all those who want to take their work teams to a mindset of continuous improvement.



Some Important Notes from the Mini-Book

The illustrations were made by my wife Diana Apráez, the launch flyer was designed by my daughter Mariana, translation by Dhiraj Bellara - @BellaraDhiraj, additionally I asked colleagues and friends of the Latin American Agile Community to collaborate with me with their reviews, prologues, advices and revisions, thanks again: Diana, Nadia, Lucho, Carlos Palacio, Carlos Quiroga, Carlos Serna, Wbeimar, Juan Andrés, Jaime, Augusto, Alma, Roberto, Daniel and Leonardo for all your contributions.

For the English edition, Ben Linders -https://www.benlinders.com/- did me the honor of writing a Foreword.

I share it below.



Foreword by Ben Linders

Retrospectives are not a new thing. They became widely known through the agile manifesto, the Scrum Guide, and by books like Project Retrospectives by Norm Kerth and Agile Retrospectives by Esther Derby and Diana Larsen. The practice of reflecting to learn and improve is much older. I was doing it already in the past century, by assisting people to form a shared picture of what's happening to learn and improve. 


The main thing that we can learn from agile is that retrospecting is a team activity. It's up to the team to find out, acknowledge, and take action. The retrospective facilitator is there to assist the team, to provide the environment, and foster a culture where people feel safe to speak up. Having said that, facilitating is not an easy thing to do.


Many people still seem to struggle when facilitating retrospectives. Expectations are often high, which makes it even harder. Jorge's book brings together many useful practices and suggestions that can help you to facilitate retrospectives that help teams to become a better version of themselves. Use the book to experiment in your retrospectives, and see what works for you. Don't worry if something goes wrong, remember the Prime Directive and use it to learn from things that didn't work. Occasionally you may want to retrospect your retrospectives too. 


Wishing you a wonderful journey of learning and improving!

- Ben Linders

----

Thanks a lot Ben for this foreword!

Thanks a lot Dhiraj for the translation!


www.amazon.com/-/es/dp/B08R6YVSCJ


Agile greetings / Saludos ágiles

Jorge Abad