Scrum Master: Identificando y removiendo impedimentos... y adicionalmente el conflicto humano

Ayer realizamos en Medellín el primer AGILE BEER NIGHT - un gran espacio, de amistad, compartir experiencias y de cerveza - pero entre muchas cosas que conversábamos noté que algo no estaba muy claro, y es el trabajo del scrum master en remover todo tipo impedimentos.

Del Scrum Master, como lo he escrito en varios post  y como lo dice www.scrum.org es responsable de:

1. Remover impedimentos
2. Ser dueño del proceso y que se cumpla el proceso 
3. Realizar coach al equipo (orientarlo a que sea mejor tanto técnica como humanamente)

Pero el primer punto es el que me ocupa, un scrum master debe trabajar en identificar impedimentos en todas partes - un cazaimpedimentos -:

• sea que se los digan los team member en el daily (recordemos las tres preguntas mágicas: ¿qué hice ayer?¿qué voy a hacer hoy?¿qué impedimentos tengo?) 
• que se lo diga cualquier miembro del equipo scrum en el transcurso del día, (aclaro: el equipo scrum esta compuesto por Product Owner, Scrum Master y Team Members, estos últimos son los encargados de construir el producto)
• que se evidencien y expliciten en la review y con mayor razón en la retrospectiva
• o que el Scrum Master, lo "huela" o lo identifique sin que nadie se lo diga. 

(ya se dan cuenta por que se requiere un scrum master con dedicación de medio a tiempo completo para un proyecto)

Y allí esta una de las claves del liderazgo servicial, es estar preguntándose constantemente: 

¿qué le falta o estorba a mi equipo para que se sientan muy cómodos y hagan bien lo que más le gusta : construir un producto que los haga sentir orgullosos?, 

La respuesta a esta pregunta puede tener muchos tamaños, colores, sabores, y fuentes, pues pueden ser identificados desde los 3 pilares (que enumera Alan Cyment):

• Productividad
• Calidad
• y Felicidad

Como en las 4 capas ( que nos cuenta fuerza tres ver más aquí)

• Filosofía : las personas
• Metodología: el proceso
• Técnica: el conocimiento requerido para completar el producto
• Ecosistema: que entorno laboral que tiene el Equipo Scrum y los team member para realizar su trabajo 

Pero he notado que el esfuerzo depende mucho del tipo de impedimento:

• impedimentos tipo hard: de productividad, calidad, metodología, técnica y ecosistema es relativamente sencillo. Su remoción se centra en encontrar qué remueve el impedimento, y en muchos casos la remoción es causal, típica acción-reacción.: ejemplos:
• falta de conocimiento
• lugar inadecuado del equipo
• información inoportuna
• no se entiende cierto tipo de reunión del framework
• historias de usuario muy grandes
• salarios
• etc.

• impedimentos tipo soft: correspondientes a la felicidad, filosofía, estos dos tienen la complejidad correspondiente al ser humano, a la persona, sus experiencias, su forma de relacionarse con otros, a como se relacionaba en el pasado, a su presente, a como ve el futuro; y en este campo las acciones son más complejas y se requiere de grandes habilidades blandas de parte del Scrum master para removerlos. Ejemplos de estos impedimentos pueden ser:
• miembros que le hagan bulling a otros por falta de conocimiento o por falta de personalidad
• personas desmotivadas a pesar de ser buenas técnicamente
• alguien con baja auto-estima
• des motivación para al trabajo
• equipo rebelde
• equipo desmotivado
• equipo ubicado en zona confortable de la que no queire salir (en otras palabras: equipo sin coraje)
• equipo o persona sin los valores ágiles
• transparencia, 
• coraje, 
• respeto,
• comunicación, 
• simplicidad
• foco
• capacidad de dar retroalimentación
• alguien que no cumple los compromisos pero que se nota comprometido
• miembros de equipo aislados
• Product Owner al extremo perfeccionista
• equipo desmotivado
• rivalidad entre miembros del equipo
• alguien que aplasta a los otros con sus comentarios ya sean técnicos o no
• Producto Owner conflictivo
• team member conflictivo
• o que el del problema sea yo mismo, el Scrum Master (y como lo decíamos acompañados de cervecitas, yo sea un Scrum Monster)
• etcétera, etcétera, y muchos etcéteras.

Estos últimos requieren de una intervención más cuidadosa y cada caso es un mundo aparte, lo que funcione en una situación no significa que vaya a funcionar en una situación similar.

Muchas veces es suficiente con hablar con el/los implicado(s), otras veces es requerido una serie de acciones y toma de evidencias para saber como actuar.

Esta intervención y problemática está relacionada con nuestra forma de ser, y cuando se trabaje en remover el impedimiento ha de ser con bisturí, con claridad, con hechos (no suposiciones y juicios) de forma que logremos cambios a través de los pedidos y ofertas. 

A estos pedidos, ofertas y compromisos se les debe hacer seguimiento para identificar mejoras o detrimentos de las situaciones e identificar pasos a seguir.

Ser Scrum Master tiene su ciencia, cada vez lo concluyo más.

Para comenzar a adentrarse en este aspecto humano, les sugiero:

