Maximización del valor.

Esto permite a las organizaciones hacer de la

calidad una prioridad en sus productos y servicios.

En nuestro caso, hemos descubierto que nos ayuda a interactuar con otras
empresas. Nos permite trabajar con organizaciones externas que tienen
diferentes prácticas de trabajo.

En esta publicación, analizaremos los principios básicos de Lean-Agile y

las prácticas que aumentan la eficacia al tiempo que reducen el
desperdicio. Además, veremos por qué necesita capacitar a su
organización en Lean-Agile antes de que usted y su equipo comiencen a
usarlo, incluso si no todos los equipos lo usarán en su trabajo diario.

La forma no tan Lean-Agile de trabajar, es decir,

desperdicio, desperdicio por todas partes y ni una
gota para beber, es decir, nadie está empoderado
ni aprendiendo
Imaginar...

Hace doce meses, Sam y su equipo se sentaron con un grupo de partes

interesadas en Hyper-Mega-Corp Z. Una nueva caja que tomaba la
entrada y producía la salida estaba en las cartas. Al igual que cualquier
persona que participa en un proceso muy lineal, similar a una cascada,
para el desarrollo de productos, el equipo y las partes interesadas
planificaron todo desde el principio. Los plazos, los requisitos, el diseño,
las características, las pruebas, etc.: predijeron todo a lo largo de una
serie de reuniones, talleres y largas cadenas de correo electrónico.

Con el plan establecido y el presupuesto aprobado, el equipo de Sam

comenzó a trabajar en el desarrollo de software para la caja. El
procesador ya estaba decidido para esta caja, por lo que el equipo
escribió un código que funcionaba con ese procesador. Pero a medida
que pasaban las semanas y luego los meses, el equipo comenzó a tener
preguntas sobre el desarrollo, pero no sentía que pudieran retroalimentar
a Sam o a sus partes interesadas.
El equipo descubrió que el procesador elegido no era el mejor para la
tarea que iba a realizar la caja. Un grupo de investigadores de seguridad
externos descubrió que la biblioteca de software que habían planeado
usar tenía fallas masivas de ciberseguridad. Y para colmo: sus partes
interesadas se sentían frustradas por no estar trabajando en tantas
funciones por mes como pensaban que deberían estar, mientras tardaban
años en dar comentarios valiosos.

Sam sabía que se estaban quedando atrás y que la caja podría estar en
problemas, pero no creía que pudieran hablar con sus partes interesadas.
Sam siguió atrayendo a los miembros del equipo a las revisiones de
gestión del desempeño para hablarles sobre su eficiencia.

Un miembro del equipo, Lindsay, había intentado hablar con Sam sobre
todo esto. Sin embargo, no existía ningún mecanismo para el aprendizaje
o la mejora continua durante el desarrollo. Las mejoras en todo tendrían
que esperar hasta la siguiente caja.

El panorama para el equipo de Sam, y la caja, era sombrío.

Ojalá hubieran tenido los principios y las prácticas correctas. Ojalá toda
su organización entendiera Lean-Agile y permitiera que el equipo de
Sam trabajara con él.

Exploremos los principios de Lean-Agile y veamos cómo podrían haber

ayudado a Sam.

Las tres capas de Lean-Agile

Es útil pensar en Lean-Agile en tres capas.

La capa superior son los principios Lean, adaptados de la fabricación. El

segundo son las prácticas ágiles de gestión de proyectos, adaptadas del
desarrollo de software (como Scrum o Kanban). El tercero son las
prácticas técnicas que te ayudan a implementar los principios de Lean
(Test-Driven Development, retrospectivas, etc.).
Lean-Agile es un híbrido entre los principios Lean y las prácticas ágiles.

¿Cuáles son estos principios Lean?

Mary y Tom Poppendieck describen mejor los principios de Lean en su
libro Lean Software Development: An Agile Toolkit. He aquí un resumen:

1. Elimina el desperdicio. ¿Qué son los residuos? Es cualquier cosa

que no "agregue valor a un producto, valor tal como lo percibe el
cliente". El residuo es cualquier cosa producida o que se queda ahí
y que no se utiliza. Piezas en un estante que solo están acumulando
polvo. Puede ser "[cuando] los desarrolladores codifican más
funciones de las que se necesitan inmediatamente". ¿El tiempo
 perdido cambiando el desarrollo de un grupo a otro? Eso también
