PEOPLEWARE

   El desarrollo de proyectos en general y de software en particular, parece llevar asociado inherentemente una problemática concreta que conduce en gran medida hacia la ineficiencia y la generación de desperdicios que finalmente se traducen en costes.
    Estimaciones que no terminan de cumplirse, predictibilidad que no llega a ser realmente eficaz, tareas estimadas de antemano que recurrentemente se quedan cortas aflorando más trabajo no previsto inicialmente.. en definitiva, retrasos en proyectos.
   Proyectos en torno a los cuales se construyen equipos de personas en exclusiva para luego ser desmantelados una vez que concluye el desarrollo del mismo (lo que hace perder la referencia para realizar mejores estimaciones en el futuro), proyectos que en muchas ocasiones no cuentan con el tiempo mínimo necesario que requiere el equipo para construir un producto de calidad evitando la deuda técnica y ahorrando los costes que supone en mantenimiento (a pagar siempre por el cliente o por el proveedor del producto).
   En definitiva, un conjunto de ingredientes que favorecen la creación de productos sin la calidad más deseable (refactorizacion & testing), y sin la profesionalidad que cabría esperar.



   Ante esta situación, y teniendo en mente que cada proyecto tiene su propia idiosincrasia que lo hace particular en diferentes aspectos, teniendo en cuanta también que no es lo mismo el desarrollo de productos puramente software de los que son un mix hardware-software (ejemplo aquí de como aplicar conceptos de desarrollo software a la construcción de un coche), es posible encontrar información e ideas disruptivas a la par que inspiracionales que podrían ser incluidas de manera gradual, por el management de compañias y organizaciones, que crean que es posible afrontar esta problemática desde otra perspectiva. En el mundo del desarrollo software, hay ideas que hablan de conceptos como:

• Crear software no es como crear puentes o edificios, dado que se trata de una creación intelectual única y singular sujeta a la creatividad y por tanto no es posible planificarla con precisión.
• Ante la dificultad de planificar correctamente, se pone en cuestión el desarrollo tradicional basado en una planificación en cascada (Gantt) en favor de una manera de proceder en la que la entrega de valor continua al cliente (que acompaña de la mano el desarrollo del proyecto), es la piedra angular. De esta manera, mientras cliente y proveedor caminan de la mano, descubren nuevas necesidades a cubrir ignoradas hasta ese momento. 

   Navegando por la web es fácil toparse con lo que se llamó Manifiesto Ágil, donde se recogen una serie de principios que pretenden ofrecer una alternativa a los procesos de desarrollo software tradicionales basados en la rigidez de unos requisitos iniciales, en la predictibilidad de un diagrama en cascada o en un conjunto de documentos y contratos preestablecidos.

 
   Por el contrario, con este manifiesto se quiso sentar las bases que permitiesen a las organizaciones desarrollar software más rápidamente consiguiendo, al mismo tiempo, responder con éxito a los diferentes cambios que pudiesen surgir durante la evolución del proyecto. Consta de cuatro valores y doce principios donde la prioridad más importante es la satisfacción del cliente mediante entregas tempranas y continuas de un prototipo funcional.

   Bajo este paraguas del manifiesto ágil han surgido varias implementaciones como son Scum, XP o Devops entre otras, aplicando de manera particular dichos valores y principios.

   Llegados a este punto cabe preguntarnos: ¿Son por tanto estas metodologías caminos que permiten llegar a encontrar el Santo Grial en lo que a desarrollo software en una organización se refiere?
En mi opinión diría que resulta complicado aplicar completamente y de primeras, todos estos principios al 100% en la realidad de un compañía instalada en los métodos tradicionales de trabajo. Sin embargo conviene tener todas estas ideas en mente de manera que sea posible detectar situaciones en la que sea posible aplicar de manera gradual cambios que permitan ir en la dirección que marca el manifiesto, consiguiendo avances que demuestren objetivamente que la nueva metodología de trabajo genera resultados mejores.
   Como siempre, el management y la alta dirección tienen que ser los catalizadores que permitan generar estos cambios, aportando los recursos necesarios así como la convicción sobre la idea de que una nueva manera de hacer las cosas es posible, arrastrando definitivamente al resto de personas de la organización.

Disclaimer: En este post he querido recoger algunas de la ideas mencionadas en el libro de Javier Garzás "Peopleware y Equipos Ágiles" ya que tuve la oportunidad de participar en el crowdfunding que se realizó, recibiendo por ello una copia del libro dedicada personalmente.😊 Algunas de las imágenes que se muestran en este texto también provienen de esta fuente.

¿QUE SIGNIFICA PEOPLEWARE?

   Peopleware es un concepto que sitúa a las personas y los equipos por encima de otros componentes como los procesos, documentos, jerarquías extensas y estructuras.

   Frente al taylorismo implantado en mundo del desarrollo software heredado de la industrialización, se sitúa otra corriente que aboga por el desarrollo ágil. Frente a los "Doers vs Thinkers" que defiende el management tradicional, emergen las jerarquías planas y los liderazgos compartidos.

   Desarrollar software no es como construir un producto industrial, donde todo el proceso está perfectamente definido y cuantificado. Desarrollar software es una producción intelectual basada en el conocimiento, generado de manera única y singular, y como tal, no puede ser plasmado completamente en un diagrama de Gantt con todos los detalles predefinidos.

   El desarrollo software, como cualquier otra actividad intelectual, es algo que depende en alta medida de la motivación del equipo, las habilidades personales y las relaciones entre las personas, constituyendo un cúmulo de aspectos que afectan de manera muy importante al resultado final del producto o servicio. Y de aquí nace la importancia de situar a las personas en la primera posición de la lista de prioridades para cualquier organización, dando forma así al concepto de Peopleware.

Peopleware está íntimamente relacionado con la idea de agilidad de desarrollo y el Management 3.0.

   Por otro lado, el Management 3.0 viene a representar una manera novedosa de gestionar equipos en la era del conocimiento, donde la supervisión estricta, el control horario, los sistemas de fichajes o el uso del miedo y la competitividad interna como base para espolear la productividad del equipo, da paso a una gestión donde las personas son el activo más valioso, y donde los managers, una vez establecidas unas directrices y un marco de trabajo básico, gestionan de manera que el equipo puede sacar su mayor potencial, donde la colaboración, la reflexión, la mejora y el sentimiento de equipo unido sea el principal valor.

   El reto reside en evitar que las personas caigan en la desmotivación y la resignación, en evitar fomentar el trabajo individual (llaneros solitarios) dando paso a equipos de trabajo ágiles, estables, pequeños, auto-organizados y multifuncionales, capaces de llegar a mantener unos valores con los que se identifiquen y por los que trabajen, de manera que se pueda alcanzar un estado de sana productividad sostenible.

   Organizarse por equipos y no por proyectos parece algo esencial en una compañía si se desea recorrer este camino. Construir equipos temporales a la luz de los nuevos proyectos va en contra de esta serie de premisas.


UN EQUIPO MOTIVADO

   Un equipo feliz en el trabajo, es un equipo motivado. Conseguir que los días en el trabajo sean tan duros y exigente como divertidos debe ser el objetivo final.

   Según Maslow la motivación en el ser humano existe para satisfacer distintos tipos de necesidades, desde las fisiológicas, a las más sofisticadas.

   En una organización o empresa, las necesidades más básicas estarían relacionadas con el sueldo, el contrato de trabajo, condiciones laborales, beneficios sociales.. y las necesidades más complejas se verían reflejadas con la autoestima, autoconfianza, reputación, reconocimiento..
La gerencia es capaz de solucionar directamente las necesidades básica, sin embargo, con las necesidades de mayor nivel solo puede crear las condiciones necesarias para tratar de solucionarlas de manera indirecta, como por ejemplo delegando, permitir al equipo auto-organizarse, dejar asumir responsabilidades, o tener posibilidad de participar en la toma de decisiones.

   La clave para estar motivado es que la actividad en sí, y la necesidad de trabajar en ella sea por sí sola suficiente para motivar al equipo (motivación intrínseca a la actividad), sin tener que recurrir a motivadores externos como podrían ser cualquier tipo de recompensa.
Aun así, las recompensas son un recurso muy potente si se utiliza correctamente, recompensando comportamientos en lugar de resultados (preferentemente pequeñas recompensas de forma continuada y en público para mostrar reconocimiento).

UN EQUIPO AUTO-ORGANIZADO

   La auto-organización es el modo que tiene un equipo de estructurarse sin necesidad de que haya una autoridad central. Es posible observar ejemplos de auto-organización en la propia naturaleza  (bancos de peces, bandadas de pájaros.. ), donde no emergen liderazgos o jerarquías claras.

  Este mismo concepto es posible aplicarlo al mundo del software y a los equipos de desarrollo, donde el manager, una vez establecido un marco de trabajo y una serie de restricciones (límites), delega la realización de la tarea al equipo, encargándose de mantener bajo control los diferentes inputs que "interrumpirían" restando rendimiento y generando ineficiencia.

   Dentro del equipo no tendría porqué haber un líder por definición, sino que se trataría más bien de un papel compartido (cada uno es responsable de una parte), o incluso rotativo o dinámico dependiendo de la actividad o problema, donde los resultados obtenidos son responsabilidad del colectivo. Cuando se da autoridad y responsabilidad a las personas, se crean líderes.

   En este contexto, normalmente el tipo de liderazgo "control y mando" es sustituido de manera natural por un "líder invitado", donde se consigue que de manera voluntaria, los integrantes del equipo realicen tareas por su propia iniciativa con el objeto de ayudar al grupo.

   En definitiva, un equipo ágil es auto-organizado, guiado por los principios del Manifiesto Ágil, por las restricciones impuestas por gerencia, y que se esfuerza en implementar soluciones de calidad para construir el producto o servicio que se le ha encargado.

   Por tanto, para evolucionar hacia este modelo de trabajo requiere de autonomía del equipo y alineación con la dirección. Para ello son necesarios:

