La tragedia de los comunes y el desarrollo de software ágil

4

En 1968 un ecologísta llamado Garret Hardin publico un artículo en la revista Science titulado “The tragedy of Commons” que presentaba una idea novedosa. Básicamente indicaba que si un conjunto de recursos estaban compartidos por varios individuos, y estos actuaban en su propio interés, agotarían y destruirían el recurso común, algo que no beneficia a ninguno de los individuos. En su artículo, Hardin, se enfoca principalmente a recursos globales (comida, agua, calidad del aire) en el que la población del mundo al compartirlos los destruirá (si no se auto-regula antes). De alguna manera hablamos de un artículo revolucionario porque rompía axiomas de la época como por ejemplo:

  • Rompía con Malthus que indicaba que una población crecería exponencialmente mientras no haya escasez de recursos. En el momento en el que esa escasez llegase, la población iría desacelerando su crecimiento hasta llegar a un equilibrio. Hardin hablaba de que no se desaceleraría, y eso provocaría una escasez con una importante crisis (como hambruna).
  • Rompía con Adam Smith, que sostenía que si se daba libertad al individuo, éste actuaría inconscientemente por el bien común. Hardin presentaba lo contrario. Presentaba como, al final, esos individuos actuando independientemente actuarían en contra de todos.

La solución de Hardin para evitar que cada individuo consumiese demasiado consistía en la regulación, ya sea la auto-regulación (el gremio) o la actuación del estado o una entidad superior. Tenemos el dilema entre liberalismo y el intervencionismo.

Un detalle que me gustaría destacar es el uso inteligente de la palabra “comunes” que en el mismo título hace referencia a dos conceptos:

  • Bienes comunes
  • Propietarios comunes

Se suele usar el concepto dilema de los comunes para describir el concepto (tanto social como de teoría de juegos) por el que un grupo de individuos motivados por sus intereses propios a corto plazo se auto-causan un daño a todo el grupo a largo plazo. Y en el estudio de este dilema se identifican muchísimas causas.

Pero este es un blog de TI, así que vamos a aplicarlo a nuestro entorno. En concreto al equipo de desarrollo, un recurso escaso compartido por múltiples stakeholders.

Visión de múltiples interesados

En muchas ocasiones el equipo de desarrollo está orientado a un producto, un objetivo, un proyecto, con más de un departamento o cliente interesado. Estos interesados tienen distintas visiones de lo que es prioritario e importante y compiten por tener espacio en el backlog. Así que tenemos el escenario del dilema de los comunes con varios propietarios que actúan “egoístamente” y un bien común limitado (el equipo de desarrollo). Tenemos aquí dos anti-patrones típicos:

  • La solución Salomónica (que yo he aplicado, y me arrepiento por ello, en el pasado). Se divide el recurso entre los interesados, y que cada uno administre su parte. Hay muchas maneras de partir el recurso: Asignar personas a cada interesado o limitar los puntos en cada Sprint son dos de ellas. Al final es poner barreras al campo. Asignar personas es de forma efectiva partir el equipo, pudiendo llegar a equipos unipersonales (yo he tenido esto). Limitar puntos, abre todo un abanico de malas prácticas con los puntos. En cualquier caso, dificulta mucho al equipo enfocarse en algo e intentar hacer tempranas. En vez de entregar A, B y C en orden, arrancamos los tres en paralelo porque cada uno es de un grupo de interesados diferente.
  • La otra solución es la multiplexación en tiempo. Es decir, primero uno y luego otro. En vez de repartirlos en paralelo, decimos que un sprint o grupo de sprints es de uno, y luego del otro. Pero llegamos a los mismo problemas de antes.

El problema principal es que hemos creado silos de priorización, y no estamos comparando elementos entre los distintos silos.

