Masa K. Maeda

Agilismo y Efectividad del Negocio

lasr21 — Mon, 21 Sep 2015 06:55:38 +0000

Agilismo y Efectividad del Negocio lasr21 Mon, 09/21/2015 - 01:55

Publicado en

SG #48

Agilidad

Autor

Masa K. Maeda

Durante los siete años que llevo ayudando a empresas como coach en Lean y Ágil y más de una década practicándolas he tenido la oportunidad de ver avances fabulosos y también, desafortunadamente, degradación en la práctica ágil. En este artículo comparto parte de estas experiencias, así como el punto de vista que comparto con mis clientes para ayudarles a mantenerse en el camino exitoso.

En toda práctica suele suceder que emergen tres corrientes de aplicación. La primer corriente es la canónica, en la cual se lleva a cabo la práctica siguiendo su definición línea por línea. Las personas que siguen esta ruta suelen ser grandes defensoras de la práctica y consideran que la forma de ser exitoso es apegándose a los lineamientos. Esto en principio tiene sentido porque minimiza la posibilidad de mala práctica. Sin embargo, tiene la desventaja de distanciarse de la realidad. En el mundo real, toda empresa, proyecto y equipo de trabajo es distinto. Aún más, la realidad cambia con el tiempo y las circunstancias por lo que un mismo proyecto podría ejecutarse de forma distinta aún en la misma empresa y con el mismo equipo, dependiendo de cuando se ejecute y las circunstancias de ese momento. Es prácticamente imposible contar con una metodología o estructura universal tal que aplicada de manera canónica nos conlleve al resultado deseado. He visto muchas personas en muchas organizaciones apegarse a la práctica canónica y tener una práctica muy bonita pero fallando miserablemente a nivel de negocio. Esto, obviamente, satisface a los practicantes quienes pueden presumir de lo bien que siguen la práctica; pero al dueño del negocio lo deja en la quiebra.

La segunda corriente es aquella en la que las personas llevan la práctica solamente en nombre. Es decir, siguen haciendo otras cosas de la misma forma pero con un nuevo nombre, por lo que en realidad no están llevando a cabo esta práctica. Esto garantiza desastre y desafortunadamente el desprestigio de la práctica original. Conforme la práctica lean y ágil se ha popularizado esta corriente se hace mas y más frecuente porque mucha gente adopta el término porque está de moda pero no se preocupa por aprender y entender la práctica.

La tercer corriente es aquella en la cual los practicantes se preocupan por adquirir un entendimiento profundo y se enfocan en adaptar su práctica a la situación real y actual de la organización. De las tres corriente, esta es la menos frecuente, simple y sencillamente porque es la más difícil. Requiere de un mayor esfuerzo tanto de parte parte de los practicantes como de parte de la organización. Los tomadores de decisiones a nivel estratégico y táctico deben expandir la forma de ver las cosas y llevar a cabo la práctica ellos mismos. Los colaboradores deben detenerse a pensar de qué manera aplicar la práctica en lugar de seguirla como si fuese una fórmula. Es mucho más fácil simplemente saber qué hacer y hacerlo que pensar en cuál es la mejor manera de hacer las cosas e ir adaptando la práctica para mejorar gradualmente y dependiendo del cambio de circunstancias.

Por otra parte, la efectividad del agilismo en los negocios requiere de un componente esencial que es el acoplamiento. Existe la frase popular “ningún hombre es una isla” que se aplica igualmente a industrias, organizaciones, equipos de trabajo y proyectos. Independientemente de si es Lean, Ágil o cualquier otra práctica, esta se realizará en el contexto de otras prácticas y procesos del negocio, por lo que es indispensable descifrar cómo hacerlas coexistir. He conocido coaches y practicantes ágiles que desaprueban y rechazan otras prácticas y sus practicantes de una manera obtusa tal que llega a generar conflicto en las organizaciones resultando en grandes pérdidas económicas y caos en la relación humana.

Dos de los aspectos que más he enfatizado a través de los años han sido la flexibilidad-adaptabilidad de la práctica y la cohesión con otras prácticas. Una consecuencia de esto ha sido y sigue siendo que algunas personas en las comunidades Lean y Agile me han criticado de manera negativa. No tengo problema con eso desde el punto de vista de libertad de expresión, pero los invito a que reflexionen al respecto. Poco tiempo después de ser coach Agile adopté también Lean y lo fusioné para ofrecer un mejor servicio a mis clientes. En aquel entonces Alan Shalloway y yo éramos las únicas personas aplicando el término lean-agile. Muchos me atacaron pero no me importó pues yo sabía que la combinación de ambos beneficiaba a mis clientes. Cinco años después la comunidad ágil comenzó a prestarle atención a Lean y ha llegado a un nivel tal que casi todo evento ágil en el mundo incluye temas Lean.

A diferencia de muchos consultores que ignoran o atacan directamente las prácticas tradicionales, yo siempre he buscado ayudar a las organizaciones a madurar de forma que sus prácticas tradicionales se lleven a cabo de manera conjunta con las prácticas Lean y Agile. Mi enfoque ha sido altamente exitoso, mientras que he sabido directamente de clientes el daño tremendo que sus empresas sufrieron como resultado de intentar adoptar ágil con un coach que llegó con espada en mano a atacar todo lo demás. De hecho, durante el último año y medio he notado que ha aumentado en la comunidad ágil la discusión sobre la coexistencia de prácticas ágiles y tradicionales. No estoy proclamando ser un visionario, pero sí considero que mediante un entendimiento profundo de Lean y Agile aunado a mi interés de hacer que mis clientes sean altamente exitosos he logrado tener la claridad mental para ser adaptativo.

La alta colaboración entre los distintos interesados en un proyecto es esencial para el éxito. Durante los últimos años he desarrollado dinámicas de alta colaboración que han resultado ser muchísimo más efectivas en algunos aspectos que cualquier metodología Lean o Agile existente. En próximos artículos platicaré al respecto.

A final de cuentas, lo que más importa no es el apego a una corriente metodológica, sino el lograr que nuestros clientes sean exitosos, y el camino para ello típicamente nos lleva a combinar elementos de distintas prácticas. Yo considero que esta adaptabilidad y flexibilidad es lo que en realidad pregona el agilismo.

Bio

Masa K Maeda es el CEO y fundador de Valueinnova LLC USA y el creador del modelo Serious LeAP cuyo libro esta próximo a su publicación. Es también consultor senior del Cutter Consortium y miembro del comité de dirección del Agile Testing Alliance. Previamente fue miembro de los equipos fundadores de 4 empresas en USA e hizo investigación y desarrollo en Apple Inc.