• Ver estos videos de Scrum detrás de Scrum: 
• Scrum detras de Scrum - Martin Alaimo
• Dojo (taller) scrum detras de scrum  - Martin Alaimo
• leer y poner en práctica el libro Más productivos de Martín Alaimo 
• Frases para entender, acompañar y hacer coach a equipo
• si encuentro y leo más autores los estaré compartiendo

Nota: 

Sé que no les solucioné los problemas, pero si los evidencié, y si algún SM (Scrum Master) solo estaba ocupado del proceso y de que solo tuvieran los insumos, creo que con este post, tiene un buen punto de partida para trabajar lo más delicado y valioso del proyecto: LAS PERSONAS Y SUS RELACIONES.

Saludos a todos

Productividad mejor que Velocidad.

-

Qué es mejor ir a 200 km/hora en la dirección equivocada, implicando que entre más avanzas más lejos estás.
o
Ir a 80 km/hora en la dirección de la visión - dirección correcta -.

-

• Productividad ( me lo recordaba Jorge Johnson @jorge_johnson) es dar valor de negocio.
• Velocidad es construir software, útil o no útil pero software al fin al cabo.

Bajo estas definiciones entonces:

1. Hacer mucho software pero no generarle valor al cliente
• mucha velocidad y poca productividad
• ejemplo:
• hacer funcionalidades que serán poco usadas y que corresponden al "nice to have" y que no están alineadas con la visión del producto.
2. Hacer poco software pero generarle valor al cliente. 
• poca velocidad pero alta productividad 
• ejemplos
• cuando estamos haciendo refactor que nos permitirá tener una mejor aplicación
• cuando estamos haciendo componentes complejos pero que requieren gran esfuerzo en su construcción.
3. Hacer mucho software y generar mucho valor
• mucha velocidad y alta productividad
• ejemplo:
• construyendo funcionalidades de valor para el cliente de complejidad normal.
4. Hacer poco software y poco valor
• poca velocidad y poca productividad
• ejemplo
• Construir un componente muy complejo que requiere mucho esfuerzo, que no será muy usado. - por lo general un capricho funcional de algún interesado con poder -, y que no se encuentra alineado con la visión del producto.

En síntesis, nuestro esfuerzo como Equipo o como Scrum Masters es guiar al Product Owner a que solicite las funcionalidades del producto que le proporcionen valor, sea que estas se hagan o no con velocidad, pues estamos bajo el principio de transparencia y sabemos que estaremos con nuestro equipo trabajando comprometidamente en el backlog priorizado, en el 20% de las características que dan el 80% de beneficio (ley de pareto para el agilismo).



Por lo tanto, siempre preguntemos:

• ¿es necesario?
• ¿le agrega valor al producto?
• ¿cuantos lo van a usar?
• ¿ese uso lo pueden hacer en una herramienta externa? (informes que perfectamente pueden manipular mejor en excel)
• y volver a preguntar ¿es realmente  necesario?
• ¿prefieres nuestro tiempo en esta funcionalidad a esta otra?
• ¿si se acabará el dinero preferirías esto o aquello?
• ¿prefieres esta validación supercruzada entre estos 8 campos o que entreguemos esta historia que te saca el total de ventas del día? (por ejemplo)

Nota: 
Aunque esta nota aplica para el agilismo, también es valida para el esquema tradicional.



--

Scrum: Cediendo el mando y control AL EQUIPO

Hace aproximadamente un año comenzamos a migrarnos a una forma de trabajo completamente diferente, llamada “Scrum”, ha sido un proceso lleno de ganancias, retrospectivas, mejoras y aprendizajes. Este framework ha implicado cambio un radical en nuestra forma habitual construir software y de relacionarnos como personas y trabajadores del conocimiento [2].

