El otro día estaba dando vueltas por la web, y en un artículo me encontré que mencionaban a la Ley de Conway (pondría el link al artículo si recordara cuál era...). En todo caso, me causó curiosidad: ¿qué es la Ley de Conway? ¿A qué se refiere? ¿Cuál es su consecuencia para el liderazgo de equipos de desarrollo?
Hace unos años que estoy trabajando en un equipo en el cual nos ayudamos todos, investigamos juntos, implementamos metodologías y herramientas en equipo y crecimos como pocos grupos con los que uno se puede comparar. Tenemos una herramienta llamada "Team Elements" donde manejamos una wiki, compartimos documentos, tenemos foros y participamos activamente de esta comunidad de Dos Ideas. Hace varios años que venimos aplicando prácticas de XP y hace un año que utilizamos Scrum para la gestión de nuestros proyectos, y tenemos un par de meses de experiencia aplicando Lean/Kanban para la gestión del manteniemiento correctivo y evolutivo.
Hace casi ocho años que en el trabajo tengo el puesto de Líder de Proyecto, y ya casi un año que sería Jefe de Proyecto. La diferencia todavía no llego a entenderla del todo, igualmente, mas allá de las categorías, hace mucho que estoy comprometido con ser un Líder dentro del los ámbitos donde me desarrollo como persona.
Hemos adoptado muchos conceptos erróneos y mitos acerca de los líderes y el liderazgo.
He aquí los cinco más comunes:
Lamentablemente, este simple tema de asegurar que nadie trabaje muchas horas por día (más de 10 ó 12) en un equipo a veces no sucede. Cuando un equipo está atrasado con respecto a la planificación, la primera cosa con la que un líder novato (o no hábil) es presionar para que su equipo haga muchas horas de trabajo. En una organización de desarrollo, si un líder hace ésto alguna vez es inmediatamente puesto en la lista negra por la gente que lo rodea.
En los artículos anteriores vimos que tomar decisiones sin intención es muy perjudical para los equipos, y para solucionar esto planteamos utilizar el Protocolo de Decisión, una práctica para tomar decisiones basándose en el consenso unánime. Pero las personas son libres para votar y defender sus ideales, por lo cual es posible que no logre generarse el consenso unánime buscado en una primera instancia.
En este artículo final de la serie exploraremos el Protocolo de Resolución, una práctica que se puede utilizar en distintos escenarios cuando las pesonas no pueden llegar a un acuerdo unánime sobre algún tema. La idea será olvidar todos los rencores y diferencias, y sólo centrarnos exclusivamente en lo que haría cambiar de parecer a los disidentes.
Como vimos en el artículo anterior, la toma de decisiones sin intención genera caos y perjudica a los equipos que desarrollan software, impiendo que puedan crear el mejor producto posible. Las técnicas habituales para tomar decisiones, tanto por mayoría o autocráticas, presentan importantes problemas. El Protocolo de Decisión brinda una estructura para que los equipos puedan ejercer su facultad cognitiva, que genera responsabilidad por las decisiones tomadas.
En este artículo exploraremos el Protocolo de Decisión, que utiliza un proceso confiable y orientado al consenso para que un equipo tome decisiones. Esta práctica busca tomar decisiones por unanimidad en el equipo... Esperen, esperen, ¿creen que es imposible lograr la unanimidad absoluta en un equipo? Los invito primero a leer este artículo, sin preconceptos.
Todos los equipos toman decisiones, continuamente. El problema es que muchas veces no son conscientes de las elecciones que hacen, ni cuándo las hacen, y por lo tanto terminan actuando con menos intención, sintiéndose menos responsables de sus propias acciones. Los equipos de desarrollo de software que quieran crear el mejor producto posible deben ser totalmente conscientes de una libertad básica humana: el poder de elegir.
En este primer artículo vamos a repasar los problemas en la toma de decisiones de equipo y las consecuencias de mecanismos deficientes, para lograr tener un primer panorama de la situación.
Algunos empleados llegan a la oficina, saludan y se ponen a trabajar. Otros, además de cumplir con las obligaciones de su puesto, ayudan a sus compañeros y se postulan para nuevos proyectos. Pero, ¿qué actitud permite llegar más lejos en la carrera?
A comienzos de la década del '80, Dennis Organ desarrolló la metáfora del "síndrome del buen soldado" para referirse a un concepto que luego se denominaría "comportamiento ciudadano" en la organización.
Se hizo una investigación sobre el liderazgo frente a la crisis del año 2001 en Argentina, de la cual surgieron varias conclusiones interesantes sobre la actitud de los líderes.
La investigación incluyó el análisis de atributos basándose en el modelo de Dave Ulrich. Se buscó comprender cómo un líder fijaba el rumbo, cómo demostraba su carácter personal, cómo promovía la dedicación individual de sus colaboradores y cómo generaba capacidad organizacional.
Una de las ventajas que poseen los equipos ágiles es que llevar a los miembros nuevos a producir bien, puede ocurrir de una forma más natural y eficiente que cuando las personas están trabajando en un mundo rígido estilo cascada. Esto es especialmente cierto si el equipo está co-localizado, con comunicación frecuente y eficiente, trabajando en pequeños incrementos de historias, y especialmente cuando se utiliza programación de a pares.
Muchas personas han notado que la presencia de la confianza dentro de los equipos ágiles es un componente fundamental para implementar el valor del Manifiesto Ágil de "Individuos e interacciones". El primer elemento del Manifiesto Ágil, y el más citado, destaca el valor de los "individuos e interacciones" (por sobre "procesos y herramientas") como fundación del proceso de desarrollo. Llevando este punto más lejos, las metodologías ágile indican que para implementar este valor es necesario crear un equipo unido y colaborativo. Más aún, muchos están de acuerdo que el éxito de estos equipos comienza con la presencia verdadera de la confianza entre sus miembros.
Pero, en un ambiente profesional, ¿cómo se ve realmente la presencia de la confianza? ¿Qué puede hacer un equipo para construir confianza?