Lean Value Innovation in a little tiny nutshell

Whoa, it is almost the end of the year and it has been a long time since I posted anything on my blog. I know it is no excuse, but I actually spent most of the last half a year outside the US and that made it very difficult for me to pay attention to the blog as much of my time was focused on delivering value to my customers.

There is, however, one very important announcement I want to make. Shojiki Solutions is changing its name to Valueinnova LLC (www.valueinnova.com) effective January 1, 2012. This is actually good news, because the company has been moving forward and now that I have been maturing Lean Value Innovation it makes perfect sense to align the company to what set us apart from the competition.

In a nutshell, Lean Value Innovation is a framework indicating that in order to effectively increase value delivery to customers as well as to our organization it is necessary to take care of for aspects:

• To improve the way we think and see things through systems thinking. This includes the system of profound knowledge, lean thinking, agile thinking, and creativity.
• To improve our environment both in the physical sense and the collaborative sense.
• To adopt methods and tools that facilitate innovation.
• To fully embrace the notion that the human factor is the most important aspect to consider if you want our organization to be successful.

 I am spending these days writing a book on the subject and hope to get it ready soon.

Cheers and happy holidays to everybody.

Lean Kanban Central Europe useful links

For those who didn't have the opportunity to attend LKCE11 here's some useful links


Session visual facilitatings
http://www.lean-kanban-conference.de/visual-facilitating/


Sessions description and slides
http://www.lean-kanban-conference.de/program/

My presentation al Lean Kanban Central Europe 2011

I will blog comments as soon a I have time to do so (I am still moving around quite a bit between Spain and Germany).

Thank you Steve Jobs

High Performance Operations book review

I had the pleasure and honor of receiving an advance copy of Hillel Glazer's book High Performance Operations for review. What follows is my unbiased opinion.

This book is bout an approach to make of compliance an actual competitive advantage through an integration of "cultural/psychological and interpersonal matters, service, and systems engineering". Hillel calls it Process Solutioneering. Hillel's writing style is very enjoyable and engaging.

As the title implies, the book focuses on compliance aspects that have to do with operations. Very important aspects that way too often affect organizations because of misconceptions on compliance are addressed here. For example, I recently had a customer who has a CMMI process that is making it take over a month of work on a task that requires less than one week of DB work and less than 30 min of coding in java. Hillel points this kind of situation as a common behavior because many companies do not count with compliance methods that scale to the work at hand. He also mentions bureaucracy, personal interests, operational complexity and other.

The core aspect of the book is it offers a set of patterns to keep compliance while at the same time also improving operational performance to gain competitive advantage.

The book begins with a motivation and an overview that provide a comprehensive fly-by of the entire book. Chapter four introduces the "how". 10 necessary factors that must exist in an organization to achieve excellence in high performance operations. Chapter 5 is about time, quality and money from the perspective of regulation and compliance and about mind setting. We should focus on guiding out thoughts and actions in the desired direction, not on thinking about avoidance of unwanted direction. Chapter 6 is about people and organizations focusing on compliance for the sake of status. Be it to show off or to get more contracts but not to really improve. It also talks about value streams and their economic impact at compliance level. Chapter 7 is about understanding the right purpose of compliance practices, which goes way beyond the verbatim application of the practices. On Chapter 8 Hillel introduces a 5-step-action "procedure to better understand the wisdom behind the practices stemming from compliance requirements". Chapter 9 is about value. this is a particularly attractive topic to me because it is focal to what my own business is about. HIllel's perspective is well-aligned in that it considers the business and customer facing value. Chapter 10 is a follow up of Chapter 9 on which he provides a guide to identify the operational system and explains the importance of performance management quantification to sustain value. My interpretation of chapters 11 to 15 is they are the set that covers Operational Excellence considering the systems engineering, service, and cultural/psychological and interpersonal matters. Chapters 16 to 18 are the wrap up. How to check the business performance and improvements, An integrated architecture that includes human factors and infrastructure. And what to expect when you do all this.