• Propósitos compartidos
• Transparencia 
• Realimentación para reforzar objetivos, prioridades y aprendizaje organizacional compartiendo las buenas y malas prácticas entre equipos para mejorar.

   Conviene resaltar que la auto-organización no es anarquía, ya que implica algún tipo de liderazgo. Las empresas que pueden permitírselo están adoptando estructuras más planas, sin eliminar roles de gestión, pero reduciendo jerarquías.

   De este modo, cuando un equipo trabaja en modo auto-organizado, es necesario determinar responsables que controlen que las cosas se terminan haciendo, que es distinto tener las responsabilidad de hacer la tarea en sí. Con ello se persigue eliminar el "efecto espectador", por el cual ante una tarea concreta, cuanto mayor número de personas haya para hacerla, más tarde acaba por hacerse (ya lo hará otro). Para ello se pueden fijar responsables de áreas que pueden rotar por meses, de manera que controlen que la tarea se lleva a cabo.

   Una técnica utilizada en el Management 3.0 son los Tableros de Delegación, que se basan en la idea de que la delegación no es todo o nada, sino que hay 7 niveles:

• Tell (Informar). El responsable toma una decisión y puede, o no, explicar sus razones.
• Sell (Vender). El responsable toma una decisión pero intenta convencer y explicar las razones al grupo.
• Consult (Consultar) El responsable pide opinión inicialmente al grupo, que tomará en consideración antes de tomar una decsión final.
• Agree (Acordar) El responsable debate llegando a un consenso para decidir finalmente.
• Advise (Asesorar) El responsable da su opinión pero no toma la decisión.
• Inquire (Preguntar) El grupo decide para después preguntar que decisión se tomó finalmente.
• Delegate (Delegar) El grupo decide y el responsable no interviene.

Ejemplo de tablero de delegación (Áreas-Personas-Niveles)

   En equipos donde no hay un responsable, jefe o figura similar, en cada una de las áreas clave, se asigna un responsable. De esta manera, para cada una de las áreas se establece un nivel de delegación, indicando además quien o quienes son los responsables de tomar dichas decisiones.

Acerca de normas y disciplina interna

   En relación a la aplicación de reglas y normas, el Management 3.0 entiende que reducen la creatividad, mermando la capacidad de respuesta a problemas inesperados. El hecho de que alguien haya establecido cómo otros deben trabajar, provoca en el equipo que se eluda la responsabilidad de pensar.

   Para ello, proponen el Principio de Subsidiariedad, el cual dice que las reglas son establecidas por el propio equipo, de fijar las que se crea conveniente, llegando al punto de no tenerlas si no es necesario.
En el caso de que el equipo no realice bien su trabajo, la responsabilidad de decidir las reglas y normas a establecer recaerá sobre el siguiente nivel jerárquico.

Concepto de Seguridad Psicológica
   Según un estudio de Google sobre equipos de trabajo exitosos, recogía que los patrones que tenían en común eran:

• Turnos de conversación. Todos los miembros del equipo hablaban la misma cantidad de tiempo.
• Sensibilidad social. Capacidad para detectar como el resto de miembros del equipo se siente por expresiones, gestos..

   A este tipo de patrones o características se las denomina "Seguridad Psicológica", según Google, imprescindible para un buen equipo de trabajo.

   Para tener buen rendimiento en un equipo hay que sentirse psicológicamente seguro, de manera que con total tranquilidad podemos compartir con el resto del equipo preocupaciones, temores, recriminaciones o cosas que no nos gusten. 

UN EQUIPO MULTIFUNCIONAL

   Un equipo debe poseer todas las competencias necesarias para lograr completar el trabajo sin prácticamente depender de otros equipos, áreas o roles fuera del mismo. Esto no significa que todos miembros del equipo sepan de todo, sino que el equipo en su conjunto posee todo lo necesario.

   Cada miembro del equipo debe estar capacitado para hacer algo más de lo que está especializado, es lo que se conoce como Habilidades en T, no habiendo un persona única con conocimiento exclusivo sobre algo.

   Según el Modelo de Tuckman que estudia la formación de equipos, un equipo pasa por diferentes fases (obligatoriamente) antes de ser plenamente productivo. Se describe por tanto una evolución que recoge en varias fases o etapas:

• Formación: Cada miembro del equipo busca su lugar en el mismo.
• Confrontación: Fase en la que aparecen disputas sobre cómo hacer las cosas.
• Normalización: Se establecen unas reglas de funcionamiento acordadas.
• Rendimiento: Relaciones entre los miembros del equipo consolidadas. 
• Finalización: Se completa la tarea y desaparece el equipo.

   De aquí se deriva el porqué de la importancia de equipos estables, ya que alcanzar el máximo de productividad requiere de pasar por todas las fases anteriormente descritas.
Del mismo modo, se puede concluir por que es necesario organizar el desarrollo de proyecto en torno a equipos conocidos y estables que trabajan en uno o varios proyectos, y no al revés, donde por cada proyecto se asignaría un nuevo equipo, el cual deberá recorrer el modelo de Tuckman nuevamente antes de alcanzar la velocidad de crucero productiva (con lo que conlleva). 

   Es necesario pensar en un equipo como en personas, no como recursos. Las personas son experiencia, motivación, emociones, relaciones, mientras que los recursos son solamente dinero u horas.

   Invertir en que un equipo esté feliz no es baladí, ya que permite ahorrarse costes intangibles derivados de la inestabilidad y rotación de personas.

UN EQUIPO PRODUCTIVO

   La idea fundamental es que en un contexto de desarrollo software (u otras disciplinas que puedan clasificarse como producción intelectual) no es razonable el medir la productividad de un equipo en base a las horas de trabajo, ya que más horas no implica necesariamente mayor avance en el proyecto.

   Se denomina Crunch Mode a la práctica que aboga por realizar muchas horas de trabajo con el objetivo de avanzar más rápido (p.e 50, 60, 70 horas semanales).
Sin embargo, diversos estudios indican que llega un momento en el que por más horas de trabajo que se inviertan, la capacidad de concentración, y productividad en general desciende de tal manera que llega a ser totalmente contraproducente.

   En esta línea, las prácticas ágiles recomiendan para un equipo de desarrollo el alcanzar el ritmo sostenible más óptimo, de manera que es posible trabajar duro pero sin llegar al punto de "burn out".

   Según  las metodologías ágiles, una mejor manera de medir la productividad del equipo es mediante su velocidad. Así, cada una de las historias de usuario es valorada mediante puntos historia, siendo la dicha velocidad la cantidad de puntos historia que el equipo puede finalizar un espacio de tiempo (sprint).

   Bajo este contexto, no es posible medir productividad de cada una de las personas, sino productividad del equipo multifuncional completo, al cual se le califica por el trabajo completado, y no por las horas invertidas.

   Para ser más productivo, conviene reducir al máximo los desperdicios (Lean Software Development). Estos pueden ser:

• Interrupciones.
• Cambios de contexto 
• Exceso de documentación
• Baja calidad del software
• Reuniones eternas
• Equipos de trabajo demasiado grandes 
• ...  

   Una persona trabajando en varios equipos distintos y en varios proyectos distintos, genera cambios de contexto muy importantes que contribuyen a reducir de manera clara la productividad.

   Para reducir o eliminar estos desperdicios, es posible tomar algunas acciones como por ejemplo, que los equipos no sean superiores a 7 personas, establecer horarios de no interrupción en las horas más productivas del comienzo de la jornada, o tener el mínimo de tareas abiertas al mismo tiempo (Work In Progress).

Concepto de Swarming

   Un concepto interesante es el swarming (enjambre), que consiste en que todo el equipo se dedica a hacer la tarea más importante del Product Backlog de manera conjunta, en contraposición a que cada miembro del equipo se dedique a hacer distintas tareas del Sprint Backlog, consiguiendo que las mas importantes se queden cerradas.


UN EQUIPO QUE MEJORA

   Desde el punto de vista de mejora del equipo, a intervalos regulares se debe reflexionar en relación a cómo llegar a ser más efectivo, y ajustar el comportamiento según las conclusiones obtenidas.

   Una de las maneras de mejorar es hacer retrospectivas con el equipo. Se trata de un ejercicio de reflexión, en el que se vuelve a vivir toda la historia del proyecto de forma grupal, y del que se sacan nuevas conclusiones y acciones correctivas a tomar para el futuro.

Referencias:

• Libro "Peopleware y Equipos Ágiles" autor Javier Garzás
• MOOC Miriadax "Agilidad y Lean. Gestionando los proyectos y negocios del siglo XXI" URJC
• Blog Javier Garzas