Entre el 2017 y 2018, tuve el gran privilegio de colaborar de forma muy cercana con Mike Beedle, coautor del Manifiesto Ágil y Scrum. Recuerdo asistir a sus talleres en Chicago y Nueva York, donde además de introducirme a su red de contactos y aprender mucho de ellos, pude prepararme para convertirme en entrenador de Business Agility y de Enterprise Scrum.
Mike fue un visionario en muchos sentidos. Sin embargo, fueron sus constantes críticas a marcos como Safe, su propuesta de un framework de colaboración de fuente abierta y el uso de creative commons lo que más me impactó sobre el desarrollo de marcos de agilidad a nivel empresarial. Dos años después, veo cómo su capacidad de influir e inspirar lo convertían en un verdadero líder.
Debo reconocer que, desde su muerte en el 2018, me había costado tocar el tema del Enterprise Scrum, a pesar de ser el primer entrenador del framework de habla hispana en Latinoamérica. No obstante, parte de mí sentía que todavía quedaba algo por hacer y me gustaría empezar con este pequeño paso.
En el 2001 Mike Beedle y otros 16 expertos del software co-diseñaron el Manifiesto Ágil, el cual sigue estando vigente casi 20 años después. Recordemos que para ese tiempo muy pocos se atrevían a desafiar un marco más allá de los equipos y menos aún llevarlo al nivel empresarial. Fue ahí donde Enterprise Scrum adquirió relevancia. Mike desarrolló un sistema centrado en el diseño y arquitectura de nuevas organizaciones. Este nuevo framework nos daría interesantes conceptos como unidades de negocio descentralizadas sobre silos corporativos, autonomía de ingresos con unidades radicalmente desacopladas, colaboración entre departamentos para desarrollar equipos enfocados a entender un segmento de clientes y canvas para el diseño de arquitectura de la información. Claro que Enterprise Scrum toca muchos otros temas, los cuales espero discutir pronto con lo que pudiera ser la futura comunidad.
Esta vez me gustaría contarles sobre el modelo CEC del framework de Enterprise Scrum, llamado así para explicar los 3 pilares dentro de un equipo: Colaboración, Engagement y Competencia. Cada concepto nos puede dar una buena idea de cómo un equipo puede alcanzar su máxima eficiencia, así que analicemos uno por uno.
Colaboración
“Nadie puede silbar una sinfonía por sí mismo sin la ayuda de una orquesta”
Cuando hablamos de colaboración nos referimos a la inteligencia colectiva dentro de un sistema social. Esta parte del modelo se enfoca en la capacidad de un grupo de individuos que no necesariamente comparten el mismo punto de vista o tienen las mismas habilidades, pero que confían y se respetan entre ellos, actuando como sistema único. Una vez aquí, sus integrantes llegan a conocerse y sobre todo a reconocerse a sí mismos como una entidad integral.
La colaboración no es algo que surge de la nada. Requiere de un mayor entendimiento de la misma y cómo surge entre los humanos, más allá de la confianza. Es justo aquí, desde la perspectiva de un framework de fuente abierta, donde sería interesante encontrar contribuidores interesados en desarrollar y detallar más a profundidad los patrones de colaboración dentro del Enterprise Scrum.
Competencia
‘La incompetencia técnica no la cura ni la agilidad’
La competencia es la habilidad práctica de cada rol para ejecutar cierto tipo de arte. Algunos ejemplos de competencia serían la habilidad de un desarrollador para dominar cierto lenguaje, la destreza de un Product Owner para estructurar historias de usuario y criterios de aceptación claros para una planificación de equipo efectiva, o la capacidad de un Scrum Master para facilitar interacciones y llevar a su equipo al máximo nivel de competencia posible. Así podemos observar cómo las competencias poseen varias dimensiones que debemos aprender a reconocer.
A pesar de que la agilidad es una solución viable para atacar los problemas dentro de una organización, tampoco es capaz de hacer magia. Si los miembros de un equipo no poseen un cierto grado de madurez individual, ningún framework va a poder contra la incompetencia de nadie. Por eso, es importante no solo diseñar cómo el equipo o subsistema va a interactuar con la organización, sino que hay que poner especial atención a cómo organizamos las competencias correctas para resolver el problema deseado. Para esto, tenemos que primero entender el problema a profundidad. Una vez ahí, podemos definir y mapear las habilidades y competencias que vamos a necesitar para resolverlo.
Desde la competencia, podríamos hacer un listado de ideas que la comunidad interesada en Enterprise Scrum podría ir madurando. Algunas en las que puedo pensar son:
-
El nivel de madurez de los roles: Entender qué es el liderazgo dentro del rol de un líder técnico por ejemplo y qué competencias nuevas necesitamos.
-
Cómo un equipo mide la forma de ayudarse entre ellos a través sus competencias: La manera en que se construye la confianza o se identifican patrones para un equipo altamente efectivo.
Engagement
‘La experiencia del empleado es la suma de todo lo que vive a lo largo de su relación con la organización’
El engagement se da desde la auto-motivación y el interés genuino. Por eso es necesario reconocer el diseño estructural o adaptación del framework dentro de un equipo.
Por otro lado, una parte indispensable de este compromiso está relacionada a la motivación del equipo y de su relación con el sistema en el que interactúa. Si hablamos del juego organizacional, hablamos de forma directa o indirecta de la estructura que hará florecer el ‘engagement’.
Aunque variables como la autonomía y la motivación intrínseca son importantes para resolver problemas complejos de la forma más eficiente, el engagement está relacionado especialmente con un buen diseño de libertad y responsabilidad. La meta es lograr una mejor adaptación al cambio a través de la manera más rápida de acoplarnos a un sistema social con claridad de estructura y objetivos. Solo así podremos alinearnos adecuadamente con las necesidades del usuario, negocio, tecnología y contexto.
Sabemos que, aunque Scrum es un marco simple de interacciones, también revela la complejidad y el misterio de las relaciones humanas al trabajar en equipo. Sin embargo, es indispensable tener un marco de referencia para diseñar organizaciones que aprendan, colaboren y co-diseñen soluciones en conjunto, desarrollen confianza y sean realmente adaptables a las diferentes necesidades que surjan en el camino.
Para concluir, me gustaría hacer un llamado a quien esté interesado en aprender más sobre Enterprise Scrum. Les invito a que juntos creemos una nueva comunidad de fuente abierta, donde se promueva la colaboración y el entendimiento de patrones organizacionales más allá de la rigidez de los marcos empresariales.
Recuerdo que Mike solía sorprendernos durante nuestros entrenamientos para hablarnos del libro que tenía pendiente por terminar. Creo que no hay mejor momento para hacerlo que ahora. Si alguien está interesado en añadir nuevas y mejores formas de trabajar juntos y le gustaría terminarlo desde donde él lo dejó, lo animo a que se ponga en contacto con nosotros en PALO IT, o mejor aún, a ponerse en contacto conmigo directamente en uaguila@palo-it.com.
