Nota breve sobre Scrum, Lean y Kanban

Este blog es para personas que desean aclarar su entendimiento sobre Scrum, Kanban y Lean.

Lean no es una metodología; es un fundamento basado en pensamiento en sistemas y en el sistema de conocimiento profundo a partir del cual se han generado prácticas y métodos tales como Kanban. La primer premisa fundamental es el mejorar todos los aspectos de la organización y no tan solo el buscar resolver problemas identificados. Esto es muy poderoso porque con mucha frecuencia el origen de un problema no está donde el problema se expresa sino en algún otro lugar; y porque una mejora que no toma en cuenta el contexto completo puede generar desbalance en otras áreas de la organización. La segunda premisa es el eliminar todo aquello que no agrega valor; resultando en mejoras en aspectos tales como productividad, calidad y satisfacción de clientes. Lean va más allá del contexto de desarrollo de software y considera a todos los stakeholders involucrados en la organización o el proyecto, por lo que no tan solo el proyecto es beneficiado.

Agile es un subconjunto de Lean y consiste es un una serie de valores y principios seguidos por una serie de metodologías de las cuales Scrum es la más popular.

Scrum se enfoca en la entrega de valor al cliente en intervalos fijos y logra esto mediante el aislamiento del grupo técnico para asegurar que se mantengan enfocados en completar las tareas a tiempo. La relación con el cliente es mediante un punto de contacto singular. La estructura de Scrum es fija y no toma en cuenta las necesidades particulares de cada proyecto. El ímpetu de hacer los intervalos auto-contenidos dificulta la implementación de ciertas tareas. Scrum no considera situaciones de la vida real que requieren de tratamiento especial tales como trabajos urgentes. Así mismo, Scrum no escala fácilmente por lo que es adecuado solamente para proyectos pequeños. La manera en que Scrum trata la escalabilidad es ya sea llevando a cabo lo que se conoce como Scrum de Scrums, o bien mediante la necesidad de contar con múltiples product owners; y en ambos casos el monto de tiempo de juntas de Scrum es incrementado y el monto de conocimiento sobre el proyecto entre stakeholders se reduce. Scrum no provee visibilidad sobre el proceso y tampoco sobre el estado actual del proyecto, por lo que es difícil identificar oportunidades de mejora. Esto quiere decir que Scrum es estático y no provee mejoras mas allá de lo logrado cuando fue implementado por primera vez. Scrum confronta alta resistencia al cambio en parte porque requiere el abandonar las prácticas actuales de la organización para implementar algo nuevo y distinto, lo cual tiene mayor riesgo y costo que una transición suave. La resistencia al cambio también tiene que ver con la introducción de nuevos roles y responsabilidades, lo cual hace que personas en la organización se puedan sentir retadas o amenazadas de alguna forma debido a la incertidumbre de la manera en la que tal cambio afecta sus carreras profesionales.

Kanban se enfoca en la entrega continua de valor tanto para con el cliente como para con la empresa. Es altamente visual y transparente por lo que todos los stakeholders tienen acceso al estado real del proyecto, facilitando la toma de decisiones a todo nivel. La alta visualización facilita la identificación de oportunidades de mejora por lo que tanto el proceso como los grupos involucrados pueden operar a nivel optimo en todo momento y el proceso evoluciona gradualmente conforme el proyecto progresa.  Kanban mantiene una disciplina sobre el monto de trabajo en progreso que mejora significativamente el valor generado y entregado gracias a su alto enfoque en calidad, resultando en mayor trabajo terminado en el mismo monto de tiempo. El flujo de trabajo puede ser medido, analizado, y gestionado tal que las características de mayor valor son entregadas primero.  Kanban cuenta con políticas de proceso explicitas tal que la comunicación y colaboración se hacen mucho más suaves y fáciles, reduciendo significativamente la posibilidad de error humano.  Kanban trata de manera distinta los distintos tipos de tareas que contienen los proyectos por lo que, por ejemplo, tareas urgentes pueden ser tratadas adecuadamente sin la necesidad de salirse de la metodología o generar excepciones, evitando así el desbalance y la pérdida de disciplina. Métricas cuantitativas facilitan el análisis de comportamiento para la identificación de causa raíz, y la implementación de soluciones es fácil y rápida. Debido a que los cambios son continuos, pequeños y graduales, el sistema completo evoluciona (stakeholders, proceso, y organización). De hecho existen casos en los que organizaciones han madurado el equivalente a dos niveles de CMMI en menos de un año. Kanban no confronta resistencia al cambio porque no hay cambios de roles y porque el punto de partida es el proceso actual. Kanban escala fácilmente porque la junta diaria (el equivalente a la junta de Scrum) no requiere ser multiplicada y su duración no requiere ser incrementada para mantener su eficiencia. Por último, Kanban considera aspectos económicos de la actividad relacionada con el proyecto, tales comos costos de retraso, de transacción, de operación y riesgo.

