Sep 19, 2011
Sep 15, 2011
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.
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.
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
Sep 9, 2011
Customer satisfaction is king
Customer satisfaction is king. Policies on cadence-based continuous flow delivery are a golden gift to the king.
Jun 26, 2011
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.
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.
Jun 13, 2011
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 3rd 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 1st 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 .
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 .
May 15, 2011
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.
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.
May 2, 2011
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.
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.
Apr 28, 2011
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 :-)
Apr 27, 2011
Masa recognized by the Lean-Kanban Univeristy
Masa is listed as part of the services offered by the Lean-Kanban Univeristy
Subscribe to:
Posts (Atom)
