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

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.

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,

In a Kanban Adoption, Go Lean

Recent posting on the Cutter blog

http://blog.cutter.com/2010/12/06/in-a-kanban-adoption-go-lean/

A Halloween Story: The Imminent Death of an Enterprise

My last blog posting on Cutter...

http://blog.cutter.com/2010/10/29/a-halloween-story-the-imminent-death-of-an-enterprise/

Competencia en trabajo de conocimiento es algo malo

Wow! Such a long time without posting. Too much going on with the business and I feel ashamed for the lack of posting. Here's an email response I sent to a person in Peru regarding competence vs collaboration:

Agile nos recomienda que cuando tenemos que llevar a cabo una evaluación, tal como por ejemplo para determinar una herramienta a adoptar, es mucho mas efectivo evaluarlas todas al mismo tiempo en lugar de una a la ves. Esto es adecuado porque reduce el monto de tiempo que toma llevar a cabo las actividades de evaluación.

La manufactura lean (entiendase Kaizen) nos dice que el trabajo competitivo es bueno porque motiva a las personas a hacer mejor.

Esa labor de competencia en Lean es, sin embargo, aplicable solamente en tareas de naturaleza manual (i.e., manufactura) y no en tareas de carácter creativo tal como el trabajo de conocimiento. Hay estudios extensivos que demuestran que motivadores externos de hecho hacen que la ejecución sea peor que si no hay motivadores en absoluto. Afortunadamente ustedes no están utilizando como motivación el darles a las personas dinero sino el adoptar su trabajo. El problema con ese modelo está en que no es lean porque genera desperdicio. Todo el tiempo y labor del equipo que pierde el concuso se va a la basura! Si ustedes pueden darse el beneficio de tener dos grupos compitiendo entonces sería mejor tenerlos a todos como un grupo colaborando efectivamente para generar una solución, y el motivador que deben encontrar es un motivador interno y no un motivador externo. El motivador externo es ganar la competencia. El motivador interno que actualmente utilizan es el adoptar la solución mejor. Podrían agregar otro(s) motivador(es) interno(s). De esa manera el trabajo de todos los involucrados será de valor. Colaboración supera competencia siempre, por eso los modelos industriales de Japón y Korea superan los de los E.U. y muchos otros paises.

Competencia impulsa a apresurar las cosas mucho mas que impulsa a innovar. Motivadores internos motivan a innovar. El concepto de respeto a las personas e incremento de conocimiento (lo cual se logra muy bien mediante cooperación) supera por mucho la competencia. El grupo de trabajo que pierde la competencia perderá motivación en su grán mayoría y el grupo que ganará comenzará a tender a ver a otros por encima del hombro y se distrairá y se confiará durante la siguiente ronda de concurso, por lo que la efectividad de ambos grupos disminuirá con el tiempo. Ese acto de ganar y de ser mejor es una ilusión.

Some coming presentations

I will be in Mexico City the next two weeks (Feb 22 ~ Mart 5) and during that trip I will be giving the following presentations:

• Feb 24, Congress building. I will be giving my second presentation on lean-agile, this time to a larger audience that includes industry leaders and some congressmen. It is very likely that it will be broadcasted through the Congress TV channel.
• March 5, ITESM (Instituto Tecnológico de Estudios Superiores de Monterrey). I will give a lecture on lean-agile and innovation which will be broadcasted to its 33 campuses accross the country via satellite and internet.

Also, Feb 25 is the MexAPLN meeting at the Software Guru offices starting at 7:30 PM. Address is Temstocles 34, 3rd.floor, Col Polanco, Mexico City.

Book Review: Lean-Agile Software Development: Achieving Enterprise Agility

Authors: Alan Shalloway, Guy Beaver and James R. Trott.

Between December of 2008 and April of 2009 I participated on a series of 6 webinars on Lean-Agile Software Development given by Allan Shalloway, under NetObjectives, and knew that the book—same title as the webinar series—was being finished at that time so I was definitely looking forward to it. I was very glad when the publisher asked BayAPLN for a review, which gave me the opportunity take over such a pleasant task.

The basic premise of the book is a better approach to drive software development efforts to maximize realized business value. It pays particular attention to how to scale agile to the enterprise; a main topic of discussion within the agile community during the last two years. The book’s proposal is to use lean-agile instead of agile alone and to “extend” scrum to what the authors call scrum# which is, simply put, doing scrum while also doing lean thinking. Particular attention is paid to the lean principles of waste elimination and optimizing the whole. The authors put together a body of knowledge that would otherwise take lots of research, reading hours, and trial-and-error experience. The theme itself is not new, you can also consult, e.g., books on lean software development by Mary and Tom Poppendieck, and a book on scaling lean and agile development by Craig Larman and Bas Vodde. Shalloway, Beaver and Trott’s book is easy to read and very informative at a conceptual level and also at an anecdotal level. The cases they present actually add a lot of value to it. I consider this to be a must for executives, managers, and non-technical people involved on software projects because it will help them understand better what lean and agile can do for their organization. It is also helpful to software and QA engineers as a great informative reading.


