Mostrando las entradas con la etiqueta AUTOORGANIZACION. Mostrar todas las entradas
Mostrando las entradas con la etiqueta AUTOORGANIZACION. Mostrar todas las entradas

lunes, marzo 15, 2021

Video: Entrevista con Germán Ortíz (CEO) - Sobre los OKR, experiencia, retos y resultados

Entrevista con Germán Ortiz es el CEO (Líder) de Ingeniería Apropiada, sobre cual han sido los experiencias, retos y resultados de usar OKR durante los últimos dos años en la gestión de la organización.

Ingeniería Apropiada http://iapropiada.com/​ , una empresa dedicada a crear soluciones de hardware y software para estaciones de servicio de gasolina y a realizar innovación en el campo de ingeniería electrónica, cuenta con más de 50 colaboradores y presta servicio en todo el territorio colombiano.



lunes, noviembre 11, 2019

Cómo Promover la Autoorganización Empleando OKR

Imagen tomada de (2)

Hola a todos

Este es uno de esos post que tenía en mi deuda de publicación, pues llevo aproximadamente 2 años trabajando con OKR (1) pero no había sacado el tiempo para compartir sobre este comportamiento que he observado en las empresas, equipos y áreas al implantar esta técnica de alineación organizacional basado en objetivos y resultados.

Los OKR al trabajarlos organizacionalmente desde el CEO e ir propagándolos de forma progresiva sobre todas las áreas, portafolios, porgramas y equipos, no solo un generan una fuerte alineación estratégica, sino que logran que los equipos y áreas estén retados y animados con tener una meta común o diferentes metas que logran que como organización se generen resultados coordinados.

Tomada de (3)


Partiendo de la base de que un equipo es un grupo de personas con un objetivo común, y al este objetivo (OKR) convertirse en el reto trimestral, del cual ellos pueden monitorear y ser responsables de su progreso, genera el compromiso y el marco de decisión para avanzar en la dirección asiganda o propuesta por ellos mismos para área, portafolio, programa o equipo.


Para garantizar esa alineación y autoorganización recomiendo:
  1. Los OKR de cada equipo deben ser públicos
  2. Se debe fomentar el tener gráficas de progreso, tipo burnup o burndown que sean actualizadas cada dos semanas o máximo un mes
  3. El equipo debe ser responsable de actualizar constantemente estas gráficas o delegar en alguien su actualización
  4. El líder coordinador de los diferentes equipos o áreas debe promover la actualización de las gráficas de los OKR y realizar reuniones de mejora continua y remoción de impedimentos con miras a lograr el objetivo
  5. En la medida que los equipos van haciéndose responsables de los OKR pueden autoasignárselos con la colaboración o validación del equipo de management.
  6. Es importante que los equipos o áreas se coordinen con otros de manera que "garanticen" la colaboración coordinada en objetivos comunes o que los relacionen.
Bajo este esquema:

  • Los líderes se liberan de la microgestión y de la operatividad
  • Los equipos y áreas tienen un marco para toma de decisiones, por lo que no están preguntando constantemente si algo debe o no realizarse
  • la organización deja de percibirse tanto como una construcción piramidal y en caos, sino se percibe como un conjunto de áreas y de equipos que colaboran con los demás para lograr grandes resultados
Hasta acá este compartir

Saludos ágiles
Jorge Abad



Notas, Comentarios, Aclaraciones y Referencias

martes, noviembre 01, 2016

Mantener el foco: Un pensamiento sobre equipos maduros y autogestionados.




Hola a todos

Dentro de la actividad de acompañamiento a equipos y Scrum Masters (SM), me he encontrado algunas veces SMs  que se sienten bastante orgullosos del nivel de autogestión de su equipo, tanto, que no requieren gestión de parte de ellos, pues el equipo es tan, pero tan maduro que ellos mismos remueven sus propios impedimentos y los SM no tiene que hacer nada, en estos escenarios lo que generalmente contesto es algo similar a lo siguiente:

Me encanta la autogestión y la proactividad de los equipos maduros, uno ve a los miembros del equipo preguntarse cosas y hacerse cargo de temas e impedimentos, y eso esta bien, pero prefiero que los equipos se enfoquen en lo que generan valor y los temas externos e impedimentos que requieren de tiempo e insistencia se dejen al Scrum Master.

