Mostrando entradas con la etiqueta lean. Mostrar todas las entradas
Mostrando entradas con la etiqueta lean. Mostrar todas las entradas

mayo 23, 2013

Estimación ágil de proyectos (y 2): Equipo multiproyecto.

Hablábamos el "otro día" sobre la planificación ágil, y explicábamos el proceso para estimar un proyecto, y ver su evolución. Trabajábamos con la hipótesis de que era un proyecto para un equipo, un entorno que no siempre se da en las empresas.
El mecanismo que aplicamos en un entorno multiproyecto es básicamente el mismo, pero contamos con una nueva incógnita: la dedicación del equipo a cada proyecto.

Sabemos lo perjudicial que es para nuestra cabeza la multitarea, lo negativo que es para un equipo el multiproyecto y lo fatal para una organización la pérdida de foco y capacidad de ejecución. Sin embargo, en muchos entornos, se sigue empezando cualquier proyecto que se nos pase por la cabeza, antes que priorizarlos claramente y dedicar energías a aquello que nos aporta más valor. Este es un tema muy importante, y que influye poderosamente en la capacidad de trabajo de una organización.

Así que, si trabajas en un equipo multiproyecto, las posibilidades de tener un buen lío son abundantes. Y la estimación va a depender tanto o más de gerencia como del equipo. ¿por qué? Simplemente por que si la dedicación no es conocida, o no es sostenida, no puedes estimar. Así que añadimos una nueva hipótesis a la hora de dar fechas. Y es arriesgada, probablemente no cae en la responsabilidad del equipo.

Si decides trabajar en multiproyecto (recuerda, es una decisión, quizás no es tuya, pero es de alguien) a la hora de estimar, deberás asignar un porcentaje de dedicación a cada proyecto. Si tienes datos históricos de porcentajes de puntos historia por proyecto, te podrán ayudar a trabajar con una hipótesis lo más cercana a la realidad posible.



mayo 16, 2012

Agilismo sin software

Al establecerme como profesional independiente, queriendo ganarme las habichuelas como Agile Coach danzando al viento para esparcir los principios ágiles, no había pensado, que uno de mis primeros trabajos sería en una empresa NO relacionada con el desarrollo de sw.
Por casualidades de los contactos (¡gracias!) estoy colaborando con una empresa de fabricación de componentes mecánicos para aeronautica. (!) Y no producen software. Aquí trabajan con la creación del proceso de industrialización, antes de crear piezas en serie. Así que mi primera reacción ante la petición de ayuda fue pensar, "¿y qué hago yo aquí?" Sin embargo, viendo el objetivo de la organización: crear equipos, organizar el trabajo del conocimiento, realizar cambios culturales,... le di una vuelta, y me di cuenta que era en gran parte lo que había tratado de hacer estos últimos años.
Así que estoy trabajando con una organización que realiza industrializaciones de piezas de aeronautica, implantando Kanban, ayudando con la gestión de equipos, técnicas de retrospectivas y en general, ayudando a trabajar con una filosofía de mejora continua basada en Lean.

Los problemas que he encontrado son básicamente los mismos que en los equipos de desarrollo de software, solo que aquí no entiendo nada de lo que producen :) ... ¡y no importa! Es verdad que en este area no puedo recomendar montar un servidor de integración continua, o explicar como hacer TDD. Pero puedo hablar de comunicación, de gestión de equipos, trabajar con paneles kanban, trabajar la organización del proceso,... es decir, transmitirles algunos de los valores más importantes para mi con el agilismo: transparencia, mejora continua, trabajo en equipo.

La principal sorpresa fue trabajar con un panel kanban de más de 40 fases. Y comprobar que todos hacen falta. Olvidémonos de nuestro mítico análisis-diseño-desarrollo-testeo-deploy :)


El poder de reflejar el trabajo en un panel kanban es impresionante. De repente, tenemos información, y sobre todo, un lugar desde el que partir para mejorar. El equipo empieza a organizarse alrededor de ello. Y a contagiarse las ganas de hacer las cosas bien y mejor cada vez.

Las prácticas y principios que hemos aprendido desde el desarrollo de software y metodologías ágiles, son transportables a otros mundos, donde el principal problema en común es la gestión del conocimiento. Lugares comunes donde la inspección y adaptación y las personas, son los mejores enfoques para afrontar los problemas.


marzo 13, 2012

La pirámide de la organización ágil