es un desperdicio, dicen Mary y Tom Poppendieck.
2. Amplifica el aprendizaje. Los Poppendieck consideran que
abordar una solución de software es muy parecido a tratar de armar
una nueva receta para un plato de restaurante de primer nivel. Un
chef iterará y aprenderá de las variaciones producidas. El
desarrollo de software es más complejo y los equipos pueden ser
grandes, pero cuando se amplifica el aprendizaje, este proceso de
descubrimiento es posible.
3. Decide lo más tarde posible. En algo como el desarrollo de
software embebido, puede haber muchas incógnitas. ¿Qué
procesador se adaptará mejor al producto y a las demandas de los
usuarios? ¿Debemos desarrollar en lenguaje x, y o z? ¿Es esta
pantalla mejor que aquella? ¿Es probable que la funcionalidad
cambie debido a los comentarios de los usuarios o del mercado?
No hay valor en especular. En su lugar, retrasa las decisiones hasta
que tengas los hechos.
4. Entregue lo más rápido posible. "Diseña, implementa,
retroalimenta, mejora" y repite. El "desarrollo rápido" es
totalmente plausible; Su velocidad le permite tomar decisiones
informadas con comentarios reales. Mantener este ciclo corto,
amplifica el aprendizaje y se asegura de que "los clientes obtengan
lo que necesitan ahora, no lo que necesitaban ayer".
5. Empoderar al equipo. Las personas que hacen el trabajo son las
que mejor entienden los detalles. ¿Quieres "excelencia"?
Asegúrese de que su equipo técnico esté involucrado en "los
detalles de las decisiones técnicas". Permita que estos equipos
utilicen "técnicas de extracción" y "mecanismos de señalización
local" (como Kanban) para programar y completar el trabajo, al
tiempo que informa a todos lo que está por venir. Mientras un líder
guíe al equipo, "tomarán mejores decisiones técnicas y mejores
decisiones de proceso de las que cualquiera puede tomar por ellos".
6. Construye la integridad en ella. En este caso, la atención se
centra en garantizar la calidad. Se trata de algo más que de que los
clientes estén contentos con el producto final, de su "integridad
percibida". Y va más allá de la "integridad conceptual", donde el
todo funciona a la perfección. En el caso del software, la
 construcción de la integridad significa que puede evolucionar sin
problemas con el tiempo, porque tiene "una arquitectura coherente,
obtiene una alta puntuación en usabilidad e idoneidad para el
propósito, y es mantenible, adaptable y extensible". Para el equipo,
la integridad proviene "de un liderazgo sabio, experiencia
relevante, comunicación efectiva y disciplina saludable".
7. Ver el conjunto. No te fijes solo en un área de un proyecto. Da un
paso atrás y observa todas las áreas involucradas. "Muy a menudo,
el bien común sufre si las personas atienden primero a sus propios
intereses [especializados]". En lugar de medir en función de la
contribución "especializada" de las personas, fíjate en el
rendimiento general del proyecto. 1

¿Dónde encaja Agile?

Al comparar los principios Lean anteriores con los principios del
Manifiesto Agile, se empieza a ver el cruce entre ambos. Ambos hacen
hincapié en el aprendizaje y en un enfoque centrado en las personas, al
tiempo que permiten proyectos sostenibles que eliminan los residuos. El
enfoque de Agile en la mejora continua también encaja bien con Lean.

La predicción es un desperdicio
Las prácticas tradicionales de gestión de proyectos, como la cascada,
intentan predecir todos los elementos de una solución desde el principio.
Las soluciones desarrolladas de este tipo rara vez se adaptarán
significativamente ante la nueva evidencia y no se adaptarán a los nuevos
aprendizajes.

La predicción conduce al desperdicio y evita que decidas más tarde

cuando tengas todos los datos y hace que la entrega sea más lenta.

En la fabricación, esto podría ser predecir qué piezas necesita y mantener

existencias de estas, ocupando espacio innecesariamente. Estas mismas
piezas también podrían volverse obsoletas antes de su uso, lo que
generaría desperdicios.
El desarrollo de software tiene un problema similar cuando se utilizan
prácticas de proyectos tradicionales, ya que las funciones de software
pueden quedar sin utilizar. A menudo, este desperdicio proviene de tratar
de predecir qué características quiere el usuario.

Un informe de 2019 de Pendo encontró que en el producto promedio de

software en la nube, el 80% de las funciones rara vez o nunca se usan.
Pendo estima que estas características no utilizadas representan 29.500
millones de dólares en inversión en investigación y desarrollo por parte
de las empresas de la nube que cotizan en bolsa.

A primera vista, tener estas funciones no utilizadas puede parecer que no

es gran cosa, pero se convierten en una carga de mantenimiento. Es
posible que simplemente eliminarlos no sea una opción. Es más
desperdicio.