Aseguramiento Ágil de Calidad

sg — Fri, 19 Sep 2014 20:53:40 +0000

Aseguramiento Ágil de Calidad sg Fri, 09/19/2014 - 15:53

Publicado en

SG #45

Agilidad

Autor

Masa K. Maeda

Soy reconocido en la industria primordialmente por mi actividad en el ámbito de Lean, Kanban y Agile. Algo menos sabido es que también soy miembro del Comité de Dirección del Agile Testing Alliance y que en 3 de las 5 empresas en Silicon Valley que fui miembro del equipo fundador yo cree las organizaciones de aseguramiento de calidad. Así que a compartiré a continuación algunos aspectos relevantes de pruebas estilo ágil.

La mayoría de las actividades de pruebas de software desafortunadamente se enfocan en hacer pruebas funcionales manuales lo cual es deficiente pues el alcance y valor agregado de ese tipo de prueba es muy limitado, resultando en productos y servicios de baja calidad.

Un punto de partida para mejorar la calidad de las actividades de prueba es considerar el Cuadrante de Pruebas Ágil, el cual nos muestra el tipo de pruebas a efectuar dependiendo de los factores considerados además de recomendar qué hacer de manera manual y qué hacer de manera automatizada. Ver Figura 1.

El primer cuadrante tiene que ver con probar aspectos que ayudan al equipo de desarrollo desde la perspectiva tecnológica. Utilizando herramientas se verifica la calidad mediante pruebas unitarias y de componentes. Esto es para asegurar que la funcionalidad del código y las interfaces de los módulos es adecuada.

El segundo cuadrante se enfoca también en probar aspectos que soporten el desarrollo, pero desde la perspectiva de negocio. En ese cuadrante se llevan a cabo pruebas funcionales para validar lo que se está construyendo respecto a las expectativas del usuario. Esto involucra pruebas tanto automatizadas como manuales.

El tercer cuadrante es para pruebas que evalúan el producto o servicio desde el punto de vista del negocio. Este es el único cuadrante en el que es aceptable sólo hacer pruebas manuales y es para aspectos de exploración, uso, aceptación y Alfa/Beta (éste último es para determinar cuál de más de una opción de funcionalidad es mejor y es determinada por los usuarios mismos).

El último cuadrante se enfoca en pruebas para evaluar el producto desde la perspectiva de tecnología. Las pruebas en este cuadrante se llevan a cabo de manera enteramente automatizada. Ejemplos de pruebas son seguridad y carga.

Tomando un paso hacia adelante, el aseguramiento de la calidad de software no debe ser una actividad reactiva. Es decir que en lugar de enfocarnos en probar código para encontrar defectos o para verificar que defectos no existan, mejor llevemos a cabo actividades para evitar que los defectos existan.

TDD

Para ello hacemos uso de Desarrollo Basado en Pruebas unitarias (TDD del inglés Test-Driven Development). En breve, se trata de generar y codificar las pruebas de lo que se va a implementar primero; ejecutar el código de prueba para asegurar que falle porque el código a probar no se ha implementado; e implementar el código que pase esas pruebas. Si esto se hace bien y completo entonces ese último código es la característica indicada en la especificación con la ventaja de que jamás tuvo errores. Adicionalmente las pruebas automatizadas son la documentación (más completa y actual). Conforme ésta práctica se lleva a cabo es indispensable factorizar el código que se está generando.

TDD es fantástico pero hay aún más. Desarrollo Basado en Pruebas de Aceptación (ATDD del inglés Acceptance Test-Driven Development) en el cual las pruebas son de aceptación en lugar de unitarias. Las pruebas de aceptación son creadas por el equipo técnico y sus líderes técnicos. La ventaja radica en que el énfasis está en el comportamiento esperado del código en lugar de tan solo en la validez del código.

BDD

Otro paso adelante es el Desarrollo Basado en Comportamiento (BDD del inglés Behavior-Driven Development) en el cual el énfasis es en verificar que el código hace lo que el negocio necesita en lugar de verificar si la implementación funciona. En éste tipo de pruebas se generan escenarios en adición a historias de usuario.

Como pueden ver las actividades de Aseguramiento de Calidad y de Pruebas son distintas y requieren de mayor nivel de excelencia técnica de lo que en muchas industrias se considera. Es posible que algunos lectores piensen que las actividades que menciono incrementarán costos y retrasarán el tiempo de entrega. No es así. En realidad los costos y tiempos mejorarán porque más tiempo es dedicado típicamente en proyectos a la detección y resolución de defectos de lo que toma evitarlos como les he mostrado aquí. Aún muchos de los defectos que no son detectados de la manera tradicional son encontrados tarde, cuando el servicio ya está en producción o fue entregado al cliente, haciéndolo mucho más costoso.

Les invito a que eleven el nivel de madurez de sus organizaciones y actividades de calidad.

Bio

El Dr. Masa K Maeda es el CEO de Valueinnova en Silicon Valley USA, Consultor Senior del Cutter Consortium, Maestro en la Universidad de Berkeley, Miembro del Comité de Dirección del Agile Testing Alliance, coautor del libro España Lean Startup Nation y autor del libro Serious LeAP que será publicado en Septiembre de éste año.

La retrospectiva de lo que viene

masamaeda — Mon, 07 Jul 2014 23:46:42 +0000

La retrospectiva de lo que viene masamaeda Mon, 07/07/2014 - 18:46

Publicado en

SG #44

Agilidad

Autor

Masa K. Maeda

Los últimos 10 años han sido, desde mi punto de vista, sin lugar a duda los más interesantes en la historia de las computadoras y del software. Estos años no incluyen eventos determinantes que alteraron el curso de la historia de la humanidad tales como la invención del transistor (la primer patente fue en 1925 y el primer transistor de uso comercial fue creado en 1954) o el desarrollo del Internet (la investigación se inició en 1960 y la primer red de TCP/IP llamada Internet fue introducida en 1982) pero muchas personas, yo entre ellos, consideramos la introducción del internet el advenimiento del segundo renacimiento.

Los eventos de la década pasada nos dan bases para imaginar lo que puede suceder en la década que viene.

Comenzaré listando algunos de los desarrollos más importantes que han habido cada año para entonces comentar porqué los he considerado así y como están influenciando lo que vendrá.