Llevo tiempo dándole vueltas a la organización ágil como creación de un lugar donde se pueda convivir con los principios y valores del manifiesto. Así que ahora que soy consultor, lo voy a intentar reflejar en un modelo ;). Seguro que lo próximo será un cuadrante de dos variables para modelizar la realidad :P
Este es mi esquema básico:

La idea de representar esto es visualizar las areas de actuación, y sus niveles, para enfocarnos en el camino de organizaciones Lean o Agile. Cada elemento de la pirámide contiene al siguiente, obviamente lo que forma los equipos son las personas, y lo que forma una organización también. Los bordes de la pirámide son las relaciones externas o internas que deben trabajar para gestionarse.
Veamos cada elemento:

 - Personas: Personas y sus interacciones sobre procesos, ¿verdad? La base de la pirámide por tanto son, somos, las personas. Significa esto que debemos respetarlas, es decir, darles autonomía, visión sobre su trabajo, objetivos claros, ayuda y soporte. Y confiar en que van a hacer un buen trabajo, por que la mayoría de la gente es capaz de hacerlo.
Generalmente desconfio de alguien que empieza hablando de la importancia de las personas -y voy y hago lo mismo-, de que son lo primero, su "recurso más valioso", etc. Y no me fio demasiado hasta que demuestra que no es solo palabrería. Es un tema que se tiene que demostrar con hechos. (y supongo que a mi me juzgarán igual)

 - Equipos: El mito del equipo autoorganizado creo que en realidad está haciendo más daño si no se entiende bien. Llegar a tener un equipo autoorganizado requiere trabajo. Es verdad que depende de que personas estén en ese equipo, podría llegar a entenderse en un par de días, o no llegar nunca. Así que lo primero es entrenar el ojo y el corazón para ver y sentir estos temas.
   Hablamos de motivación, de liderazgo, de sentimientos. Pero también hablamos de compromiso compartido, de responsabilidad y visión compartidas. El equipo debe tener una dirección clara, y hay un problema cuando no todas las personas están alineadas en la misma dirección.

 - Organización: Alguien debe establecer una dirección hacia la que marcha una empresa (otro post si quereis hablamos de cooperativas o organizaciones "democráticas"). Pero la cuestión fundamental es que las personas que forman la organización deben darse cuenta del cambio de rol que se produce. Su trabajo va a ser poner las bases, facilitar, la creación de equipos, el crecimiento de las personas, para que cada vez puedan hacer méjor su trabajo. Creer que el equipo es el producto* es para mi la clave.

 Dentro de la pirámide invertida tenemos un problema, la estabilidad. Aquí hay dos métricas fundamentales: el beneficio y las personas. Estas métricas deben estar balanceadas de manera precisa. No puedes mantener una organización basada en la felicidad de las personas si no se mantiene económicamente. Básicamente, si no somos capaces siquiera de mantener un nivel higiénico en la economía, no llegaremos muy lejos. Sin embargo, centrarnos en la métrica de la rentabilidad, es crear empresas vacías, donde la gente está de paso, sin corazón. No hay duda que existen empresas que priman los beneficios -y les va bien en ese aspecto-, pero bueno, no hago todo esto para trabajar en/con una de ellas :)
 Mi corolario con este tema es, además, que contra más a gusto trabajen las personas, mayor visión compartida y mayor motivación, los clientes estarán más contentos y se acabará notando favorablemente en la cuenta de resultados.

 Tenemos más areas en la pirámide, que son las fronteras. Pero este post está quedando ya muy largo. Debereis esperar un par de días, para hablar de métricas, metodologías, espacios de colaboración, principios y valores.

 De momento esto no es ni un modelo, pero es un lugar para exponer ideas y temas. Todas las sugerencias son bienvenidas.

abril 27, 2011

¿Es TDD la hermana pequeña de la validación formal?

Hace un tiempo, al crear el grupo de TDD en castellano, hacía esta pregunta del título. ¿Es TDD la hermana pequeña de la validación formal? Hay un artículo del gran E. W. Dijkstra, "Sobre la crueldad de verdaderamente enseñar ciencias de la computación" que me parece muy revelador tal y como hoy entendemos la ingeniería del software, y cómo se veían las cosas hace tan solo poco más de 20 años.
Básicamente Dijkstra proponía enseñar a los estudiantes de informática, como introducción en el primer curso, la validación formal de los programas sin siquiera tocar un ordenador para programar. Bastante sorprendente.
¿podremos un día verificar formalmente que un programa hace lo que esperamos que haga, y nada más? Lo que pasa, que el principal problema no es verificar, si no CONOCER, aprender, asimilar, conceptualizar lo que tiene que hacer.
Os dejo con este video, del 2001, con una pequeña entrevista a tan interesante personalidad.



Podeis encontrar todos sus manuscritos, algunos de ellos traducidos a castellano en la universidad de Texas.
Computer science is no more about computers
than astronomy is about telescopes
E. W. Dijkstra
Siempre me ha intrigado el verdadero sentido de esa frase...

febrero 21, 2011

Equipos, equipos, equipos,... y luego ágil

El ideal de los equipos autoorganizados, es eso, casi siempre -me temo-, un ideal. En mi personal investigación sobre el tema de los equipos de alto rendimiento (¿alguna vez habeis participado en uno? - la sensación es "diferente"-) estoy trabajando en dos areas principalmente:


1) La organización de las personas como equipo. Es decir, ¿qué diferencia un grupo de personas trabajando juntas, de un equipo? En esta linea, estoy otra vez releyendo el libro "Software for your Head". Libro difícil de leer donde los haya, pero que da la impresión de esconder un tesoro oculto entre sus páginas.
Las mecánicas de un equipo de alto rendimiento ¿se pueden reproducir, inducir, insertar en cualquier grupo de personas con un objetivo común? La charla de Jim McCarthy en Agiles2008, me parece interesantísima.
Por otro lado, me pregunto si el equipo autoorganizado no es una quimera. Por ejemplo, asistí a una charla sobre "Tácticas para liderar equipos interfuncionales", dónde el ponente dijo que no puede haber equipo autoorganizados sin lider, excepto en casos dónde todos los componentes del equipo son expertos en la materia en la que trabajan. Así que esta idea refuerza la labor del ScrumMaster como lider-y coach- dentro de un equipo que utilice Scrum.

2) Elevar el nivel de las personas de cada equipo. A mayor nivel personal y técnico de cada individuo, el equipo ganará exponencialmente comunicación, colaboración, y por tanto, velocidad de desarrollo.
"Oh, you want to be an artist? A great artist?" "Yes" "That's easy! Become a great human being and then paint."
Supongo que aplica lo mismo a un gran desarrollador.

No se puede ser un gran equipo de desarrollo ágil, sin ser antes un gran equipo.

mayo 19, 2009

Equipos vs. personas

Si algo me gusta de Scrum como metodología ágil es que intenta sacar el máximo potencial a los equipos. Entendiendo equipo no como un grupo de personas que trabajan juntas, si no como un grupo de personas que comparten una visión y una motivación que les une con lazos especiales.
La medición de métricas en Scrum está muy orientada al equipo: La velocidad y el burn-down son elementos a nivel de esta agrupación. Las personas son controladas por el mismo equipo de manera secundaria. Si en cada daily-scrum, se ve una persona que no avanza, hay motivos y datos para que el resto de personas le ayuden o le den un toque, pero el foco está puesto en el equipo.
Ya decía Alistair Cockburn que construir software es un juego cooperativo, que sin equipo no hay juego, o al menos no hay juego satisfactorio. Lean nos habla de la calidad en integridad conceptual, que se note que la calidad del producto por que aflora la integridad del equipo que lo realiza.
Ahora me pregunto yo cómo realizar métricas para evaluar el desempeño de las personas... por qué, ¿es necesario en un ambiente ágil? Las personas que no "funcionen" serán rápidamente detectadas por los equipos y no las querrán con ellos. ¿hay mejor métrica que esa?
Si las métricas personales dependen de las estimaciones, ratios de cumplimiento de sus tareas,... ¿es posible formar así un equipo con una motivación común? ¿no lo estaremos tensando demasiado? Supongo que debe haber un equilibrio, pero yo desde luego pondría má peso en el equipo. Nadie construye software solo.
En fin, más preguntas para Agile-Spain ;)

marzo 16, 2009

Lean: Construir con calidad