Adaptación por encima de predicción: eficacia vs

eficiencia
¿Por qué es mejor adaptarse que predecir? A primera vista, adaptarse
puede parecer menos eficiente que predecir, y lo es. Para entender Lean-
Agile y por qué tiene tanto éxito, hay que entender la diferencia entre
eficiencia y eficacia y cómo detiene el desperdicio.

La eficiencia se centra en el tiempo y el costo, la cantidad de trabajo

realizado, mientras que la efectividad se trata de construir lo correcto.
Adaptarse a los nuevos conocimientos a medida que surgen, terminar con
la solución correcta y evitar el desperdicio que proviene de hacer lo
incorrecto.

Si te centras en la eficiencia, no podrás ver las ventajas de ser eficaz.

Tienes que dar un paso atrás y ver el panorama completo de lo que el
equipo está creando.

Por ejemplo, medir cuántas líneas de código escribe un equipo por hora o
cuántas funciones agrega por semana es una forma de ver un proyecto de
software. Las ganancias significativas aquí pueden hacerte pensar que,
debido a la eficiencia, un equipo lo está haciendo bien.
Sin embargo, Lean-Agile significa potencialmente hacer menos, pero
debido a que el equipo está siendo efectivo, están agregando las
características correctas. Puede haber un pequeño aumento en el costo,
pero hay un aumento significativo en el valor generado.

Prácticas técnicas que impulsan la efectividad en

los equipos de software
Estas no son todas las prácticas técnicas disponibles para los equipos de
desarrollo de software. Pero estas son prácticas que se centran en la
eficacia por encima de la eficiencia.
Sea eficaz con el desarrollo basado en pruebas

El desarrollo basado en pruebas (TDD) es una forma de desarrollar

software. Los desarrolladores escribirán una "prueba unitaria" antes de
escribir código, comprobando que estas pruebas fallan y, a continuación,
escribirán código para pasar esa prueba.

La investigación de Microsoft ha encontrado que TDD puede conducir a

un aumento del 15-35% en el tiempo de desarrollo inicial (el enlace abre
PDF), pero también encontraron que aumenta la calidad del código. El
código escrito con TDD tenía menos defectos, según Microsoft. La
creación de pruebas unitarias también significa que estos activos existen
para su reutilización más adelante en el ciclo de vida de un producto.

Un estudio de 2018 que analizó TDD y pruebas unitarias (el enlace abre
PDF) encontró que el enfoque también condujo a un código con menos
defectos. Al observar las puntuaciones de mutación (en las que se
comprueban las pruebas mediante la introducción de defectos en el
código), este estudio encontró que la TDD condujo a una detección del
87,5% de estos defectos. Por el contrario, un último enfoque de prueba,
probar el código al final de un proyecto, típicamente favorecido en el
desarrollo de estilo Waterfall, encontró solo el 67% de los defectos.

Adoptar un enfoque TDD significa que la corrección de estos defectos se

produce desde el principio, antes de que puedan crear residuos.
Tomar decisiones lo más tarde posible desarrollando soluciones en
paralelo

Otro ejemplo de eficiencia vs eficacia es observar cómo la toma de

decisiones lo más tarde posible puede percibirse como menos eficiente,
pero es más eficaz. En concreto, el proceso de desarrollo de soluciones
en paralelo.

¿Cómo funciona esto? Supongamos que tiene un problema técnico, como

decidir qué procesador sería el adecuado para un sistema integrado.

En Waterfall, el procesador se elegiría desde el principio, en función de

las predicciones sobre su rendimiento. Pero si has elegido el procesador
equivocado, no lo sabrás hasta que hayas avanzado significativamente en
el proceso de desarrollo. En este punto, los cambios en el código para
acomodar un procesador diferente retrasarían un proyecto, creando
desperdicio.

El enfoque Lean-Agile consistiría en preseleccionar los mejores

procesadores posibles y desarrollarlos en paralelo para todos ellos. Al
desarrollar en paralelo, comienzas a ver qué opciones no están
funcionando y antes. Podrá comparar los procesadores con las tareas de
usuario que necesita que realicen. Te adaptarás en base a conocimientos
reales.

Elegir un procesador desde el principio es eficiente, pero no es

necesariamente efectivo.
Usa Mob Programming para resolver problemas difíciles en equipo

La programación de mobs (o mobbing) es cuando un equipo se sienta