Un malentendido sobre Kanban es la creencia de que se aplica solamente en proyectos de mantenimiento. Kanban es un método para la gestión de cambios necesarios para madurar la organización. De hecho, es tan efectivo que también ha sido utilizado en áreas fuera de desarrollo de software, tales como recursos humanos, administración, salud, educación y hasta en oficinas de abogados.

Otro aspecto importante a considerar es el hecho de que lean y Kanban son sistemas abiertos que permiten la utilización de una variedad incremental de herramientas para mejorar organizaciones, independientemente de si son ágiles o no.

En septiembre de 2010 llevé a cabo un estudio sobre adopción de Kanban a nivel mundial por medio del Cutter Consortium. Los resultados muestran que a pesar de ser relativamente joven, Kanban está siendo adoptado ya en todas las regiones del mundo y que esta generando mejoras en satisfacción de usuarios, calidad, y productividad fueron reportadas por un 59%, 63.6%, y 71.1% comparado con Scrum.

Kanban está siendo adoptado por empresas de todo tamaño: desde menos de una docena hasta de mas de 100,000 empleados (este último número reportado en la conferencia LSSC11 a principios de Mayo de 2011).

Es posible adoptar lean sin Kanban y viceversa, pero la combinación de ambos tiene mucho mejor resultado.

Scum y kanban no son mutuamente exclusivos. Ambos pueden ser implementados en la organización y ser compatibles. A fin de cuentas todo depende de las necesidades de la empresa.

LSSC11 -- the day before.

Awesome weather here at Long Beach the day before the start of LSSC11.

It was great to meet with friends again and to get to meet in person some people I knew only remotely, such as Olav Maassen who wrote an article for the special issue on Kanban of Cutter's IT Journal I had the pleasure of being the guest editor for.


I also had the pleasure of meeting Donald Reinertsen and spent one-on-one time talking about cost, WIP, and lean.


Tomorrow the LSSC11 begins with tutorials and with a Technical Advisory Board.

One week to LSSC11 -- Register now!

We are only one week away from the LSSC11 Conference.

This is the place to go to to get up to speed on Lean and Kanban.

Register now and see you there :-)

Masa recognized by the Lean-Kanban Univeristy

Masa is listed as part of the services offered by the Lean-Kanban Univeristy

http://www.leankanbanuniversity.com/masa-maeda

SFBALWS invited speaker Siddharta Govindaraj

The May meetup of the San Francisco Bay Area Limited WIP Society is having Siddharta Govindaraj as invited speaker.

Topic: Using Class of Service for Managing Risk in Innovative New Product Development

Date: May 12

Time: 7:30 PM

Location: Thoughtworks

                  315 Montgomery San Francisco, CA

Make sure to RSVP indicating your name and affiliation. Security will be given a list to grant access to the building. 

Improving People and Processes

Improving People and Processes: Lean-Agile, Systems Thinking, and the System of Profound Knowledge

by Masa K. Maeda, Senior Consultant, Cutter Consortium

Click here for the full executive summary

Click here for the full executive report 

Organizations deal with pressure on a daily basis. Executive and managerial pressure frequently comes in the form of on-time delivery, cost cuts, and scope coverage; customer pressure usually comes in the form of feature requests and better quality; employee pressure continually asks for more time to finish tasks, fewer work hours, and better guidance.
Some organizations consider those kinds of pressures to be part of the daily corporate life and end up just bearing with them. Most of those organizations eventually collapse because lack of improvement puts them further behind over time. Other organizations take a proactive approach to better the organization. Some of those actions could be localized to focusing on ailing areas or could be of global scope and higher impact, such as replacing the organization's governance standard or model or adopting one if the organization didn't come with it already. Or it might mean replacing entire teams or migrating entire operations to other countries. In the accompanying Executive Report, I present, in detail, a better means to improve your organization through the improvement of people and processes, taking into account excellence, quality, and value through the application of lean-agile thinking, systems thinking, and the system of profound knowledge (SOPK).