The book consists of an introduction, three parts, and an appendix. The Introduction sets the tone for the book and revisits the basics of agile and lean (manifesto, principles, etc.). But make no mistake; this book is not for people new to agile or lean, and for those who are it is better to do some previous reading or they might get lost at times.

Part I starts with a discussion on why it is not preferable to think of software development as a science or a technique instead of as a discovery means to the end of satisfying a need, and gives a gentle introduction to some lean principles within software development. Chapter 1 nicely explains the transition of manufacture-based practices to software development. Chapter 2 addresses the business value added by agile and lean through better customer interaction, better delivery, and product focus. Chapter 3 gives some insights on how to get started with the transition to lean-agile, and chapter 4 dives into lean thinking for portfolio management, which I consider to be the most important chapter of this part because it gives a good deal of practical advice to do high value-added changes to your organization.

Part II Focuses on lean project management. Chapter 5 addresses some limitations of scrum that are particularly important when considering scalability. The authors propose what they call Scrum# as an extension of scrum that includes lean thinking. I personally think the problem is not scrum itself but rather how we put it into practice and what they propose as scrum# to me is nothing more than having a better (lean) way of applying the scrum framework; maybe because I learned about lean years before scrum came to be and so I have always used lean thinking when doing scrum. In any case, I would advocate to simply keep the term scrum as-is and encourage people to learn and apply lean to it rather than getting into new terminology, which I think might create confusion instead of clarity. I was very pleased to see that Kanban was added to the book and wish it had been explained in more detail, on a dedicated chapter, because kanban is very powerful in eliminating some disadvantages of scrum and it will gain importance as a highly effective software development framework. Chapter 6 is about iteration 0, which is the preparation phase before starting your actual scrum iterations. I entirely agree with the need to do the prep work but I have never been fond of calling it iteration because in people’s minds it time-boxes a very important phase that not necessarily—and almost never—takes the same amount of time as the actual scrum iterations (see, e.g., Jim Highsmith’s book Agile Project Management). Chapter 7 is a good explanation on how to do lean-agile release planning. Chapter 8 explains the importance of visual controls and information radiators, which is a subject that most executives have a hard time accepting from the lean-agile perspective but once they fully realize their high value regardless of their simplicity they usually embrace these fully. I definitely enjoyed seeing a chapter on the role of QA (chapter 9) because this is often under-treated in the software development literature in general, unless it is on a dedicated QA book. This inclusion goes well with the lean-agile principles of working in teams and optimizing the whole.

Part II addresses scalability at enterprise level on chapter 10 with a very effective discussion format. Management’s role in lean-agile is treated on chapter 11 with good arguments but I would’ve liked it better if it had elaborated further on this very important role. Chapter 12 was one of my favorite ones since it does a good job at discussing the Product Coordination Team, a relatively new approach that has proven to be better suited for scalability than scrum of scrums. Chapter 13 is rather a teaser about the importance of a better, lightweight, approach to software architecture and design, which is okay since it is beyond the scope of the book.

Part III consists of chapter 14 only and is an epilogue to the book that basically encourages people to explore and learn more about lean, primarily, and about agile.

Appendix A explains Steve Bockman’s Team Estimation Game. A dynamic, fun, and effective step further of what you can do with the Planning Pocker that is also scalable. Appendix B presents the authors’ model of lean-agile software development, a nice quick reference to refresh the key concepts.

Alan, Guy, and James wrote a fabulous book that is a must-read for those interested on a successful lean-agile adoption whether or not you need to scale.

First MexAPLN meeting

The first MexAPLN meeting took place today at 7:45 PM at the Marie Callender's restaurant in Mexico City located on Insurgentes Avenue. Attendees were executives from diverse entities: Sergio Eduardo Duran Rubio (Accival), Martin Villalba Paredes (FIDEM), Alejandro Escamilla (Software Guru magazine), Armando Peralta and Ivan Carlos Rivera (Infotec), Jesus Flores, Jennifer Vazquez and René Molina (Bytline), and myself.

After introductions I talked briefly about how agile got started under a bottom-up approach and how as time has passed by, the practices matured, and the chasm has been crossed, executives are taking a more important and proactive role towards adoption thus the increase of top-down adoption. I then talked about what APLN is and, as a case, how BayAPLN operates. Next explained the benefits that MexAPLN can provide to industry and to us as professionals by bringing awareness on agile-lean.

Last we talked about the success factors and did some action planning for the next meeting, that time to be held at a company instead of at a restaurant.

