¿Agile vs Remote?

Cuando leo sobre experiencias de desarrollo ágil en la red tengo la impresión de que mucha gente percibe el Agilismo como algo contrapuesto a tener en una organización personas y equipos trabajando en remoto. ¿Hasta qué punto el desarrollo ágil es compatible con tener equipos distribuidos?

El acento en el agilismo está puesto en la cercanía. Se prioriza la interacción directa entre las personas sobre los procesos y las herramientas. El cliente, el negocio, participa del proceso de desarrollo, no se limita a negociar un contrato.

Continúa leyendo ¿Agile vs Remote?

La comunicación en los equipos colaborativos

Continuando con Software for Your Head, he leido algunos aspectos sobre comunicación entre los miembros de un equipo que quiero compartir con vosotros.

En este libro se concretan en cuatro apartados básicos los comportamientos que permiten a cualquier equipo colaborativo mejorar sus resultados. En cierta manera los primeros sirven de base a los siguientes. Los apartados son:

  • “Checkin”, relativo a la presencia, a la participación real de los miembros de un equipo.
  • “Decider”, relativo al proceso de toma de decisión.
  • “Aligment”, facilitador de la toma de decisiones.
  • “Shared Vision”, con los comportamientos que logran una visión compartida de los miembros del equipo: el objetivo final.

En los cuatro casos los comportamientos están “codificados” haciendo uso de protocolos, patrones y definiciones. Ese es el software para tu cabeza del que habla el título del libro. Por ejemplo los aspectos de comunicación son presentados como un patrón dentro del apartado de “Checkin”.

Jim y Michele MCarthy explican que la presencia, la integridad para con uno y con el grupo está en la base de la calidad en la comunicación. Sin presencia real hay represión de emociones, rechazo a la visión compartida, y esto lleva a que la conexión entre las personas sea de baja calidad y la información transmitida pobre o nula. Acabamos perdiendo el tiempo.

La presencia es el prerequisito de una buena comunicación, una vez que se establece “la conexión”. Sin embargo esta no llega gratis.

Como dicen los autores: “Most people spend their working hours in the default human-human interface environment, created by no one, but
affected by everyone.” El mecanismo con el que se trabaja es de lo mas rudimentario, y en el lo mas importante es no sentirnos molestos o incómodos. La gente “conecta” solo por casualidad.

Lo que proponen es sustituir esa casualidad por algo elaborado. La mayoría de los equipos no logran “conectar” porque no realizan las tareas previas que garantizan una buena comunicación. No comprueban “el estado de la línea” para ver las velocidades a las que es posible comunicarse ¿en que estado emocional está el otro? ¿su contexto es el mismo que el nuestro o lo que le vamos a decir le va a sonar a chino?.

Tras empezar la conversación la calidad no se mantiene sola, hay que cuidarla activamente, tener una comunicación consciente. La comunicación en un equipo debe partir de un acuerdo para establecer comunicación de calidad. Se debe monitorizar el estado de esta mientras se realiza, para poner remedio en caso de que se esté perdiendo.

En algún lugar del libro nos acaban diciendo “ni te molestes en comunicarte si previamente no has establecido una conexión”. ¿Quien no ha sentido la frustración de creer que se le ha entendido y darse cuenta al cabo de unos días que no ha sido así? Eso entre compañeros del mismo área, imaginad en un equipo multidisciplinar o multicultural.

Un libro prometedor "Software for your head"

Estoy leyendo un libro que he encontrado a través de este post. Su título: “Software for your head. Creating and maintaining a shared vision” y su versión electrónica se puede descargar de forma gratuita.

Me atrajo porque ayuda a clarificar las características esenciales que están detrás de los grandes equipos, mas allá de sistemas o modelos mas o menos elaborados o mas o menos de moda. Además sus resultados se apoyan en la observación de multitud de talleres de equipo realizados por los autores. El libro describe estas características como una serie de protocolos, patrones y otros elementos que seguidos permiten generar equipos que viven para crear productos sobresalientes.

La primera parte está dedicada al requisito básico para abandonar la mediocridad: los miembros del equipo deben estar presentes. Cuando se les ve reunidos no son máscaras que no expresan con sinceridad lo que sienten y piensan, su tiempo es precioso y saben lo que les gusta. Un equipo excelente tiene personas que actúan con integridad hacia si mismos y hacia los demás. Ese es el camino.

Hay un parrafo en el libro donde traducido viene a decir: “Es falso pensar que actuar profesionalmente es actuar de alguna manera sin emociones, o pensar que lo personal y lo profesional son aspectos separados, donde uno es uno mismo solo en el ámbito personal”. En una cadena de montaje o en una organización jerárquica produciendo productos indiferenciados, podía tener sentido que las personas estuvieran desconectadas, ausentes del trabajo. Hoy en día esto no tiene sentido. Menos cuanto mas diferenciado es el producto que se pretende crear.

Los autores llegan a hablar de que el producto es un reflejo del equipo, una idea muy potente.

La presencia está muy relacionada con la conciencia de lo que se hace, con el conocimiento de lo que se quiere. De ahí que la presencia en el trabajo vaya pareja con la eficiencia en el trabajo, nuestro tiempo es valioso. Lo único con derecho a captar nuestra atención son los resultados.