Este principio -verdad subyacente que no cambia con el tiempo o el espacio-nos indica que debemos construir el código desde el principio con calidad suficiente, no testearla únicamente al final. Para asegurar la calidad puedes hacer dos tipos de inspección: después de que los errores ocurran, o para prevenirlos antes de crearlos.
La falta de calidad en la construcción genera deuda técnica -una deuda que se cobrará posteriormente sus intereses: falta de mantenibilidad, disminuirá la eficiencia, bugs insospechados-, que más tarde se convertirá en un problema. Además significará que tenemos trabajo a medias por hacer, así que hemos generado desperdicio en el proyecto.
No basta con estar preparado con buenas herramientas para llevar el control de defectos, listas de bugs. Todo eso es desperdicio, trabajo a medio hacer, por que significa que cada funcionalidad en la que has encontrado un error está a medio terminar realmente. La tarea de testeo debe prevenir los errores, no encontrarlos, participar en la mejora del proceso de creación de software. Las metodologías ágiles han desplazado muchas tareas tradicionalmente de equipos de testeo hacia los roles más de programación o desarrollo. Para ello algunas de las principales técnicas recomendadas en el desarrollo son:
  • TestDrivenDevelopment: Crea primero los tests, escribe código, comprueba más tests, refactoriza y vuelve a empezar. Por cierto, acabamos de crear un grupo en castellano para hablar de TDD.
  • Integración Continua: Complemento perfecto para las pruebas unitarias, ayuda a la integración entre código de distintos desarrolladores y versiones.
  • Refactorización: Básicamente es cambiar el código fuente sin modificar su comportamiento. Permite mejorar la estructura del código, por mantenibilidad, rendimiento,... para permitir un crecimiento adecuado y sostenible de las aplicaciones.
Pero los Poppendieck identifican un concepto más alla de lo que comunmente entendemos como calidad -en su versión más típica de comprobación de defectos-, y es la integridad del producto software:
  • Integridad percibida: Se refiere a que el producto logra un balance entre la funcionalidad entregada, usabilidad, estabilidad y economía que emociona al cliente.
  • Integridad conceptual: Indica que el los conceptos principales del sistema colaboran juntos como un todo cohesionado de manera fluida. La integridad conceptual es un prerrequisito de la percibida, puesto que si el sistema no dispone de una manera consistente de presentar los temas, el tratamiento de datos o las metáforas, la percepción del usuario no podrá ser completamente favorable.
La clave para mantener la integridad es una buena comunicación entre todas las personas implicadas. Es muy típico que en proyectos medianos o grandes, no se compartan la visión de la globalidad del producto, lo que conduce a problemas de integridad conceptual. A veces hasta es dificil conseguirlo con tres o cuatro desarrolladores! :\

El cambio mental es que la calidad no solo se debe controlar, sino que se debe construir. No basta con recolectar métricas, si no que hay retroalimentar el sistema para disminuirlas.

febrero 26, 2009

Lean: Crear Conocimiento

Este principio -verdad subyacente que no cambia con el tiempo o el espacio- trata sobre la importancia del aprendizaje. El desarrollo de software es radicalmente distinto a los procesos de producción. La creación de software es un ejercicio de descubrimiento, mientras que la producción intenta limitar las variaciones entre elementos. Para mejorar este ejercicio debemos maximizar el aprendizaje en cada etapa.
Las herramientas propuestas para maximizar el aprendizaje son:

  • Feedback: Cualquier ciclo que termina con una evaluación de su desarrollo y resultado proporciona una oportunidad inmejorable para el aprendizaje. Las metodologías tradicionales plantean pocos puntos para el feedback, por que parece que cuestionan la planificación o el saber-hacer de la gestión de proyectos.
  • Iteraciones: Las iteraciones permiten aprender poco a poco sobre el proyecto, de manera incremental, probando y desarrollando sobre lo que se va aprendiendo.
  • Sincronización:Es imprescincible una buena sincronización entre las partes involucradas en desarrollos complejos. Se debe fomentar compartir el conocimiento entre las personas. Muchas metodologías ágiles comparten la idea de la propiedad del código compartida.
  • Desarrollo basado en conjuntos: Para aprender bien las cosas debes probarlas, hacerlas, ofrecer un rango de soluciones que podrían funcionar. Hay que ser capaz de desarrollar un conjunto de pruebas que muestren qué hipótesis eran las correctas sobre la solución de un problema.
El aprendizaje por tanto puede ser visto desde dos puntos de vista: el equipo que aprende a desarrollar software cada vez mejor, y el equipo que aprende cada vez más sobre el proyecto (funcionalidades, lógica) que está construyendo. Es importante que se crea en el concepto de mejora continua, de lo contrario, estas tareas de retrospectivas, feedback,... puede acabar quemando a gente que hubiese preferido un entorno más conocido (¿hay de esos por ahí?). Debe ser una situación gradual, de aprendizaje continuo, pero relajado.

febrero 16, 2009

Lean: Eliminar la basura

Este principio -verdad subyacente que no cambia con el tiempo o el espacio- trata sobre la necesidad de eliminar los elementos que producimos y que no son realmente necesarios para crear el producto software que necesitamos hacer, que no le añaden valor.
El primer punto por tanto es averiguar qué es lo que da valor y lo que no. Identificar los procesos, artefactos o tiempos que no añaden nada a lo que el cliente necesita. Algunos ejemplos [1] de basura dentro de un proyecto pueden ser:
  • Requerimientos que no se van a utilizar. Recordemos siempre la regla de Pareto. El 20% de las funcionalidades proporcionarán el 80% del valor del producto.
  • Complicaciones de diseño/interfaz que no eran necesarias.
  • Esperas entre etapas:
    • Tiempo desde que se obtiene la información hasta que se usa.
    • Tiempo desde que alguien necesita información hasta que la obtiene
    • Tiempo desde que se crea un error hasta que se detecta/corrige.
  • Otro tipo de esperas muy peligrosas, las producidas por la multitarea (o la procrastinación)
  • Escribir demasiado código. Puede estar relacionado con el tema de la complejidad, o quizás simplemente es que no se supo hacer de una manera más sencilla. Pero si algo lo puedes hacer con la mitad de código, estás creando basura.
  • Trabajo a medio hacer, sin terminar. Equivalente al inventario en sistemas de producción.
  • Errores, cada bug creado en el desarrollo es un desperdicio. Suena obvio, pero a veces ponemos más enfasis en encontrar la basura que en no generarla.
  • Actividades de gestión. Estas actividades no aportan valor directo a los productos, y aunque obviamente son muy importantes para el correcto funcionamiento de organizaciones y equipos, hay que vigilarlas para que no se conviertan en focos de desperdicio. Lo más típico: la burocracia.
Uno de las dificultades de este principio es discernir qué factores se pueden reducir o aligerar para eliminar basura. Identificar qué pasos en los procesos no producen valor para el cliente. No siempre valen las mismas conclusiones para todos los entornos. En algunos proyectos algunos tipos de documentación pueden ser un desperdicio, pero en otros, que por ejemplo ya sabes que después los vas a ceder a otro equipo o van a tener un mantenimiento muy prolongado, puede ser vital documentar exhaustivamente.
La herramienta propuesta por Lean[2] para la identificación de la "basura" es la creación de mapas de cadenas de valor, para analizar el flujo de aporte de valor de los procesos utilizados por el equipo para la creación del producto, desde su concepción hasta que llega al cliente. Los mapas ayudan a visualizar los tiempos que se pierden de manera gráfica.
Debes trabajar para poder ver las pérdidas de tiempo en un desarrollo de software. Determinadas veces serán obvias (burocracia, procesos de documentación que generan artefactos que nadie usa ni usará,...), pero otras no son tan claras, o lo que es peor, pueden no ser bien aceptados los cambios que necesitarías llevar a cabo para eliminarlos. La burocracia y las costumbres pueden ser dificiles de erradicar por que dan (falsa) seguridad y confianza[3].
Por lo tanto, ¿es este principio beneficioso para el desarrollo del software? Sin duda. Aporta mejoras en dos de las areas que comentamos en el primer post sobre Lean:
  • Mejora la productividad de la "tubería-desarrollo". Hacemos más eficaz los equipos y la organización por que dejamos de realizar tareas que no aportan valor al cliente, que al final, es quien determina nuestro éxito o fracaso.
  • Mejora las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en la organización global. No debes dibujar un mapa de creación de valor para el departamento de desarrollo, si no para la organización completa! Seguro que salen muchas ineficiencias interdepartamentales.
Bibliografía:
[1] Implementing Lean Software Development
[2] Lean Software Development: An Agile Toolkit
[3] Eliminando obstáculos
[4] Gestionando la recesión con Lean, Agile y Scrum
[5] Los Poppendieck


febrero 10, 2009

Tres preguntas