Por ejemplo, si algo requiere del apoyo de un área externa, pues está bien que el miembro del equipo haga uno o dos intentos por contactarla, pero en vista que no se logra, le realice un pedido al SM del siguiente tipo: "oye he intentado comunicarme con x para lograr tal cosa para el proyecto, ayúdame por favor, pues esto noto que va a requerir de mucho tiempo y debo seguir con otras tareas".

En Scrum cada rol tiene su foco y su forma de generar valor, y es importante tener esto presente aun cuando el equipo se encuentre en importantes estados de madurez.


Hasta acá esta corta reflexión, ¿qué piensas de esto?¿estás de acuerdo?

Bienvenido el feedback y la reflexión.

Saludos ágiles

Jorge Abad

Referencias, Aclaraciones, Notas y Comentarios


  1. Una buena referencia: El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo





viernes, octubre 21, 2016

Cumplimiento de Promesas y Ofertas como Generadores de Confianza y Tejido en los Equipos



Diagrama basado en el libro de Ontología del Lenguaje de Rafael Echeverría

Hola a todos

les comparto las reflexiones asociadas a este diagrama que me fue explicado por mi amigo Wbeimar Vásquez:

  • Hacia el interior del equipo
    • El cumplimiento de ofertas y promesas entre los miembros del equipo  produce CONFIANZA
    • La CONFIANZA logra tejido social y relaciones fuertes al interior del equipo y capacidad para asumir compromisos y realizarceles pedidos que serán cumplidos
  • Hacia el exterior del equipo
    • El cumplimiento de ofertas y promesas del equipo produce CONFIANZA en el equipo.
    • La CONFIANZA en el equipo logra tejido social y relaciones fuertes con el equipo y capacidad para asumir y asignarles pedidos retos, compromisos.

En el sentido negativo sería:
  • Hacia el interior del equipo
    • El incumplimiento de ofertas y promesas entre los miembros del equipo  produce DESCONFIANZA
    • La DESCONFIANZA deteriora tejido social, debilita y destruye relaciones al interior del equipo y genera incapacidad para asumir compromisos y pedidos
  • Hacia el exterior del equipo
    • El incumplimiento de ofertas y promesas del equipo produce DESCONFIANZA en el equipo.
    • La DESCONFIANZA en el equipo deteriora tejido social, debilita y destruye las relaciones con el equipo y se duda en su capacidad de asumir compromisos, asignarle retos y realizarceles pedidos.
Hasta acá esta pequeña reflexión


Saludos Ágiles
Jorge Abad


miércoles, octubre 12, 2016

martes, septiembre 27, 2016

¿Que significa autoorganización en Scrum?

La autoorganización en Scrum, significa que el equipo decide la mejor forma de construir el Sprint Backlog durante cada sprint, de resto los otros contextos siguen respetándose y aplicando respectivamente.





domingo, noviembre 22, 2015

Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado





"Un gran poder conlleva una gran responsabilidad", le decía el tío Ben a Spiderman, y la verdad, es de los primeros mensajes que se debe dar a un equipo cuando se les habla de autooganización