La solución, pues como dije antes hay dos maneras:

  • Gremial: Los interesados se reúnen y discuten entre ellos qué es más prioritario. Y lo hacen desde un prisma global, no departamental.
  • Autoridad: Un ente común (un directivo, un product owner, …) toma control sobre el recurso, entiende las necesidades de todos y decide cómo distribuirlo.

Parece obvio, pero no siempre es fácil tener una solución. La primera la Gremial, requiere que todos los interesados entiendan el problema y quieran invertir tiempo y esfuerzo en entender lo de los otros. A veces un facilitador moderándolos, puede ser la solución. La segunda, como su nombre indica, necesita autoridad. Y sinceramente, no siempre es fácil. El Product Owner puede no tener (o no usar) esa autoridad. Y las personas que la tienen, pueden no querer dedicar tiempo al problema.

Visión Operación Vs Desarrollo

El otro gran dilema en el consumo de recursos. Tenemos un equipo de desarrollo al que le llegan interrupciones, pequeñas cuñas en forma de incidencias, problemas, consultas y peticiones de servicio. ¿Qué atender?

Es el mismo problema pero visto desde otro prisma. Y el dilema de los comunes aparece con varios posibles efectos:

  • El objetivo del sprint por encima de todo. Si no está en la planificación del sprint, que se espere. Todo por cumplir. Por supuesto, esto genera importantes problemas.
  • Nunca avanzamos porque vivimos entre incidencias todo el día.

Mismo problema de antes y mismas soluciones. La gremial, en la que los distintos interesados consiguen ponerse de acuerdo o una autoridad que en todo momento decide qué es lo que realmente es más importante para el bien de todos. Desde mi punto de vista, este problema difiere del anterior en que no hablamos de una decisión cada mes o cada dos semanas, sino varias veces al día. Así que conseguir una solución gremial a cada caso, se me antoja complicado. Creo que en este caso, un product owner con capacidad de decisión que entienda perfectamente negocio es imprescindible.

Conclusiones

Somos humanos, y los mismos principios que aplican a las sociedades, los tenemos en pequeñito en la empresa. La tragedia de los comunes, la tenemos en nuestras oficinas todos los días: distintos interesados luchando por los recursos de desarrollo, como niños peleando por los caramelos de una piñata. Y sólo tiene dos soluciones: Una coordinación entre interesados (solución gremial) o una entidad con capacidad para ver la figura completa y autoridad para poder limitar el recurso a cada uno (Intervencionismo).

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

4 comments

  1. Sebastián Lora López 16 enero, 2019 at 08:40 Responder

    Muy de acuerdo con las 2 posibles soluciones.

    La común creo que es la que más puntos de vista y más perspectivas tendría en cuenta, pero efectivamente es la más difícil de llevar a cabo de con una frecuencia alta, ya sabemos que encontrar consensos en grupos de personas, es muy complicado, y más cuando hay escasez de recursos de por medio.

    Considero que la figura del Directivo / Product Mananger / Product Owner como comentas es clave, al final se trata de trasladar una estrategia a la realidad, y eso requiere priorizar, e incluso implica que a veces hay cosas que se van a hacer nunca, por mucho que a un stakeholder le parezca vital. También me parece igual de importante que la persona que decida pueda tener en cuenta (conociendo o escuchando) todos los puntos de vista: negocio e ingeniería.

    Gracias por el artículo,muy interesante.

    Un saludo,

    Sebas

  2. MD 20 enero, 2019 at 02:42 Responder

    Vaya, creía que ibas ha hablar de la “tragedia de los comunes” y el desarrollo del software en relación a que todo el mundo se aprovecha de herramientas, librerías y proyectos libres pero ni dios libera el código donde lo usa…o como mínimo colabora (monetariamente o picando código) con el proyecto libre que generosamente le ayuda a ganarse las pesetas.

    A la cabeza me viene de hace unos años el famosos Heart Bleed donde todo cristo tenía montada toda su infraestructura con OpenSSL pero solo había un desarrollador trabajando en el proyecto libre…porque no había dinero para mas.

Post a new comment