Acabo de leer un post sobre Agile: ¿la evolución de las metodologías tradicionales? En general hace una comparativa sobre los métodos tradicionales y los ágiles de desarrollo de software. Expone algunos problemas que tienen las metodologías ágiles desde su punto de vista, que me han resultado interesantes por la experiencia en testeo del autor.
Pero lo que me han interesado han sido las tres preguntas con las que acaba el post:

  • ¿Existe la evolución de las metodologías Agiles?
  • Aquí creo que el autor se refiere a preguntar por si las siguientes generaciones de metodologías ágiles van a ser más formales, con un enfoque más tradicional. Creo que podrá haber dos evoluciones hasta que llegue la revolución. La primera, miles de equipos adaptando sus propias metodologías, y variantes de las definidas actualmente. Y la segunda, las que provengan basadas en el concepto de Lean Development. Estas evoluciones especificadas más formalmente basadas en Lean, proveerán el marco más ágil visto nunca para el desarrollo de software, plasmando los principios en procesos.
    Después vendrá la revolución en el desarrollo de software, pero de eso todavía no tengo pistas.

  • ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?

  • Yo no tengo duda que actualmente se han formalizado como reacción a las tradicionales, pero que no han surgido en su concepto de ellas. Antes se empezó a desarrollar software, cada uno haciendo las cosas como podían. Una serie de gente formalizó los procesos de creación de software basándose en las teorías clásicas de gestión de proyectos industriales, y de ahí surgieron las metodologías formales. El resto estuvieron callados hasta que vieron que la presión de las mismas era demasiado negativa. Y volvieron a los orígenes.

  • ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?

  • No lo creo. Puede haber una síntesis de las mismas, de las dos corrientes, que quizás nos lleve a un mejor sitio del que nos encontramos ahora, o quizás no. Pero los principios en los que cree cada tipo de metodologías son básicamente contrarios. Se podrían reconciliar prácticas o procesos, pero reconciliar principios que das como intrínsecamente ciertos es más dificil.



Un saludo a Javo, me ha gustado mucho su blog. No todo va a ser leer bonanzas sobre "las ágiles" ;)

febrero 08, 2009

Desarrollo software Lean

Uno de los temas en los que estoy más interesado ultimamente en este mundo del desarrollo de software es el "Lean Development". Es un conceto que surgio de la adaptación del modelo de Toyota de fabricación al software. Orginariamente parece que fueron "los Poppendieck" los inventores del término, en un par de libros que no te puedes perder:
Lo importante de Lean, es que se basa en unos principios, adaptados del TPS. Y esto es una de las claves para su futuro éxito, que no son herramientas, no son pasos a dar o procesos a seguir. Son principios cuyo valor reside en su aplicabilidad independientemente del "estado del arte" en el que te encuentres. Las medidas las decides tú, los cambios guiados por principios son efectivos si los principios son adecuados. Así que llegamos a la cuestión, ¿son los principios Lean acertados para lograr un mejor desarrollo de software? (Ahí es nada, definimos mejor como de mejor calidad, mejor satisfacción del cliente, mejor ganancias para el proveedor,... mejor lo que quieras!)
¿Cuales son estos principios? (el orden no importa)
  • Eliminar la basura
  • Crear conocimiento
  • Construir calidad inherente en el producto
  • Retrasar el compromiso
  • Entregar rápidamente
  • Respetar a las personas
  • Mejorar el sistema global
Iremos viendo cada uno, intentando adivinar si son beneficiosos para el desarrollo de software. (!me acabo de obligar a escribir al menos 7 posts!).
Otra pregunta que te sueles hacer cuando empiezas a conocer Lean es su relación con las metodologías ágiles. Básicamente creo que hablan de lo mismo, pero Lean está un paso por encima a nivel organizativo. Las metodologías ágiles (XP y Scrum al menos, que son las que más conozco, no olvidemos que existen otras) se focalizan en el equipo que desarrolla un proyecto. Lean complemente esa visión con principios aplicables a la organización que soporta los equipos, y que debe gestionar un portfolio de proyectos y equipos. Hay cuatro cuestiones que se deben lograr:
  • Seleccionar las cosas adecuadas en las que currar (Lean Management). ¿te interesan todos los proyectos?
  • Ajustar la carga de trabajo a la capacidad. Muchas veces ni siquiera conoces tu capacidad.
  • Mejorar la productividad de la "tubería-desarrollo" (Lean-Scrum). Aumentar la capacidad del sistema.
  • Mejorar las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en mejorar el sistema global.
Recapitularemos tras ver los principios, y volveremos sobre estas cuatro cuestiones. Si quieres ir adelantando las ideas, aquí tienes una pequeña recapitulación de los principios.

P.1 Eliminación de la basura.
P.2 Creando conocimiento
P.3 Construir con Calidad