Son muchos los aspectos que cambian, y que pueden ser consultados en la guía de scrum en www.scrum.org, pero este post se centra en el principal aspecto en el que se centra el agilismo: “LAS PERSONAS” (El manifiesto ágil comienza con: PERSONAS E INTERACCIONES SOBRE PROCESOS Y HERRAMIENTAS, ver más en http://agilemanifesto.org/iso/es/), y dentro de esas personas el El Team Developer.

Dentro de Scrum tenemos varios roles interviniendo en la construcción del producto:

• Los stakeholders: cuyas expectativas y necesidades son priorizadas por el Product Owner
• El Product Owner : Encargado de lograr y transmitir la visión al equipo, decidir que se construye del producto, y del ROI del mismo.
• El Scrum Master: Encargado del proceso de scrum, remover impedimentos y realizar coach al equipo.
• Y El Team Developer (equipo de desarrollo): Encargado de autoorganizarse y construir el producto

En este camino de Scrum (el cual por no ser prescriptivo) deja definiciones abiertas donde uno se mueve con libertad, he observado que uno de los aspectos más complejos de comprender y asimilar es el equipos auto-organizados.

Digo complejo, pues estamos de un esquema  Mando y Control (en inglés Command & Control[1]) donde el Gerente de Proyecto es quien comanda la misión y el éxito o fracaso de ella dependerá de los lineamientos que dé, decidiendo:

• qué hacer
• cómo hacerlo
• quién debe hacerlo
• cuándo hacerlo

El éxito también dependerá del equipo, las herramientas, los stakeholders, etc., pero  en el ambiente de gerencia de proyectos y organizacional, es Vox Populi  que un buen gerente es factor determinante y principal para el éxito del mismo.

Ahora si pensamos en el nuevo esquema, en el que las responsabilidades de la gerencia de proyectos es fraccionada:

• El camino a seguir es dado por el Product Owner, definiendo el qué y el cuándo.
• El scrum master es un líder servicial que busca que se cumpla el proceso definido y se encarga de que el equipo sea cada vez mejor y tenga todas las herramientas e insumos para completar el trabajo comprometido removiendo los impedimentos.
• El equipo decide libremente (de lo ítemes de backlog priorizados para el sprint) con qué se compromete y cómo va realizarlo.

Bajo este esquema, queda el rol de la gerencia de proyectos inoperante y convirtiéndose en un reto profesional el hecho de pasar de Gerente de Proyectos (líder, amo y señor de la visión, del equipo, de la táctica y la estrategia) a Scrum Master (líder al servicio del equipo).

Y es por esto este post se centra en ceder el control, y el Gerente de Proyecto cede toda esa supremacía tan anhelada por algunos, a un ente con mayor poder: “AL EQUIPO”, pues este siendo un sistema complejo encuentra mejor la forma de autoregularse y controlarse de forma que va encontrando mejores caminos y formas para crecer como equipo y hacer crecer el producto.

Y hasta acá suena todo muy poético, pero es un proceso que toma esfuerzos tanto desde el punto de vista del gerente de proyecto que se transforma en Scrum Master (si así lo desea) como desde el equipo que antes eran personas que recibían órdenes y directrices a ser responsables del cómo y quién debe hacerlo, pasando de un “organismo subyugado” a un “organismo consciente de si mismo, estableciendo y encontrando sus propias reglas, en crecimiento, evolución y mejora” generando equipos para organizaciones 3.0.

A continuación enumeraré aspectos claves en esta transformación:

1. Ventajas:

• El compromiso con lo que se va adquirir durante el sprint lo adquiere el equipo y no otros externos a él
• En el planning el equipo escucha lo que se desea construir, realiza la estimación,  decide hasta donde es capaz de llegar y define la forma de construir.
• Durante la construcción el equipo decide qué construir, cómo construirlo y quien debe hacerlo. En ocasiones Scrum Master orienta al equipo para que estén siempre construyendo lo que tiene mayor prioridad y mayor riesgo, evitando desenfoque del equipo.
• Durante la ejecución del sprint el equipo tiene las herramientas (el tablero kanban, los burndown charts) que le permiten saber si lograrán o no el compromiso.
• En la reunión de review, el equipo realiza la entrega del producto construido al Product Owner y a los Interesados, recibiendo directamente la retroalimentación por el trabajo realizado.
• Igualmente, durante el review se reciben los honores por lograr el trabajo comprometido en el planning, o se pasa la pena de no lograrlo. (antes estos honores y penas eran del gerente de proyecto - y por la forma tradicional de construir software,  por lo general eran penas - ). La review también tiene el poder de realizar la motivación sobre el equipo, pues los aplausos le dará la razón en su forma de alcanzar la victoria y los fracasos le darán los elementos para mejorar en el próximo sprint (generalmente de 2 semanas) y lograr la victoria perdida en el vigente.
• En la retrospectiva guiados por el scrum master, el equipo encuentra como mejorar en Productividad, Calidad y Felicidad; identificando mejoras en su proceso de construcción, y en su forma de relacionarse como equipo, con el Scrum Master y el Product Owner.

1. Desventajas y riesgos

• Equipos que no se quieran comprometer y que elijan trabajar muy por debajo de su capacidad.
• Equipos que no estén dispuestos a aprender y a poner en prácticas las retrospectivas.
• Miembros de equipo que no se comprometan, pues a pesar de que estuvieron en el planning y junto con sus compañeros delimitaron el producto a construir durante la ejecución del sprint dejan a sus amigos "tirados" no realizando tareas con el profesionalismo requerido, es decir, inyectando bugs, trabajando a mucho menos capacidad de lo normal, etc.
• Mala comprensión de la autoorganización y autogestión, creyendo que esta característica no implica deberes, ni responsabilidades.
• Scrum Master aun con chip de gerente de proyectos, interesado en controlar al equipo y decirle exactamente qué, quién, cómo y cuándo hacer las tareas.
• Creer que esto ocurrirá por arte de magia con solo decir las palabras mágicas : “SCRUM : EQUIPOS AUTO-ORGANIZADOS”, falso, se requiere de mucho acompañamiento, coach y de personas receptivas y decididas a entender las reglas y compromisos que esto implica.

1. Beneficios

• Un compromiso alto sobre lo que se va a construir…
• Responsabilidad asignada a quien tiene el poder de lograr el resultado
• Un sistema complejo (el equipo) es dominado por reglas impuestas por ellos mismos y no bajo la autoridad y liderazgo del gerente de proyecto.
• El equipo no requiere de reuniones de seguimiento, pues el equipo con sus gráficas y radiadores de información saben en qué punto están y si van a lograr los objetivos.
• Como resultado de lo anterior, el equipo se "presiona" a si mismo (de forma natural) para lograr las metas trazadas conjuntamente.
• EL ÉXITO DE LO QUE SE VA A CONSTRUIR DURANTE EL SPRINT NO ES RESPONSABILIDAD DEL SCRUM MASTER (antes gerente de proyecto - e insisto, si es que quiso cambiar de rol -) SINO QUE ES ENTREGADA AL EQUIPO

Referencias:

[1] Field Manual 6-0, Mission Command: Command and Control of Army Forces, Headquarters United States Army, Department of the Army, Washington, DC, 2003.

[2] Cyment, Alan. El espíritu de Scrum,  El arte de amar los lunes. V0.2 - http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum

Seis (6) estrategias para lograr mayor velocidad de los equipos en Scrum

Hace unos días en Ceiba (empresa donde trabajo como Scrum Master)  filosofábamos en equipo la siguiente pregunta:

¿qué era necesario hacer para lograr mayor velocidad (puntos por sprint)?

Nota aclaratoria: no fue presión mía como Scrum Master hacia el equipo, pero si es cierto que yo lancé la inquietud (realizando la Inception :-) como en la película el Origen, de Nolan y Di Caprio)