The term "improving the whole" is not an if-you-only-have-a-hammer approach but rather the acknowledgement that we can acquire a way of thinking that broadens our perspective to look at our organization, processes, and people. It allows us to understand the kind of tools we need to continually better them.

Analytical thinking focuses on knowledge of the parts, properties, and behaviors of an object. Systems thinking focuses on the understanding of the properties and behaviors of an object, its parts, and the system under which it operates. This means that analytical thinking takes us levels inward with respect to the object, whereas systems thinking takes us levels outward with respect to the object because explanations always lie outside and not inside the system being studied. Systems thinking is very effective in solving even very difficult challenges and problems because the understanding acquired makes it easier to determine the root cause or causes of issues we encounter.
The SOPK is a management framework that has four parts: (1) willingness to change the management style, (2) transforming the individual, (3) fully applying its principles to all interaction with other people and decision making, and (4) transforming the organization.

Ponencia y taller en la Semana de la Cultura Laboral en Tlaxcala

Tuve el honor de ser invitado a dar la Presentación Magistral de Clausura de la Semana de la Cultura Laboral que se llevo a cabo en Tlaxcala, así como de dar un taller sobre Innovación de Valor el día 13 de Abril de 2011. Ambas tuvieron lugar en el auditorio del IMSS.


La presentación la atendió un auditorio lleno (con alrededor de 30 gentes de pie en los pasillos) consitente de industriales y oficiales de gobiernos de la region; maestros de enseñanza media y superior; y estudiantes de esos mismos niveles. El tema titulado "Entregando mayor valor a cliente y a la empresa mediante un enfoque moderno de calidad" lo presente bajo colaboración con la UNAM y con Esprial (empresa Española). La audiencia lo recibió con entusiasmo y parece ser que si logré tener impacto con toda la audiencia a pesar del reto que confronté debido a su diversidad. El tema incluyó innovación de valor, lean-agile, y Kanban.

Después de la ceremonia oficial de clausura se llevó a cabo el taller titulado "Mejorando la calidad mediante innovación colaborativa". La efectuamos el Mtro. Jorge Polo Contreras, el Mtro. Luis A. Nava, y yo. Efectuamos varias dinámicas para demostrar:

• El beneficio de trabajar en equipo
• El beneficio de la diversidad para llevar a cabo proyectos de manera mas exitosa
• El beneficio de limitar el monto de trabajo en progreso
• Las desventajas de efectuar múltiples tareas simultaneamente
• La importancia de darle el valor adecuado al factor humano para el éxito de la realización de productos y de la prestación de servicios.
• La ventaja de combinar pensamiento innovador con un ambiente que fomenta innovación y el contar con herramientas innovadoras que facilitan innovación.

Primer curso Gestión Lean-Agile de Proyectos en México avalado como acreditación por Shojiki Solutions

El primer curso de Gestión Lean-Agile de Proyectos en México Acreditado por Shojiki Solutions se llevó a cabo del 4 al 6 de Abril de 2011 en la Colonia del Valle, Distrito Federal.


Un grupo de 9 personas atendieron el curso impartido por el Dr. Masa K Maeda.


El curso fué muy intenso y de alto calibre. Los participantes se divirtieron, fueron retados con los cambios de paradigmas y sobrevivieron la transformación ;-)

De izq a der: Dr. Masa Kevin Maeda, Ing. María Elizabeth Rivera Patiño, Ing. Marlon Torres Valle, Mtro. Ismael Villegas Ochoa, Mtro. José Manuel Muguiro Alvarez, Mtro. Luis Alonso Nava Fernández, Mtro. Marco Antonio Navarro Gutierrez, Ing. Maria Luisa Regato, Ing. Leonardo Mrak, Mtro. José de Jesús Hernández Suárez.


Felicidades!

El mismo grupo tomó también un curso de Kanban el 7 y 8 de Abril.

Donate to help Japan

Shojiki Solutions will donate $100 dollars to helping Japan for each registration to its training courses.

Alternatively please make a donation through any sponsoring agency.

Thanks.

Cutter IT Journal Issue on Kanban

The Viral growth of Kanban on the Enterprise

Kanban is becoming amazingly popular very quickly because of its accelerated rate of adoption and remarkable impact on organizations of all sizes. Such fast pace is both good and bad because it is benefitting organizations when adopted properly and because of the risk of doing it wrong by rushing an adoption without fully understanding it. For example, a frequently asked question on Kanban is whether it is a methodology for software development, or for software maintenance, or for project management, or a systematic approach to cultural change in the organization, or other. Another frequent question is if Kanban is the next logical step after Scrum and if that means Scrum should be done before doing Kanban. The March issue of the Cutter IT Journal contains articles that help answer questions.