En 2004 el Internet pasó de ser un ambiente primordialmente estático a uno dinámico e interactivo (Web 2.0); Facebook es lanzado como ¨thefacebook.com¨. Un terremoto de magnitud 9.3 que mata 230,000 sucede en el Océano Índico se convierte en el evento más difundido a nivel mundial primordialmente mediante el internet mediante la tecnología Web 2.0.

En 2005 las memorias Flash USB son introducidas al mercado reemplazando los discos floppy y YouTube es fundado. Los ataques terroristas, suicida en Londres y el huracán Katrina que destruyó una gran parte de Nueva Orleans son difundidos primordialmente mediante el internet.

En 2006 Twitter es lanzado. YouTube pasa de ser un sitio web de entretenimiento sin trascendencia social o cultural a ser el nuevo medio de difusión de cultura y noticias. Amazon lanza su servicio Cloud, convirtiéndose en pionero en esa tecnología y ganándose alto respeto en la industria de alta tecnología.

El evento más importante de 2007 fue el colapse económico a nivel mundial. El iPhone y el Kindle son lanzados al mercado. Se reportan montos significativamente bajos de hielo en el Océano Ártico.

Durante el 2008 vimos la explosión de servicios Cloud y el rechazo de Yahoo! ser adquirido por Microsoft. Android es lanzado al mercado. Las Olimpiadas se llevan a cabo en Beijing haciendo alarde tanto de tecnología como de desarrollo arquitectónico y a pesar de los problemas sociales internos y políticos con Tibet, que se hacen más visibles gracias al internet.

En 2009 El virus H1N1 se difunde de tal manera que es declarado la primer pandemia mundial desde 1967 y su peligro es mayor debido al alto número de personas viajando por todo el mundo. Cinema en 3D es lanzado. La competencia por el mercado móvil se intensifica entre iPhone y dispositivos que usan Andriod.

En 2010 el iPad es lanzado e inicia una nueva era en tecnología móvil. Facebook alcanza 500 millones de usuarios.

2011 fue un año de muchos inicios. Vimos el lanzamiento del servicio Google Translate, el primer movimiento de Hacktivismo donde hackers pasan a tener relevancia social y política, y la competencia de los ultrabooks también es iniciada. El evento más importante fue la revolución en Egipto, donde el internet desempeñó un rol clave como medio de comunicación, concientización y divulgación no regulada.

En 2012 vimos un giro cuestionable: los intentos de regular, monitorear y controlar el uso del Internet. Facebook entra al mercado de bolsa con proporciones históricas. Netflix consume el 20% de todo el tráfico del internet en USA después de las horas de oficina.

En 2013 Twitter entra al mercado de bolsa sobrepasando el éxito de Facebook. Las impresoras 3D son el nuevo hardware de mayor atención con usos e inventos impredecibles.

¿Qué podemos esperar en los próximos 10 años? Basado en los eventos pasados y en las tendencias tecnológicas veo cosas fascinantes y cosas vergonzosas.

Dentro de lo fascinante veremos la madurez del desarrollo de software influenciado primordialmente por Lean y Ágil; la aceleración de innovación gracias a dispositivos tales como las impresoras 3D; Una dilución entre la televisión, el internet, las computadoras, y los dispositivos móviles donde todos serán capaces de controlarse entre ellos y de controlar el entorno (espacios de trabajo y hogares); Casi toda tecnología digital será inalámbrica, incluyendo la energía; y redes de computadora serán autocorrectivas. Veo también el advenimiento de robots serviciales en hogares; avances en genómica que reducen la dependencia en hospitales y doctores; Redes sociales se convertirán en redes de colaboración para resolver problemas y generar productos y servicios.

La parte vergonzosa será el uso de tecnología que limitará la libertad de las personas y permitirá que personas en puestos de poder y gobiernos incrementen su nivel de control. El impacto social y económico será lo más importante.

Bio

El Dr. Maeda es el CEO fundador de Valueinnova LLC en USA y tiene 25 años de experiencia. Cuenta con clientes de todo tamaño, desde Fortune 500 hasta Startups en 12 países en 4 continentes. Es el autor de libro Serious LeAP, a publicarse éste verano, y coautor del libro España Lean Startup Nation. Tiene más de 60 publicaciones y numerosas presentaciones magistrales en conferencias internacionales. Previamente hizo investigación y desarrollo para Apple Inc. y fue miembro de los grupos fundadores de 4 empresas en Silicon Valley

Innovación de valor mediante Lean-Agile: Logrando ventaja competitiva

Anonymous — Mon, 16 May 2011 18:11:36 +0000

Innovación de valor mediante Lean-Agile: Logrando ventaja competitiva Anonymous Mon, 05/16/2011 - 13:11

Publicado en

SG #32

Agilidad

Autor

Masa K. Maeda

Todo profesionista eventualmente llega a la realización de que todo proyecto y equipo de trabajo es distinto. Lo interesante está en que por otro lado tenemos estándares, modelos y métodos para ayudarnos a reducir el nivel de caos en los proyectos. Esto ha tenido como consecuencia que muchos líderes y equipos caen en la trampa de la plantilla y hacen las cosas siguiendo ciegamente los estándares sin percatarse de la contradicción de sus actos con respecto a la realidad de los proyectos y equipos.

El uso combinado del pensamiento lean y ágil ha demostrado ser muy exitoso para mejorar organizaciones. Mediante mi propia práctica así como casos reportados, he encontrado que el éxito no es tan completo como pudiera serlo porque el alcance es típicamente limitado a los confines del desarrollo de software, dejando a un lado otros factores tales como interacción con clientes, comunicación y colaboración entre stakeholders, incremento de ventaja competitiva y enfoque en innovación.

El Prisma Lean-Agile

Digamos que dos nuevos productos son ofrecidos en el mercado por empresas enteramente nuevas, por lo que no se cuenta con una imagen empresarial establecida. Así mismo, no se llevó a cabo ninguna actividad de mercadotecnia por lo que el único parámetro de evaluación que los clientes tienen son los productos mismos. Ambos productos ofrecen las mismas características y la misma calidad (ver Figura 1). La pregunta es: ¿cual producto compraría usted?

Al hacer esta pregunta dos respuestas prevalecen:

a) El más barato.
b) El que más me guste.

Exploremos estas respuestas un poco más con una tercer pregunta. ¿Si el que le gusta más tiene mayor precio, estaría usted dispuesto a gastar ese dinero extra y de ser necesario, esperarse un poco de tiempo hasta tener el dinero para comprarlo?
Consistentemente, la mayoría de la gente contesta “sí”. Esto implica que si una de las dos empresas llevó a cabo innovación con respecto a valor para con el cliente tal que su producto es más atractivo entonces es más probable que tenga una ventaja competitiva.