La respuesta a esta inquietud ha llegado gradualmente, y pienso que es  uno de los interrogantes obligatorios que tiene que plantearse un Scrum Master y que debe plantearle al equipo.

Dentro de las responsabilidades del SM están:

• el seguimiento del proceso
• el coach al equipo
• y dentro de ese coach llevarlo a una productividad mayor (a un doble de productividad según Sutherland - padre de scrum-  [1] )

Hay que reconocer que Scrum nos ha permitido ser muchos más veloces y productivos debido a:

• Involucramiento y compromiso del dueño del producto, que permite resolver inquietudes rápido
• Visibilidad y resolución rápida de impedimentos
• Retrospectivas bien hechas, que nos llevan a la mejora continua
• Empoderamiento del equipo, de forma que este por si mismo se auto-organiza y encuentra la mejor forma de entregar el producto
• Los valores de coraje y compromiso, que han permitido querer ir más allá y poder enfocarnos mucho más en como ser mejores
• Atención a la excelencia técnica, que ha hecho que nuestra deuda técnica cada vez sea menor, lo cual mejora nuestra velocidad. "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad" [2] (principio del manifiesto ágil). (este punto lo retomaré más adelante)
• Teniendo el equipo motivado y feliz,  equipos motivados son más ágiles "Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo." [2] (principio del manifiesto ágil).

Pero luego de estar allí, es necesario plantearse ¿es posible ser mejores? a continuación entonces, enumero en orden de importancia (según mi criterio) las formas en las que considero y he encontrado que podemos ser más veloces:

1. Seguir el patrón Scrumming the Scrum 

En la conferencia de Jeff Sutherland | "Scrum: The Future of Work" [3], presenta este patrón de scrum como una de las formas de llegar "hiper-productividad" en los equipos

Patrón: Scrumming the Scrum [4]

Este patrón se basa en:

• Identificar y priorizar la(s) mejora(s) (kaizen) a realizarle al proceso de Scrum  en la Reunión de Retrospectiva. Recordemos en la retrospecttiva debemos enfocarnos en:
• cómo mejorar el proceso de elaboración del producto,  el cómo que Scrum no resuelve y deja en libertad a los equipos).
• cómo mejorar la calidad y el producto
• cómo mejorar la felicidad del equipo
• Enfocarse  en la(s) mejora(s)  más importante(s) y críticas. He leído por ahí que máximo 3 cosas muy importantes a mejorar (1, 3 ó 4 no recomiendo ningún número en especial - yo prefiero pocas cosas a muchas -  intenten una opción y concluyan - recordemos que lo que funciona en un equipo no tiene por que funcionar en otro)
• Ponga el Kaizen en el primer lugar del sprint backlog con criterios de aceptación cuantitativos.
• Revise la mejora Kaizen en el Sprint Review como si fuera otra historia.

Beneficios:

• terminar antes
• solicitar mas backlog para el sprint
• incrementar la métrica de "el clima de ayer" para el próximo planning.

2. Seguir el patrón de Interrupción 

Otro de los patrones expuestos en esta conferencia Jeff Sutherland | "Scrum: The Future of Work" [3] para llegar a la  "hiper-productividad", es el presentado a continuación:.

Este patrón es útil cuando el producto ya se encuentra en producción y se requiere atención inmediata a temas específicos.

El patrón se basa en:

• Luego del Kaizen determine una cantidad de puntos disponibles para tareas inmediatas que requiere el Product Owner.
• Si identifica que no se van a consumir úselos en más historias.

Beneficios:

• Equipo dispuesto para atender urgencias con un tiempo asignado para ello, sin que les quite velocidad y compromiso..
• Product Owner contento con su equipo, debido a que pueden atender temas urgentes.

3. Hacer Sprints más cortos 

Esta recomendación nos la dió Ricardo Colusso (@rcolusso) de kleer.la en donde nos sugería realizar sprints de 1 semana.


Beneficios:

• Poder fallar más rápido, debido a ciclos de retroalimentación más cortos.
• Despliegue de producto más rápido

Requerimientos

• Más compromiso del Product Owner
• Más historias de usuario refinadas y cumpliendo el criterio de Ready.
• Historias de usuario más pequeñas

Nota: No he intentado esta sugerencia

4. Tener un backlog refinado y con el criterio de ready