The issue features an article by David Anderson, de creator of Kanban, with Arne Roock on aspects of Kanban adoptions. Taking Kanban adoption in Germany as starting and central point, they discuss how Kanban adoption has disseminated throughout the world and how cultural factors influence the rate of adoption. Anderson and Roock also describe the main reasons why Kanban should be used.

Allan Shalloway’s article on Demystifying Kanban gives us a panoramic view on what Kanban is and isn’t by comparing it with what he has been calling first generation agile methodologies, such as Scrum and XP, and discussing how Kanban overcomes their challenges. Allan has identified seven misconceptions on Kanban and discusses four of them at length and three of them in brief, then he concludes the article with a “test” to determine whether or not your organization is actually doing Kanban.

Dan Verweij and Olav Maassen, present the success story of Kanban adoption at an insurance company in the Benelux, in Western Europe. They describe how the insurance company went from a pilot project on Kanban to 20 teams doing Kanban in around 18 months as well as the reasons for the adoption, which include business, management, and operational reasons.  Verweij and Maassen discuss the difficulties encountered throughout the adoption and the various benefits obtained and conclude their paper with four recommendations to adopting Kanban.

The article on Kanban for help-desks, written by Rolland Cuellar, is around the context of what he calls “managing the unplannable” as a phrase to describe the challenges encountered at help-desk organizations. He explains why approaches such as waterfall and Scrum are not suitable for such type of activities, and how Kanban makes the cut for both help-desk and network operations organizations. Cuellar gives credit to limiting work-in-progress, a core property of Kanban, as an important differentiator useful to that kind of organizations and addresses other factors such as visualization. The result was a significant improvement on responsiveness and an increase in customer satisfaction.

Last but not least is the article on the use of Kanban on distributed onshore-offshore environments by Siddharta Govindraj and Sreekanth Tadipatri. The paper lists some difficulties on doing outsourcing and how Kanban is better suited than Scrum for it. The authors elaborate on how Kanban was applied and present nuggets of cases to illustrate the benefits obtained. They present s series of pitfalls and close with a discussion on cultural challenges encountered.

Playing increases productivity.

Last year I volunteered to translate David J. Anderson's book on Kanban into Spanish. Translating a book was a first for me and I had no idea what I've gotten myself into. Don't get me wrong, the book in itself is great and Kanban is an important part of my business. But translating a book is much  harder than I ever imagined.


Once the translation was finished the index needed to be created and that task was to be done by sometime else mainly because were couldn't find a tool able to easily generate it. Long story short getting the index done started longer than the translation itself because we couldn't find sometime to do it and it became clear that getting it done would end up being costly.


It occurred to me that maybe we could get a highly motivated student to do it well at a lower cost. I offered a high school student a third of the amount a professional would charge, which to him was to be the highest paying gig he had ever had, and I considered that to be enough of a motivator.


Taking advantage of a week- long school break we estimated the task would taking almost the entire week working full time. That became a turn off top the student who was looking forward to having some fun least pat of the time, but the money ease too good to pass. And so he began working on it at my office. I was keeping an eye on him and my main concern was the qualify of the work and likelihood of requiring longer time.


A couple of hours later I noticed  him doing things extremely quick. I went to his desk to check upon his progress and saw that not only everything was being done as expected but he was blasting away! I asked him how he was doing and he said "I am pretending this is one of my video games and figured out a strategy to do this with the minimum eye and keyboard movements." This was awesome! Although money was a good extrinsic motivator, he had found his own intrinsic motivator... to win the game.


He got done in just a day and a half. Upon reviewing the work done I noticed the need to do some time- consuming changes to improve the index and asked him to do a second pass, which he finished in less than one day. He was able to spend over half of the week having fun with his friends and having pocketed some good money, which he added to his savings to buy a semi- professional video camera.


Reading the Wired magazine this morning while enjoying a hot mocha I read an article about how the UK' s Guardian newspaper had the daunting task of analyzing 170,000 pages of bonus expenses and how reporters were, understandably, reluctant to do that. They then turned the task into a hammer and made it public. The result, over 2,000 people played it and the task got done in less than
four days.


One of the three core aspects of value innovation is to have an innovation fostering environment and the more work we do in the form of games is a great way to achieve that.