Muchos team members (miembros de equipo en Scrum) malinterpretan el término y lo consideran una declaración de anarquía que implica que ya no deben cumplir su contrato laboral, con expresiones como:




  • "Como soy autogestionado no tengo que avisar a nadie a que horas entro o salgo de trabajar", considerando que tienen una jornada laboral contratada de 8 ó 9 horas (según el contrato laboral (¡¡¡PLOP!!! - caso real -)
  • "Trabajaré haciendo lo que mejor pueda, aunque pueda dar más no lo voy a hacer"
  • "Como soy autogestionado, puedo dedicar todo el tiempo que desee a facebook o whatsapp"
  • "Salgo a hacer una vuelta y no tengo por que avisarle a nadie"
  • "Aunque todos llegan a las 8 am para el daily, la verdad  a mi eso no me aporta llegaré todos los días a las 9 am y no estaré en el daily por qué eso no me aporta" (¡¡¡RE_PLOP!!! - caso real -)
  • "Ya hice mi parte y la pasé al equipo de Quality Assurance"
  • Cuando salgo antes del horario de oficina sin importarme el compromiso del sprint por que soy "autogestionado"
  • Cuando inflo las estimaciones en el planning para trabajar con "muy buena holgura" 
  • etc.[1]


Mike Cohn (@mikewcohn) argumenta (clic aquí)
  • Autogestión no significa (clic aquí)
    • El equipo decide que objetivo alcanzar
    • o incluso quien es parte del equipo
  • Autogestión es:
    • acerca como el equipo determina como responder al ambiente (a los objetivos planteados)
    • y los líderes y gerentes influencian el ambiente
La autogestión es mas orientada a ser capaces de gestionar el trabajo en progreso y monitorear el progreso, y en un nivel superior cuando el equipo es autoorganizado (cuando el equipo es más maduro) ser capaces de diseñar el equipo y su contexto, como lo muestra la siguiente imagen:
tomada de[2]: 

Entre tantas cosas he descubierto que un equipo es autogestionado cuando

  • Son dueños del sprint backlog durante el sprint.
  • Deciden cual es la mejor estrategia para consumir el sprint backlog durante el sprint.
  • Honran los compromisos y la palabra dada en el planning  y utilizan el timebox del sprint lo más productivo posible, y en caso de que se termine el sprint backlog pedir al PO más ítemes
  • Si me comprometí con mi equipo a hacer una cantidad de puntos, a no dejar tirado a mi equipo con el compromiso
  • Dan visibilidad de los impedimentos
  • Ponen todo el empeño para que en la jornada laboral se cumpla el compromiso y en caso de observar que no se va a cumplir dar visibilidad de las razones que ocasionaron que no se cumpliera
  • Gestionan el progreso durante el sprint tanto en el kanban, burdown chart o cualquier herramienta de gestión y/o gestión visual
  • Sus team members cumplen con el contrato laboral (la verdad es lo mínimo, pero hay personas que es necesario explicárselo)

Y es allí donde el papel del Scrum Master toma importancia pues guía al equipo y a los respectivos team members a entender el concepto, a hacerles entender la responsabilidad que tienen y el poder que tienen en sus manos. De manera  que están cambiando el micro-seguimiento o RC [3], por la libertad de dar visibilidad del progreso y de potencializar la interacción con sus compañeros generando verdadero trabajo de equipo.

Yo creo en el agilismo, lo he visto funcionar, pero siempre que comienzo con un equipo scrum es de los primeros mensajes que doy, pues libertad no significa libertinaje, y agilismo no significa que no te enfoques responsable y maduramente en cumplir los compromisos que adquieres al principio de cada ciclo o sprint.


Termino como empecé, parafraseando un poco

"Team Member ser autogestionado es un gran poder, y un gran poder conlleva una gran responsabilidad"

Saludos ágiles

Jorge Abad



Referencias 
  1. Hay algunos pensamientos extractados en el hashtag de twitter #LesaAgilidad (sería genial que aportaras algunos que consideres)
  2. http://www.applitude.se/2011/05/self-organizing-teams-the-most-debated-agile-principle/
  3. RC: "Respiración en el Cuello" del gerente de proyecto, que por ejemplo pregunta cada hora, ¿cómo vas?



lunes, noviembre 16, 2015

Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización


Desde hace un tiempo vengo profundizando en cómo lograr la autoorganización en los equipos,  este tema me apasiona entenderlo e intriga de forma insistente a quienes pasan de la gestión tradicional (comando - control) a la agilidad, como lograr la autoorganización (la confianza, la inspección y adaptación). He escrito varios post con este tema de trasfondo:
  • Ejecutando proyectos con equipos autogestionados - clic aquí
  • ¿Y por qué dudamos de la auto-organización de los equipos? - clic aquí
  • Como Jugando Fútbol - Un Símil con Scrum - clic aquí
  • Cualquiera puede ser ágil / Cualquier equipo puede ser ágil - clic aquí
  • Más en el label Autoorganización- clic aquí

Y lo que quiero compartir hoy es, como un Scrum Master lleva al equipo a la autoorganización (algo comencé en este post - Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos -) pues es allí donde toma valor la presencia de un Scrum Master como parte del equipo.

Coincido plenamente en el modelo propuesto Ángel Medinilla  @angel_m, para los pasos o edades que vive un Scrum Master, en el cual se pasa de "The Scrum Guy" hasta "Scrum Sensei"


Pero, aunque se alcance el estado de "The True Scrum Master" o "Scrum Sensei", es necesario considerar el liderazgo situacional (propuesto por Blanchard) cada que se inicia un nuevo team de Scrum.


Ese liderazgo situacional (o estilo de acompañar a un equipo Scrum por parte del Scrum Master) debe ser según el estado de madurez del equipo





*Etapas del equipo vs Tipo de Scrum Master Requerido (elaboración propia)
Etapa del equipo (Tuckman)
Tipo de Scrum Master Requerido

Scrum Dude / Scrum Guy
1. Formación ( Forming)
Scrum Mom
2. Conflicto (Storming)
True Scrum Master
3. Normalización (Norming),
True Scrum Master
4. Desempeño (Performing),
Scrum Sensei / True Scrum Master
5. Separación (Adjourning),
Scrum Sensei / True Scrum Master


Y ese estilo de acompañamiento que lo lleva a la autoorganización lo veo muy similar a Enseñar a Montar en Bicicleta (wow me tomo mucha argumentación llegar hasta acá, pero sentí que debía hacerlo .. continuemos) pues:

  • al principio tu debes guiar, dirigir, inspirar, dar instrucciones precisas para que el equipo vaya aprendiendo scrum (y el niño comience a montar en bicicleta) Acá es típico que:
    • se tiene que insistir en lo importante de los dailys y como hacerlos bien -clic aqui-
    • no falta quien diga: "soy autoorganizado entro a las 10 y me voy a las 2 ¡¡PLOP!! - prometo un post de esto - " y es necesario hablarle de compromiso, disciplina, confianza, madurez, de que la autoorganización se entiende como la capacidad del equipo de resolver independientemente su compromiso de sprint backlog sin faltar a sus compromisos laborales.
    • Timebox de las reuniones, etc.
  • luego comienzas a soltar poco a poco y es hasta probable que el equipo se caiga, aprenda y tropiece pero sigues soportándolo corriendo detrás de él agarrando el sillín/silla algunas veces.
    • Fallen experimentos
    • Propuestas de retrospectivas funcionen y otras no
  • y luego lo "dejas solo" sin dejar de acompañarlo, dándole instrucciones lejanas de cuidado, o advertencia, u otras muchas animándolo.
    • Tal vez, visitas el kanban y preguntas como van con la herramienta, si les ha servido, los felicitas o les explicas el por que de ciertas prácticas
  • hasta que ya no necesita de ti para ser autoorganizado y el equipo completamente independiente
Aclaro, se sigue necesitando del Scrum Master para remover impedimentos y realizar las otras muchas tareas, pero ya no necesitan del Scrum Master para autoorganizarse, pero sí talvez para algún cuestionamiento que los lleve a ser cada vez mejores.


Nota: No creo en coach de Scrum o Scrum Masters certificados o no, que nunca hayan practicado Scrum, no saben transmitir la esencia del mismo y el espíritu que hay detrás del Framework. En el lenguaje de la bicicleta sería: aunque no dudo que hayan casos de quienes enseñen a montar en bicicleta sin haberla montado, la experiencia de quien enseña es importante para que quien esta aprendiendo aprenda más rapido, aprenda correctamente y aprenda mejor.

Hasta acá este compartir, hasta la próxima

Saludos ágiles

Jorge Abad.

domingo, agosto 09, 2015

Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos

Siguiendo con la serie

Comenzando con un equipo en Scrum - clic aquí - 


Otro de los aspectos que he notado que es importante al dar inicio con un equipo que quiere convertirse en Equipo Ágil, es hacerlos conscientes de los ciclos de vida de los equipos y que es natural todas las etapas por las que van a pasar:

Estas fases con conocidas como el Modelo de Tuckman de los equipos:

1. Formación ( Forming), se caracteriza por:

  • la incertidumbre en el equipo
  • los miembros del equipo estan sondeando a todos los miembros
  • estableciendo conductas aceptables
  • al finalizar esta etapa todos comienzan a sentirse parte del equipo
  • El líder debe dirigir
  • El Scrum Master sería Scrum Mom* (Mamá Scrum = Apegados a las reglas) 
2. Conflicto (Storming), se caracteriza por:

  • conflictos internos
  • los miembros del equipo acepta la existencia del grupo
  • hay resistencia a las restricciones que se les impone a sus individuos
  • al finalizar esta etapa el equipo cuenta con un esquema de liderazgo claro para todos
  • El líder debe actuar como coach
  • El Scrum Master comienza a ejercer su rol como es esperado en el modelo y ayuda a resolver conflictos
3. Normalización (Norming), se caracteriza por:
  • el grupo manifiesta su cohesión
  • se despierta un sentido de identidad y camaradería
  • se culmina esta etapa cuando
    • se solidifica la estructura del equipo
    • se ha asimilado las expectativas sobre el comportamiento correcto
  • El líder actúa como facilitador
  • El liderazgo comienza a ser compartido con el equipo
  • El Scrum Master ejecuta su rol como lo espera el modelo
4. Desempeño (Performing), se caracteriza por:
  • la energía del equipo ya no se dirige hacia concocerse sino hacia la tarea que lso cocupa
  • el equipo es consciente y responsable de sí mismos y realmente es un equipo autogestionado
  • Se consideraría la ultima etapa si el equipo no es disgregado
  • El equipo requiere que el  líder le delega tareas y proyectos, el equipo no necesita ser instruido o asistido
  • El líder delega
  • El Scrum Master actua como un Scrum Sensei*
5. Separación (Adjourning), se caracteriza por:
  • la conclusión de las tareas encomendadas
  • unos miembros reciben con gozo los logros alcanzados
  • otros miembros del equipo se entristecen por la finalización del equipo
  • Los miembros que llegaron a esta etapa son grandes facilitadores para acompañar a otros equipos en su jornada al alto desempeño


Comparto a continuación algunas imágenes y referencias en los que se puede profundizar y reflexionar:

MODELO DE TUCKMAN: RELACIONES Y DESEMPEÑO
Modelo de Tuckman

Relación entre los miembros de equipo en el modelo de Tuckman

Desempeño del equipo en sus diferentes etapas en el modelo de Tuckman


MODELO DE TUCKMAN: TIPO DE LIDERAZGO SEGÚN LA ETAPA DEL MODELO






MADUREZ DEL SCRUM MASTER EN EL TIEMPO*




*Etapas del equipo vs Tipo de Scrum Master Requerido (elaboración propia)

Etapa del equipo
Tipo de Scrum Master Requerido

Scrum Dude
1. Formación ( Forming)
Scrum Mom
2. Conflicto (Storming)
True Scrum Master
3. Normalización (Norming),
True Scrum Master
4. Desempeño (Performing),
Scrum Sensei / True Scrum Master
5. Separación (Adjourning),
Scrum Sensei / True Scrum Master





Saludos ágiles
Jorge Abad






domingo, mayo 24, 2015

Como Jugando Fútbol - Un Símil con Scrum



Hola a todos

Muchas veces cuando comienzo a hablar del marco de Scrum, recuerdo uno de los símiles que escuché en el Ágiles 2014 (sino estoy mal se lo escuche a Pablo Tortorella - @Pablitux), y era que Scrum se parece a jugar fútbol (similar a como Ken Schwaber dice que es como jugar ajedrez [1]).

Se tienen:

  • unas reglas a seguir
  • una cancha
  • un arco
  • un árbitro y unos auxiliares
  • la forma en que se hacen goles y las faltas, 
  • dos equipos
Y dentro de ese marco los equipos juegan, ganan, pierden, se divierten y quien no siga esas reglas - obvio -  no estará jugando fútbol.



Pero la parte en que noto más similitud es en que:

  • se tienen estrategias
  • hay equipo
  • hay un entrenador que motiva y orienta al equipo, 
  • los equipos se adaptan según el transcurrir del partido y el comportamiento del otro equipo.
  • y de igual forma los jugadores interactuan con un objetivo común,  y ese objetivo común logra que se regañen entre ellos, se reprendan, se griten de cancha a cancha pasándose la pelota, se hagan señas y hasta cometan faltas.
Hay pasión, hay sufrimiento, hay coraje y compromiso cada minuto del partido...


Iniciando a Jugar y el Modelo de Tuckman
Observo también, que cuando un equipo inicia a jugar fútbol por primera vez los jugadores no saben mucho del estilo del otro, de sus habilidades y falencias, pero a medida que juegan partidos juntos aumenta la confianza, el lenguaje, la amistad y aparecen estrategias de juego que son útiles para ganar, aun para decidir si necesitan hacer cambios al interior o no.

Similar ocurre cuando un equipo Scrum se comienza a desarrollar, en los primeros sprints no saben quién es quién, quien tiene mejores habilidades, y ni como lograr mejor el backlog comprometido, pero a medida que pasan y pasan los sprints, en los equipos scrum comienza a aparecer la comunicación, el objetivo común, la meta que une, el esfuerzo grupal, el "gritarse" cuando al otro el pasaste el balón y estaba mirando para otro lado - léase, "llamarse la atención mutuamente entre team members  durante el sprint y/o la retrospectiva  por que el otro no estaba  conectado con el Sprint o no colaboró adecuadamente"- . y aquello que no era evidente en la gestión tradicional (dónde cada cual es responsable de su porción de Diagrama de Gantt) y hasta ella misma lo aplastaba si le veía muy revolucionario,  permite Scrum que aparezca: EL EQUIPO AUTOGESTIONADO - El Santo Grial del Agilismo -  responsable de lo que se compromete, un equipo que tiene coraje de superar sus propio estado incial, buscando dar siempre lo mejor de sí, logrando mayor y mejor desempeño en todos sus planos: productivo, técnico y de equipo. 


Nota: les recomiendo leer este excelente post de Martin Alaimo - @MartinAlaimo sobre el modelo de Tuckman  - http://www.martinalaimo.com/es/blog/equipos-estables -  que enlaza perfectamente con lo expresado acá


Bueno esta fue mi corta reflexión de hoy

Hasta la próxima

Saludos ágiles

Jorge Abad


Referencias
[1] <<The word “framework” means that much is not specified and must be devised by those using the framework. I equate Scrum to the game of chess. You can read the official rulebook for chess. The moves, players, sequences, scoring, etc. are all specified. Learn them. Then you can play chess. Maybe your chess game isn’t so good, but you can study great games, strategies, and tactics, and practice to get better and better. However, you are playing the game of chess, so you don’t have the option of changing the rule book. If you change the rules, it’s not chess any longer. Just learn how to play the game with excellence, which is enough of a challenge.>> https://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework/ 

miércoles, abril 22, 2015

¿Y por qué dudamos de la auto-organización de los equipos?

Hola a todos

Hay algo que he notado que es recurrente cuando he dictado entrenamientos o charlas sobre Scrum y es en específico el rol del TEAM /DEVELOPER TEAM / EQUIPO DE DESARROLLO / EL EQUIPO, la primera pregunta que surge por alguno de los presentes es:

¿y cómo logran que se vuelvan auto-organizados?

Es como si dudáramos de nuestra capacidad de

  • jugar en equipo
  • jugar fútbol, baloncesto, rugby, voleibol
  • armar un paseo
  • realizar un asado
  • preparar entre varios una cena
  • jugar un juego de mesa
  • entre otros.


Pero para ser franco, yo siento esa pregunta hecha desde el temor, desde la desconfianza, desde un lugar de la memoria o experiencia  donde a alguien (incluso el mism@ que lanzó la pregunta) que le encomendaron algo no lo entregó a tiempo y para acabar de ajustar todos se dieron cuenta que despilfarro el tiempo en otras cosas sin importancia que no le aportaban al objetivo.

Yo comprendo esos temores - he estado allí - , y es por eso que tal vez:

  • nos aferramos al comando-control, 
  • asignamos tareas
  • asignamos filas de Gantt (hechas en ms project) a diestra y siniestra
  • ponemos "recursos" (que en realidad son personas, y trabajadores del conocimiento), 
  • les imponemos un tiempo calculado por un experto (que no fueron ellos)
  • hacemos micro-seguimiento, o micro-gestión cada ciertas hroas
  • y si se demoran más les decimos que deben pagar o/y mirar como reponer el tiempo.
La verdad tiene sentido, nos han fallado, hemos fallado y nos dominan los temores, y esos temores nos llevan al lado oscuro [1] - como diría Yoda - (al de comando-control - ver más)


Pero Scrum tiene herramientas que enganchan, empoderan y comprometen al equipo:

  • un objetivo de construir cosas listas (Done) a corto plazo.
  • Un planning que establece compromisos
  • El review que verifica si se logró el compromiso o se quedó en deuda  -(ver más en :  La cara del santo hace el milagro. Efectividad del Planning y Review - )
  • la retrospectiva que con su inspección y adaptación nos lleva hacia nuevos retos, y nos saca de zonas cómodas.
  • y el Scrum Master, que es el agente de cambio que esta cuestionando, ayudando a que el Equipo Scrum ( Product Owner, Team Members, y Scrum Master) salga de su zona de confort

Yo veo Scrum, como un buen juego de equipo, como el fútbol que establece:

  • Cancha, roles, y arbitro //unas cuantas reglas claras ( 3 roles, 4 reuniones, 3 artefactos,  ver más),
  • personas que se divierten jugando // un equipo que se trabaja motivado
  • una táctica para ganar // un tablero kanban y un burndown que muestran lo que tenemos que hacer en un ciclo corto de tiempo y si podemos o no lograr la meta.
  • el deseo de meter gol //un objetivo común y claro "generar el mayor valor en el cliente con la menor cantidad de software posible, en el periodo más corto de tiempo"

Observo en los equipos de desarrollo y en especial de scrum la capacidad innata a auto-organizarse. y dudar de eso, es dudar del niño interior que llevamos dentro, de nuestra capacidad de inventar de poco a poco, de ir mirando como dentro de las reglas establecidas todos nos vamos adaptando, de como podemos jugar mejor sin romper las reglas y meter la mayor cantidad de goles/puntos/aciertos/historias de usuario posibles en un periodo de tiempo.

Es dudar de nuestra voluntad de querer hacer un muy buen el trabajo, de querer dar resultado en equipo, es dudar de la capacidad humana y tribal de relacionarse, trabajar juntos y de querer avanzar en conjunto.

Y si alguien no quiere jugar bien

Creo que todos en diferentes circunstancias cuando alguien no juega correctamente en equipo

  • en el partido de futbol/baloncesto/voleibol el equipo llama la atención del que no está conectado
  • en el asado si alguien solo esta allí para ser servido y no colabora "ni siqueira" a recoger, le llaman la atención o no lo siguen invitando
  • la tía regañona que daña el paseo o la cena juntos deja de ser invitada.

Los equipos al verse empoderados, cuestionan a los miembros que no ayudan en el objetivo común, y poco a poco los equipos van encontrando su forma, número, miembros,  modo, identidad y estilo; y es trabajo del scrum master lanzar las preguntas para que el equipo se conecte, reflexione, inspeccione, adapte y avance.

Cerrando

A mi modo de ver dudar de la auto-organización es dudar de nuestra naturaleza humana.

Cierro con esta frase :"La auto-organización no es una opción en Scrum; es un principio básico. Sin ella  nunca tendremos equipos de alta performance [2]




¿Ustedes que piensan? Queda abierta la discusión

Saludos Ágiles

Jorge Abad


----------
Otra lectura recomendada de este blog: Cualquiera puede ser ágil / Cualquier equipo puede ser ágil


--

[1] "El miedo es el camino al Lado Oscuro.
El miedo lleva a la ira.
La ira lleva al odio.
El odio lleva al sufrimiento.
El sufrimiento al Lado Oscuro.
Cuidado con el miedo, joven padawan." - Maestro Yoda

[2] Hundermark, Peter (traducido por Cyment, Alan) . Un mejor Scrum  -  http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum-2.pdf

domingo, marzo 08, 2015

Cualquiera puede ser ágil / Cualquier equipo puede ser ágil

Unas preguntas comunes cuando dicto un entrenamiento, es

  • ¿y un equipo de seniors puede ser ágil? -  dado sus resabios
  • ¿y un equipo de juniors puede ser ágil? -  dado su inexperiencia
Y lo que generalmente contesto es:

"si funcionamos en un esquema de gestión tradicional que es tan desgastante y orientado al fracaso, con seguridad lo haremos en ágil, se requiere de acompañamiento, pero se logra" 

Y es que pienso que  "Cualquiera puede ser ágil", o mejor "Cualquier equipo puede ser ágil", similar a la frase del Chef Gusteau en Ratatouille: "Cualquiera puede cocinar"


No lo niego, soy humanista:
  • creo en la gente, 
  • creo en que todos podemos y queremos lograr grandes cosas, 
  • creo que podemos aprender a trabajar en equipo y lograr excelentes resultados
Es cierto soy Scrum Master y mi enfoque en las personas no puedo ocultarlo, es inherente a quienes vibramos con este rol de Scrum, y quienes queremos que las cosas mejoren.

Pues como lo expresa uno de los los principios á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."

Es por tanto, necesario el entorno, apoyo y confianza para que emerja la agilidad.

Bien lo dice Lucho Salazar en su post " “No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”:  "Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas"

(Siguiendo con la reflexión) Similar a como lo expresa Anton Ego en su discurso final en Ratatouille (1) pienso que un equipo ágil puede venir de cualquier parte, un gran equipo ágil pienso que es más difícil, pero con que sean un buen equipo, con seguridad estarán darán grandes resultados (mucho mejores que los ofrecidos por el mando-control de la gestión tradicional).

Acaso
  • ¿que persona no quiere sentirse exitosa en su trabajo?
  • ¿que equipo no quiere dar resultados?
Y eso es lo que nos da un entorno ágil, un lugar para aprender, fallar, corregir camino, y lograr grandes resultados, mientras trabajamos motivados y felices.



Saludos ágiles
Jorge Abad.

Referencias
(1) Frase de Anton Ego : <<Antes de este suceso, nunca escondí mi desdén por el lema del Chef Gusteau: “cualquiera puede cocinar”. Pero, me doy cuenta, recién ahora comprendo sus palabras. No cualquiera puede convertirse en un gran artista, pero un gran artista sí puede provenir de cualquier lugar.>>


Consideraciones y Aclaraciones Importantes

 Jurgen Apelo en Management 3.0

"The Agile Blind Spot 

I believe a “weakness”of the Agile Manifesto is that it doesn’t (explicitly) recognize that all software projects need people being smart, disciplined, and attentive. The “people over process”paradigm is great, until you find out that your team consists of two trolls, a parrot, and a hairdresser, and a relatively bright project manager, who happens to be deaf, blind, and mute. No amount of coaching can help a team like that to magically self-organize and to deliver a successful product. I call this the Agile “blind spot.”Agile (as promoted by the manifesto) is great only when the team is great (or at least good enough). To be fair, the need for great teams is probably even twice as important in non-agile environments,but the Agile Manifesto too leaves competence issue unresolved."  

Ken Schwaber
“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”




jueves, noviembre 20, 2014

La cara del santo hace el milagro. Efectividad del Planning y Review

Scrum tiene muchas fortalezas, esta cubierto de soluciones para años y años de heridas de guerra de equipos de software a lo ancho y largo del mundo, cada elemento esta puesto allí ayudando a que los otros funcionen.

Una de las cosas que he observado es la fortaleza que tienen el Planning y el Review, y el milagro que logra en el equipo:

  • En el Planning: El Team Developer con el P.O. (Product Owner - Dueño del Producto), entiende que se quiere construir y se compromete con unos ítemes de backlog que llevará a la DoD (Definition of Done -  Definición de terminado). La clave acá es que al equipo nadie le impone el compromiso, es un acto de libertad, coraje y confianza en si mismos -un consenso libre entre sus integrantes -. En el esquema tradicional hay un GP (Gerente de Proyecto) que le impone unos tiempos y estimaciones a su equipo, sin otra opción que cumplir o cumplir , ya sea en el tiempo asignado o en el propio después de la jornada laboral.
  • En el Review: El Team le presenta al P.O. y a los Interesados* lo construido, y pasan a la gloria, a una ligera vergüenza si algo no sale como lo esperado, o una "humillación" sino cumplieron con poco o nada de lo comprometido (con su respectiva DoD). El que siente la frustración o felicidad es el equipo al mostrar el resultado a sus directos interesados (sin intermediarios o gerentes que cuenten el "chisme" de la típica pregunta ¿como les fue en la entrega?) La cara del P.O. y los Interesados es lo que más compromete y le da propósito a un equipo. 
El equipo toma poco a poco vida, reflexiona para si mismo y dice:
  • tenemos que seguir dando la talla o
  • no nos puede volver a pasar esta misma situación
(esta puesta la semilla para la retrospectiva)

El milagro del compromiso, coraje, foco y auto-organización poco a poco comienzan a emerger y ahí es cuando yo digo como el famoso dicho:

La cara del santo** hace el milagro

Saludos ágiles

Jorge Abad.



* Interesados: Puede ser los líderes funcionales de los clientes, usuarios, o cualquier persona que le importe en obtener un buen producto
** P.O. + Interesados

domingo, agosto 25, 2013

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: