Presentación: La Gestión de Proyectos Evoluciona: Abrazando la Flexibilidad de los Enfoques Híbridos

Video: Contratación y Gestión de Proyectos de Sofware

¡Los invito a ver este video sobre un #CastorSinFiltro en el que comparto reflexiones sobre los desafíos en la contratación y gestión de #ProyectosdeSoftware:

• En ocasiones, los #contratos y #RFP son asignados por áreas de #costos, priorizando la #eficiencia o el #ahorro en el #precio, lo cual va en detrimento de la excelencia técnica y el rendimiento del software.
• Muchos proyectos son #gestionados por profesionales excelentes que tienen poca o ninguna experiencia en el desarrollo de software, lo que lleva a ignorar la #complejidad inherente. A menudo se percibe erróneamente el desarrollo de software como una línea de producción, donde hacer una pieza es igual a hacer otra. Sin embargo, el software es inherentemente impredecible y preciso. Dos piezas aparentemente similares y "pequeñas" pueden requerir tiempos de desarrollo completamente diferentes. Una bien construida puede ser rápida de desarrollar, mientras que otra, en un entorno #hipercomplejo, puede llevar hasta seis veces más tiempo o incluso más.

Es importante recordar que desarrollar software no es una tarea ni predecible ni exacta: Dos tareas aparentemente iguales y "pequeñas" pueden requerir tiempos completamente distintos. Una puede estar bien construida y tomar poco tiempo, mientras que la otra puede encontrarse en un entorno hipercomplejo y requerir hasta 6 veces más tiempo que la primera.

¡Comparte tus comentarios! ¿Qué desafíos has enfrentado en la contratación o gestión de proyectos de software?

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

 

Tweet: "El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad". - Nicoll Hunt

 

 

"El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad". - Nicoll Hunt

"The first step of any project is to grossly underestimate its complexity and difficulty." – Nicoll Hunt

— Programming Wisdom (@CodeWisdom) January 23, 2021

Mis notas sobre la charla "El Corazón de la Agilidad" de Alistair Cockburn

Hola a todos

Hace poco mi gran amigo y líder técnico Daniel Ramirez, publicó las notas de la sesión que asistimos sobre el Corazon de la Agilidad de Alistair Cockburn - en Pragma el pasado mes de noviembre de 2019 -  https://contactosagiles.co/aoc-colombia-2019/el-corazon-de-la-agilidad/ -, yo también dejar un pequeño registro de ciertas frases contundentes que nos compartío Alistair en esta excelente sesión:

---

El corazón de la agilidad se basa en:

• colaboración
• entrega
• reflexión
• mejora

---

Combinando estas palabras se obtiene

• colabora para entregar
• entrega para reflexionar
• reflexiona para mejorar
• mejora la colaboración
• colabora para mejorar
• colaboramos para tener mejores ideas
• entrega para aprender
• la mejora reflexiva (es la inspección y adaptación de scrum)
• pausa para reflexionar (obvio no es una combinación)
• mejora para cambiar el mundo (obvio no es una combinación)
• mejora el sistema de entrega

---

Los tres estados del aprendizaje

• Shu - seguir la técnica
• Ha - agregar técnicas diferentes, romper la regla
• Ri-  dejar el dojo

---

Concepto clave Kokoro:

• esencia o corazón de algo
• simplificación radical de conceptos

---

Al hacer una transformación en una organización se debe buscar:

• no intentar cambiar la cultura
• aumentar la confianza
• reducir el miedo
• mejorar la interacción
• mejorar el sistema de entrega
• mejorar la conversación entre las personas

---

Respecto a la gerencia de proyectos y a los errores

• una empresa es una fábrica de ideas
• una idea es precursora de una decisión
• las decisiones son las molécula de lo que hacemos y entregamos al mundo
• cada producto tiene mas de 100.000 decisiones
• cada decisión es una posibilidad de error
• El "ARTE" de la gerencia de proyectos se basa hoy en día en DESCUBRIR LOS ERRORES LO MÁS TEMPRANO POSIBLE
• debido a lo anterior, entregamos lo antes posible para obtener feedback y evitar avanzar en la dirección equivocada

---

Preguntas para mejorar un equipo, un área, una organización:

Qué hacemos para: - Mejorar nuestra colaboración - Mejorar nuestra reflexión -Mejorar nuestra mejora

---

Notas y frases varias:

• si mi mundo es de contratación tradicional, es decir, alcance tiempo y costo fijo, sugiere hacer contratos de tres meses para poder adaptarnos dentro de esas restricciones
• Valor: el cliente sabe lo que es valor
• Una empresa será más ágil entre más NATURAL le podas dar MALAS NOTICIAS AL JEFE
• Debemos mejorar la conversación entre las personas
• el corazón de la agilidad es un recordatorio, no un proceso
• "Show me the feedback loops"
• Una métrica importante: ¿cuántas veces por dia o semana se interrumpe el trabajo del desarrollador?
• "Todo lo que se diga puede ser malinterpretado o malutilizado y no se puede escoger cual de ellos dos sucederá"
• "El corazón de la agilidad está en descubrir los errores y dar las malas noticias"
• SAFe que es nivel shu
• La resistencia al cambio es normal
• Cambia poco a poco

---

Otras imágenes de su pasada por Medellín

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272

"Nuestro trabajo en la Agilidad es dar las malas noticias temprano, simplemente porque es menos costoso"

---- 

"Agilidad es encontrar errores más rápido, y si no se los podes contar a tu jefe y virar, ¿para qué haces Agilidad?

---- 

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272

Tomado de: https://twitter.com/pablitux/status/1198710728707973121

---

Hasta acá este compartir

Video de la charla: http://www.lecciones-aprendidas.info/2022/09/video-corazon-de-la-agilidad-alistair.html


Saludos ágiles

Jorge Abad

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

Desperdicio Generado por la Pérdida de Contexto o "Switcheo" entre Proyectos

Hola a todos

Hay cosas sobre las cuales no se puede dejar de insistir, y esta es una de ellas el multitasking, pérdida de contexto o switcheo constante entre proyectos.

La dejo por acá para que la usen de referencia.


Saludos ágiles

Jorge Abad

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2)

Imagen de la película: ¿Dónde está el piloto? - Idea de mi amigo Wilmar Hincapie

Hola a todos

En el pasado Ágiles 2017 en Chile, hablando con Leonardo Agudelo (@sweepnoise) sobre los proyectos piloto, me hacía ver que no solo eran importantes los puntos del artículo anterior (mira la primera parte de este artículo - Clic aquí):

• 3 a 4 meses de duración
• Con 1 a 4 equpos de trabajo
• Importante para la organizaicón
• Patrocinio ejecutivo
• La gente correcta
• Dominio de la tecnología

Sino que era necesario revisar el manifiesto ágil buscando los elementos para cumplirlo y para generar el ambiente propicio para que germine la agilidad, a continuación les comparto este análisis y algo de mi experiencia:

• Crear un contrato que permita la agilidad, seamos sensatos un contrato con todo fijo -alcance, tiempo y costo fijo- no nos permitirá tener éxito. (ver sobre contratos agiles - clic aquí- )
• No usar las tipicas métricas de cascada (CPI, SPI) para medir el proyecto (es un desastre tratar de acomodar ágil a esto - se los digo por experiencia)
• Permitir el cambio como parte natural del proceso (he observado que en proyectos que quieren hacer ágil, siguen con la política de control de cambios --¡¡OMG!! NO SE IMAGINAN EL DOLOR DE CABEZA. es necesario archivar este proceso para poder hacer el piloto)
• Cambiar las métricas de la evaluación de desempeño de las personas que participaran (es decir, en cascada a un analista le daban una buena calificación si tenía pocos controles de cambio, si este analista se va para el piloto de ágil, las historias de usuario las grabará sobre piedra - y me ha pasado -)
• Requerir que el negocio este involucrado y contar con su participación al 100% (con el ROL de Product Owner o de Interesado clave)
• Que exista la comunicación cara a cara (todos en el mismo sitio , co-location)
• Crear las excepciones - válidas a los procesos organizaciónales - que permitan la agilidad
• Prioridad en los despliegues
• Prioridad en los controles de cambio de ambiente
• Prioridad en las autorizaciones
• etc

Cerrando

Ya hemos perdido mucho tiempo y dinero haciendo proyectos en cascada, démosle la oportunidad a ágil, pero bajo las condiciones para que este tenga éxito, sino no tiene sentido.



Alguna otra recomendación

No dudes en compartirla en la zona de comentarios.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Mira la primera parte de este artículo - Clic aquí

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.

Hola a todos