Perspiration, innovation, and success.

On a day like today, 164 years ago (Feb 11, 1847), Thomas Alva Edison was born. Most people know about Edisson as the inventor of the light bulb and the phonograph, and that he invented a bunch of other things (but have little to no idea what those other inventions are). He held a recortd 1093 patents! According to the Wikipedia, Edisson had only three months of official schooling--he dropped out amongst other things because he was considered "addled".

Edisson is also credited to have said "Invention is 1 percent genius and 99 percent perspiration"--he might have had quite a metabolism. But really, what made him do so much was a combination of high energy, a curious mind, and an amazing skill for making associations. Figuring out new, different ways to put seemingly unrelated things together and coming up with new applications to things that already existed or that he had invented were the skills allowed him to do so much. Just look at his inventions and you will see that most of them were incremental inventions; an invention was built from the results of a previous one. But that wasn't all, he was a great businessman and created an industry to support him, so the 99 percent perspiration was done mostly by all the workers he had at his factories and laboratories. A good number of the inventions and patents weren't a result of his ideas but rather the result of the collaboration with some of those workers; and some key ideas were actually from those people and not from Edisson himself.

Edisson's Menlo Park, NJ laboratory

Long before lean manufacturing and before Frederick Taylor, Edisson was pioneering mass production; most likely influenced by the raise of the Industrial Revolution and the works of Eli Whitney Jr., who make key inventions on machinery to automate some processes for the textile an milling industry.

Edison had an amazing insight on the importance to balance value to customer and value to the Enterprise to have a successful business. He also understood the importance of collaboration as a means to accelerate innovation. The conversations held with his most important workers and seriously consideration and analysis of what they proposed led to most of "his" inventions.

Today's organizations have fallen behind. They make employees work isolated inside cubicles and "teamwork" is rally a buch of people working by themselves on separate pieces of a product. Communication between groups in the organization is limited to orders and FYI's mostly. The groups building products have no direct, or very little, contact with customers or end users. The enterprise's priority is to make profit and not to satisfy users. As we try to turn things around applying Value Innovation, Lean-Agile, and Kanban we often confront strong resistance to change.  It seems some executives are so afraid of failure that they lost track of the fact that to move ahead of the competition and to succeed it is important to move away from the beaten path and do something new and different; and that to do so we have to be willing to invest and perspire,

Value Stream Mapping and a touch of reality

Rather recently I had a team from a customer create a VSM of their process. The usual steps: identify the different steps, or actions, of the process and their sequence; estimate the calendar task for each step; estimate the actual time it takes for each step to be executed; estimate the wait times between steps; identify and calculate loops in the process, if any; then calculate its efficiency by dividing the actual execution time by the total cycle time. I was shocked when they showed me their to be at close to 90%! I knew something wasn’t right, taking into account their own comments earlier during the training on the large number of projects they were running and the dependencies that sometimes taking up to months to resolve. I asked them to consider one typical project and recalculate.

It is very hard to imagine a highly productive team that is running close to 140 simultaneous projects with a staff of around 30 people, each project requires around ½ dozen staff members and takes between 4 to 5 weeks and up to 3 years to get done. 

Each post it is one project!

I explained to the team why although they are busy all the time their efficiency couldn’t be high. There was too much multitasking, frequent long waits, projects that were never finished because a dependency was never resolved, and projects that were either poorly finished or finished late because they had to improvise to pull it off when a dependency was not being satisfied by the corresponding stakeholder. With that in consideration the efficiency was 29.3% at best and most times under 20%. They agreed with this assessment and are now working towards implementing an actual Kanban system to help them control how much they are working on at a given time, improving communication, and figuring out effective ways of enforcing policies to reduce delays (hopefully eliminate them).

Using the Kanban game for time-boxed simulation

A few weeks back I read an interesting LinikedIn posting on how to do time-boxing using Russell's Kanban game. It is an interestig way to lean Scrum using a Kanban board.

I have yet to try to do that buy my hunch is that playing the game doing time-boxing will bring afloat some of the limitations of Scrum such as task management, the lack of classes of service and policies associated to them, the lack of a way to handle urgent tasks, and the fact that not all tasks are necessarily done within the time allocated.

La Mejor Manera de Probar

Esta es una presentación de Juan Gabardini sobre formas de hacer pruebas de manera Agile. Una version en texto está disponible en Software Guru.

http://softwareagil.blogspot.com/2011/01/la-mejor-manera-de-probar-en-agilesbsas.html