RespuestasAgiles: ¿Qué es la LEY DE LITTLE y por qué es importante para las GERENCIAS DE TI y PMOs?

"Todos tienen un plan hasta que son golpeados en la cara". - Mike Tyson

 

Algunas frases sobre planificar, pleneación, planificación y los planes

Hola a todos

Las frases son muchas veces puntos de quiebre que nos hacen reflexionar, reafirmar o reformular nuestras creencias, paradigmas o prejuicios.

A continuación les comparto unas frases e ideas sobre planeación, planificación y planes.

“If you fail to plan, you are planning to fail!” Benjamin Franklin "Si fallas planeando,están planeando fallar"  Benjamin Franklin

Otras versiones derivadas de la anterior:

"Al no planificar, se está planeando fallar" "la gente no planea fracasar, fracasa por no planificar"

También tenemos estas más contundentes

"No battle plan survives contact with the enemy" "Ningún plan sobrevive al contacto con el enemigo"

"In preparing for battle I have always found that plans are useless, but planning is indispensable" “En la preparación para la batalla siempre he encontrado que los planes son inútiles, pero la planificación es indispensable” Dwigth D. Eisenhower

"Everybody has a plan until they get punched in the face " “Todos tienen un plan hasta que son golpeados en la cara” -Mike Tyson

En marcos ágiles

"Valoramos más respuesta ante el cambio sobre seguir un plan" www.agilemanifesto.org

Y por experiencia propia en marcos ágiles

En marcos ágiles se hace planeación y se revisa el plan frecuentemente debido a que la planeación es adaptativa, muy diferente que en que en gestión tradicional que es más orientada a cumplir el plan que fue trazado desde inicio.

Saludos Ágiles

Jorge Abad

Hablemos de la Complejidad, la Gestión de Proyectos y Cynefin

Hablemos de la Complejidad, la Gestión de Proyectos y Cynefin from Jorge Hernán Abad Londoño

Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User Story Map

Charla compartida en el V congreso de gerencia internacional de proyectos del PMI Colombia 2016, en donde se muestran los principios realizar la planeación y seguimiento de un proyecto ágil usando la técnica de User Story Map de Jeff Patton

---

Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User Story Map from Jorge Hernán Abad Londoño

Diatriba: El tema recurrente de llamar "RECURSOS" a las personas que trabajan en un proyecto

Hola a todos

Uno de los temas más insistentes cuando comienzo a trabajar Scrum con mis compañeros de las áreas de Gerencia de Proyectos, es explicarles lo dañino que es llamar a quienes construyen el producto “recursos”.

Y es difícil para muchos entender que nuestros compañeros de trabajo, los que ejecutan son nuestros pares, la diferencia consiste en que ellos construyen el producto y desde la gestión se tiene la responsabilidad de liderar, pero si ellos no estuvieran allí o no quisieran realizar el proyecto no habría ni a quien liderar ni como realizar el proyecto.

En entorno conspira para esto

Al observar las condiciones  de este uso común, tiene cierto sentido pues por todo lado:

• Literatura de proyectos
• PMBoK
• Documentos del PMI
• Microsoft Project
• herramientas de gestión de proyecto
• y aún en la RAE

Determinan que los elementos (incluyendo las las personas) disponibles para resolver una necesidad son denominadas RECURSOS (1)

 Y de ahí se crea el imaginario y varias ideas extrañas en el inconsciente de los líderes de proyectos :

• Un recursos puede reemplazar a otro, supuesto falso pues los trabajadores de conocimiento generan resultados únicos y la forma como construyen algo dependerá de las fuentes que hayan conocido hasta el momento, la expertise y hasta el ánimo con que se encuentren
• Varios recursos harán más rápido el trabajo de uno, otro supuesto falso pues muchas veces más personas implican más entropía, más canales de comunicación, más conflicto, más fricción y por ende mas retraso (2)
• Entre otras particularidades

"La mayoría de nosotros, como gerentes, somos propensos a un defecto en particular: una tendencia a gestionar a la personas como si fueran componentes modulares." – Tom DeMarco, Peopleware, 1987 (9)

El lenguaje como generador de realidad

Es común ver que esta cosificación (diría que conveniente) de lo humano y lo creativo del hombre, termina derivándose en expresiones entre gerentes de proyecto como:

• Cuando liberas el recurso para incluirlo en mi proyecto
• El recurso se enfermo
• No sé qué hacer con ese recurso
• Ese recurso es bueno, ese recurso es malo
• Los recursos están en tarde de descanso

Como me lo hacía ver mi amigo Lucho Salazar @luchoSalazarC :

“los gerentes y líderes de proyecto en general no se consideran a sí mismos recursos, solo hablan así de quienes trabajan para ellos en un proyecto.”

Recuerdo mucho hace unos años que pertenecía a una empresa donde los compañeros se quejaban que los Jefes/lideres/gerentes de proyecto los trataran de recursos y no como personas y de cuenta de esa falencia

• Armaban y desarmaban el “equipo”
• Tenían compañeros part-time en un proyecto y en otro
• Y no les preguntaban sobre el proyecto y sus opiniones no eran tenidas en cuenta, solo era personas que tenían unas tareas asignadas dentro del diagrama de Gantt y que cobraban por su trabajo, nada más.

Dado lo anterior, se confirma la tesis de  Echeverría en su libro sobre Ontología (3) donde se afirma que el lenguaje es generador un realidad,o sea, cuando expresamos algo estamos creando una realidad alrededor de las palabras que pronunciamos, y este lenguaje de los “recursos” genera una realidad en la que concebimos o creemos que las personas que componen un equipo son plug and play – o como máquinas - y podemos “usarlas” en el entorno laboral similar a como se gestiona un activo fijo (pc, mesa, mueble, una máquina, etc.)

Es de allí también que las áreas de recursos humanos han cambiado sus nombres a:

• Gestión del talento humano
• Gestión de lo humano
• Desarrollo de personas
• Gestión y desarrollo de personas
• Entre otros

Las consecuencias

La realidad generada por este tiempo de comportamientos y expresiones es negativa, pues el deseo que tenemos todos de participar o trabajar con un equipo genial o aún más un equipo de alto rendimiento se ve frustrado cada vez que se mueven las personas del equipo, pues cada equipo es único, las relaciones son únicas, dadas por las personas que lo componen, quitamos a alguien, lo reemplazamos por otro y el equipo se reinicia y vuelve a comenzar la curva de Tuckman.

Entonces lo que tanto anhelan los Líderes de proyecto – alto desempeño, productividad, autoorganización -  se ve frustrado por sus mismas acciones y su falta de desconocimiento de lo humano.

"Los equipos son inmutables, cada vez que alguien entra o sale es un equipo nuevo, no uno modificado" @richardadalton #Agile #scrum #Genial pic.twitter.com/V1jz9ohaJw

— Jorge Hernán Abad L. (@jorge_abad) 22 de septiembre de 2016

Es de resaltar que una de las premisas claves y exitosas  de la agilidad es tratar a las personas como personas – no como recursos- y les da un lugar primordial ellas y sus interacciones (4) y  enfocándose en generar equipos estables y motivados que van madurando y dando resultados cada vez más sorprendentes con el tiempo.

Para dónde va esto

Es importante entonces que los Gerentes, Jefes, Gerentes de Proyecto, el Líderes de Proyecto y Scrum Master (5) comprendan que con quienes trabajan son igual de importantes que ellos, que sus compañeros  tienen el rol de ejecución, diferente al de ellos que tienen responsabilidad de dirección, coordinación o facilitación.

Es allí donde la Gerencia Moderna, Management 3.0 encuentra frases que son bastante fuertes en este sentido

• Trata a tus empleados como quieres que ellos traten a tus clientes
• Trata a tus empleados como tus mejores clientes (Lema Disney)
• Trata a tus empleados como si te hicieran el favor de querer trabajar contigo 

Frases que tienen mucho sentido en las empresas de tecnología y en muchas otras áreas donde competencia de los caza-talentos por empleados es voraz y cualquiera se puede ir, y el éxito de las áreas de talento humano es medida entre otros aspectos en función de:

• La capacidad de atraer los colaboradores correctos
• La capacidad de retenerlos en la organización

Para terminar

Quieres resultados geniales:

• Conoce a los integrantes de tu equipo, comparte con ellos, realicen juntos un actividad de Mapas personales (personal maps)(6) entre muchas otras, genera lazos fuertes que los lleven a sentirse apoyados y respaldados por ti y por sus compañeros
• Manten tu equipo estable en el tiempo, esto les permite madurar y llegar a estados de desempeño y según el coaching que reciban y la disposición de ellos, podrían llegar a alto desempeño o desempeño extraordinario

Los dejo con esta frase

“SON PERSONAS, NO RECURSOS”(7)

Y este pensamiento

“En esta era del conocimiento y la complejidad, el éxito de las organizaciones no está dado por la capacidad de explotar a las personas, sino por la capacidad que tengan las organizaciones de desarrollarlas y liberar el potencial innovador y creativo de ellas trabajando en equipo” (8)

Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Definición de la Rae - http://dle.rae.es/?id=VXlxWFW
2. Esto en el mundo de la gerencia de proyectos es conocido como la Ley de rendimientos decrecientes: al incrementar la utilización del personal, la producción crece a tasa decreciente. 
3. Ontologia del lenguaje. Rafael Echeverria - clic aquí -.
4. Manifiesto agil - clic aquí -.
5. Se espera que estos ultimos tengan esto claro pues tienen el Agile Mindset
6. Mapas personales, personal maps - clic aquí.
7. Con esta frase comienzo muchas veces mis charlas a los gerentes y líderes de proyecto y se las hago repetir al menos tres veces diciendo: “digan conmigo: Son personas, no recursos”, y luego les explico (4) Parafraseando un poco lo que el decía, la cita original es:  Según Peter Drucker: “ La más importante, y en realidad la verdaderamente única, contribución de la ciencia de la gestión en el siglo XX fue el incremento, en 50 veces, de la productividad del trabajador manual en la producción. La más importante contribución que la gestión necesita hacer en el siglo XXI es, de manera similar, incrementar la productividad del trabajo del conocimiento y del trabajador del conocimiento. El activo más valioso de una compañía del siglo XX era su equipo de producción. El activo más valioso de una institución del siglo XXI (sea o no de negocios) serán sus trabajadores del conocimiento y su productividad.” para ver más clic aquí.
8. Este artículo fue discutido con mi esposa que es Especialista en Gestión del Talento Humano, a quien considero más experta en estos temas que yo.
9. Una excelente referencia -"Equipos Estables por sobre Pool de Recursos" de Martin Alaimo - Clic aquí.
10. ¡Me desahogué!, este post estaba hace muchos días pendientes por escribirlo.

Comenzando con un equipo Scrum: Actividades para activar un equipo el primer día, team canvas y otras técnicas

Hola a todos

Hoy quiero compartirles una agenda de trabajo que pueden emplear el primer día que comienzan con un equipo ya sea tu rol como facilitador, scrum master, gerente ágil o gerente de proyectos.

Primero: Conozcamos nuestros nombres y una comida que no nos gusta

• Tiempo máximo : 30 minutos (dependiendo de la cantidad de personas)

En esta parte hago una ronda con el equipo y lo comenzamos por la derecha contestando varias preguntas sencillas

• Nombre
• Rol o cargo
• comida que no nos gusta (he notado que genera mucha empatía este tema), pero se puede reemplazar por:
• Película de cine que más le gusto
• lugar bonito al que haya ido
• última película de cine
• un restaurante
• etc.

La segunda persona contesta este sencillo esquema y repite el de su compañero de la izquierda junto con la comida con le gusta, la tercera persona lo mismo con sus dos compañeros, hasta que el último (o sea el facilitador) dirá el nombre de todos y la comida que no le gusta.

Segundo: Una actividad de equipo

• Tiempo máximo : 60 minutos (dependiendo de la actividad)

Resulta que el equipo aun no es un ser como tal, saben todos que ese es el objetivo pero aun no nace, es un imaginario. entonces en este punto recomiendo realizar un reto de equipo, dentro de este reto de equipo los ponga a trabajar juntos y les de sinergia, dentro de estos retos pueden estar los siguientes:

• Para equipos medianos y grandes (6 a 20 personas)
• Ball Point Game - (clic aquí para ver las unas indicaciones)
• La dinámica de listones - (clic aquí para ver el video) (1)
• Para equipos pequeños (de 6 o menos personas)
• Construir una torre con un trozo de cinta, spaguettis, un metro de hilo y en la punta un masmellow - (clic aquí para ver el video) 

Tercero: Un nombre y una imagen

• Tiempo máximo : 30 minutos 

Habiendo interactuado juntos, la idea es que cada uno se dibuje dentro de un pliego de papel y busquen un nombre para el equipo, esta actividad les da identidad, pertenencia y los ubica en un mismo espacio.

Cuarto: Personal Maps o Mapas Personales

• Tiempo máximo : 45 minutos 

Luego cada uno de los integrantes del equipo debe realizar un mapa personal (o elaborarlo entrevistado por un compañero) y lo presenta el equipo, esta actividad ayuda a mejorar las interacciones y a entender que no somos roles, ni cargos, somos personas que tienen una vida, metas y aspectos muy variados fuera de la zona de interacción, y permite mejorar la forma como vamos a trabajar.

Para conocer más hacer clic aquí - Mapas Personales

Y para cerrar, Team Canvas (2)

• Tiempo máximo : 120 minutos

En esta actividad el equipo en conjunto define aspectos fundamentales de su interacción

• Propósito
• Personas y roles
• Objetivos comunes
• Valores
• Reglas y actividades
• Fortalezas
• Debilidades y riesgos

Van navegando por cada de uno de ellos con un timebox determinado, en este link encontrarán la guía para realizarlo - http://theteamcanvas.com/use/

Con esto definido, están listos para los retos que juntos van a enfrentar.

Concluyendo

Esta agenda es una propuesta inicial, pueden haber muchas agendas de trabajo, si tienen mejoras me encantaría que me las compartieran.

Saludos ágiles

Jorge Abad

Referencias, comentarios, aclaraciones y notas

1. Esta actividad la conocí gracias a mi estimado compañero y amigo Sebastián Velásquez - @sebasla
2. Este lienzo lo conocí gracias a mi amigo y maestro Lucho Salazar - @LuchoSalazarC

Una propuesta de Definición: Gerente de Proyectos Ágil

Hola a todos

De un tiempo para acá me es común ver en los perfiles de Linkedin quienes se definen asi mismos como:

• Gerente ágil
• Gerente Agile
• Gerente de Proyectos Ágil
• Gerente Ágil de Proyectos
• Agile Project Manager

Cosa que me agrada y alegra pues dice uno:
 - que bueno,  lo logramos, están a salvo, en el lado luminoso de la fuerza, han dejado el comando-control (1) y han comenzado a confiar en sus equipos, vamos a tener más equipos felices trabajando. (2)


Pero también hay casos en donde solo lo ponen como una moda sin comprender lo que abarca el "nuevo" término.

Debido a esto quiero por aca poner un grano de arena poniendo desde mi perspectiva que es un Gerente Ágil de Proyectos o cualquiera de sus derivaciones.

• Un Gerente Ágil de Proyectos es alguien que promueve los principios y valores ágiles dentro de sus proyectos:
• buscando generar entornos de trabajo donde los equipos sean colaborativos y creativos, de forma que exista una comunicación transparente, alta motivación, confianza, excelencia y autogestión, 
• liberando software (productos) de valor, de forma temprana, continua y con excelencia técnica
• maximizando el ROI
• permitiendo ciclos cortos de mejora continua que le permitan realizar inspección y adaptación basado en la experiencia de ciclos anteriores
• y velando por una óptima utilización de recursos financieros y del tiempo (3)

Basado en el manifiesto ágil(4), lean software development(5), lean minset(6), management 3.0 (7)(8) y la experiencia en este mundo de la agilidad quisiera evidenciar algunas prácticas, principios y actitudes que debería tener un proclamado o autoproclamado gerente ágil de proyectos:

• Su foco es crear una solución para el problema de su cliente, realizando las preguntas correctas, resolviendo el problema correcto y generando un resultado de gran valor.
• Tiene un gran conocimiento de los frameworks y métodos ágiles, sabe cuando emplear los unos y los otros, adicionalmente permite que estos funcionen con las reglas establecidas para los mismos.
• Cree en las personas y no las trata como recursos que puede quitar y mover.
• Sabe que existe un proceso pero es consciente que el trabajo en equipo y la generación real de equipos estables de trabajo es la clave del éxito de de su proyecto.
• Empodera y energiza a las personas y los equipos.
• Es consciente que el plan es un medio no el fin
• Maximiza la comunicación tanto horizontal como vertical
• Maximiza la comunicación y la transparencia a todos los niveles para reaccionar tan rápido como sea posible.
• Tiene y propicia una comunicación clara, transparente y asertiva
• Es un líder servicial, con metas claras que orienta y empodera
• Comprende que lo más importante es la generación temprana y continua de valor y no el cumplimiento del plan,
• Comprende que el plan es una herramienta y no un fin.
• Genera valor en ciclos cortos de trabajo
• Percibe el cambio como una oportunidad de generar valor. y no lo posterga.
• Hace planes y proyecciones basados en la capacidad de su equipo de trabajo y en las métricas obtenidas de el.
• No impone compromisos irrealistas y que no se puedan cumplir
• Cree que los resultados excepcionales tienen como fuente la motivación y no la presión
• No presiona al equipo por resultados irreales, creyendo que si los presiona para el 120% obtendrá el 100% esperado.
• Comprende que la excelencia técnica y la calidad es clave en todos los procesos del proyecto
• Comprende que la generación de incentivos es una herramienta que no genera compromiso y es consciente que es mas valioso el feedback, el reconocimiento tanto en equipo como entre pares. 
• Propicia espacios de aprendizaje y ciclos cortos de mejora continua, de no más de un mes con preferencia al periodo mas corto.
• Toma decisiones cuando tiene todos elementos necesarios para tomarlas
• Reacciona tan rápido como sea posible, generando rápido feedback sobre el producto, procesos, personas y herramientas.
• Comprende los espacios de los problemas y los resuelve de acuerdo a su clasificación evitando el reduccionismo y la sobresimplificación -clic aquí- 
• Comprende cuando emplear planeación predictiva y cuando emplear gestión empírica basada en inspección y adaptación -clic aquí- .
• Tiene un gran foco en reducir toda fricción e incrementar el flujo
• (con sus aportes esta lista seguirá creciendo)

Como siempre, bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Esta práctica es conocida por confiar infructíferamente en el plan en proyectos de software y no generar entornos de confianza con alta generación de valor.
2. Además yo era uno de ellos, y me tomo casi 6 meses abrazar y comprender muchos de los principios ágiles (soy un rehabilitado, jajaja)
3. Se tomaron elementos del Del triángulo de hierro al triángulo ágil (modificado) de mi estimado y bien ponderado amigo Lucho Salazar - @luchosalazarc para la generación de esta definición
4. Manifiesto Ágil - Clic Aquí
5. Lean Software Development - Clic Aquí
6. Lean Mindset - Clic Aquí
7. Managmenent 3.0 - Clic Aquí
8. Martie el monstruo de Management 3.0 - Clic Aquí

Ámbitos del Proyecto y del Producto en Scrum

Hola a todos