Otra de las recomendación que nos la daba Ricardo Colusso (@rcolusso) de kleer.la y que también remarcaba Sutherland era la necesidad de tener un backlog refinado y con el criterio de ready, esto indiscutiblemente proporciona una visión clara hacia donde va el producto.




Beneficios:

• Visión de producto
• equipo enfocado

Requerimientos

• Más compromiso del Product Owner
• Realizar la reunión de refinamiento al la mitad del sprint
• tener al menos 2 sprints más con historias de usuario cumpliendo el criterio de Ready.

5. Resolviendo la deuda técnica

La deuda técnica es uno de los elementos que termina frenando la velocidad de los equipos y va en contra de la atención a la excelencia técnica (que es uno de los principios del manifiesto ágil).  Recomiendo el post de Henrik Kniberg - The Solution to Technical Debt . Aunque pienso que es un tema de estudio y de compromiso con el cliente, producto, product owner y mismo equipo.

Presento dos gráficas de este post, que muestran la necesidad de detener la deuda técnica y comenzar a "pagarla" antes de que la velocidad de nuestro equipo se vea frenada radicalmente.

Efecto de programar con código apestoso (crappy code) (en español no encuentro una palabra polite para crappy) [4] 

Efecto de trabajar con código limpio (clean code) [4]

Beneficios:

• Velocidad
• entendimiento del código
• excelencia técnica

Requerimientos

• Equipo con coraje y conocimiento técnico
• Equipo y Scrum Master que sepan vender la idea de resolver la deuda técnica el Product Owner.
• Hacer la deuda técnica como parte del kaizen y darle prioridad e  importancia en el proyecto.

Recomendación

• Tener lineamientos técnicos que se cumplan desde el inicio del proyecto.

6. Teniendo una holgura (Slack) cada cierto tiempo

Por último, la holgura o Slack es un tiempo intencional dejado entre sprints para cubrir cualquiera de las siguientes tareas:

• Innovación técnica
• transferencia de conocimiento entre equipos
• realizar ajustes pendientes de soporte y mantenimiento

Algunas de las formas de implementar el Slack son:

• dejar un tiempo pequeño entre sprints de 1 a 2 días 
• 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
• El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
• Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
• etc..

Recomiendo visitar este post: Cutting Slack in Scrum

En conclusión

Si seguimos estas directrices, no dudo que podremos mostrar gráficas de velocidad similares a la que presenta Jeff Sutherland

Incremento de velocidad aplicando los patrones 1 y 2 [4]

 Y pronto estaremos escribiendo artículos y recomendaciones de como ser mejores en Scrum.

Consideración importante respecto a la puntación de historias

Cuando se mejore la velocidad y encontremos qué cosas que antes nos tomaban más tiempo, pero ahora luego de la mejora nos  toman mucho menos,  debemos de tener una consideración importante respecto a la puntuación:

• si tus puntos fueron diseñados poniendo un pivote de  funcionalidad conocido (ejemplo una pantalla con un formulario de 8 campos), no hay lio, ese pivote y las demás funcionalidades las hará  el equipo más rápido y la puntuación seguirá siendo la misma.
• Si tu pivote esta basado en días felices/productivos (ver [7]) (yo uso esa técnica), considera que si haces algo más rápido debes puntuarlo de la misma forma que usabas al principo del proyecto, como si no tuvieras hiper-velocidad o hiper-productividad, ejemplo:
• si una pantalla tipo a= te tomaba  2 días felices (2 puntos).. .pero luego de la mejora te toma un dia feliz (un punto) síguela puntuando como antes, pues esa es la referencia inicial con la que se dimensionó el proyecto y permitirá visualizar la velocidad y la mejora.

Hasta ahora he encontrado estas 6 formas, talvez hayan más o sean realmente menos, si alguien conoce, aprende, o ensaya más y las puede/quiere compartir bienvenidas sean, es importante todos aprender de todos.


Queda abierto el espacio para sus comentarios y experiencias.


Saludos

Jorge Abad


---
Referencias:

• [1] Video - Jeff Sutherland | "Scrum: The Future of Work" - referencia a la productividad del equipo  https://www.youtube.com/watch?feature=player_detailpage&v=RYIPSPWVc8o&t=1457 
• [2] Principios del manifiesto ágil .http://agilemanifesto.org/iso/es/principles.html
• [3] Video - Jeff Sutherland | "Scrum: The Future of Work" https://www.youtube.com/watch?feature=player_embedded&v=RYIPSPWVc8o
• [4] Diapositivas -Jeff Sutherland | "Scrum: The Future of Work" http://scrumlab.scruminc.com/gallery/album/104-scrum-the-future-of-work/
• [5] Henrik Kniberg - The Solution to Technical Debt  http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt
• [6] Cutting Slack in Scrum
• [7] Scrum y XP desde las trincheras. Por Henrik Kniberg. http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

Notas sobre: Lo mío no es el desarrollo, lo mío es la gerencia

Hace unos días en Ceiba (empresa donde trabajo como Scrum Master), nuestro gerente de producción nos compartió una interesante conferencia del Ingeniero Jorge Aramburo CEO de PSL, empresa líder en ingeniería de software en Colombia.

