Toma de decisiones probabilística

Larry es un analista de datos para la toma de decisiones. Presentó el resultado de investigación de su Doctorado en CMU, sobre el análisis de métricas para equipos ágiles y determinó que existen cuatro métricas que se relacionan con la productividad real de una empresa.

• Administrar probabilísticamente es una MEJOR alternativa que todas las demás. 
• La calidad de las decisiones depende de las alternativas consideradas y los modelos utilizandos. Pero la administración probabilística es SUPERIOR.

Para más detalle aquí la presentación de Larry: http://es.slideshare.net/lmaccherone

Ejemplos: El sitio desarrollador por Larry http://lumenize.com/, utiliza un modelo Monte Carlo que nos permite analizar la probabilidad de la productividad en función de los últimos datos de productividad de la empresa. Así podemos ver que existe una probabilidad para terminar un proyecto un una fecha determinada.

También nos presentó un estudio que realizaron un Sw Developmente Performance Index (SDPI) que está compuesto de cuatro métricas:

También se puede consultar la presentación completa en: http://es.slideshare.net/lmaccherone
Las conclusiones de este estudio son muy interesantes:

Y como tema adicional, Larry dió 10 consejos para visualización de datos para la toma de decisiones:

Usando métricas para tomar decisiones tiene sus riesgos, pero se pueden mitigar.
En el siguiente slide de la presentación Larry nos presentó está métricas.

El 8vo dragón o riesgo con el uso de métricas para toma de decisiones es Human emotions vs bias. Y la manera de matar (mitigar) este riesgos es haciendo consciente de las bias que tenemos. Todos tenemos bias. 

Dinámica:
Parking Lot. Las preguntas que salgan ponerlas en un espacio para preguntas. Al final se contestarán en una mesa redonda o si hay tiempo al final de la charla.

Controlar el WIP.
Métricas (Scrum, Lean/Kanban, Lean), Consejos para la toma de decisiones,

Libros recomendados:
How to measure everything.

Temas clave
Somos inexactos para pronosticar de manera calibrada,

Lessons learned in the Kanban Trainning Course week at Seattle

25 de mayo de 2015

Reflexionando acerca de lo que aprendimos en Seattle en el Curso de Certificación de Entrenadores de Kanban de Lean University.

-Por Alejandro, Arturo y Pepe.

1. Los cinco pasos de Teoría de Restricciones y Kanban son equivalentes.
2. A un nivel mecánico, Kanban y SCRUM son muy similares, pero a un nivel filosófico son diferentes. En SCRUM hay muchas supersticiones, mientras que Kanban está basado en datos. 
3. En el mundo real no hay correlación entre el tamaño de la tarea y el tiempo que se tiene para terminarla. En el mundo real casi todas las tareas pasan el 95% del tiempo esperando y por tanto solo el 5% en touch time. 
4. En Kanban es necesario un punto de compromiso. En cuanto una tarea llega a este punto empieza a correr el customer lead time.
5. En las organizaciones la eficiencia del flujo es en promedio un 5%, las organizaciones super eficientes tienen una eficiencia de flujo del 40%. Es decir de 20 dias que tarda en entregarse una tarea, solo 1 dia pasamos trabajando de manera acumulada en ella o sea 1/20.
6. Descubrimos el juego de getKanban.com. Un juego para aprender Kanban de una manera muy intuitiva. 
7. De Brendan, empresario de startups nos comentó que el Venture Capital es una pésima opción. Para que los fundadores pudieran ganar 3 millones de dolares utilizando este método de financiamiento tendrían que vender su empresa en 300 millones de dolares. El mismo dinero lo podrían obtener muchas más fácil de otras maneras.
8. Valió la pena aprender del creador de Kanban, nos ahorro al menos tres años de entrenamiento autodidácta. La vida es tan corta que debemos aprovecha cuando se puede aprender de los maestros. Como dice Evaris Gaola, si aprendí mucho es porque aprendí de los maestros, no de los alumnos. 
9. Conseguimos muchos contactos para invitarlos a eventos a México. Al Congreso de Mejora de Procesos de Sw, para Exponegocios, continuamos en contacto con otros coaches de métodos ágiles. Definitivamente cuesta salir pero vale la pena.
10. Como dar un curso para que otras personas puedan replicarlo. Si quisieramos que los maestros de los tecnologicos y universidades aprendimos una buena metodología para transferirles este conocimiento. Presentar un caso propio, presentarles el material y que lo expongan.
11. Lean Kanban University convirtió un producto intangible en un producto tangible. 
12. El $$ está en la consultoría, el ofrecer cursos, asistir a conferencias, dar conferencias, publicar en blogs, etc. es marketing para tu producto.
13. El Kanban de la industria automotriz y el kanban para los servicios profesionales es difernte siendo los puntos más importes el punto de compromiso y 
14. El PSP no sirve. La principal causa es que el leadtime no tiene relación con el tamaño de una tarea. En PSP se estima en base al tamaño. Así no tiene sentido.
15. Tenemos una resistencia al cambio irracional porque el cambio amenza nuestra identidad. El sistema de McKinsey es el equivocado, siempre trata de cambiar todo. Con SCRUM tambien te pide que cambies tu contexto. 
16. Si llegas a algun lugar y no hay nada pon SCRUM, si el proceso ya está definido usa Kanban.
17. El Enterprise Services Planning es para implementar Kanban en procesos de Tecnología que es una buena opción para empresas de Software. Incluye una mayor visión de indicadores. 
18. Aprendimos que el juego de la pizza (que no conocíamos) para enseñar Kanban no es útil, pero sí lo es para mejora continua.

p.d. Cuando viajes a USA llevate tus zapatos viejos y comprate unos nuevos.