En Búsqueda de la Auto-organización

Publicado en

Autor

En las semanas que le siguieron al temblor del Distrito Federal en 1985, la sociedad civil se organizó para apoyar a los rescatistas con comida, agua, descanso e incluso, ayuda médica y psicológica. La gente puso tiendas entre los edificios derrumbados, improvisaron cocinas, camas y consultorios. Lo hicieron a pesar de que el Gobierno, que buscaba controlar la situación y la información, se los prohibió. Sin embargo, policías y militares no pudieron contra ellos. Algunos voluntarios tenían familiares bajo los escombros, otros más lo hicieron por solidaridad. La sociedad civil tenía un objetivo compartido: ayudar lo más pronto posible y reclamó su derecho a participar. El modelo de mando y control, donde existe una autoridad central, no fue necesitado.

Algo similar sucedió con los huracanes Ingrid y Manuel. Si bien, el sentido de emergencia es el que detona estas acciones, las personas se organizan y cooperan con la causa sin que exista un líder o una obligación.

A esto se le llama auto-organización: cuando no necesitamos una jerarquía para lograr un objetivo compartido. No es necesario que exista la necesidad de emergencia; las personas se organizan dentro de grupos de lectura, en foros de internet y para la planeación de una fiesta. Incluso, actividades internacionales como la Wikipedia, la creación de subtítulos para series y movimientos naturalistas y religiosos. Basta ver a los niños jugar en una fiesta infantil, ellos ponen sus reglas y actúan en consecuencia. Si no están de acuerdo pelean y al final llegan a un acuerdo; podría decirse que auto-organizarnos es una cualidad innata.

Vivimos en un mundo complejo

Conforme crecemos, todos los adultos (y en especial los ingenieros) tenemos el deseo de mantener un orden y una jerarquía. Nos es importante que podamos predecir un comportamiento, como dar la fecha de entrega de un proyecto con exactitud.

Sin embargo, en el desarrollo de software enfrentamos problemas complejos relacionados con el conocimiento de la tecnología, de los requerimientos y hasta las personas involucradas en el desarrollo (incluidos los stakeholders). ¿El cliente no recibe lo que espera?, entonces hay que tener un equipo de pruebas que lo garantice; ¿el cliente cambia el requerimiento a medio desarrollo?, entonces hay que hacerlo firmar contratos estrictos; ¿el diseño del sistema no soporta los requerimientos de stress y volumen?, entonces hay que inspeccionarlo. Nuestra respuesta natural a la pérdida de control es la burocracia: poner más control y crear expertos.

La realidad es que vivimos en un mundo complejo en el que una gran cantidad de variables y la interacción entre éstas, son las que provocan un resultado. Tratar de rastrear una causa raíz es una misión imposible.

¿El cliente no recibe lo que espera?, tal vez el cliente no sabe lo que quiere, o los analistas no han hecho las preguntas correctas, o quizás el equipo de desarrollo no entendió bien el requerimiento, o la especificación funcional estaba inconsistente, o el administrador de proyecto del cliente no responde las llamadas, o al final, tal vez son todas estas variables y muchas más que desconocemos.

Si volteamos a ver otros sistemas complejos, como nuestro cerebro o el universo, encontramos un elemento en común, el control distribuido en forma de auto-organización.

¿Qué es un equipo auto-organizado?

La auto-organización se basa en el principio de que las personas más cercanas al problema son las personas idóneas para resolverlo. Las personas conocen sus habilidades y aptitudes y las ponen a disposición del grupo para así lograr un objetivo común.

Para equipos de desarrollo de software que deben resolver problemas complejos, el ser un equipo auto-organizado no debiera ser una buena práctica ni algo opcional o deseada. La auto-organización debe ser la práctica default.

La adaptación al cambio y la innovación que requieren estos equipos encuentran tierra fértil en un equipo auto-organizado. Sus integrantes se sienten motivados y en control de su proceso, ponen sus propias reglas, aprenden conforme ejecutan, se presionan los unos a los otros, son capaces de lograr resultados asombrosos.

El control distribuido es crucial para la supervivencia en un ambiente complejo.

¿Dejar el control al equipo?, es que no conoces a mi equipo

