Gamikanbanation

The benefits of Kanban are very clear and have been proven on organizations of diverse kinds and all sizes, and so are the benefits of Personal Kanban. Personal Kanban has resonated so well that people of all ages benefit from it, and this includes kids.

The benefits of gamification, when done properly (and not abused to become more of a Skinner-style conditioning practice, which doesn't work on the long run) are also being proven.

A Chilean couple, Luis and Natalia, came up with an awesome and very clever idea that combines Kanban and gamification to help improve their daughter Micaela's behavior. Micaela is a 3-year old fantastic girl with a great personality and very active. She also has a tendency to get distracted and to let her behavior be influenced by peers. Her parents haven trying different approaches to help her out. What finally worked for them was a very clever combination of Personal Kanban and Gamification. Let's call it Gamikanation.

The fotos show how this works. Luis and Natalia used a combination of Kanban and gamification. To make it easy on Micaela, the board has implicit wip and being a personal Kanban some tasks are in progress throughout the day such as wearing her shoes and behaving well; and some are immediate action such as eating her food and brushing her teeth. The gamification aspect is using pink hearts (for a boy they could be cars or sports balls or other that agrees with the kid’s interests) and using icons instead of words (which works better independently of whether the person is already able to read or not).

Positive results were immediate and significantly better than anything they have tried in the past. Even the school staff noticed Micaela’s change and amazed asked Luis and Natalia what they did. 

For those interested on some guidance the book Agile Kids by Shirly Ronen-Harel and Danny Kovatch, translated into Spanish by our own Angel Agueda, is a great help.

Addendum: unos días después de publicar éste blog recibí email de Ivonne, cuyo hijo Alex, de 6 años de edad comenzó a utilizar Kanban. Para evitar interpretaciones a continuación está parte del email que recibí, verbatim:
"Alex está muy emocionado con esto, todos los días está pendiente de actualizar su Kanban, apenas termina una actividad se ocupa de cambiarla a terminada. Me sorprende que ha mejorado su actitud y se esfuerza en terminar y hacer aquellas cosas que hasta el sábado no hací,a más que nada por no tener la disposición o motivación suficiente para ello.
La familia y el colegio ha notado estos cambios positivos y motivación por participar y terminar aquellas cosas que antes no hacía por iniciativa propia.

Muchas gracias por todos los conocimientos y aportes que nos has entregado, sin duda para mí en términos personales y profesionales Lean Agile ha sido un crecimiento muy positivo y beneficioso."

Valueinnova Kanban Certifications

Valueinnova started offering three Kanban Certifications at the beginning of 2013.

• The Kanban Methodologist Certification is the entry level one. It certifies the professional is capable of applying the Kanban system and method successfully to obtain it is necessary to take the 2 day course, dedicate some extra hours of education attending related events such as webinars, conferences or other training, a certain amount of time actively practicing Kaban on a real project, and presenting and passing an exam.
• The Kanban Leader Certification is for those interested on leading kanban teams. Requirements are to have a Methodologist certification and go through a series of actions similar to those for Methodologist but focused on Leadership.
• The Kanban Mentor Certification is for those interested on Mentoring Kanban adoptions. It requires the previous two and also has similar requirements but at a higher level

At this point there are six Kanban Methodologists worldwide:

• Marco Salas de la Paz: Panama
• Angel Agueda Barrero: Spain
• Matías Carrasco: Chile
• Luis Horacio Díaz Stoffel: Chile
• Gabriel Humberto Bracho Soto: Chile
• Ivonne Mienert C: Chile

Demystifying Kanban talk at Yahoo! headquarters in Sunnyvale California, USA

I had the privilege of giving a talk for the Silicon Valley Agile Leadership Network at Yahoo! headquarters in Sunnyvale California, and at 86 people the fortune of this having been the largest-attendance meeting the SVALN has had so far.

The meeting started with a gentle 10-minute introduction on what Kanban is and isn't (it is for managing improvement and not for managing projects) and some basics of Systems and Lean thinking. Then 65 minutes of fun, workshop style introduction to the Kanban system and method. The audience was divided in 4-people temas (that is 21 teams) doing a series of time-boxed exercises, which with the help of several volunteers Masa managed to pull off successfully. Attendants had a lot of fun and it was a learning experience to all. The last five minutes masa wrapped things up and commented that comparing Kanban with Scrum doesn't make sense because they have different purposes. Scrum is to manage software projects and Kanban is to manage continuous improvement.

Yahoo!'s meeting room was just perfect for the event and the food they provided was great. SVALN did a fantastic job organizing the event and setting up the meeting room. Volunteers were key to the event's success.

A case of advantage on maturing the Kanban board

Organizations new to Kanban that have no experience with Agile usually find it easier to design 
their boards than those with Agile background because Kanban recommends the board to reflect 
the actual process rather than an abstraction. Compare for example Board 1a, quite common in 
agile practices, with Board 1b. 

Board 1a  

Board 1b 

This is a good start. As we all know, a project’s behavior changes over time. This means the 
Kanban board should keep up with those changes, but unfortunately many Kanban 
organizations don’t go about keeping the board up to date and that has undesirable 
consequences such as fake visualization and forcing the real process to adjust to he board 
process. Both of them affect quality and value delivery. Oh but there’s more to it. We miss big 
time on the identification of opportunities for improvement.

 I will illustrate the benefits of keeping the board up to date through a real case. One of my 
customers is a small Telecom business that provides technical services to some of the biggest 
Telecoms in the world. The very first coaching session I gave them right after finishing Kanban 
training consisted on helping them create their first functional Kanban board. As a coach I didn’t 
build the board for them, of course, but rather had them create it providing guidance as I saw it 
necessary. During that session I realized that the last portion of their process was convoluted so 
I decided to dig into process details with them rather than focusing on creating the board. 
Throughout the discussion the team agreed that part of the process was suboptimal and I made 
a recommendation which we agreed upon and so the first Kanban board was created reflecting 
the actual process but already suggesting a small but important change at the end. The change 
had to do with the customer verification phase.

I visited them to do a second round of coaching and was very pleased to see they had modified 
the board to be a show on Board 2a. I asked to a team member to explain the board to me and 
he did a pretty good job; and at the same time I noticed some hesitation explaining the sub-
column labeled “Pending”. I decided the to dig in to it. Discussing this with the team it became 
clear that it had to do with dependencies they had with their subcontracted providers as well as 
with internal dependencies, and their cycle time was being affected by it. 

Board 2a  

I then suggested to them to further visualize “Pending”. The result was Board 2b. We added a new
column to visualize de 3 subcontracted providers and also kept de original sub-column which was
to be used only for internal dependencies. 

Board 2b  

This change allowed to better understand the behavior of each subcontractor a well as to see how
the customer was taking care of its own dependencies. The subcontractors behavior was quantified
(the rest of the process had been quantified before from the beginning) and that allowed to show
them how their response time affected final delivery. This motivated the subcontractors to improve,
one of them started adopting Kanban also, and that resulted in significant improvement on delivery
to customer. This also motivated a behavioral change on the team itself to take care of their internal
dependencies more efficiently. The rend result was an increase of on-time delivery to customer from
86% to 99%.

Additional benefits surfaced from this such as the obtention of more contracts without having to 
increase staff.

--Masa K Maeda

LKSE12 conference presentations

Here's some joy for those of you who missed the Lean Kanban Southern Europe all together or couldn't see all the presentations you wanted to because they took place at the same time.
This link takes you to all the recorded presentations.
http://lkse12.leanssc.org/media.htm

Kanban for customer portfolio management

My business focuses on lean-agile coaching, consulting and training, not on software development services, and I successfully use Kanban to manage my customer portfolio.

It is untrue that Kanban is only good for software change management work. Many people new to Kanban have this misconception mainly for two reasons. One is because Kanban started in a change management team at Microsoft. The other one is because David J Anderson declared that Kanban is a method for change management in the organization and that statement can be misinterpreted. What David meant with that is Kanban helps you bring positive change to your organization. Although the original Kanban description is around software it is actually context free. There is a very popular book entitled Personal Kanban by Jim Benson that I invite you to consult.

Getting back to the main subject of this blog. I have been using Kanban for years to manage customer-facing and business-facing activities. The customer facing activities Kanban board has one swim lane per customer for easy visualization of the activities with each customer and to avoid making mistakes on which customer a given activity is for.  Each customer has its own backlog, which we make visual as the first column on the board. The other columns are Ready, Execute (doing/done), Customer verification, and Completed columns. The WIPs for each customer are different and in agreement with the customer needs and my resources. The figure shows the electronic board we use. We actually have several boards, one for each country. Advantages of the electronic board are not only the fact that they make remote communication easier but also that it allows us to resort the lanes, which we do as a means to indicate level of priority and activity. That is, a lane (a customer) bubbles up if the activity and priority increases and bubbles down if the activity decreases. That way if we will not be doing any work with a customer for a while its lane is "out of the way" and is still easily available to reuse at a moment's notice. We also count with a swim lane called "other" and we use this for general work that has to do with potential customers when relationship hasn't matured yet to the point of earning a dedicated lane.

Our classes of service are

• Business task
• Business appointment
• Business partner / associate task
• Fixed delivery date
• Immediate

Intangible tasks are business-facing and are, therefore, on a separate board.

Cheers,
Masa K Maeda

Quotable Kanban book by Janice Linden-Reed

Quotable #Kanban book is out http://bit.ly/puYJHD congrats Janice!

The 3 principles of the Kanban Method

This is from an email exchange that took place within the last 24 hours.

[David Anderson]:

Yesterday I changed this language in my keynote in Zurich...

While they are core or seed properties (for a complex adaptive system) they are also practices. In the interests of promoting common language I am now calling them "core practices" or Alistair Cockburn has suggested "Imperative practices".

The 3 principles of the Kanban Method are...

1. Start with what you do now

2. Agree to pursue incremental evolutionary change

3, initially respect current processes, roles, responsibilities and job titles

Kanban actions when encountering a bottleneck.

What kind of actions should be considered to take care of a bottleneck?

- Are the people on the immediate upstream doing things right or rushing them?

- Do we need to add a buffer?

- Is this something temporary so doing nothing is the right thing to do?

- Is the root cause somewhere farther upstream?

- Do we change WIP?

- Do we reallocate human resources?

Note: this list is not exhaustive. 

In the need of scientific proof

I was reviewing the feedback sheets from a course I finished two days ago and one of them called my attention. There was a comment indicating I should've given scientific evidence to explain why lean and Kanban work. I understand how compelling it is to count with scientific proof; however, no having scientific proof of something is not sufficient to say something didn't work.

Most things that work are followed by a scientific explanation and not the other way around. Even when no scientific proof is available, should we stop doing something that works?

Lean and Kanban work because they tackle projects from a systems perspective and because they also pay attention to the human factor. That is, they go beyond just the project to find opportunities for improvement and do root-cause analysis. They see projects and people as complex adaptive systems better than other approaches.

The longer professionals demand solutions that are heavily rooted on scientific proof the longer it will take them to realize the huge potential they are missing and will continue to struggle with projects more than is necessary.

Btw, that same person gave me a low score on "being on time" even though I was there 30 minutes before start time every day of the course and kept the lunch break times as agreed. Oh!... wait, maybe my score would've been higher if I had allowed more time for lunch.

Lean Kanbann Jazz and Origami

Proposal session sent to Lean Kanban Central Europe 2011 conference.
http://www.lean-kanban-conference.de/


Abstract:


What do Lean, Kanban, Jazz and Origami have in common... and where do they differ? In this presentation I will talk about important aspects of Lean and Kanban that I consider to be key to their success and to be what sets them apart form other approaches and methodologies such as Agile and Scrum, yet could be easily ignored. This is very important because ignoring them as Lean and Kanban gain popularity will result in failed adoption at organizations. I use Jazz and Origami as metaphors because they greatly facilitate the understanding of those key aspects. I will also be introducing the term Understanding Worker and the phrase Think Outside The Kanban Board .

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.

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 de Certificación en Gestión Lean-Agile de Proyectos en México

El primer curso de Certificación Lean-Agile de Proyectos en México 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.

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.

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.

Kanban book in Spanish

The best book on Kanban: David J Anderson's is now available in Spanish
http://agilemanagement.net/index.php/kanbanbook/
Translated by Masa K Maeda


English Cover Spanish Cover