To finish we did an intro planning pocker exercise for those new to it.

Lean-Agile could've saved this company

Air-Go was a software services company that went belly up. It's former CEO reported 10 reasons it failed. When I read about it I couldn't stop wondering where that company would be nowadays had it been an lean-agile company. I identified 8 of the reasons could've been fixed doing lean-gile
1. Poor people interaction. There was too much focus on personal benefit instead of team and business benefit. Also, interaction with customer was low.
2. Lack of vision. Chartering was never done and the company had no direction.
3. Different values. Individuals and teams were not on the same page with respect to what value should be added and how to add it.
4. Lack of focus. Teams handling too many projects at the same time instead of one at a time.
5. Overestimating. No knowledge of their teams' velocities.
6. Failed often but late. Most of their projects failed and failed too late.
7. Too much planing and very little execution. BDUF!
8. Overconfidence and designing for best-case scenario. Lack of planning and incremental/iterative development.

A recipe to improve enterprise success-fail project rate

Larry Gelwix has been the head coach of the Highland HS Rugby team in Salt Lake City for 36 years. Along that time he has accumulated a 413-9 win-loss record; the most impressive any sports coach—professional or amateur—has achieved ever. Wouldn't it be fantastic if our projects had a similar success-fail rate? Some aspects of his coaching style are well in tune with some agile-lean values and principles:

• High degree of teamwork: doing collaborative work with all stakeholders within and beyond the project boundaries makes much more likely to achieve team coherence.
• Horizontal leadership: to give room for self-organization, delegation, empowerment of the team to make better decisions, and boost skill improvement amongst team members. This fades away micromanagement and a command-and-control culture.
• Setting goals: short, achievable milestones which are goals on their own right. An incremental-iterative approach to create products foments discipline, increase quality, and motivate customers to provide feedback throughout the creation of the product they want.
• Realizing potential: by trusting and empowering the team we form motivated individuals. And a motivated person is usually more productive and less prone to make mistakes.

This recipe doesn’t ensure project success, but it can help your enterprise become hyperproductive and, as a consequence, successful. As Larry said: “good decisions don’t make life easy, but they do make it easier.”

SG article on Agile-lean with standards and models

Software Guru published my article on agile-lean with standards and models, which has two objectives. I try to clarify the distinction between standards, models, and values because I often see people use them as if they meant the same and because they are used the wrong way in practice. I also indicate some ways in which agile-lean can be used in enterprises that require governance under a standard or a model.

The contents of the article published are edited from the original article I sent, which is often the case when publishing articles on a magazine. For those of you who would like to read the original you can find it on my website's documents page under the title:

• Spanish version: "Beneficiando estándares y modelos mediante agile-lean"
• English version: "Agile-lean benefits standards and models"
  

The importance of good software development in Financial Institutions

Mario Sandoval, president of the AMFE (Asociación Mexicana de Entidades Financieras Especializadas) announced that real state development is key to reactivate the financial market. On a similar note, Stefano M. Stoppani, Principal Director or CRIFMexico and Regional Director for Latinamerica, mentioned back in February that proactive fianancial management infrastructure (for payments) requires the usage of four aspects to allow for the right decisions to be made and for efficient execution:

• software
• processes and organization
• data
• analysis

What his means for us is that Agile-lean management and software development, if implemented, can play a crucial role in all of them.

On the software side we have methodologies such as scrum, XP, etc. that increase the efficiency of teams and the overall quality of the software generated. On the process and organization side we have agile-lean project management which creates a better structure for all stakeholders, including customers, to collaborate and make decisions. Agile databases enables data modeling and their implementation to be done more effectively. Good modeling is crucial to good analysis and agile modeling provides waste-elimination ways to do so without consuming vast amounts of time and resources.

Lean Manufacturing for electric manufacturing companies

My last business trip to Mexico included meetings with two electric manufacturers. One of them had a fairly good level of manufacturing process in place, with an reasonably clean/ordered plant and a good skill set baseline. The other one had a rather chaotic atmosphere: overcrowded in some areas, extremely hot, and with some workers building several different items at the same time. The commonality they have is the quality of their products is hurting them although, and surprisingly, the first factory more than the second one. Although both companies are profitable they lose money in the faulty products they produce and one of them even lost it's most important customer.

Both companies keep ISO compliance but the time/money consuming compliance activities have done little, if anything, to fix their problems. One first one has made efforts to follow JIT and Six Sigma but to no avail. I noticed during the visit to their plants two common denominators. They both hace a genuine interest on improving their processes; and they have received very limited coaching on how to implement and enforce a good manufacturing process.

I gave them a presentation on Lean Manufacturing and how it may help them produce better products and potentially get their workers to be more productive. Their response was enthusiastic and now it is a matter of them deciding if they want to give Lean a shot.