Ahora bien, si tenemos de nuevo dos productos como en el caso anterior, pero en esta ocasión los dos productos ofrecen: mismas características, misma calidad, mismo precio y son igualmente atractivos. ¿Cuál compraría usted?

Digamos que como no hay diferenciador, ambas empresas venden exactamente el mismo número de unidades. Ahora bien, si una de las empresas llevó a cabo innovación con respecto a la forma en que su producto fue creado entonces es probable que el costo de producción, distribución y operaciones sea menor. Ello quiere decir que esa empresa obtuvo mayor ganancia. Y aún más, esa empresa tiene mayor probabilidad de que su siguiente producto sea más atractivo o de menor costo, así como también pueda ser lanzado al mercado en menor tiempo.

Esto quiere decir que llevar a cabo innovación con respecto a valor hacia el cliente y con respecto a valor hacia la empresa, nos da potencialmente una ventaja competitiva significativa. Esto lo podemos representar mediante el Prisma Lean-Agile.

Figura 1. El Prisma Lean-Agile.

En el Prisma Lean-Agile tenemos:

Restricciones. Son los elementos establecidos en el triángulo de hierro de gestión de proyectos, es decir presupuesto, itinerario y alcance.
Calidad. Es aquella establecida por el cliente y la cual tenemos la obligación de alcanzar y de hecho exceder.
Innovación. La que estamos definiendo en el presente artículo.
Valor. Es el factor más importante, por ello su posición de pináculo en la estructura. El valor es establecido por el cliente y el valor para la empresa debe estar supeditado al valor para con el cliente.

Innovación de valor

El término innovación de valor fue acuñado por Chan Kim y Mauborgne, y tiene que ver con enfocarse en crecer el negocio mediante la identificación de nuevos mercados en lugar de enfocarse en competir. La manera en la que yo he introducido innovación de valor es un poco diferente pero alineado en buena medida con esa definición.

La forma que propongo para pensar en innovación es tomar como punto de inicio cosas que ya existen y generar algo nuevo que resulta en un cambio positivo significativo que agrega valor al cliente y a la empresa. Ello implica éxito comercial. Ese algo nuevo puede tener que ver con procesos, herramientas, formas de colaborar, etc. y puede ser de cualquier tamaño y grado de simplicidad.
Su resultado es una aceleración en la ventaja competitiva y en la madurez empresarial con lo cual se alcanza flujo continuo de valor más fácilmente y se mejora construyendo sobre sus propios éxitos.

Pensamiento innovador

El pensamiento innovador es el estado mental en el que los stakeholders:

Están dispuestos a aceptar y pasar por una transformación de la manera en que ven y hacen su trabajo.
Aplican pensamiento en sistemas para entender mejor lo que se debe lograr y resolver problemas complejos de forma más eficiente.
Utilizar el sistema de conocimiento profundo como una guía para mejorar la gestión y la organización.
Utilizar pensamiento esbelto (lean) para mejorar procesos.
Utilizar pensamiento ágil para utilizar herramientas innovadoras de forma más eficiente.

Esta transformación facilita reconocer la importancia de contar con agentes de cambio en todos los niveles de la organización.

Ambiente que fomenta innovación

Las personas que practican lean-agile ya tienen un buen entendimiento de las ventajas de contar con un ambiente que fomenta la innovación. El ambiente apropiado conjunta los recursos humanos y materiales adecuados de manera tal que facilita las actividades de innovación. Es decir:

Mejora la comunicación entre todos los stakeholders tanto internos como externos a la empresa (incluye clientes y de ser posible usuarios finales).
Facilita la colaboración entre todos los stakeholders.
Es transparente con respecto a todos los aspectos del proyecto y la organización. Entre mayor es el nivel de conocimiento compartido mejores decisiones y mejor acción se puede llevar a cabo, resultando en incrementos de productividad y calidad. Así mismo, la motivación de los stakeholders también se incrementa.
Le permite a los stakeholders explorar y encontrar mejores formas de hacer las cosas y crear mejores productos y servicios.
Le da autonomía a los stakeholders.

Herramientas innovadoras

Un gran ejemplo de ese tipo de herramienta es el método Kanban, el cual incrementa la efectividad del equipo y promueve mejoras de parte de los stakeholders externos al equipo. Al mismo tiempo provee herramientas visuales y evidencia cuantitativa facilitando el análisis de causa raíz, permitiendo así dedicar más tiempo a la generación de las mejoras mismas.

Las herramientas innovadoras están en alineación con la autonomatización (la automatización con toque humano), se motiva el automatizar para que los recursos humanos puedan ser canalizados a actividades que realmente requieren del ingenio y otros factores humanos con lo que efectivamente llevarán a cabo mejoras. Nótese que algunas herramientas innovadoras no incrementan automatización pero incrementan productividad y/o calidad.

Factor humano

Así como el Prisma Lean-Agile tiene valor como su pináculo, innovación de valor tiene como su cúspide el factor humano, el cual es a fin de cuentas lo que hace que la innovación suceda. Las herramientas, el ambiente y el pensamiento innovador son las bases para que las personas generen ventajas competitivas y maduren la empresa. A fin de cuentas, lo que los líderes deben gestionar no son proyectos sino personas.

Caso de éxito

En México apliqué innovación de valor como parte de la adopción lean-agile. La tabla 1 muestra la transformación obtenida.

Tabla 1. Antes y después de adoptar lean-agile Kanban utilizando innovación de valor.

Bio

El Dr. Masa K Maeda es Presidente y Fundador de Shojiki Solutions, una empresa dedicada a ayudar empresas en la adopción y mejoramiento del uso de metodologías Agile-Lean. Tiene más de 20 años de experiencia en la industria de software en Japón, México, y Estados Unidos. Obtuvo el Doctorado y Maestría en Sistemas Inteligentes y Ciencias de la Información en la Universidad de Tokushima en Japón y la Licenciatura en Ingeniería en Computación en la Universidad Nacional Autónoma de México. www.shojiki-solutions.com

El Prisma Lean-Agile

Anonymous — Sat, 21 Aug 2010 19:30:26 +0000

El Prisma Lean-Agile Anonymous Sat, 08/21/2010 - 14:30

Publicado en

SG #29

Agilidad

Autor

Masa K. Maeda