Hace poco leí un gran post de Mike Cohn relacionado con como elegir el proyecto piloto: (ver el post  aquí) en donde reforzaba 4 variables (más un bonus):

• Duración: 3 a 4 meses
• Tamaño: Entre 1 y 4 equipos de trabajo (un equipo de máximo 9 personas)
• Importancia: Importante para la organización
• Patrocinio y Compromiso Ejecutivo: Alto
• y un Bonus: Contar con las personas correctas para hacer el proyecto (las que nos garanticen ganar esto funciona para cualquier escenario - agile o tradicional-).

El punto que quiero agregar (como fuente de mi experiencia) a esta lista de 5 puntos es:

• La Tecnología: la tecnología debe ser dominada por el (los) equipo(s) de trabajo

y ahí es donde va aporte, no tiene sentido (adicional a los 5 puntos anteriores) hacer un piloto en agile, o Scrum donde:

• la tecnología es nueva en el mercado, es decir, el proveedor nos están brindando la "valiosísima oportunidad" de ser de los primeros que la usan o implementan (¡OMG!),  o
• el equipo de trabajo no conoce la tecnología, es decir:
• no se domina la arquitectura
• no se conocen los componentes
• no se conocen los retos subyacentes, las características, 
• las premisas y supuestos no se dominan, 
• no se conoce como hacer el tunning del sistema, entre otros.
• y aunque el equipo recibió una "muy buena capacitación" y les funcionaron "todos los laboratorios" sabemos que eso no los hace expertos en algo nuevo (que al menos requeriría seis meses de trabajo continuo para comenzar a tener cierto dominio)

Sabiendo que el propósito es generar una victoria temprana y un gran impacto en la organización, de forma que sea comparable con los proyectos en cascada de similares condiciones.

No recomiendo hacer el primer piloto en agile con tecnología desconocida (y para ser sincero tampoco en cascada), pues no se verían resultados en el mediano plazo ni de la tecnología nueva ni del método.

Mi recomendación general sería:

• hagamos un proyecto piloto en agile con que cumpla las seis premisas:
• 3 a 4 meses de duración
• Con 1 a 4 equpos de trabajo
• Importante para la organizaicón
• Patrocinio ejecutivo
• La gente correcta
• Dominio de la tecnología

• y si, aun así desean el proyecto de la tecnología nueva y retadora, pues que sea otro proyecto adicional al primero, pero:
• que "este no sea el de mostrar" que Agile funciona (pero eso sí estoy seguro que si en este proyecto hacen correctamente Agile o Scrum les aseguro que avanzará más rápido que en cascada)
• que tenga e alcance pequeño 
• que cuente con alto acompañamiento al equipo de parte de expertos o personas conocedoras de la tecnología
• que la organización tenga paciencia este proyecto y su presentación de resultados,  
• y que los patrocinadores tengan alta tolerancia a la frustración pues este problema no corresponde a un escenario complejo (ni mucho menos predictivo) sino a una caótico donde es difícil tener victorias tempranas (1).

Hasta acá esta corta recomendación, reflexión y lección aprendida.

Saludos ágiles

Jorge Abad

(ver más en : Mira la segunda parte de este artículo - clic aquí )

Notas, aclaraciones, comentarios y referencias

1.  Ver el framework de Cynefin para entender el contexto de esta afirmación (clic aquí)

Demostrando el Valor Económico de Ejecutar Proyectos de Manera Ágil (Datos Hipotéticos)

Hola a todos


Hace poco alguien me preguntaba como demuestro el valor económico de ejecutar un proyecto en ágil versus uno tradicional. Dado este reto me dí a la tarea de crear este ejemplo hipotético basado en la experiencia de muchos proyectos ejecutados en ágil y en tradicional.

Datos de entrada

• Proyecto Tradicional (fila 1 a la 10 de la tabla)
• Tiempo formulado: 10 meses 
• Costo inicial: $500
• Tiempo adicional: 10 meses (por lo general los proyectos grandes fallan en grande y toman el doble del tiempo y del costo)
• Costo adicional : $500 (en color rojo)
• Valor total proyecto $1.000.
• Salida a producción: Mes 21
• Luego de estar el proyecto en producción alguien determinó que el beneficio era por 80 mensual
• Proyecto Ágil (fila 13 a la 24 de la tabla)
• Tiempo formulado: 10 meses
• Costo inicial: $500
• Tiempo adicional: 4 meses 
• Costo adicional : $200(en color rojo) (se decide ir un poco más allá del presupuesto para hallar todo el valor de negocio esperado)
• Valor total proyecto $700
• Salida a producción Release 1: mes 5. Beneficio producido 30
• Salida a producción Release 2: mes 8. Beneficio producido y acumulado 50 
• Salida a producción Release 3: mes 15. Beneficio producido y acumulado 80

