Este blog comparte estrategias y aprendizajes sobre desarrollo de software, marcos, métodos y metodologías ágiles como Scrum, Kanban y XP, con un enfoque en escalamiento ágil y Business Agility. Su propósito es ayudar a profesionales de la gerencia de proyectos, productos, scrum masters, agile coaches, agentes de cambio, y líderes a mejorar sus procesos y promover la experimentación como motor de innovación, facilitando su adaptación en entornos empresariales cambiantes.
Uno de los retos más comunes en agilidad es definir claramente qué es una historia de usuario y, sobre todo, cuál es su tamaño adecuado. He encontrado útil compartir esta definición:
"Una Historia de usuario es una pequeña porción de valorcuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue, puede estar entre unas cuantas horas hasta máximo 36 aproximadamente."
Otra versión que enfatiza el impacto en el negocio es:
"Una Historia de usuario esuna pequeña porción funcional de valorcuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue; puede estar entre unas cuantas horas hasta máximo 36 aproximadamente, que le permite al equipo de desarrollo de forma tangible y rápida mostrar progreso al negocio"
Justificación de esta definición
El propósito de estas definiciones es alinear expectativas sobre el tamaño y alcance de una historia de usuario. En la práctica, es común encontrar historias que son demasiado grandes o demasiado pequeñas, lo que afecta el flujo de trabajo y la entrega de valor real.
¿Qué significa una "pequeña porción de valor"?
Para que una historia de usuario tenga el tamaño adecuado, debe cumplir dos principios clave:
Ser lo suficientemente pequeña para completarse en poco tiempo (idealmente en menos de dos días de trabajo acumulado). Esto permite que el equipo entregue de forma frecuente y fluida.
Ser lo suficientemente grande para aportar valor tangible al usuario o negocio. Esto significa que debe entregar una funcionalidad completa y usable, no solo una parte técnica aislada.
Una historia demasiado pequeña puede caer en fragmentación innecesaria, por ejemplo:
"Agregar un nuevo campo en un formulario" (sin que esto implique una funcionalidad completa para el usuario).
"Implementar solo la lógica de frontend" sin que el usuario pueda interactuar con el sistema de manera funcional.
Por otro lado, una historia demasiado grande se convierte en un problema porque:
No se logra entregar dentro del sprint, afectando la previsibilidad del equipo.
Genera un esfuerzo desproporcionado que impide recibir retroalimentación temprana.
Puede requerir múltiples iteraciones para completarse, lo que dificulta la entrega continua de valor.
¿Por qué definir un límite de hasta 36 horas?
Anteriormente, usaba la referencia en días, pero esto generaba confusión. Algunas personas asumían que se trataba del esfuerzo acumulado de varias personas en paralelo, cuando en realidad el enfoque está en el tiempo total requerido.
Este límite de tiempo permite que las historias de usuario sean manejables y estén listas para ser desplegadas dentro del sprint sin convertirse en un obstáculo para el equipo. Además, facilita:
Un flujo de entrega continuo, evitando acumulaciones y bloqueos.
Un progreso visible para el negocio, al recibir incrementos de valor en ciclos cortos.
La detección temprana de problemas, reduciendo el riesgo de retrabajo.
¿Cómo lograr historias de usuario con el tamaño adecuado?
Asegurar que cada historia entregue valor real. Si un usuario no puede interactuar con la funcionalidad o si no se resuelve un problema concreto, entonces la historia está mal definida.
Evitar fragmentación innecesaria. Dividir en tareas técnicas (backend por un lado, frontend por otro) no es lo ideal, ni lo correcto. En su lugar, cada historia debe representar un incremento funcional, usable y comprobable del usuario.
Reducir la complejidad sin perder el impacto. Si una historia es demasiado grande, dividirla de manera que cada parte siga teniendo sentido de negocio y sea usable por el usuario.
Definir historias de usuario en estos términos ayuda a los equipos a mejorar su agilidad y a entregar valor de forma consistente.
¿Tu equipo tiene una definición clara de historia de usuario? ¿Cómo manejan su tamaño? Comparte tu experiencia en los comentarios.
Esta es una pequeña nota, donde dejo registro de una conversación reveladora que tuve con mi gran amigo Juan Andrés Ochoa, algoque hemos ido construyendo mutuamente:
Los equipos de alto desempeño cuentan con cuatro características:
Personas idóneas, es decir, son apropiadas para hacer la misión que se les va a encomendar.
Propósito.
Métricas que les muestren si están en el alto desempeño. Estas pueden ser tempranas y rezagadas, o un indice que combine ambas, es decir, en el caso de los equipos ágiles, soy un equipo ágil si impacto al negocio, entonces cuáles son las métricas que determinan que tengo agilidad (incluida, obviamente la excelencia técnica) y cuáles son las métricas que determinan que sí estoy impactando el negocio.
Una narrativa de cultura que proporcione un marco de actuación, que le cuente al equipo:
Lo que NO se espera del equipo, ejemplos:
que no se gestione la deuda técnica,
que no se asista a los eventos,
que no se respete a las personas.
Lo BÁSICO que se espera del equipo, ejemplos:
que cumpla sus compromisos,
entregue trabajo con excelencia,
se den retroalimentación mutua,
que reciban sin problema retroalimentación externa.
Lo EXTRAORDINARIO que se espera del equipo, ejemplos:
Investigar nuevas formas de hacer las cosas,
hacer de la innovación una forma de trabajo,
traer nuevos negocios a la empresa.
Lo anterior, se puede extrapolar al resto de la empresa cuando la vemos como un gran equipo conformado de equipos.
Como sabemos las historias de usuario nacieron con Extreme Programming (XP) en
1999, para ilustrar el formato libre que estas tienen, quiero compartirles
algunas historias de usuario que encontré en libros de la colección de XP:
Fuente:Planning Extreme Programming, Por Kent Beck, Martin Fowler
Encuentra la tarifa más baja.
Presentar al cliente las diez tarifas más bajas para una ruta en particular.
-
Mostrar vuelos disponibles.
Muestra posibles vuelos (con conexiones) entre dos planetas cualesquiera.
-
Ordene los vuelos disponibles según su conveniencia.
Cuando muestres los vuelos, ordénalos por conveniencia: tiempo de viaje,
número de cambios, cercanía a la hora de salida y llegada deseada.
-
Compra de tiquete
Compra de billete con cargo a tarjeta de crédito. Verifique la validez de la
tarjeta de crédito al hacer esto. Consulte también las normas generales de
inmigración.
-
Realizar perfil de cliente.
Guarde los datos del cliente para una referencia rápida, por ejemplo,
información de la tarjeta de crédito, domicilio, necesidades dietéticas y
gravitacionales.
-
Revisar itinerarios.
Mostrar todos los itinerarios que tiene el cliente en el sistema.
-
Cancelar itinerario.
Si un cliente cancela un itinerario, cancele todos los vuelos, hoteles, etc.
-
Imprimir documentos de inmigración.
Imprima la documentación necesaria para salir y llegar a un planeta, solo
para los planetas más fáciles.
-
Mostrar hoteles.
Mostrar hoteles cerca de un lugar.
-
Mostrar disponibilidad del hotel.
Mostrar hoteles que se encuentran disponibles para el período indicado en el
itinerario.
-
Ofrecer búsqueda sofisticada de hoteles.
Permita al cliente buscar hoteles utilizando más que fechas y ubicaciones.
Esto incluiría instalaciones, nivel de servicio, costos y recomendaciones.
-
Reserva un hotel.
Reservar un hotel. Cargue a la tarjeta de crédito y verifique la validez de
la tarjeta de crédito.
-
Proporcionar programas de hotel/línea espacial.
Mostrar hoteles que tengan acuerdos de venta conjunta con la línea espacial
que utiliza el cliente. Muestre los precios, incluidos los descuentos
disponibles con estos programas, solo para líneas espaciales que colaboran
activamente con nosotros en esta etapa.
-
Ofrecer alquiler de aviones.
Permitir al cliente alquilar un avión mientras se encuentra en un planeta.
Vincula las fechas del vuelo espacial. Mejorar el perfil del cliente para
incluir preferencias de avión (selección de seguro, manual versus
automático, etc.)
Notas de Jorge Abad
No dudo que algunas de las anteriores sean épicas y requieran ser
divididas. Con lo anterior, el punto a ilustrar quelos creadores de las historias de usuario usaban/usan un formato libre
para ellas.
es valiosísimo, pero las historias de usuario no tienen por obligación que escribirse de una forma u otra, debe encontrarse el mejor esquema que sirva para la organización y su contexto.
Fuente: Extreme Programming Installed Ron Jeffries, Ann Anderson, Chet
Hendrickson
Las cuotas sindicales varían según el sindicato y se cobran únicamente
en el primer período de pago del mes. El sistema calcula la deducción
automáticamente. El importe se muestra en la tabla adjunta.
Cuando una transacción causa que la cuenta de un cliente entre en sobregiro,
transfiera dinero desde la cuenta de protección contra sobregiros, si
corresponde.
Cuando una transacción hace que la cuenta de un cliente entre en sobregiro,
envíe un correo electrónico mostrando la transacción y el saldo al cliente.
Si la protección contra sobregiros está vigente, muestre la transacción de
sobregiro y los saldos de cuenta resultantes en el correo electrónico.
Para cada cuenta, calcule el saldo sumando todos los depósitos y restando
todas las deducciones.
Produzca un estado de cuenta para cada cuenta, que muestre la fecha de la
transacción, el número, el beneficiario y el monto. Se adjunta una
declaración de muestra: haga que el informe se parezca aproximadamente a la
muestra.
----
Cuando el GPS tiene contacto con dos o menos satélites durante más de 60
segundos, debe mostrar el mensaje "Pobre contacto de satélite", y esperar la
confirmación del usuario. Si el contacto mejora antes de la confirmación,
borre el mensaje automáticamente.
Si la estación que se reproduce actualmente contiene información digital, la
información se muestra en la pantalla LCD de la radio. Si no hay información
digital disponible, muestre la frecuencia de la estación.
Permitir al usuario agregar nuevos tipos de servicios a la lista inicial del
sistema. Por ejemplo, es posible que desee agregar una entrada especial para
lavar el automóvil en el lavado "gratuito" de la escuela secundaria. Incluya
el monto y la fecha de los campos estándar, además permita al usuario
agregar texto adicional o campos numéricos. Los informes deben sumar
automáticamente los campos numéricos. (Nota del programador: es necesario
dividir la historia. Separe los campos numéricos y de texto en dos
historias, más una para la suma).
(Partición 1) Permita que el usuario agregue nuevos tipos de servicios,
incluidos los campos estándar más cualquier campo de texto adicional que
desee.
(Partición 2) Permitir al usuario agregar campos numéricos a los tipos de
servicios definidos por el usuario.
(Partición 3) En todos los informes, muestre los totales de todos los
campos numéricos, no solo los campos estándar de galones y cantidades en
dólares.
Fuente: La Programación Extrema en la Práctica. James Newkirk, Robert C. Martin
La cabecera del sitio (esto es, en todas las páginas) deberá indicar si el
usuario no ha entrado y ofrecerle un botón para entrar (similar a un carro
de compras). Muestra el nombre o el e-mail si pulsa.
Cuando se dispara la entrada, y el sitio no puede detectar que el usuario es un miembro, el usuario es transferido a una página de entrada, y le pide su nombre de usuario y la contraseña y explica la filosofía y proceso de entrada del sítío.
La página de entrada debería al usuario permitirle saltarse el login y
entrar como invitado.
Cuando el usuarío seleccione registrar, cargará la página de registro, solicitándole la dirección e-mail, nombre, apellido, afiliación y si desea o no ser informado sobre las novedades del sitio. Una vez enviado, el sistema genera una contraseña y la envía por e-mail al usuario. El campo e-mail no puede quedar en blanco.
Proporcionar una utilidad que permita a los usuarios invitar a otras personas a hacerse miembros (enviándoles un formulario HTML). Una vez que se reciba la contestación el sistema los registrará y les enviará un e-mail de confirmación con su contraseña.
Los usuarios usuarios deben ser capaces de cambiar su perfil (dirección de e-mail, contraseña, nombre, apellido, afiliación). Poner dos campos de contraseña para pedir confirmación.
Listado de historias de usuario para el proceso de estimación (Nota Jorge Abad: Aunque no está el detalle de cada una, es interesante observar la granuralidad de las mismas)
Historia de Usuario 4.1. Disparar el Mecanismo de Entrada
Historia de Usuario 4.2. No Desplegar Ventanas
Historia de Usuario 4.3. Dirección de E-mail como Nombre de Usuario
Historia de Usuario 4.4. Restricción de Portabilidad
Historia de Usuario 4.5. Cabecera Elegante del Sitio
Historia de Usuario 4.6. Historia de Entrar
Historia de Usuario 4.7. Cookies (Nota Jorge Abad: Esta historia es entre funcional y técnica)
Historia de Usuario 4.8. Entrar como Invitado
Historia de Usuario 4.9. Entrada Transparente
Historia de Usuario 4.10. Registrar Usuario
Historia de Usuario 4.11. Miembro
Historia de Usuario 4.12. Contraseña Olvidada
Historia de Usuario 4.13. Migrar Datos de Access (Nota Jorge Abad: Esta historia es netamente técnica, por definción no debería ser una historia de usuario, pero indiscutiblemente es trabajo a realizar)
Historia de Usuario 4.14. Direcciones de E-mail Heredadas
Historia de Usuario 4.15. Notificación vía E-mail
Historia de Usuario 4.16. Especialización de la Notificación
Historia de Usuario 4.17. Anchura de la Página
Historia de Usuario 4.18. Invitación de los Miembros
Historia de Usuario 4.19. Cambiar el Perfil de Usuario
Una buena definición de historia de usuario que me ha sido útil compartir es:
"Una Historia de usuario es una pequeña porción de valorcuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue, puede estar entre unas cuantas horas hasta máximo 36 aproximadamente."*
Otra definición que también puede funcionar es:
"Una Historia de usuario esuna pequeña porción funcional de valorcuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue; puede estar entre unas cuantas horas hasta máximo 36 aproximadamente, que le permite al equipo de desarrollo de forma tangible y rápida mostrar progreso al negocio"
*Nota: antes usaba la expresión de días pero generaba confusión, y se terminaba creyendo que eran muchas personas trabando durante esos días, por eso preferí poner el tiempo total requerido.
Resumen del artículo "Para crear un equipo de alto rendimiento, pida un 85% de
esfuerzo"
El artículo "Para crear un equipo de alto rendimiento, pida un 85% de
esfuerzo" de Ben Horowitz, publicado en la revista Harvard Business Review en
junio de 2023, sostiene que la clave para crear un equipo de alto rendimiento
es pedir a los miembros del equipo que se esfuercen al 85%.
Horowitz argumenta que pedir a los miembros del equipo que se esfuercen al
100% todo el tiempo es contraproducente. Esto se debe a que el agotamiento y
el estrés que resultan de operar al máximo nivel pueden conducir a errores,
decisiones pobres y, en última instancia, a un rendimiento inferior.
En cambio, Horowitz sostiene que pedir a los miembros del equipo que se
esfuercen al 85% permite a los individuos y al equipo en su conjunto rendir de
manera óptima a largo plazo. Esto se debe a que deja espacio para la
creatividad, el aprendizaje y la recuperación.
Horowitz ofrece varios consejos para ayudar a los líderes a implementar la
regla del 85% en sus equipos:
Establezca expectativas claras. Los miembros del equipo deben saber qué se
espera de ellos en términos de rendimiento y esfuerzo.
Cree un entorno de confianza y apoyo. Los miembros del equipo deben sentirse
cómodos para admitir cuando necesitan ayuda o descanso.
Facilite el aprendizaje y el crecimiento. Los miembros del equipo deben
tener oportunidades para aprender y desarrollarse en sus roles.
Horowitz concluye que la regla del 85% es una forma efectiva de crear
equipos de alto rendimiento que sean productivos, innovadores y sostenibles.
Algunos ejemplos de cómo implementar la regla del 85%:
En lugar de exigir que los miembros del equipo trabajen horas extras,
ofrezca flexibilidad para que trabajen desde casa o en horarios flexibles.
En lugar de esperar la perfección, acepte que habrá errores.
En lugar de centrarse en la cantidad de trabajo realizado, concentre su
atención en la calidad del trabajo.
La regla del 85% es un enfoque simple pero poderoso para crear equipos de alto
rendimiento. Al pedir a los miembros del equipo que se esfuercen al 85%, los
líderes pueden ayudar a sus equipos a rendir de manera óptima a largo plazo.
One of the factors that most destroys agility is the lack of adequate
prioritization patterns according to the context in which it is located, that
is, both upstream (1) and downstream (2) practices are used (which even from
the good intention) destroy value for the organization. In general, we can
incur:
Building unnecessary things
Building things that are necessary but worthless
You don't build what's important
We let ourselves be carried away by intuition
We let ourselves be carried away by authority
We let ourselves be carried away by feelings of friendship or enmity
etc.
We destroy value and generate waste by dedicating time, effort and money from
business areas, execution areas and suppliers in things that should not have
been developed and relegating others, which would allow better financial
performance or customer satisfaction.
---
---
---
(and one of mine)
"Building something that was not correctly prioritized is destroying value for the organization"
---
Below, I share some of the anti-patterns that I have observed when
prioritizing both PMO - Project Management Office -, VMO -Value Management
Office- and Product owners, and that I promote to be removed in processes of
agile transformation or team agile coaching.
I hope they will help you advance in the knowledge of better ways to
prioritize the work to be done.
Expect more articles on this topic.
Agile greetings,
Jorge Abad.
References, notes, or comments
Upstream: where the project, product or initiative is prioritized by the PMO, VMO or those who are responsible for prioritizing the portfolio.
Downstream: where the product is being developed, and the solution team builds the different functionalities.
Uno de los factores que más destruye la agilidad es la carencia de patrones
adecuados de priorización de acuerdo con el contexto en el que se encuentre, es decir, tanto aguas arriba (upstream) (1) como aguas abajo (downstream) (2) se emplean prácticas (que aun desde la buena intención) destruyen valor para la organización. En
general podemos incurrir en:
construir cosas innecesarias
construir cosas necesarias pero carentes de valor
no se construye lo realmente importante
nos dejamos llevar por la intuición
nos dejamos llevar por la autoridad
nos dejamos llevar por los sentimientos de amistad o enemistad
etc.
En últimas, destruimos valor y hacemos que se genere desperdicio por dedicar
tiempo, esfuerzo y dinero de áreas de negocio, áreas de ejecución y
proveedores en cosas que no debían haber sido elaboradas y relegando otras,
que permitirían un mejor desempeño financiero o de satisfacción del cliente.
---
---
(y una mía)
"Construir algo que no fue correctamente priorizado es destruir valor para la organización"
---
A continuación, te comparto algunos de los antipatrones que he observado al
momento de priorizar tanto por PMO - Project Management Office -, VMO -Value Management Office- y Product owners, y que promuevo sean
removidos en procesos de transformación ágil organizacional o de
acompañamiento de equipos.
Espero te sirvan para avanzar en el conocimiento de mejores formas de
priorizar el trabajo a realizar.
Este artículo escrito por mi gran amigo y compañero de trabajo Roberto Moraga, es una referencia para entender el método A/B testing y cómo puede este llevarnos a crecimientos exponenciales.
Todos reconocemos y experimentamos que el 100% de CPU constate en nuestra máquina la relentiza y la hace ineficiente; me impacta es que no podamos reconocerlo en nosotros mismos y en nuestros colaboradores, y los/nos terminemos quemando.
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)"
Relación el Tiempo de Ciclo, la Utilización y el Tamaño de los Lotes
"Reduzca el tamaño de lote para: reducir la variabilidad e incrementar la predictibilidad"
se tenga un sprint backlog que contenga de 6 a 10 historias de usuario
de similar tamaño
se estima usando Fibonacci en el planning póker para amortiguar un poco
la variabilidad de las historias de usuario
se sugiere planear con el 70% al 85% de la capacidad del equipo
Durante décadas, 3M ha programado desarrolladores de productos al 85%
de su capacidad (2)
Y Google es famoso por su “20% de tiempo” (que permite a los
ingenieros trabajar un día a la semana en lo que quieran, una práctica
que significa que hay capacidad adicional disponible si un proyecto se
retrasa) (2)
Ericcson planea sus equipos de producto al 70% (7)
Tomado de: Scrum y XP desde las trincheras por Henrik Kniberg (4).
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
Principle Q6 & Fig 3-6 illustrate this point. Think of queueing
function as transforming a change in loading into a change in queue size
(& thus cycle time). Operating at high utilization amplifies
variability. Manufacturers have known this for a long time, developers not
so much
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:
Baja eficiencia de flujo y baja utilización: desperdiciolandia
Alta eficiencia de utilización y baja flujo: islas eficientes
Alto flujo y baja utilización: océano eficiente
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 variaciones 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
Identificar si estas en el estado de Islas Eficientes o Desperdiciolandia (por lo general estas allí)
buscar primero la eficiencia de flujo
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)
Reduzca el tamaño de lote o elementos del backlog
para:reducir la variabilidad e
incrementar la predictibilidad
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?