En esta conferencia, Jorge comparte sus opiniones y conclusiones sobre las malas prácticas de gerentes de proyectos.

Estas son algunas de las frases/notas más relevantes de la presentación:

• Un grupo de personas no se va a desempeñar mejor que la calidad de gerencia que tienen

---

• La pobreza en la gerencia de proyectos se debe a:
• La poca claridad por parte de la alta dirección de las compañías acerca del papel de TI en la estrategia de las organizaciones
• La poca comprensión que tenemos del rol que debe cumplir un gerente, lo que nos conduce a la asignación de personas equivocadas para el rol.
• El esfuerzo constante que requiere llegar a ser un buen gerente (esfuerzo que casi nadie esta dispuesta a hacer)
• "Llegar a ser gerente es un viaje... un viaje que la mayoría no completa. Las personas no alcanzan las habilidades, el conocimiento, los valores, perspectiva, juicio y la comppetencia emocional para ser buenos gerentes"[1]
• El papel que juega el entorno en una buena gerencia

---

• Un proyecto es exitoso en la medida que cumple o excede las expectativas de todos los interesados.

---

• Un buen indicador de calidad en gerencia de proyectos es : " número y tipo de intervenciones (normalmente correctivas), exitosas o no que debe hacer una persona de mayor rango en la organización para resolver un asunto que debió ser resuelto por el gerente de proyectos."

---

• Las intervenciones por rangos altos son normales cuando está en entrenamiento. Si el gerente las solicita es un buen síntoma (quiere aprender).

---

• Las personas exitosas tienen un denominador común:
• No son superficiales
• Tienen conocimiento superior al promedio acerca de los temas relacionados con su trabajo.(competencias metodológicas).
• Aplican con éxito el conocimiento (competencias técnicas).
• Constantemente reflexionan, estudian, leen, preguntan, cuestionan …. mejoran, tanto sus competencias metodológicas como técnicas
•  Adquieren el conocimiento de dominio necesario cuando enfrentan un nuevo proyecto. No hay que empujarlos.

---

• La posibilidad de tener éxito está directamente relacionada con las competencias y la complejidad de la tarea. Algunas personas tienen éxito en emprendimientos sencillos, pero no pueden manejar situaciones difíciles.

---

• Realmente no es un secreto. Lo que si resulta extraño  es que la mayoría de gerentes de proyectos relacionados con tecnología (especialmente si involucra software) no tienen el conocimiento necesario para ejercer el rol con éxito. Por varias razones:
• Las especializaciones, maestrías y certificaciones ofrecidas, generalmente son de carácter general, y no abordan las particularidades de los proyectos de TI, especialmente de software. La gerencia de este tipo de proyectos requiere una base teórica específica.
• Muchos gerentes de proyecto no han tenido la experiencia de “vivir” un proyecto como practicantes. Aunque no todo buen practicante se convierte en un buen gerente (no necesariamente tiene las competencias), los gerentes requieren un conocimiento profundo sobre el asunto que administran. Un examen lo pasa cualquiera que haga el esfuerzo. La vivencia, en cambio, no puede remplazarse
•  Pasar de la teoría ala práctica toma años. Quien lo logra,además de tener las competencias para ello, permanentemente pregunta, reflexiona, estudia, compara, observa,tratade explicarlasdiferencias entre teoría y práctica y, sobretodo…. Persiste.
• No es fácil encontrar personas apasionadas, individuos que deseen agregar valor que comprendan al cliente  que deseen agregar valor,que comprendan al cliente,
• conozcan su negocio y necesidades. 
• Es muy diferente un individuo que “sabe hacer su trabajo” a alguien que “sabe que hacer con su trabajo” 

---

• Los triunfadores son profundos porque están orientados al resultado, y saben que si dejan de aprender no lograrán nada importante. Tienen pasión (motivación intrínseca) por lo que hacen,  tienen claros sus objetivos y desean hacer una diferencia.

---

• “El deseo de saber es connatural alas personas buenas” Leonardo Da vinci

• Competencias buscadas en un gerente de proyecto
• Cardinales
• Proactividad
• Análisis de problemas
• Energía
• Decisión
• Orientación al logro
• Tenacidad
• Impacto
• Capacidad de innovación, adaptación
• Atención al detalle
• Específicas:
• Conocimiento profundo de la ingeniería (teórico y práctico )

---

Errores en la elección gerentes:

• Alguien muy organizado: 
• No toda persona organizada es candidato a ser gerente
• Un mal practicante de ingeniería.
•  Solo designe individuos destacados
• Un buen practicante individual será un buen gerente. 
• A lo mejor resulta pésimo

---

La buena gerencia depende de la suma de los siguientes factores:

• Conocimiento
• COMPETENCIAS METODOLÓGICAS
• Prácticas
• COMPETENCIAS TÉCNICAS
• Comportamiento
• COMPETENCIAS SOCIALES E INDIVIDUALES

----

“A la gente la contratan por conocimiento, pero la despiden por comportamiento ” Peter Drucker

---

Una persona competente es una mezcla entre Saber, Saber-Hacer y Saber-Ser, pero es este último el que primordialmente determina el éxito de las personas

----

“[Competencia] Es una característica propia de un individuo que está directamente relacionada a un 