alrededor de una computadora y trabajan juntos en el código. Una
persona a la vez está escribiendo la solución (conductor) mientras las
personas que los rodean navegan por el problema y comunican una
solución (navegadores). A intervalos establecidos, los roles rotan a través
del equipo. Tienes la inteligencia de todos aplicada al mismo tiempo para
asegurarte de que estás haciendo lo correcto, con el beneficio adicional
de revisiones de código constantes e informales
Tener a más de una persona trabajando en una tarea a la vez puede
parecer ridículo cuando se trata de industrias donde el talento es escaso.
Pero el mobbing es otra práctica en la que parece ser menos eficiente,
pero es más efectiva.

Woody Zuill, quien ha hecho mucho para defender la programación de

mafias, descubrió que con ella, la finalización de tareas ocurre en un
período de tiempo más corto que tener una sola persona trabajando en
ella.

Es una forma productiva de trabajar. Pero hay muchos beneficios del

mobbing que ayudan a que la programación de mobs sea efectiva:

 Ofrece un entorno de aprendizaje continuo.

 Disminuye el miedo al fracaso.
 La programación de multitudes permite la comprensión
compartida, el conocimiento compartido y la propiedad
compartida.
 Reduce los tiempos de entrega, aumenta la comprensión y la
comunicación.
 Mejora la calidad del código, ya que los errores se pueden detectar
y corregir a tiempo.

Para una comprensión más profunda de la Programación de Mobs, la

charla de Woody Zuill sobre la práctica es un buen comienzo:

Lean-Agile no es nada sin formación y

concienciación
Una cosa que hemos descubierto en Bluefruit es que para que Lean-Agile
sea un éxito, hemos tenido que capacitar a todo nuestro equipo en él.
Ingeniería y no ingeniería. Pero no siempre hemos capacitado a todos y,
debido a esto, vimos fricciones entre nuestros ingenieros y el equipo de
liderazgo, finanzas, recursos humanos y administración, así como ventas
y marketing.
Estas partes indirectas de nuestro negocio utilizan algunas de las
prácticas que hemos descrito, pero entienden los principios en el centro
de nuestra forma de trabajar.

Con nuestros clientes, también nos aseguramos de que sepan de dónde

venimos. Los entrenamos a través de los principios de Lean-Agile
cuando comienza una conversación de ventas.

Pero, ¿cómo se puede empoderar a las personas

con principios básicos sin ser de arriba hacia
abajo?
La mejor manera de obtener la aceptación de Lean-Agile es a través del
coaching. En lugar de dictar los principios, la capacitación debe permitir
que su equipo los descubra y cómo puede funcionar para ellos y para
otros. A continuación, se mantiene esta formación, ayudando a las
personas a que formen parte de su comportamiento y no sean algo en lo
que tengan que pensar.
Entrenar en lugar de dictar

Las personas son más receptivas a los conceptos cuando llegan a las
mismas conclusiones lógicas por sí mismas.

Un ejemplo podría ser la introducción de prácticas formales de

codificación en una organización. Los desarrolladores a menudo
aprenden sobre programación de diferentes fuentes y adoptan
peculiaridades y estilos personales en la forma en que codifican.

Para el desarrollo de software, esto presenta un problema, ya que puede

ser difícil para cualquier persona, que no sea el desarrollador original,
comprender el código y mantenerlo en el futuro. Puede ser difícil leer y
navegar, revisar o hacer cambios, poniendo en riesgo la calidad del
trabajo futuro.

En lugar de entregar un libro de reglas a seguir, puede animar a los

desarrolladores a encontrar un consenso sobre qué estilos de codificación
utilizar. Así es como entra en juego el coaching. El coaching a menudo
implica llevar a las personas a un taller de equipo, presentarles un
problema, hacer que se vayan y trabajen en él y luego regresen para
revisar el ejercicio y las soluciones de los demás.

El proceso de revisión ayuda a todos a evaluar los beneficios de los

diferentes enfoques y, con el empujón del entrenador, a seleccionar las
mejores partes. Luego se van a resolver otro rompecabezas, regresan y
revisan de nuevo. Repetir sesiones de coaching como esta a lo largo del
tiempo ayuda a los desarrolladores a adoptar el mismo estilo de
codificación.

Sé eficaz, sé Lean-Agile
Esperamos que a estas alturas estés lo suficientemente interesado en
Lean-Agile como para empezar a pensar en cómo podrías llevarlo a tu
organización.

Para leer más sobre las prácticas de Lean-Agile, consulte las

publicaciones a continuación.
1
Mary Poppendieck, Tom Poppendieck, Lean Software Development:
An Agile Toolkit (Crawfordsville, Indiana: Addison Wesley, 2003), pp.
xxv-xxviii.