Find easily the root cause of a problem using the right diagram tool

A Current Reality Tree is part of the Logical Thinking Process tools and steps created by Eliyahu Goldratt.

This is the process to create one:

1. Identify the Undesirable Effects

2. Make sure each of them is written understandably

3. Diagram causal relationship among them

4. For each undesirable effect look for causes

1. Causes may be common for more than one

2. If you have more than one cause, use ellipses to join them (and)

5. Follow until you find root causes

Why use text to diagram tools

Getting fast feedback helps you to think clearly and smoothly. 

When you are using a diagram tool like Visio, or LucidChart. A good part of your time is dedicated to making arrows, and containers reflect what you're thinking. 

But, what you need is to get feedback as soon as possible about what you are thinking about. Modify it, check it again, until your diagram represents a better model than the initial one.

I use the Theory Maker Text to Diagram Tool to create a Current Reality Tree.

This is the original diagram from the Book, Agile Retrospectives.

This is the diagram generated on Theory Maker.

This is the text that. 

UE 4 // Developers are resigning; fillcolor=pink

 No professional development opportunities

 Increased pressure on the developers

  UE 3 // Customer is unhappy; fillcolor=pink

   Customer is not integrated

    No customer contact

   UE 1 Velocity is too low; fillcolor=pink

    Low quality of the requirements

     No customer contact; fillcolor=green5

    Consistent problems with building the software

     No automated tests

     No integration environment; fillcolor=green5

   UE 2 The quality of the software is poor; fillcolor=pink

    No automated tests

     No integration environment; fillcolor=green5

    Missing know-how

     No professional development opportunities; fillcolor=green5

   

direction=BT

variable;colour=grey2

arrow;colour=grey3

_____

You can paste it on the  Theory Maker Web Page. 

Then you can modify it. 

Alejandro Garcia made a great compilation of text to diagram tools. Thanks again for showing me this one.

Aministración Visual de Proyectos

Basados en Cadena Crítica de Goldratt. Definitivamente obligado para los que llevamos proyectos. Cortesía del Viejo.

Al tener muchos indicadores pierdes el enfoque... No más de tres...

La regla del viejo para las métricas, se basa en la teoría de restricciones del maestro Goldrat. Menos métricas son mejores para todos.

Goldrat dice que no debes enfocarte en más de tres métricas. Cuando Norton le presentó a Goldrat el Balanced Scorecard, Goldrat opinó que eran demasiadas métricas. Goldrat opinó que cuando tienes más de tres métricas los integrantes de la organización tienden a  manipular la información para sabotear el sistema.

Lo que medimos influye sobre el comportamiento de la organización. Por ello debemos tener mucho cuidado

Shoulders of Giants (SOG). Comprender mejor la solución que el creador. Ver artículo completo aquí. Realmente vale la pena:  http://www.goldrattschools.org/pdf/shoulders_of_giants-eli_goldratt.pdf En este  artículo se describe perfectamente como la filosofía de la línea de producción de  FORD y el sistema de producción TOYOTA se basan en los mismos principios.

Nota al margen. Después de leer este artículo y ahora leyendo la biografía de Jobs  me sorprendió que ni Ohno ni Jobs se enfocaban en la reducción de costos. En la mayor parte de las empresas mexicanas el enfoque en los costos es una constante. ¿Quién tendrá la razón?

Tips para administración utilizando Teoría de Restricciones (TOC)

En el CIMAT se realiza un coloquio o plática entre estudiantes, profesores y gente relacionada con el CIMAT. En esta ocasión toco el turno a Alejandro García. De manera previa ya habíamos realizas una sesión introductoria de Teoría de Restricciones. De la cual luego les comentaré. La sesión tuvo la siugiente agenda:

1) Primero realizamos el ejercicio para demostrar que se es más productivo cuando se realizan tareas secuenciales a tareas con multitasking.

2) Caso de matnenimiento de aviones de la fuerza aérea israelí. 6 ingenieros, 6 aviones por ingeniero, tiemp promedio 17 meses. 6 ingenieros, 3 avios por ingeniero, tiempo promedio de mantenimiento 5 meses. Qué pasó? Redujeron el mutlitasking

3) Minimizar el multitasking

3.1) Gráfico de cuantos proyectos permiten elevar la productividad de un Ingeniero de Sw.

4)  Primera observación respecto al tiempo

4.1) El cuadruple del tiempo promedio para dar una buena estimación

4.2) Todos los IS queremos ser considerado personas confiables y eso implica cumplir compromisos. Cuando a un IS experto no promete más del 80%.  Ello implica no exagerar.

4.3) La variabilidad hace que los ingenieros se esfuersen para cumplir las metas. 

4.4) Hay otro ejemplo de startups. Cuando una compañía empiza y tiene pocos desarrolladores produce más que cuando se integra más gente a la compañía en el transcurso del tiempo.

La regla equivocada de la administración es "La manera de asegurar que un proyecto termine en tiempo es tratar que cada actividad termine en tiempo".

Las nuevas reglas:

1. No convertir los estimados en compromisos
2. Mover la protección del nivel de tarea a nivel proyecto
3. Usar un buffer de administración para establecer prioridades

Ejemplo:

1) Diagrama de PERT de un proyecto normal con buffers al final de cada terea.

2) La primera ocasión se reduce la estimación al 50% y se deja un buffer de 33%. El proyecto queda en 66% de la estimación original.

3) Cuando las estimaciones son optimistas solo agregas el 33% de buffer.

4) Se administran los buffers. Si el buffer va bien ni me meto a ver como van las tareas. Pero si tengo problemas de que mi buffer se está consumiendo y se me va a pasar debo de tomar acciones.

4.1) De aquí se deriva que si el buffer esta libre, tal vez conforme avance el proyecto se pueden realizar más tareas.

4.2) Empresas que utilizan está técnica, realizan reuniones de avance de una manera más rápida.

4.3) Con el método de buffer puedes aceptar adiciones si está contemplado dentro del tiempo.

Las premisas son que:

1. Buscamos tieempos optimistas.
2. El buffer sirve para problemas inesperados.
3. Si alguna tarea se retraza no hay problema, siempre y cuando sea razonable el tiempo del buffer.

Ejemplo de los pueblos japoneses a la orilla de las montañas. Lo invitaron porque con TOC resolvieron el problema. Una casa es un proyecto, necesitas un buffer. Un constructora de una fraccionamiento. Hay otras técnicas que se utilizan para contabilidad y otro tipo de cosas...

Conclusiones del equipo:

• Vale la pena dar el beneficio de la duda a la Teoría de Restricciones.
• Es contra intutivo la aplicación de Teoría de Restricciones en empresas de desarrollor de software.
• Vale la pena buscar y obtener más ejemplos al respecto.