Tras la publicación del anterior post, Implementar el manifiesto Agile, varias personas me propusieron cambios. Alguno aprovechó para insultarme y para quitarme el carnet de anarquista por decir:
Me parece increíble que en mi entorno laboral, trabajando por cuenta ajena en una empresa capitalista que factura millones de euros anuales, me esté organizando de una forma, en mi día a día, más anarquista que en un sindicato que se dice “anarcosindicalista”
Me quedo con las críticas construictivas y vamos a mejorar la idea del manifiesto con ellas, haciendo esta versión 0.2, Alpha. Y aprovecho para hacer una fe de erratas. En el anterior post traduje de forma incorrecta Product Owner como “Jefe de proyecto”, cuando debería ser “Dueño de producto”. Mis disculpas.
Además, en el anterior post se me olvidó una figura importante, así que repaso todas las figuras que hay (o que puede haber) y corrijo este otro error.
- El cliente, que es el que pide cosas
- El dueño del producto, que es el que las prioriza y el que pide cosas que se deben hacer para satisfacer al cliente
- El equipo de desarrollo, que es el que curra
- El scrum master (este es opcional) que es el que vela porque todos los procesos de organización se hagan correctamente
Si tomamos el funcionamiento teórico* de los colectivos anarquistas y más concretamente de los sindicatos de corte anarcosindicalista, tenemos los siguientes actores y su concordancia con las figuras agile:
- La asamblea, que es la que decide qué se debe hacer. En este caso serían el cliente.
- El secretariado permanente, que es el que se encarga de que se haga lo que ha decidido la asamblea. En este casó sería el dueño de producto (pero ojo, el secretariado en su totalidad como ente colegiado, no el secretario general o el secretario de tal o de cual)
- Cada una de las personas al cargo de una secretaría o de un grupo de trabajo. Serían los Scrum Master.
- Las personas que conforman los grupos de trabajo que ayudan a una secretaría o que se han montado para una acción concreta. Serían el equipo de desarrollo.
De modo que la asamblea, periódicamente, pediría cosas (preparar una acción contra esta o aquella empresa, hacer una campaña por este o aquel motivo, iniciar un conflicto, hacer una manifestación… lo que fuera) todas ellas dentro del principio SMART (Specific, Measurable, Archievable, Relevant and Time-bound)** que ya mencioné en el anterior post.
Luego, fuera de la asamblea, el SP cogería esas peticiones, vería las fechas de entrega pedidas y las priorizaría. Cada secretaría o grupo de trabajo cogería las peticiones de su área de competencia y determinaría las tareas necesarias para llevarlo a buen término. Las tareas se priorizarían, se estimarían y se miraría qué tareas quedan pendientes de asambleas anteriores. Si es algo menos prioritario, se deja para luego, si es algo que está a punto de terminarse, se hace lo primero… todo dentro de la autonomía del grupo de trabajo, pensando en las fechas para las que tiene que estar cada tarea.
Tal vez el funcionamiento debería ser mediante un tablón Kanban, en el que cada columna de estado tenga limitado el número de tareas y en el cual cada persona pueda saltar de una tarea a otra, ayudando a la persona que tiene asignada una si así lo requiere. El objetivo, al final, sería no perder la perspectiva de todo lo que se quiere hacer y de cuanto cuesta hacerlo.
Organizarse, insisto, de forma asamblearia
Notas:
* No me tiren de la lengua, que me pierdo
** Específicos, Medibles, Alcanzables, Relevantes y Adaptables en el plazo