In conclusion. The book is not a technical masterpiece (it isn't intended to be so) nor a recipe to follow step-by-step. It is a combination of awareness booster and guidance to take as a foundation to modify the organization's behavior surrounding compliance.

I recommend this to all organizations that operate, or are considering to operate, under some sort of governance.



You can learn more about this topic at http://www.hillelglazer.com/

Quotable Kanban book by Janice Linden-Reed

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

Processclerosis

I began working with a customer rather recently whose line of business is software development for very large banks. my relationship with them began with a training course on lean-agile project management that led to coaching. 

They were very happy and proud to have reached CMMI L2 one week before I began working with them.


The CEO agreed with my recommendation to bring Kanban in and after two days of training we began working on a new, small project. As result of their new CMMI status there was an executive decision to display large posters with their current processes throughout the company to bring visibility and ensure everybody followed process.

I decided it would be good to begin with the creation of an actual Value Stream Map for the project. The team created it based on their CMMI process, as expected, and discussing the action details for the project.  The resulting VSM is shown below. The orange cards are the steps, the blue cards are one per stakeholder, and the yellow cards are actions; so we have 8 steps with between 4 and 9 stakeholders per step and between 3 and 17 actions per step. In total there are 90 actions.

Most of you might be thinking something along the lines of "wow, is that a small project?" I was equally puzzled so I asked one of the team members to explain it all to me (I was at a meeting with executives while the map was being created). What called my attention from her explanation was that only two of the action cards actually had to do with coding! There were a few other technical actions but over 80% of the actions had nothing to do with the project itself and everything to do with process. As in, non-value-added process.


I decided to guide them through questions to help them realize the tremendous amount of waste they had but nobody in the team, including the manager, saw an issue with their process. I then asked them how long it would take to do the coding... and they said it would take at most 30 minutes (their bet was 10 minutes). So we have a 90-action process that requires up to 9 stakeholders for a customer request that takes at most 30 min of technical work.


It was clear then that they were still high from their recent CMMI L2 accomplishment and weren't seeing the obvious so I asked them to create a Kanban board and use it to manage the project flow making sure to quantify their actions from day one. This meeting took place on a Tuesday and the intention was for the project to be done by Friday or Monday at the latest. They revealed that some DB work also needed to be done and that would take several more hours of work so it appeared as if the value-added work was to take in reality less than one day. My recommendation was to get the information as directly as possible from the customer, implement the code with the proper testing and deploy it. Their CMMI process should've considered lightweight solutions in agreement with the size and complexity of the project instead of having a one-size fits all process.


I had one remote meeting a few days later to see if they had finished and to use the quantification gathered to help them realize their process needed improvement. But they hadn't even written the WIPs on the Kanban board, which we had already determined, and even less using it because they were focused on just executing away. This showed how the company is yet to properly use tools and methods and how and what they had accomplished with CMMI was being seen as an after-the-fact formalization to comply with governance. The second meeting took place three weeks later only to learn that they have 82 items in backlog and 26 in progress and 3 finished --new action cards were created. Then they made the mistake of changing the Kanban board to look the way they want things to happen and not the way they are actually happening, and the clear opportunities for improvement were being lost by their decision to remove the columns where delays were happening. I had a long conversation with them to modify the Kanban board and to work on those improvement opportunities because their delays were precisely due mostly to them and if nothing was done then the small project is going to end up taking over a month! The quantification gathered so far showed very clearly the high level of waste by the large number of actions yet to be processed and the long cycle times.

I emphasized on the need to make sure the Kanban board is a mirror of their reality and that by removing columns they were letting go of amazing opportunities to better the quality of their work and the lengthy cycle time. Most importantly, they were ignoring to consider everything that's happening around the board, their decisions and actions, or lack of them, and the impact it is having in both customer satisfaction and the economy of the project.


Quantification began 8 days late, when the project was expected to have been done. There are plenty of opportunities for improvement, some very important ones related to their customer, but internal changes need to happen first before they can talk to the customer and make agreements to improve.

Note: I Had the opportunity to show the VSM photo to Hillel Gazer and he commented that this is a very common problem in  organizations that do CMMI and the problem is due to a combination of a poor understanding from the organization and in good measure because maturity evaluations are often done by-the-book instead of based on understanding to help the customer do it right.


I'll write an update as this project develops and how the company matures.

--- Update: as of Nov 4, 2011 the project is far from finishing. The company indicated over a skype meeting I had with them that the delay is because customer approval is the bottleneck. They are not being proactive towards helping change behavior even when now they count with data to present their customer the economic impact this is having for everybody. Curiously, they themselves are reluctant to change and seem to want Kanban to magically improving things without any changes.

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

Customer satisfaction is king

Customer satisfaction is king. Policies on cadence-based continuous flow delivery are a golden gift to the king.

Customer satisfaction is king

Customer satisfaction is king. Policies on cadence-based continuous flow delivery are a golden gift to the king.

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-Agile Project Management Certification and Kanban training in Panama

I spent between May 26 and June 7 (with a break in between to go to Peru to give Kanban training) to give a Lean-Agile Project Management Certification course and a Kanban course in Panama to a small group from the telecom industry.

All participants loved the topics and the training. They also arranged for me to give a presentation at Telefónica in Panama and then a remote presentation at Telefónica Guatemala.

Look forward to the outcome...

Bringing Lean and Kanban to Peru

I spent June 1~3 bringing Lean and Kanban to Peru.

June 1 was a presentation on Lean and Kanban at the Universidad Peruana de Ciencias and June 2~3 was to give Kanban training to a group of highly motivated people from Agile Peru, Academia and industry.

Both activities were quite successful and I look forward to being back to Lima both for training and to do business.

3rd PMI Panama Project Management Congress

May 25-26 was of high-activity at the El Panama hotel, where the 3^rd PMI Panama Project Management Congress took place. Panama City is a very active place with a blooming economy. New business buildings are under construction and there are more jobs than people to take them. The boost in the economy is mainly due to the ongoing Panama Canal traffic plus its current expansion and the banking industry.

The congress had around 300 participants attending the congress days and then there was a workshops day on May 27.  There were 4 keynotes: on management by Jeff Hodgkinson; on the future of management in Panama by Eduardo Jaén; on the subway project for Panama by Roberto Roy; and on the project management effort to recue the 33 miners trapped in Chile by Hugo Constanzo. All keynotes were worthwhile but I want to give special mention to Constanzo’s for its incredible success regardless the high stakes and low odds it confronted—and Constanzo’s high humanity and humility which shows his quality as a great manager and an exceptional human being.

There were a total of 24 sessions on diverse topics from the very practical to the conceptual, techniques, experiences, government projects, and other. My presentation was on agile and lean as a means to better handle project cycles and implement an evolutionary approach to management.

The three workshops offered where on Authentic leadership for breakthrough results by Hawk Carpenter; A sixth sense for project management by Tres Roeder; and Practical lean-agile and innovation for managers by yours truly.  All workshops were successful and I was flattered by the fact that my workshop got the highest attendance and ranking of all.  I hope to get the opportunity to give this same workshop at the SFBAC soon.

LSSC11 Report

The Lean Software and Systems Consortium 2011 Conference took place last May 3-6 in Long Beach, California. This third conference was very impressive in more than one way. The conference grew 6 times since the 1^st conference for a total of over 800 attendees from all over the world, literally; it lasted 5 days (day one was for workshops and a day long Technical Advisory Board meeting);  21 sessions/panels per day; daily keynotes; topic-games room; Open Space; Intoductory talks; and tools showcase. Even more important were the countless conversations and discussions on aisles and halls. The event was organized by NetObjectives, led by Allan Shalloway, and by David J Anderson & Associates.

The Brickel Key awards banquet was quite an event, with six world-class candidates. In alphabetical order Siddharta Govindaraj (India) for his toolsForAgile software, Russell Healy (New Zealand) for his GetKanban game, Chris Hefley (USA) for his LeanKitKanban tool, Richard Hensley (USA) for his work on Kanban with CMMI, Mattias Skarin (Iceland) for his work and publications promoting Lean and Kanban, and Yuval Yeret (Israel) for his contribution bringing Lean and Kanban to Israel. The awards went to Russell Healy and Richard Hensley. The diversity of origin from the candidates is proof of the worldwide impact of Lan and Kanban.

Presentations covered familiar topics such as adoption and improvements as well as new topics such as lessons from the military, psychology, chaos, innovation, and risk. I myself had the opportunity to present Lean Value Innovation. All sessions were recorded and will be made available by mid June at http://www.leanssc.org/membership/ were some content will be available for the general public on a rotating basis and all content will be available to members.

To many attendees this was the best conference ever, and I agree with that opinion.

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.

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 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.

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