estándar de efectividad y/o a un desempeño superior en  estándar de efectividad y/o a un desempeño superior en un trabajo o situación. Son comportamientos observables en la realidad cotidiana del trabajo y en situaciones de evaluación; son un rasgo de unión entre las características individuales y las cualidades 

requeridas para el desempeño en una organización [Martha Alicia Alles]”

----

LA ESENCIA

La esencia de la gerencia es ser capaz de influenciar positivamente a los demás, de crear un impacto en las personas para que tengan un desempeño extraordinario.

El gerente es un instrumento para que el grupo tenga éxito

La única medida de la gerencia es el éxito. No existe otra.

En Colombia y Latinoamérica se ha confundido la gerencia con el tracking de tareas. Los “tracker” 

compilan las tareas y se les asigna la responsabilidad de divulgarlas, pero eso no es gerencia!

----

Paradojas de la gerencia

• Los gerentes
• Son responsables del trabajo
• pero
•  trabajan a través de otros (no hacen el trabajo)
• --
• Deben enfocarse en el trabajo
• pero
•  para hacerlo deben enfocarse en las  personas
• --
• Deben desarrollar las personas
• … y al mismo tiempo
•  evaluarlas
• --
• Son responsables del trabajo
• pero
• trabajan a través de otros (no hacen el trabajo)
• --
• Son responsables del trabajo
• pero
•  trabajan a través de otros (no hacen el trabajo)
• --
• Deben manejar el grupo
• pero
• … y el contexto en el cual se mueve este
• --
• Deben manejar el grupo
• pero
• …  sin perder de vista los individuos
• --
• Debe enfocarse en el hoy
•  y en el mañana
• --
• Debe lograr que el grupo sea eficiente  …
• y a la vez innovador
• --
• En ocasiones deben hacer daño 
• para hacer el bien

Las paradojas nunca se resuelven.Se manejan. Por esta razón, un gerente sin capacidad de juicio, criterio, competencia emocional, empatía, liderazgo, valores y principios jamás tendrá éxito 

 ---

El carácter del gerente

En el carácter de las personas reside su sistema de valores. El carácter se forma como una acumulación de valores.

• ¿Tiene la genuina intención de hacer las cosas correctas?
• ¿Valora el trabajo de las personas?
• ¿Sabe oír?
• ¿Reconoce su propios errores y actúa en consecuencia?
• ¿Valora el trabajo de las personas?
• ¿Trabaja duro?
• ¿Practica lo que dice?
• ¿Le preocupan los demás?
• ¿Reconoce cuando no sabe algo?
• ¿Le preocupan los demás?
• ¿Los valora como personas?
• ¿Es empático?
• ¿Acepta las diferencias?
• ¿Es estable emocionalmente?
• ¿Es tenaz y resistente aún en los momento difíciles?
• ¿Es justo?

Las personas aprenden a hacer lo que ven, no lo que se les dice 

-----

Reflexión

El trabajo de gerencia consiste en un montón de pequeños encuentros la mayoría no planeados a lo largo  pequeños encuentros,la mayoría no planeados,a lo largo del día, y todos los días. Cada encuentro es una posibilidad de influenciar positivamente a otros.

---

Reflexión

Alguien que es buena gente, pero que el proyecto lo tiene mal, no sirve como gerente de proyecto

Un buen gerente no es aquel quien le gusta a todos. Es el individuo en el que todos confían. Y la diferencia es muy grande!

----------

Reflexión: UN BUEN GERENTE

No olvide que los proyectos de TI involucran un ambiente humano muy complejo y, como decía Peter Drucker, detrás de cada trabajador que contrata viene pegado un corazón y una mente diferentes.

----------

“La mejor manera de predecir el futuro es crearlo”

Peter Drucker

-----

Más notas en:

http://neobernal.tumblr.com/post/61475093524/lo-mio-no-es-el-desarrollo-lo-mio-es-la-gerencia

---------

Referencias:

• [1] Linda Hill y Kent Lineback. Being the boss.

Gráficas Ágil vs Tradicional

Hola a todos


A continuación presento unas gráficas esquemáticas que muestran de manera simple y comparativa como se perciben los proyectos desde el Agilismo (scrum, kanban, xp) y  desde el enfoque tradicional (llámese cascada o RUP).

Si existen, o tienen más gráficas que agregan valor a esta comparación con gusto las publicaré con su respectiva referencia.

Nota: En los proyectos ágiles se sale puede salir a producción desde el primer sprint.

Nota: La moral/motivación del equipo de trabajo en el enfoque tradicional es fluctuante de acuerdo al desgaste cliente-proveedor.

Nota: El heroísmo no es común en proyectos ágiles, pues los equipos se comprometen a lo que son capaz de cumplir sin sobre-esfuerzos. En equipos ágiles lo que existe es el compromiso.

Nota: Las herramientas de seguimiento del proyecto de scrum nos dan la visiblidad suficiente en el proyecto. Bajo el enfoque tradicional (por lo general el seguimiento se hace son ms project) se cae en el problema de un avance satisfactorio hasta el 90% de ahí pasan los días y se sube al 91% y luego muchos muchos días al 95%, y al final por fn se llega al 100%.

.

Cualquier retroalimentación con gusto será recibida.

Referencias.