En un equipo auto-organizado son los integrantes quienes asisten a juntas, estiman, dan fechas de entrega y dan seguimiento al proyecto, hablan directamente con el cliente cuando se está definiendo el requerimiento, plantean la arquitectura, el diseño y los lineamientos de calidad de código. Todos exponen y conocen los resultados.

La idea asusta a los altos mandos acostumbrados a tener el control. Conocen a los integrantes de su equipo e imaginan escenarios anárquicos, donde cada quien llega a la hora que quiere, se toman decisiones “al aventón” y la calidad del producto es pisoteada.

La realidad es que líderes y gerentes conocen a su equipo en un contexto de control. Quizá han delegado responsabilidades, pero no han dado el empoderamiento (empowerment) a todo el equipo.

Aún con un equipo auto-organizado, líderes y gerentes seguirán a cargo del proyecto de desarrollo y del equipo. Pareciera que se está pidiendo a estos altos mandos que se pongan la soga al cuello y le damos la soga al equipo para que la jale o la suelte.

Pero nada más lejos de la realidad. Líderes y gerentes son responsables de establecer los límites en los que el equipo podrá moverse. Deben de proveer la estructura de trabajo, es decir: los principios y valores que se deben procurar. También deben tener una visión de hacia dónde se debe mover el equipo y asegurarse que el equipo la entienda y se la apropie.

¿Cómo lograr la tan ansiada auto-organización?

Lyssa Adkins en su libro Coaching Agile Teams, habla de una recuperación del “mando y control”. Asegura que a pesar de ser creyente fiel y fanática de los equipos auto-organizados, hay ocasiones que sus viejas costumbres de “yo digo y tú haces”, salen a la superficie.

De mi experiencia como gerente, sé que es más fácil mandar que convencer. Y para el equipo también es más fácil obedecer que proponer, en especial cuando nos consumen los problemas de día a día, las fechas límite se acercan, la calidad del desarrollo queda en esperanzas.

Comienza la desconfianza, las horas extras y la asignación de culpas.Sin embargo, hay un elemento colgado en la pared que me recuerda mi obligación de promover la auto-organización: el tablero físico de tareas.

También conocido como tablero de Kanban, en este tablero hay post-its, indicadores de colores y hasta estampas. Abarca todo un pasillo y es el centro de gravedad del equipo. Frente a ese tablero tenemos juntas y resolvemos conflictos; ahí se asignan las tareas, se cuelgan diseños y se replantea la táctica a seguir. De una mirada el equipo sabe si está perdiendo el paso.

Una vez que los integrantes del equipo entienden la dinámica del tablero (como qué significa cada columna) y ponen las reglas de trabajo conjunto (como siempre tomar una tarea de prueba antes que una de programación), las conversaciones dejan de ser el “dime que hago” y se transforman en “hay que echarle la mano a fulanito” o “estamos teniendo un impedimento que no nos permite avanzar y no lo hemos manejado correctamente”.

La transparencia y comunicación que derivan de ese tablero son pasos firmes hacia la cultivación de un equipo auto-organizado. A partir de ahí es necesario seguir trabajando todos los días.

Líderes y gerentes deben de preguntarse qué les impide dejar el control, cuáles son sus temores y cómo enfrentarlos. Como estrategas deben apoyar al equipo de desarrollo en su crecimiento profesional buscando que la visión personal y como equipo se encuentren.

Los integrantes del equipo de desarrollo deben procurar la excelencia técnica y la comunicación con sus compañeros. Deben apoyarse y conocerse en el otro hasta lograr una simbiosis. El éxito y la satisfacción de pertenecer a ese equipo se darán cuando sus integrantes se den cuenta que el resultado del trabajo en conjunto es mucho mejor que la suma de los logros individuales.

El camino que debemos seguir para lograr un equipo auto-organizado está lleno de tentaciones y obstáculos. Pero sé que vale la pena. ¿Estás listo para intentarlo?

Bio

Rosalinda Muñoz (Rox) es Scrum Master en Tralix. Su principal interés siempre ha sido desarrollar software con calidad para que sus clientes estén satisfechos y los equipos de desarrollo se sientan orgullosos y sean competitivos. Estudió una maestría en Ingeniería de Software en España y al volver a México implementó el aseguramiento de calidad con procesos y auditorías. Estudia y pone en práctica conceptos de cultura organizacional, ontología del lenguaje y desarrollo de softskills. Se prepara para ser Agile Coach. @jeri4queen