Siguiendo con la serie (http://www.lecciones-aprendidas.info/2016/05/ambitos-del-producto-y-del-proyecto.html ), les comparto dónde está ubicado el Equipo Scrum (el cual esta compuesto por Product Owner, Scrum Master y Team Members) dentro del ámbito del Producto y del Proyecto

Saludos Ágiles

Jorge Abad

Diatriba: Una salida a la sobresimplificación de nuestros problemas en proyectos

Hola a todos

Hoy quiero compartir una situación común en los proyectos y organizaciones, que se repite una y otra vez, adicionalmente creo que tanto ustedes como yo lo hemos vivido

El escenario es sencillo:
Se reúnen varios líderes asociados a la construcción de un proyecto (1) a deliberar ¿por qué este se encuentra mal o en riesgo?, Y la primera respuesta que sale es:

• ¡El problema son los RECURSOS! ( - refiriéndose al equipo de trabajo - ,wow ¿estudiamos 5 años, más las experiencias, diplomados, certificaciones, especializaciones y maestrías para responder esto?)

y acá veo varios  problemas en esta óptica que quiero compartirles:

1. En primer lugar no son recursos, son personas, esta eterna lucha por que comprendan que el trabajo lo hacen personas tan valiosas como quienes dirigen y que al pensar en una forma reduccionista sobre las personas lo que logran es ignorar o desperdiciar la capacidad creativa e innovadora del ser humano, y del equipo que los acompaña.
2. ¿Quién en sus cinco sentidos quiere hacer mal su trabajo? La verdad no dudo que los hayan (serán muy pocos), pero no es lo común, todos queremos hacer cosas que ayuden a otros, que sirvan, que sean útiles y que estén alineadas con el propósito para el cual sentimos que estamos acá en esta tierra, por lo tanto culpar al equipo de trabajo es una costumbre simplista que indica que no se quiere abordar con el debido interés la causa y la solución del problema.

Pero cuando lo opinión mágica no está orientada a los "recursos" se centra en otro tema (9), todos concuerdan, se abrazan y sonríen, deciden que hacer y salen de la reunión hasta que después sean convocados a otro comité para hablar sobre lo mismo y notar que los problemas no fueron resueltos o todos lo olvidan pues surgió otro proyecto en problemas para analizar.

¡Rayos! Y recuerdo siempre a la cita del periodista del siglo pasado H.L. Mencken

Para cada problema complejo hay una solución clara, simple y equivocada,( H.L. Mencken)

No lo niego, al principio yo era así, además cuando asumes posiciones de liderazgo tiendes a adoptar los mismos lenguajes y análisis de tus pares, pero luego cuando en el 2012 conocí las metodologías ágiles y el poder de las retrospectivas para mejorar un equipo y su forma de trabajo, realmente cambió mi forma de ver las cosas.

Con esta nueva óptica, encontrarme en reuniones como esta no niego que me daba enojo, pues tendemos a la simplificación o sobresimplificación por herida newtoniana, ¿cómo así? Todos hemos sido heridos en nuestra lógica por Newton y su causa y efecto y tendemos a creer que todo se resuelve así, por lo tanto, buscamos desesperada y angustiosamente una causa que explique nuestro problema (o efecto) y dado esto encontrar la solución y continuar con el siguiente problema pues hay muchos líos en la fila esperando a ser resueltos.

Algunos ejemplos de nuestra común sobresimplificación:

• ¿por qué el país está mal, por el presidente?
• como si todos no hiciéramos parte de un país y fuéramos parte de la maquinaria que lo mueve.
• los proyectos de software fallan principalmente por los requisitos
• es una de las causas pero no es la única causa
• ¿Y por qué fracasó su relación de pareja?, por una infidelidad de él/ella
• es muy probable que la infidelidad sea el síntoma y no la enfermedad, y la enfermedad era una serie de disfunciones en la pareja que hicieron que hubiese esa infidelidad,
• etc.

Y me topé con Cynefin

Cynefin es un framework para entender qué tipo de problema estamos enfrentando y proporciona herramientas de cómo resolverlo, este framework me fue presentado por mi estimado Ricardo Colusso (@rcolusso) y desde ahí comencé a aficionarme a el, y recientemente leí un minilibro sobre el tema en Infoq.com (4) y muchas ideas se aclararon - recomendada su lectura -. Explicaré brevemente en qué consiste.

El framework de Cynefin fue elaborado por el Investigador Dave Snowden, y el término significa "hábitat", divide los tipos de problema en 5 áreas y propone herramientas para solucionarlo

• El obvio:
• Problema conocido
• tiene relación directa causa efecto
• Ejemplo: Se chuzó la llanta, solución cambiar la llanta o parcharla
• Se resuelve con una mejor práctica
• Pasos de solución: inspeccione - categorice - responda
• El complicado
• Problema que se puede llegar a conocer
• Tiene relaciones causas y efectos conocidas
• Ejemplo: Se daño un vehículo y el mecánico luego de inspeccionarlo sabe los diferentes arreglos que hay que hacer para poner nuevamente el vehículo en marcha y estado óptimo.
• Se resuelve con las mejores prácticas, juicio de expertos, todo es perfectamente planeado (cronogramas, tiempos, planeación predictiva, PMP) y los expertos resolverán este tipo de problemas de la misma manera teniendo el mismo éxito.
• Pasos de solución: inspeccione -analice - responda
• El complejo
• Problema es entendido en retrospectiva
• las relaciones causa y efecto no son repetibles
• Ejemplo: La economía es excelente prediciendo el pasado y explicándolo pero no es precisa hacia el futuro
• Se resuelve con la multiexperimentación
• Pasos de solución: inspección - adaptación
• El caos
• El problema es incoherente
• las relaciones causa efecto no son perceptibles
• Ejemplo: Escenarios de I+D
• La solución es novedosa
• Pasos de solución: ensayo y error
• El desorden
• Corresponde al punto cuando llegamos a un problema y aún no lo hemos categorizado en los cuatro anteriores

Bajo todo lo expuesto quisiera invitarlos a varias cosas:

1. No caer en la sobresimplificación de los problemas que enfrentan, identificar si hay causa y efecto directamente relacionada o explicable, ya sea en el espacio de lo obvio o de lo complicado o realmente no.
2. Si lo anterior no se cumple trate de identificar si está en el espacio de lo complejo, desde mi punto de vista y de otros muchos en la industria del software (5) la gestión y ejecución de proyectos de software cae allí, o sino díganme ¿qué gerente de proyecto de software es capaz de predecir todos los percances que le van a presentar en la ejecución del mismo, por más buena gestión del riesgo que haga? La verdad no conozco el primero, son capaces de explicar que les pasó y porqué les paso pero no de predecirlo por más que llenen el cronograma de colchones para la gestión del riesgo..
3. Si estás en una reunión de estas de análisis de problemas, propón lo siguiente:
1. Identifiquen las causas
2. las prioricen (cuales son las que consideran más importantes)
3. Propongan soluciones
4. Las prioricen (cuales consideran claves, 3 o 4) (6)
5. las ejecuten y observen en un ciclo de no más de un mes (ojalá menos) los resultados de ese experimento y decidan qué pasos seguir, tal vez sea necesario otro experimento.

Para este último escenario existen diversas herramientas de 

• análisis de causa raíz
• retrospectivas (que incluyen lo anterior)(8)
• Toyota Kata (7)

que son bastante fuertes y útiles.

Por tanto, quisiera invitarlos a que abracemos la complejidad de nuestros proyectos y organizaciones y abandonemos la sobresimplificación.

Cerrando

Y bueno, propongo que los líderes de proyecto, gerentes, etc, seamos más creativos y demostremos nuestros años de estudio, experiencia y certificaciones identificando las verdaderas causas y dejemos la sobresimplificación de los problemas que enfrentamos, entendiendo que nos movemos en un espacio complejo sobre el cual no tenemos control, esta actitud, será mucho más útil, que ignorarlo.

"No estamos en las organizaciones para ofrecer soluciones rápidas sino para ofrecer las soluciones correctas"

Saludos ágiles

Jorge Abad

Notas, Referencias y Aclaraciones

1. También puede ser una empresa, un área organizacional.
2. Es un trabajo arduo remover este vicio de la gerencia tradicional de proyectos
3. Expicación de Cynefin segun wikipedia -https://en.wikipedia.org/wiki/Cynefin_Framework
4. Excelente libro sobre Cynefinby por Greg Brougham, corresponde a la colección de minilibros gratuitos de infoq.com - (clic aquí)
5. Debo esta referencia, pero no dudo que los firmantes del manifiesto ágil hacen parte de este grupo,
6. No se deben hacer todas las mejoras, al menos 3 o 4 para saber cual fue la mejora, solución o experimento que más influyó en la solución del problema.
7. Excelente presentación sobre el tema de Hiroshi Hiromoto (@hhiroshi) (clic aquí)
8. Retrospectivas (ver más acá)
9. He también visto como se centran estos comités en culpar a las pruebas y acusan de la calidad del software solo a esta actividad del proceso, o cualquier otro chivo expiatorio ¡OMG!

Todos Terminarán Siendo Ágiles

Hace un tiempo he venido reflexionado junto con mi círculo de amigos de Ágiles Colombia, especialmente con Lucho Salazar (@luchosalazarc) y Leonardo Agudelo (@sweepnoise), sobre que pronto la industria en general, los monstruos de la tecnología, las certificaciones, etc, tenderán hacia el cambio Ágil (Agile) o incluirán en su estilo o títulos algo relacionado con esto (1).


Y el cambio será (esta siendo) relativamente natural y orgánico,  este cambio nace desde TI con:

• las metodologías ágiles (en especial Scrum)
• el manifiesto ágil
• el lean software developement

y nuestro afán en dejar de fallar haciendo en software (pues desde TI, llevamos años y años fracasando y haciéndole perder dinero, tiempo y oportunidad a nuestros clientes, a nuestras empresas y tiempo valioso de familia o descanso a todos los que han (hemos) estado involucrados en proyectos de software) y comenzamos a enfocarnos diferente, a generar valor de forma distinta, a trabajar más en equipo y generar valor en periodos cortos, y este cambio ha hecho que alguien ajeno a TI, diga: "estos locos están haciendo las cosas distinto, por fin funcionan, que podemos aprender de ellos, yo quiero eso mismo para mí y mi equipo".

Pero ¿quién no desea ser exitoso en los proyectos que emprende y usar las técnicas y herramientas más apropiadas?

Y si yo desde otro enfoque, industria, mercado o empresa veo que otros lo están haciendo bien y les esta yendo bien, lo más obvio es que quiera copiar esa buena forma de trabajo y usarla en mi contexto (recordemos que la copia es una forma de innovación).

Ágil, no es sicorigido, es más emergente y orgánico (como lo expresaba arriba) y se va adaptando según se va comprendiendo y se va transformando la cultura.

Si observamos bien:

• Certificaciones como PMI-ACP, 
• Microsoft proclamandose ágil, 
• el Management 3.0, 
• Lean Six Sigma

Entre muchos otros enfoques, vemos que esto no es una moda, que es un enfoque distinto para hacer las cosas y que llego para quedarse.

Yo doy la bienvenida a todos los que se quieran sumar a este esquema, más natural, humano, orgánico, adaptativo y retador de trabajo, enfocado en el trabajo de equipos autogestionados, dirigidos, con propósito, que transforman no solo a las empresas de TI, sino todos los nichos donde se encuentran.

Yo anhelo que hayan muchas empresas que se embarquen en este estilo de gestión y dar resultados más pronto que tarde, tanto por el beneficio de sus empleados como de esos mismos negocios (recordemos que en negocios quien no se adapta y evoluciona desaparece).

Pronto todos trabajaremos con porciones o la torta completa del enfoque ágil, y los beneficios totales o parciales que de este se deriven.

Yo por mi parte me sigo quedando con la parte DEL PRESENTE CONTINUO del Manifiesto Ágil, que reza:

Estamos descubriendo formas mejores de desarrollar

software generar Valor (2) tanto por nuestra propia experiencia como

ayudando a terceros.

Seguiré buscando formas mejores de generar valor, tanto para mi beneficio, los equipos de trabajo en los que participo, como para mis clientes.

Saludos ágiles

Jorge Abad.




Fuentes y aclaraciones:

• (1) Acuérdense de mi, un día llegará que CMMi tendrá certificación AGILE
• (2) Modificación que le observé Agustín Villena @agustinvillena
• Management 3.0. Jurgen Appelo

Diferencia entre Gerente de Proyecto, Scrum Master y Product Owner

Hola a todos

Hace días tenía pendiente construir esta tabla en la que  se observa la diferencia de responsabilidades entre un:

• Gerente de Proyecto -  GP -
• Scrum Master -  SM -  (Maestro de Scrum*) y
• Product Owner - PO - (Dueño de Producto)

		ROLES SCRUM
Áreas de Conocimiento de la Gerencia de Proyectos del PMBOK 5	Gerente de Proyecto	Scrum Master / Maestro de Scrum*	Product Owner / Dueño de Producto	Equipo de Desarrollo
Integración del Proyecto	Se cumple
Alcance	Se cumple		-Priorización del Backlog  -Especificacion de funcionalidades  -Rápido ROI** de las funcionalides
Tiempo	Se cumple		- Tiene un Plan de liberación del producto que garantice el ROI
Costo	Se cumple
Calidad	Se cumple	Aseguramiento de calidad (garantiza que se realice principalmente Scrum y procesos organizacionales)		Control de Calidad sobre el producto
Recursos Humanos	Se cumple	Coach del Equipo y del Product Owner		Equipo Auto Gestionado
Comunicaciones	Se cumple
Riesgos	Se cumple	Hace gestión de impedimentos que algunas veces consiste en prevenir riesgos y/o futuros problemas que se observan para el proyecto/producto. La mayoría de las veces es más reactivo que proactivo.
Adquisiciones	Se cumple
Interesados	Se cumple		Relacionamiento con los interesados del proyecto que poseen requisitos del proyecto

Por lo tanto,

• No se cumplen las siguientes igualdades o transiciones
• Gerente de Proyecto = Scrum Master  
• Gerente de Proyecto = Product Owner
• Si un GP quiere hacer la transición a SM deberá suprimir varios aspectos de su normal disciplina (8 en total) y soltar el comando-control y comenzar a creer en la auto-organización y en el Product Owner. Las preocupaciones de un SM son radicalmente otras.
• Una persona con los roles de Product Owner y Scrum Master*** al tiempo es casi un gerente de proyecto, tiene demasiado poder y le quita uno de los aspectos claves de Scrum, que consiste sana tensión entre el PO y el SM.
• Es requerido un GP o alguien que se encargue de:
• Contrataciones
• Otros interesados
• Costos
• Riesgos
• Comunicaciones
• etc

Notas y Aclaraciones
* Maestro de Scrum: Me da la sensación que nos suena más claro y contundente en español (muchas veces usamos palabras en inglés y no las cargamos de su significado)
** ROI : Retorno de la Inversión.
*** Una de las recomendaciones para hacer Scrum




Saludos Ágiles y hasta la próxima

Jorge Abad

Causas del "MANEJO" o dícese de "LA FALTA DE TRANSPARENCIA"

Siempre que tengo la oportunidad de dar clase, facilitar una charla o compartir con un grupo de desarrolladores de software pregunto:

¿Quiénes de ustedes han visto decir mentiras a su gerente/líder de proyectos?

o les pregunto a los gerentes de proyectos presentes:

¿ustedes dicen mentiras en sus proyectos?

La respuesta lamentablemente en ambos casos es abrumadora, es un rotundo 

SI   :(

Hemos visto decir en la gerencia tradicional frases como:

• a esto hay que "darle manejo"
• el avance es del "tanto" por ciento pero digamos mejor que es este otro número
• o la típica sensación de que decimos que vamos en el 90% y nos demoramos otro 90% para terminar el 10% que supuestamente nos faltaba

Pueden haber varias causas dignas de investigación, sin tener datos fiables pero de acuerdo a mi experiencia y a la de mis colegas diría, que la causa principal es que 

"el proyecto se salió de control"

y es probable que sea considerado usted un mal gerente de proyecto o la culpa la tenga el equipo.

Pero viene una pregunta más fuerte, 

¿se puede controlar lo que no se no es posible controlar?

¿se puede controlar lo que esta en el campo de lo complejo?

Yo pienso que NO, y esa es la causa de la falta de transparencia.

El modelo de Cynefin nos da luces al respecto (ver referencias 1 y 2 entre muchas otras)

En software todo hace que el proyecto se atrase y se vuelva impredecible:

• el cliente
• los desarrolladores (la falta o exceso de los mismos)
• los egos 
• la inexperiencia
• los requisitos
• los servidores
• el software base
• la relaciones entre los componentes
• los componentes 
• las buenas relaciones
• las malas relaciones
• los insumos en el momento inapropiado
• la retroalimentación tardía
• la retroalimentación de las personas inadecuadas
• lo nuevo o viejo de cierto tipo de una u otra tecnología
• objetivos poco claros
• y muchos más, (ver referencias 3,4 y 5)

Si de una vez por todas decimos con sinceridad:

• estamos resolviendo el problema del software con las herramientas incorrectas
• fallamos aplicando métodos predictivos que aplican perfectamente en escenarios donde podemos imaginar con tranquilidad los acontecimientos (escenarios complicados, según el modelo de Cynefin)  

• cuando debemos ser adaptativos (o empleando el empirismo que propone Scrum), realizando inspección y adaptación (escenarios complejos, según el modelo de Cynefin)  .

Espero que algún día mis compañeros Gerentes de Proyectos de Software obsesionados:

• en ser secretarios de MS PROJECT (como le dice un gran Scrum Master y Coach - Jorge Johnson)
• en darle "manejo" a las situaciones ocultando información y cayendo en la FALTA DE TRANSPARENCIA
• en controlar lo que no se puede controlar

Acojan el agilismo y abracen sus principios y valores.

Saludos ágiles

Jorge Abad

___________

Referencias:

1. Sistemas Complejos Adaptativos: Modelo Cynefin (clic aquí)
2. Cynefin: la complejidad que nos rodea (clic aquí)
3. ¿Por qué fallan los proyectos? En: Navegapolis.net. Disponible en: <http://www.navegapolis.net/content/view/701/49/ >  [citado 24 de Junio de 2014]
4. STANDISH GROUP. Chaos Manifesto2013 - Think Big, Act Small. En: Version One [en línea]. Disponible en: <http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf> [citado 24 de Junio de 2014]
5. STANDISH GROUP. The Standish Group Report. [en línea]. Disponible en: <http://www.projectsmart.co.uk/docs/chaos-report.pdf> [citado 24 de Junio de 2014]

¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu

Usted o su empresa siendo el CLIENTE:

• ¿Formula proyectos que sabe de antemano que NO se van a ejecutar en el tiempo que tiene pactado?
• ¿Se busca quien haga su proyecto a pesar de tener expectativas irreales en cuanto tiempo y costo?
• ¿Argumenta que si hay un proveedor que es capaz de postularse es porque la solución es posible?
• ¿tiene reuniones afanosas donde todos se miran, sonríen, estrechan manos  diciendo que sí vamos a ser  capaces, vamos a poner todas las condiciones para que sea así?

Usted o su empresa siendo el PROVEEDOR:

• Le jura a su cliente que va a cumplir aunque no tiene ni las personas, ni la expertise para hacerlo
• Su gerente  general le dice a usted como gerente de proyecto:  tienes que hacer ese proyecto con las personas que tiene, pues el "no voy a contratar mas gente / - o mal llamados recursos -  "
• Se mienten entre sí en el posible equipo ejecutor diciendo:” tranquilo yo sé que ustedes lo van a lograr, ustedes son muy buenos” aunque no falta el pesimista que dice – “hombre esta es la misma historia de siempre, vamos a caer en lo mismo”, lo ignoran y siguen adelante…
• Se diseñan estrategias super-apretadas para cumplir algo irrealizable (el Project, el Gantt y el Power Point pueden con todo)
• Estima proyectos grandísimos sin la participación del equipo ejecutará.

A ustedes dos (cliente y proveedor) ya lo saben:

El proyecto será:

• un fracaso
• o un eterno desgaste  muy difícil de cerrar
• Reuniones y reuniones
• Actas firmadas
• Revisión de documentación
• Y hasta invitación a revisión de los abogados

Alguien pagará los platos rotos

• Lo más seguro es que sea el proveedor 
• Estos platos los pagan los trasnochos del equipo de trabajo, de esta forma se pagará la “mala planeación” que si somos sensatos fue la mala venta o presentación a un proyecto problemático.
• Y pasará a engrosar la lista de proyectos problemáticos que harán que nuestro valor hora de venta hacia el mercado aumente.
• Su reputación estará nuevamente en juego.
• En muy pocos casos los pagará el cliente, pero si es así, con seguridad le costará su puesto, o su reputación.

Se verán abocados (cliente y proveedor - gerente del lado del cliente y gerente del proyecto) a realizar reuniones continuas y constantes de re-planeación de proyecto donde se pasarán horas reformulando el proyecto, creando nuevos cronogramas  (donde el tiempo lo sacarán del tiempo de descanso correspondiente  a los desarrolladores) y firmando con sangre nuevas fechas (a ratos no sé de dónde sacan tanta sangre cierto tipo de empresas) y lo peor al no cumplirlas usted (ya sea cliente o proveedor) perderá credibilidad y la palabra dada ya no servirá.

 En esta circunstancia es probable que su Jefe o Gerente (los CEO, o plumas blancas como le decimos en mi país) tengan que ir a reuniones a repactar todo nuevamente.(y lo peor es probable que las reputación y palabra de ambos también se desgaste en este tipo de círculos viciosos)


Si usted es el cliente:

• Su jefe le estará preguntando por qué eligió ese proveedor y tendrá constantes reuniones de seguimiento y de estrés con él.
• Usted pensará de nada me sirvió haberme desgastado en la elección o haber confiado en la empresa “x” o en mi amigo “y” que trabajaba en esa empresa.

Si usted es el proveedor

• El comercial dirá: “yo solo cumplí con vender el proyecto, acá lo aceptaron, nadie dijo NO, ni nadie me detuvo, además yo logrando otro estoy en otro proyecto si quieren me invitan a una reunión a ver que hacemos”. (la caricatura que sigue es.. inspiradora.)

(pero bien..sigamos con el tema)

• Al gerente de proyecto le dirán
• mire como planea mejor ese proyecto, para que salga adelante
•  otras veces le dirán: Nos va tocar hacer ESO aunque no esté en el alcance para calmar al cliente (léase ESO como una nueva fuente de problemas pues va a estar muy seguramente mal especificado y como siempre este tipo de regalos salen caros).
• El gerente hablará con los desarrolladores y todo su equipo.
• "Muchachos tenemos que trabajar fuerte, el proyecto es un lío, ustedes saben que yo no lo vendí, pero estamos acá para sacar las cosas adelante. Vamos a trabajar duro, les daremos pizzas y pollo para que trabajen de noche y fines de semana. Yo sé que lo vamos a lograr, yo confío en ustedes, y si lo logramos voy a buscar como logro una bonificación de la gerencia general."

----

Y a todas estas, todos dicen en su interior… este es el mismo deja vu de siempre, repetimos y repetimos los mismos errores, acá en esta organización no aprendemos. De nada nos sirve tener procesos definidos y/o rigurosos como CMMi, certificados o no, todo es el mismo desgaste (por no querer decir todo es la misma m…).

Muchas veces el desarrollador o el gerente de proyecto  se va para otra empresa y allá vuelve y encuentra la misma historia.

---


La verdad no entiendo la industria de software, ni los clientes, ni los proveedores, no acogen muchas veces Procesos Ágiles que son transparentes porque les da miedo, pero ¿acaso todo este recurrente deja vú no es peor que una película de terror que se repite y reinventa con nuevos y/o los mismos protagonistas?

Esto es cómo jugar a la ruleta rusa entre 4 personas y con 5 balas en el tambor.

No entiendo ¿por qué los Clientes (aclaro "los malos Clientes") no quieren pagar el costo de un buen proyecto?, y  ¿por qué los que son/somos proveedores no aprendemos a decir que NO?

Hasta acá esta pequeña diatriba y desahogo... hasta la próxima.


----

¿Quieres jugar un juego?

Hagamos un proyecto a la forma tradicional con una metodología robusta, mirarás el RFP (la convocatoria, la licitación) y sabes que no lo lograrás, si no lo haces saldrás del mercado, pero si lo haces cortaré la libertad de tu equipo de trabajo y trabajarán horas y horas, perderás tiempo y dinero sin lograr el alcance, ni cerrar el proyecto. Tienes 3 días para presentar la propuesta… tic tac.. tic tac