En otro parrafo comenta: “La especificaciones, los planes o las presentaciones no suelen tener que ver con el resultado. De igual manera las reuniones, las revisiones y la administración no son el resultado. Aunque estas cosas pueden contribuir a lograrlo, a menudo evolucionan hasta convertirse en tareas que se justifican por si mismas”. Si te ves realizando tareas no relacionadas con la creación del producto o no contribuyendo directamente a aquellas que lo producen, probablemente estas haciendo algo mal. Seguro que tu presencia real y comprometida se necesita en alguna parte.

Creo que este libro va a merecer una lectura completa.

El mito del desarrollador solitario

Acabo de leer esta entrada en O’Really Radar sobre los mitos de la programación, en concreto sobre el mito del desarrollador solitario. En este post se termina afirmando que, al contrario de lo que afirma el mito, ningún software de entidad surge de la mente de un único programador. Es similar a ese otro clásico, el del científico solitario, ese genio, ese héroe que logra de la nada una nueva teoría. ¡Qué daño hacen los mitos!

En el desarrollo de software, cualquier cosa que vaya más allá de un prototipo necesita de un equipo para crearse. El artículo nos recuerda el ejemplo de Linus Torvalds, que al contrario de lo que cuenta la leyenda, es falso que sea la persona que desarrolló Linux. Lo que hizo fue crear un prototipo del núcleo de este sistema operativo. Los siguientes 19 o 20 años los empleó en coordinar el trabajo de los voluntarios que escribieron el 99% restante del código.

Ya se sabe lo acertado que estuvo hace unos siglos ese egocéntrico llamado Isaac Newton cuando dijo aquello de que “Si he visto un poco más lejos es porque me he elevado a hombros de gigantes”.

Programar es una habilidad básica

Programar es construir algo diciéndole a una máquina de forma precisa qué es lo que quieres, con unas herramientas que nos obligan a cumplir unas reglas muy claras. Esto no es algo que hagan solo los programadores. Aunque pueda resultar chocante, cualquiera que haya modificado fotos con photoshop ha programado, también cualquiera que haya creado páginas web con editores sencillos, que haya metido una animación en una presentación o que haya creado un video casero definiendo tiempos y transiciones.

En programación se suele hablar de programación imperativa y de programación declarativa. En el primer tipo se usan lenguajes con los que se establecen los pasos necesarios para llevar a cabo una tarea. En la programación declarativa se define lo que se va a crear haciendo uso de definiciones, de condiciones y otras características. El primero es útil en la definición de un trabajo a realizar, el segundo en la definición de una entidad que va a cumplir una función. Cuando pensamos en programación solemos pensar en programación imperativa. Pero cuando trabajamos con una hoja de cálculo o creamos una página web hacemos uso de programación declarativa.

Los ordenadores personales, móviles, tabletas y todo lo que está por venir nos ofrecen cada vez mas posibilidades, multiplican nuestra capacidad de hacer cosas. Pasado mañana se valorará a la gente aún mas que hoy en día por su capacidad para manejar herramientas. ¿Pero que es en realidad manejar una herramienta? Usar una herramienta de forma eficaz es comunicarnos con ella haciendo uso de un lenguaje. Pasado mañana se valorará a la gente por su habilidad para hablar y aprender muchos lenguajes, muchos idiomas. De esto es de lo que hablamos cuando hablamos de alfabetismo digital.

Profesionales excelentes, no prima donnas

Uno de los principios contenidos en el manifiesto por el desarrollo ágil de software, publicado en 2001, dice lo siguiente:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

En el desarrollo ágil el acento está puesto sobre el individuo, sobre el experto en algo. Con buen criterio afirma que hay que confiar en su capacidad para aportar soluciones, hay que despejarle el camino en caso de que haya obstáculos que dificulten la consecución de su tarea, hay que darle inspiración en vez de darle instrucciones.

Se nos dice que la empresa ideal no es jerárquica, es cooperativa, es rápida. Con una gestión ligera y diferente y un grupo de expertos que se autoorganizan. Para llegar a ella la organización debe cambiar, los “jefes” deben cambiar…  Pero también son necesarios individuos, expertos con las cualidades adecuadas para trabajar de esta manera.

Un equipo ágil que ofrezca resultados de calidad también exige tener personas con unos valores y cualidades particulares. Se cede el poder al experto, pero de nada nos valdrá si olvida que trabaja por un objetivo común, poco aportará si no es capaz de escuchar, si no busca activamente integrar las ideas de los demás en sus ideas.

Cada vez mas, los problemas a los que nos enfrentamos son esos que llaman “wicked problems“, problemas perversos. Complejos, sin procedimientos claros para resolverlos y por supuesto sin posibilidad de automatizarlos. Para aportar soluciones hacen falta muchas voces, pero también muchos oidos.

No son prima donnas lo que necesitan los equipos sino profesionales excelentes, gente que no solo sirva para sacar las castañas del fuego sino que ayuden a crear equipos brillantes y con futuro.