La mayoría de los ejecutivos y líderes a los que asesoro tienen dificultad para terminar sus proyectos a tiempo y dentro de presupuesto, lo cual es frustrante para ellos. Un aspecto que los frustra aún más es el hecho de que los clientes parecen nunca estar satisfechos. Mucho se ha publicado en cuanto a maneras de atacar estos problemas, pero la mayoría de las estrategias se quedan cortas, especialmente en cuanto a la satisfacción del cliente.

Recientemente Jim Highsmith propuso el Triángulo Agile, el cual nos da una base mas sólida para resolver este problema. Yo he propuesto una extensión al triángulo de Highsmith, resultando en un prisma para gestión de proyectos basado en Lean-Agile. En este artículo explico dicha estrategia.

El triángulo de hierro

La teoría tradicional de la gestión de proyectos se basa en el concepto del “triangulo de hierro”. Éste consiste en una descripción gráfica de las tres consideraciones clave para gestionar proyectos: alcance, costo, e itinerario (ver Figura 1). La teoría de este triángulo indica que podemos mantener fijos dos de estos aspectos, pero no los tres (ej. si fijamos costo e itinerario, debemos ser flexibles con el alcance). En la vida real la gran mayoría de las empresas pretenden fijar los tres, por lo que la flexibilidad no es permitida, o es permitida cuando ya es demasiado tarde. Muchos ejecutivos evitan las fluctuaciones porque piensan que es una señal de falla e incompetencia. El resultado es una mala calidad de los productos y servicios resultantes, y quien paga las consecuencias es el cliente.

Figura 1. El triángulo de hierro.

Yo conocí el triángulo de hierro durante un curso de administración de proyectos hace muchos años. Dado que yo siempre he puesto particular interés a la calidad, cuando el instructor terminó su explicación sobre el triángulo le pregunté en qué parte de éste se encontraba la calidad. Él pensó al respecto por un momento y dijo que la calidad estaba en el centro del triangulo de manera implícita. Si eso era cierto entonces, ¿por qué no lo mencionó durante su explicación? Además, la calidad es demasiado importante como para “estar implícita”. Decidí no regresar a ese curso.

Terminar los proyectos dentro de tiempo, costo y alcance no garantiza clientes satisfechos.

El primer triángulo ágil

Poco después de la publicación del manifiesto ágil se creó un nuevo triángulo basado en los valores y principios de Agile (ver Figura 2). Dicho tríangulo considera los mismos elementos que el triángulo tradicional, pero se dibuja de forma invertida, con el alcance en la parte inferior. La forma de interpretarlo es que para que un proyecto sea exitoso se debe fijar el alcance del proyecto y dejar que el costo e itinerario se ajusten adecuadamente. Es decir, los ejecutivos deben permitir el monto de dinero y tiempo necesario para que el alcance se logre. El problema con esta visión es que es difícil de implementar en las empresas debido a la flexibilidad que implica.

Figura 2. El triángulo ágil.

El nuevo triángulo ágil

El costo e itinerario son más bien un impedimento. Casi siempre estamos cortos de por lo menos uno de ellos. El alcance también es un problema porque con demasiada frecuencia los proyectos son muy ambiciosos y terminan siendo recortados. A fin de cuentas esto quiere decir que los tres son de hecho restricciones. Jim Highsmith se dio cuenta que el triángulo agile original es incompleto y propuso uno nuevo (ver Figura 3). Este triángulo tiene calidad como uno de los tres aspectos que considerar. El segundo aspecto son, sin sorpresa, las restricciones: costo, tiempo, y alcance, que deben ser gestionadas de manera tal que se maximicen la calidad y el valor esperado. El tercer aspecto es el mas importante: el valor, el cual es la medida de satisfacción del usuario porque el producto o servicio le da lo que realmente desea y necesita.

Figura 3. El nuevo triángulo ágil.

Cuando leí sobre esta propuesta de Highsmith estuve placenteramente sorprendido y definitivamente concuerdo con ella. Un producto exitoso es aquel que provee el valor más alto posible al cliente. El beneficio para la empresa es la recurrencia de clientes y los inversionistas felices.

El prisma lean-agile

Para entender el razonamiento detrás del prisma lean-agile, primero compartiré con ustedes una historia reciente con un cliente al que asesoré.

Cierto hotel de lujo recientemente me pidió que evaluara el software de automatización de operaciones que habían desarrollado. El sistema desarrollado era bastante completo e incluía aspectos tales como gestión de servicio a cuartos, actividad telefónica, front desk, estacionamiento, lavandería, cajas de seguridad. El gerente de sistemas, llamémoslo Pedro, era el creador del sistema —literalmente— y me mostró lo que había hecho hasta ese entonces. Atinadamente me mostró la funcionalidad en los lugares donde las acciones se llevaban a cabo. Por ejemplo, me llevó al front desk para mostrarme las operaciones que se llevan a cabo ahí y la manera en que el sistema era usado. El tono de su voz durante las explicaciones cambiaba de orgullo a frustración y viceversa. Pedro eventualmente dijo: “no entiendo por qué los empleados cometen tantos errores al usar el sistema si todo está claro, y tampoco por qué me llaman a todas horas del día y de la noche con preguntas innecesarias”. Pedro estaba en lo cierto en cuanto a que la mayoría de los problemas realmente no existían, y en cuanto a que la mayoría de los problemas eran por error humano. Su convicción era que el personal no sabía cómo usar computadoras adecuadamente.

Mi conversación con Pedro ese día comenzó frente a un pizarrón en una sala de juntas, donde él dibujó un diagrama mostrando su estrategia de automatización, incluyendo lo que ya se ha hecho y las perspectivas. Sus planes eran razonablemente sólidos desde el punto de vista técnico. Algunos aspectos que no me gustaron fueron el enfoque reactivo y la falta de atención a la calidad, así como falta de atención a los usuarios. Pedro consideraba que sus sistemas han agregado mucho valor debido al alto monto de automatización y la confiabilidad del código. Sin embargo, los usuarios no estaban satisfechos. Algo faltaba ...

Pedro me llevó alrededor del hotel para mostrarme las diferentes aplicaciones en el lugar donde son utilizadas y con datos vivos. Comenzamos en la zona de registro en el lobby, de ahí las operaciones de uso directo por los clientes, las operaciones a nivel de servicios, y finalmente infraestructura. Yo estaba sorprendido en dos sentidos opuestos. Por un lado, el sistema era muy completo en términos del alcance y profundidad de su funcionalidad. Sin embargo la usabilidad del sistema era bastante mala, consistía en un gran conjunto de ventanas apiladas, todas con apariencia similar, sin una secuencia intuitiva, y con poca tolerancia a error humano. Incluso hubo ocasiones en las que Pedro mismo tuvo que hacer una pausa para determinar el estado de la aplicación y evitar cometer un error mientras me explicaba la funcionalidad.

Entendí por qué los empleados del hotel estaban teniendo tanta dificultad con los sistemas y que Pedro fuera requerido continuamente. Parecía ser que Pedro no se daba cuenta de las causas raíz, pero admitió la necesidad de mejora una vez que se las señalaba. Un área de mejora importante era la calidad; y con eso no quiero decir necesariamente que los sistemas tenían muchos defectos sino más bien que la usabilidad necesitaba más trabajo. La parte que faltaba era un diseño adecuado de la interfase de usuario. La funcionalidad de las aplicaciones era definitivamente adecuada, pero el mal diseño de la interfase de usuario hacía que la funcionalidad fuera de poco valor ya que los usuarios confrontaban todo tipo de retos que resultan en retrasos, errores, frustración, y hasta abandono. El lenguage de una interfase de usuario debe tener coherencia estructural con enfoque en facilidad de uso sin perdida de funcionalidad.

Dejemos a un lado el caso de automatización de hoteles y consideremos un producto de consumo. Usted está buscando por un nuevo teléfono celular y pasa algún tiempo viendo diferentes modelos, buscando el que mejor satisface sus necesidades. Digamos que termina con tres para escoger. Uno de ellos es de bajo precio pero no ofrece toda la funcionalidad que desea; podemos dar ese por eliminado. Los otros dos aparatos tienen todas las características que necesita, tienen el mismo nivel de calidad, y el precio entre ellos es tan cercano que es irrelevante en la decisión. ¿Cuál escogería? El que le gusta más desde el punto de vista de diseño.

Es decir, aquel con el que usted se sentirá mejor sacando de su bolsillo para mostrarselo a sus amigos. Muy probablemente usted escogería el que le gusta más, aún si tuviera mayor costo. ¿Por qué? Porque el diseño innovador le importa a los consumidores y están dispuestos a pagar más por el.

El diseño innovador es importante para los usuarios, tanto como el valor y la calidad adquirida. Poner el diseño bajo la sombrilla de valor le daría menor importancia de la que de hecho tiene—similar a cómo la importancia de la calidad disminuiría si la ponemos bajo la sombrilla de valor.

W. Edwards Deming, quien fue altamente influencial en el desarrollo de lo que actualmente conocemos como Lean, enfatisó la importancia de prestarle atención a tres aspectos: sistemas, gente, y la mejora integral (la perspectiva holística). El pensamiento Lean nos dice que debemos prestar particular atención al valor entregado al cliente, tanto interno como externo. Habrá quienes puedan argumentar que el diseño cae dentro de la categoría de valor, o de calidad. Sin embargo, mi opinión es que eso equivaldría a lo que el triángulo de proyectos hace con la calidad, dándola como implícita. Adicionalmente, Lean pone un gran énfasis en el factor humano (lo que Taiichi Ohno llama “autonomación” o automatización inteligente), simplemente que en lugar de la perspectiva de humanos controlando un flujo de procesos de manufactura, aplicamos el concepto como la satisfacción de usuario interpretada como la motivación que tiene de usar un producto o servicio, más allá del valor que le provee su funcionalidad.

Tomando en cuenta esto, yo propongo que el diseño tenga un lugar explícito en la gestión de proyectos de tecnología, una vista que transforma el triángulo de Highsmit en un prisma, como se muestra en la Figura 4. Nótese que el valor está en la cima porque continúa siendo el aspecto central a considerar.

Figura 4. El prisma lean-agile.

La mayoría de ustedes han de recordar la guerra de los reproductores de música digital poco después de que ésta tecnología fue introducida. La competencia era furiosa y no había un ganador claro que estuviera como líder, hasta que Apple introdujo el iPod. Para ese entonces yo ya había adquirido un reproductor que tenía más características que el iPod y era más barato. Sin embargo, todos mis amigos que adquirieron iPods me dijeron que no les importaba si mi reproductor era “mejor”. Esto muestra como los clientes pueden llegar a darle mayor importancia al diseño y facilidad de uso que a la funcionalidad o el costo.

El diseño no está limitado a la interfase de usuario. Se refiere a encontrar nuevas maneras de hacer cosas tales como crear herramientas, la generación de procesos de desarrollo de software, las estrategias de gestión de proyectos, las actividades relacionadas a calidad, etcétera. El diseño innovador puede contribuir a la reducción de costos, por ejemplo, mejorando la eficiencia de nuestras herramientas y procesos. Lo que deseamos lograr es una evolución continua de la empresa y de los productos o servicios que generamos para mantener a nuestros clientes y empleados felices, y para mantenernos competitivos.

Pedro se tiene que enfocar en mejorar el diseño de sus sistemas de automatización de hoteles si desea darle a sus usuarios el valor correcto. Esto también le traerá beneficio a él mismo, no solo porque dará un mejor servicio sino porque las llamadas de soporte se reducirán significativamente.

Referencias

Project triangle, Wikipedia.
J. Hisghmith. Agile Project Management. Addison-Wesley, 2010.
Autonomation, Wikipedia.

Bio

Dr. Masa K. Maeda es Presidente y Fundador de Shojiki Solutions, una empresa dedicada a ayudar empresas en la adopción y mejoramiento del uso de metodologías Agile-Lean. Tiene más de 20 años de experiencia en la industria de software en Japón, México, y Estados Unidos. Obtuvo el Doctorado y Maestría en Sistemas Inteligentes y Ciencias de la Información en la Universidad de Tokushima en Japón y la Licenciatura en Ingeniería en Computación en la Universidad Nacional Autónoma de México. www.shojiki-solutions.com

Coaching y Producción

Anonymous — Tue, 15 Jun 2010 18:51:48 +0000

Coaching y Producción Anonymous Tue, 06/15/2010 - 13:51

Publicado en

SG #28

Agilidad

Autor

Masa K. Maeda

¿Qué tienen en común los Beatles, Nirvana, y la Orquesta Sinfónica de Minnesota? Cada uno de ellos tuvo la suficiente suerte de trabajar con un productor que les ayudó guiándoles durante la creación de una gran grabación. Los productores exitosos de música entienden que la colaboración iterativa es un ingrediente clave para la producción de grandes grabaciones. Los mejores productores aprendieron que el balance de la creatividad, las habilidades, el tiempo y el dinero son esenciales para lanzar grabaciones valiosas. Al igual que produciendo música, me doy cuenta que coachear proyectos agile (ágiles) es una artesanía que involucra llegar a conocer a la comunidad del proyecto, el producto que se está construyendo, las herramientas y las tecnologías. Los coaches exitosos balancean el desarrollo de habilidades, peticiones para el producto, tiempo y presupuesto, como una manera de lanzar software que es oportuno y valioso.

El proceso de producción de música

Cada canción sigue un proceso similar de grabación, mezclado, generación del master, y lanzamiento. Dentro del proceso cada canción sigue una jornada única. (Ver Figura 1) El productor ayuda a que las canciones sobrevivan el proceso de grabación guiando a los artistas a través del proceso de grabación similarmente a como un coach ayuda a un equipo a lanzar un producto de software.

Existen dos categorías de productores: productores prescriptivos, empujan a la gente a seguir el proceso y las técnicas que ellos han utilizado exitosamente; y productores descriptivos quienes tienden a guiar y enseñar con anécdotas. En lugar de decirle a la gente qué hacer, ellos sugieren ideas y motivan a los artistas a tomar riesgos y decisiones sobre la mejor manera de capturar su música.

Pre-producción. El tiempo dedicado en la preparación, antes del primer día en el estudio, vale mucho la pena para crear una sesión de grabación relajada y exitosa. La preproducción no debe prescribir el resultado de ninguna sesión de grabación, sino ayudar a aprender más sobre los artistas y la manera en que tocan como grupo. Si crees que un proyecto de software es mas difícil que un proyecto de grabación, entonces unos días en el estudio te podrán enseñar que el monto de emoción, miedo y volatilidad en el estudio, es normalmente mayor.

Las sesiones de grabación. Las sesiones de grabación es donde las canciones son cantadas y las pistas son cortadas. El proceso es absolutamente iterativo e incremental. Ayudando a la banda a enfocarse en cada canción, así como en la colección entera de canciones, el productor agrega continuidad. El productor trabaja con uno o más artistas, grabando y re-grabando partes separadas; y con el ingeniero de grabación de manera que la tecnología sea utilizada para ayudar a los artistas conforme su ejecución es capturada con fidelidad. El productor puede ayudar a asegurar que los artistas y la canción sean atendidos por la tecnología, en lugar de hacerse sirvientes de la tecnología.

Coaches de desarrollo de software como productores

Mi primera oportunidad para la creación de software fue en una pequeña compañía exitosa. Nuestra compañía trabajaba muy parecido a lo que hoy se entiende como ágil: teníamos juntas informales cortas, éramos dirigidos por resultados, y programábamos en pares aunque tan solo le llamábamos “trabajar juntos”. Conforme cambié a empresas más grandes se me pedía que siguiera diversos procesos que tan solo parecían frustrar a la gente. Como un acto de autopreservación le presté atención a los procesos ágiles que estaban emergiendo, éstos parecían proveer el monto de estructura al que me había acostumbrado durante mis primeras experiencias de software, y la experiencia era en mucho como el estudio de grabación.

Creo que me hice coach de manera más bien descriptiva que predictiva. Después de varios años de ofrecer coaching, busqué maneras de mejorarlo y aprender qué parte de cada proyecto exitoso tuvo que ver con el coaching y qué parte tuvo que ver con la comunidad o nuestro uso de métodos ágiles. Fue rápidamente claro que muchas de mis habilidades como productor habían sido transferidas a mi coaching. Mientras que los medios difieren, la labor del coach y del productor son muy similares. Ambos ayudan a la gente a crear su mejor producto con el tiempo, dinero, y tecnología disponibles. Donde el productor ayuda a los artistas a hacer grabaciones de las canciones, el coach ayuda a las comunidades de proyecto a hacer de los sueños del Product Owner un software funcional (ver Figura 2).

Preproducción. Muchos proyectos comienzan con algún tipo de preproducción a fin de crear el tiempo y espacio para que una comunidad esté lista para producir. Esto ofrece el mismo beneficio que en el mundo de la música. Usualmente agrego cuatro prácticas de preproducción al coaching:

Estatutos del proyecto.
Crear un backlog de producto inicial.
Espacio informativo de trabajo.
Iteración 0.

Intento asegurarme de que el monto de rigor de preproducción es apropiado para la comunidad que estoy coacheando. Por ejemplo, un equipo muy adaptivo puede completar estas cuatro fases en unos cuantos días. Contrariamente, un grupo grande y distribuido que está reemplazando un sistema complejo puede necesitar más tiempo de preproducción.

Estatutos de proyecto. Para ver mejor el valor del coach tomemos los estatutos de proyecto desde el punto de vista del coach. Muchos gerentes crean estatutos de proyecto, pero tristemente poca gente los lee porque probablemente son enterrados, no son compartidos, o la gente no toma pertenencia. La comunidad ágil tomó una herramienta existente y la hizo mejor mediante su transformación en una herramienta colaborativa. Los estatutos son creados por la comunidad para la comunidad. Son una forma para que se conozca la comunidad entre ella, el propósito del proyecto, la gente en la comunidad inmediata y extendida del proyecto, así como las fortalezas y riesgos que están por delante.

Las iteraciones tempranas. En el estudio, el corte de buenas pistas de soporte es esencial para producir un gran producto final. Conforme la banda graba y regraba cada canción comienzan a crear un buen estado de ánimo. En ocasiones ese estado crece orgánicamente, con intervención limitada del productor. Las iteraciones tempranas son un tiempo importante para generar vínculos y hábitos sanos. Cada iteración reta a la comunidad a reunirse en una forma tal que se entregue software funcional y una base de código sana de manera sostenible. Describo un par de ejemplos:

Ayudando a la Gente a Aprender. En lugar de meterse y tocar una parte para un músico que esta luchando por lograr algo, el productor utiliza sus habilidades y ve la manera de entender porqué el músico está teniendo dificultades. Un coach hábil encuentra el momento adecuado para ofrecer palabras de apoyo y el momento adecuado para dar un empujoncito.

Liderando y enseñando. Mientras que tu coach puede dirigir las primeras juntas o las sesiones de planeación de iteración, los mejores coaches saben que la ruta hacia el éxito sostenible se pavimenta permitiendo que la comunidad se encargue lo antes posible.

• Explicando porqué más que diciendo cómo. Ayudar a los artistas en el estudio a utilizar el proceso para capturar su música es mucho más importante que enseñarles a utilizar los aparatos. Agilidad sostenible es más común cuando la gente ve el valor de la práctica, en lugar de que tan solo se les diga cómo hacer la práctica.
• La importancia de dejarlo hecho. Mientras que el coach hace el trabajo con individuos, en otras ocasiones el trabajo es con la comunidad. El couching de éxito sostenible significa dejar que la comunidad
tome posesión y crezca su uso compartido.

Afinamiento continuo. Tanto el productor como el coach tienen trabajos difíciles que requieren de gran paciencia y liderazgo continuamente respetuoso. Coachear es un proceso continuo y no un evento. Cambios gracias al coaching suceden en una serie de pequeños momentos que incrementalmente se suman de manera sutil en pequeños eventos, que le ayudan a la comunidad a experimentar, examinar, y mejorar de pedacito en pedacito.

Conclusión

Ya sea que estés produciendo discos o software, decir historias es una de las herramientas más poderosas. Tú puedes decirle a la gente qué hacer, el estilo prescriptivo, pero puede que no te escuchen. En su lugar, diciéndoles lo que has hecho, el estilo descriptivo, inicia una discusión significativa.Una vez que las personas están metidas en el tema, el estilo descriptivo les permite aprender qué parte de tu experiencia puede ser útil.

Figura 1. El proceso de producción de música

Figura 2. El proceso de producción de software

Bio

David Hussman es fundador y director de DevJam, empresa norteamericana que se dedica a enseñar y coachear equipos
interesados en adoptar métodos ágiles. David ha coacheado a cientos de equipos ágiles en todo el mundo. Previamente, David se
dedicó a construir software para diversos dominios tales como audio digital, biométricos, salud y educación, por nombrar algunos.
@davidhussman

Lean-Agile lo mejor de dos mundos

Anonymous — Wed, 24 Feb 2010 00:26:18 +0000

Lean-Agile lo mejor de dos mundos Anonymous Tue, 02/23/2010 - 18:26

Publicado en

SG #27

Agilidad

Autor

Masa K. Maeda

Agile (desarrollo ágil) ha estado resonando en Norteamérica desde mediados de los 90’s. En Asia y Europa se ha estado adoptando por poco más de una década. En Latinoamérica apenas está por alcanzar media década, con Brasil como el país a la delantera, y países como Argentina, Perú y Chile tomando fuerza en buena medida gracias a la cercanía geográfica y la fuerza económica de Brasil.

En México ya existían unos cuantos casos aislados, y en el 2009 aumentó significativamente el interés en distintas industrias aunque todavía hay mucho desconocimiento. Yo, por ejemplo, viviendo en los E.U. pasé en 2009 alrededor de 120 días hábiles en México evangelizando e intentando hacer negocios ofreciendo servicios para la adopción de lean (desarrollo esbelto) y agile. Rápidamente me dí cuenta que todavía se conoce poco sobre agile, y mucho menos sobre lean.Lean se originó en Japón dentro del área de manufactura en los 70’s y gradualmente se expandió a otras áreas tales como gestión, manejo de oficinas, y eventualmente desarrollo de software. Muy probablemente la primer publicación de gran influencia sobre desarrollo de software lean fue el libro titulado “Lean Software Development: An Agile Toolkit” de Mary y Tom Poppendieck [1].

Bueno pero, ¿si agile es considerado lo más novedoso y fabuloso entonces por qué queremos prestarle atención a lean? ¿quiere eso decir que agile es incompleto o no es tan bueno como parecía? Por un lado, agile es altamente compatible con lean (en buena medida los valores y principios agile tienen fundamentos lean), y por otro lado no existe un modelo, estándar, metodología o práctica que sea una bala de plata.

Agile ha demostrado ser mucho más efectivo no necesariamente porque es una nueva receta, sino porque resalta aspectos que habían sido ignorados o se les había prestado poca atención. De manera similar, lean nos ayuda a ajustar el enfoque de lo que es importante para lograr el éxito de los proyectos. Ambos son muy efectivos por si mismos, y juntos hacen una combinación fabulosa.

Lean nos indica que debemos prestar atención a siete factores:

Eliminar todo aquello que genera desperdicio, es decir, que no agrega valor al producto o servicio a generar para satisfacer la necesidad real de usuario.
Aprendizaje sobre el producto o servicio a generar, así como también incrementar el nivel de conocimiento y experiencia de todas las personas involucradas, tanto ingenieros como gerentes, ejecutivos, diseñadores, arquitectos, e inclusive el cliente.
Saber tomar decisiones en el momento adecuado (comparado con tomar decisiones temprano) basándonos en el tipo de pensamiento adecuado.
Entregar productos o servicios de manera temprana en lugar de manera rápida o monolítica.
Darle a la gente poder de decisión mediante auto-organización, liderazgo, motivación y experiencia.
Construir productos y servicios con integridad tanto a nivel de lo que el usuario percibe como a nivel de el producto mismo (la calidad que el usuario percibe y la calidad real).
Considerar el todo. Las mejoras no pueden ser en tan solo un subconjunto de lo que se requiere para generar el producto o servicio, sino en todo lo que comprende al producto y todo aquello requerido alrededor del producto para su creación.

Así como diversas metodologías como Scrum, XP, o FDD surgieron a partir de agile con influencia de lean, la metodología de Kanban surgió a partir de lean con influencia de agile y teoría de restricciones. En contraste con Scrum, por ejemplo, Kanban no requiere de iteraciones, y nos permite tener una visualización más completa del desarrollo la cual permite ver variaciones de manera temprana y por lo tanto tomar acción más efectivamente.

Lean en conjunto con agile nos provee de una serie de herramientas muy poderosas, comenzando con el hecho de que generan un cambio en la manera de ver proyectos, cómo gestionarlos y cómo desarrollarlos.

Nos muestran una forma de ser exitosos sin tener que continuar con los hábitos que consumen recursos tanto materiales como humanos
de manera desmesurada. Son elementos que no podemos darnos el lujo de ignorar dada la situación económica actual.

Lecturas recomendadas:
[1] M. Poppendieck & T. Poppendieck, Lean Software Development.
Addison-Wesley, 2003
[2] M. Poppendieck & T. Poppendieck, Leading Lean Software Development. Addison-Wesley, 2009
[3] A. Shalloway, G. Beaver, J.R. Trott, Lean-Agile Software Development.
Addison-Wesley, 2009.
[4] J. Highmith, Agile Project Management, 2nd ed. Addison-Wesley, 2009.

Bio