• [1] Patil, P S; Patil, S B and Rao, Srikantha. Agile Principles as A Leadership Value System in The .Software Development: Are We Ready to be Unleashed?
• Las gráficas 8 y 9 las he visto en muchas otras fuentes, mas no tengo las referencias (si tienen este dato lo agradecería)
• El resto de gráficas (4, 5, 6, 7, 10, 11, 12, 13) son de autoría propia. 

Frases para entender, acompañar y hacer coach a equipos (1)

Mi amiga y compañera de trabajo Verónica Vera @verovera78 es un tesoro de conocimiento, consejos y experiencia en el tema de coach de equipos ágiles, hace unos días me enviaba un correo donde me contaba que ella no sabía mucho de deportes pero que leía como los directores técnicos y los entrenadores lideran sus equipos. Me indicaba además que leía mucho sobre Pep Guardiola.

Al igual que ella, yo no tengo el chip para los deportes pero si quiero aprender de ella y de estos DT y entrenadores, siguiendo ese espíritu recopilaré en este post y bajo la etiqueta frases coach a equipos, lo que me vaya encontrando para guiar mi equipo y ser un mejor Scrum Master.

Cada cual con las frases reflexione y aplique a su contexto:




"En los primeros partidos necesitamos ante todo resultados para darle confianza al equipo pero también necesitamos tiempo" Guardiola (http://www.elespectador.com/deportes/futbolinternacional/guardiola-debuto-victoria-bundesliga-articulo-439041)

-

"Antes de empezar a competir le tenes de ganar al Ego más grande de TODOS que es el tuyo" D.T Pekerman (https://www.youtube.com/watch?feature=player_embedded&v=6KqGbdcIqkc)

-"tenes que entender que hay otros caminos, que si vas más rápido que el resto, es igual que si fueras el más lento de todos" D.T Pekerman (https://www.youtube.com/watch?feature=player_embedded&v=6KqGbdcIqkc)

-

"para ser escuchado primero tenes que haber oido" D.T Pekerman (https://www.youtube.com/watch?feature=player_embedded&v=6KqGbdcIqkc)


-
"cuando se juega en equipo, se celebra en equipo" D.T Pekerman (https://www.youtube.com/watch?feature=player_embedded&v=6KqGbdcIqkc)


-

“Tienen que tomar decisiones…hagan lo que les dé la gana, pero háganlo con decisión” Josep (Pep) Guardiola (http://www.finanzaspersonales.com.co/trabajo-y-educacion/articulo/frases-para-triunfar-negocios/50735)

-

“No hay que intentar cambiar a los jugadores. Cada quién es como es…hay que buscar el botón que los enchufa y saber que ese botón es diferente en cada uno” Josep (Pep) Guardiola  (http://www.finanzaspersonales.com.co/trabajo-y-educacion/articulo/frases-para-triunfar-negocios/50735)

-

• "Si perdemos, continuaremos siendo el mejor equipo del mundo. Si ganamos, seremos eternos"
• "El secreto de un buen equipo está en el orden, que todos sepan lo que hay que hacer"
• "Lo que te hace crecer es la derrota, el error"
• "No hay nada más peligroso que no arriesgarse"
• "Perdonaré que no acierten, pero no que no se esfuercen"
• "Sólo se nos recordará si ganamos, si no ganamos, todo esto quedará como una anécdota"
• "La gran suerte que uno puede tener es hacer lo que le gusta. Dar con eso es la esencia de todo"
• "La herramienta más educativa que yo he tenido ha sido a través del deporte. Allí he aprendido a aceptar la derrota, que otro es mejor, a levantarme después de no haber hecho bien las cosas, esforzarme para hacerlo mejor..."
• "Yo no he encontrado aun a un futbolista, a un deportista de alto nivel, que no le guste aquello que hace"
• "Tenemos que ser audaces, salir al campo y hacer las cosas, no sentarnos y esperar a que suceda. Tenemos que demostrar lo que podemos hacer y que merecemos ganar el título. Tenemos que ser valientes y salir a jugar"
• "El talento depende de la inspiración, pero el esfuerzo depende de cada uno"
• "Mi único mérito es amar mi profesión"
• "No podemos mirarnos siempre en el espejo y decir lo buenos que somos. Cuando las cosas van bien es cuando hay que estar más atentos. El miedo a perder es la razón fundamental para competir bien"
• "¿Yo gané cuatro clásicos como entrenador? No, nosotros los ganamos"
• "Más allá de la educación que me han dado mis padres, que ha sido muy buena, el deporte también me ha educado. Lo que me ha formado como persona es el deporte. He aprendido a ganar y a celebrarlo con moderación, y también he aprendido la dureza de la derrota"
• "El secreto de este equipo son los jugadores. Les hago correr y que jueguen todos. Son muy buenos. Mucho trabajo. Cuando no corren les denuncio y como no les gusta, corren"
• "No pido nada especial a los jugadores. Sólo que hagan lo que saben y sean atrevidos. Sin atrevimiento, no se sacan adelante los partidos importantes"
• "Hay muchas maneras de plantear los partidos, pero no he conocido nunca a un equipo que no vaya a ganar"

 Josep (Pep) Guardiola 

Fuente: (http://www.frasecelebre.net/Frases_De_Pep_Guardiola.html)

-


Este post sigue en construcción... vienen más frases...