Descargar Excel - Clic Aquí

Resultados obtenidos

• Los indicadores de TIR, Punto de Equilibrio, Ingresos netos en tres años, son mucho más favorables en Ágil que en Tradicional.
• En ágil se puede generar el mismo impacto con menos valor en producción debido a que el alcance construido en ágil se enfoca en solucionar un problema de forma incremental y no en resolver el problema con un alcance definido al inicio que no se sabe si cumplirá con las expectativas del cliente.

Aclaraciones

Es importante aclarar que he estado en proyectos donde:

• El valor de negocio se ha encontrado antes del presupuesto y fecha esperada, y para esto es clave un excelente Product Owner orientado por el valor de negocio, el ROI y no por satisfacer un alcance.
• Y tambien he fallado haciendo ágil en escenarios donde:
•  el cliente no entendía la metodología 
• y donde bajo un proyecto con alcance, tiempo y costo fijo y un contrato desventajoso, montamos ágil para mitigar riesgos pero aun así no logramos cerrarlos

En conclusión

• El éxito de un proyecto ágil esta dado por la estrategia para construcción del producto definida por el Product Owner, (Sin descuidar la excelencia técnica -Sin excelencia técnica no hay agilidad).
• Aunque este solo fue un ejercicio académico, el resultado de hacer ágil no es solo económico, existen entre otros:
• mejor satisfacción del cliente
• mayor visibilidad
• mejor gestión del riesgo
• Incremento en la felicidad del equipo
• ver más en http://stateofagile.versionone.com/

10th State of Agile 2015 - Versionone

Y para cerrar una idea

Ya le hemos dado muchas oportunidades a la forma tradicional - o cascada-  de hacer proyectos de software y hemos perdido, tiempo, dinero, clientes, amigos, trasnochos, ingenieros que han renunciado y familias que se han desintegrado(1), entonces ¿qué te impide hacer tu próximo proyecto de forma ágil?

Aclaraciones

1. Este dato lo he comprobado en dos ocasiones, en los que el ingeniero desarrollador me compartió que no estuvo por más de un año en su hogar, pues trabajaba de continuo sábados, domingos y festivos  en un proyecto, siendo esta  una de las causas raíces para que se generara el divorcio y por ende la desintegración de su familia.

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

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.

Algunos Tweets de Agilidad y Scrum

#ScrumMaster que mucho abarca poco aprieta y poco o ningún #scrum puede hacer pic.twitter.com/CXPK3LluNv

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

---

¿Qué tal esta perla...? @luchosalazarc @JohnnyOrdonez @juanenlasala @jorge_abad #FrAgileTrans pic.twitter.com/Uxk9i3aupB

— Luis Mulato (@luismulato) 5 de septiembre de 2016

---

@jorge_abad pic.twitter.com/yQtBS0jCwr

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

---

@luismulato @Management30 Esta es poderosa, tomada de https://t.co/NUHRnJaVt9 pic.twitter.com/1xSOCyofDg

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

---

@jorge_abad pic.twitter.com/YrAIZH0Nef

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

---

Bien lo dice @LuchoSalazarC "Exigir los resultados, no los garantiza"
Es mejor
-suprimir la presión
-más coraje,motivación y confianza,

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

---

Una carta de bolsillo para nunca olvidar ser asertivo pic.twitter.com/m06qEOzTxA

— Carlos Gil (@cafegifo) 23 de agosto de 2016

---

I'm refactoring "legacy code" written last week.

…by a guy who hasn't upgraded his skills in 20 y… ^ @codebyjeff pic.twitter.com/G5DDcXUWkk

— AgileFortune (@AgileFortune) 22 de agosto de 2016

---

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

Ámbitos del Producto y del Proyecto

Hola a todos

Les comparto esta imagen que puede ayudar a identificar qué ámbito corresponde al producto y qué ámbito al proyecto, ayudando a aclarar algunas dudas al respecto.

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