# SCRUM / Agile para agencias

Estos consejos están basados en escenarios comunes para la mayoría de las agencias. No son una solución que lo resuelva todo, sino una colección de enseñanzas que le han funcionado mejor a [Aperto](https://www.aperto.com/en), una agencia creativa alemana fundada en 1995 que es parte de IBM desde el 2016.

## 1. Clarificar la terminología
Es importante que todos tengamos la misma idea de cada término, de otra manera se pueden tener problemas de comunicación.

### Scrum y agile no son lo mismo

**Scrum** es un framework que define reglas, roles y procesos específicos (en un origen) para desarrollo de software. Un ejemplo son los _sprints_; el intervalo de tiempo en el cual un producto se entrega. La implementación de scrum contribuye al desarrollo ágil, por lo que los términos se entienden comúnmente como sinónimos aunque no lo sean.

un sprint es un intervalo fijo de un més o menos donde se hace todo el trabajo para cumplir la meta del producto, incluidas las reuniones de review y retrospectiva.

**Agile**, por otro lado, es más bien una forma de pensar o cultura, que encapsula mucho más de lo que hace Scrum. los conceptos que definen la cultura agile están escritos en [el Agile Manifesto](http://agilemanifesto.org/iso/en/manifesto.html) y se puede ver en [este video](https://youtu.be/Z9QbYZh1YXY).

por lo tanto **Scrum** solo es una de las posibles implementaciones de la metodología **agile**.

## 2. Conocer los roles de Scrum y adherirse a ellos

En Scrum se definen los siguientes roles:
* Product Owner
* Scrum Master
* Equipo de desarrollo (esto no lo usaremos como tal, pongamosle otro nombre!)
* Stakeholders (como el usuario final o la gente involucrada del lado del cliente)

No se tienen otros roles ni se consideran necesarios. El project manager tradicional no es necesario en esta metodología, ya que solo retrasaría el proceso ya que todas las tareas realizadas previamente por el project manager ahora son cubiertas por los roles listados anteriormente.

Cada rol adicional que exista en el proyecto y esté entre el equipo y el cliente se considera un obstáculo para la comunicación efectiva y directa entre el equipo y el cliente.

### Tomarse los roles y responsabilidades seriamente

Si uno no necesita del proyect manager no haría más sentido emplear a los anteriores project managers en una combinación de los roles de Scrum Master y Product Owner?

No. Por un lado ambos roles tienen suficientes tareas que al tratar de ejecutar ambos roles significaría descuidar uno de los dos. El Product Owner se mantiene en contacto constante con los Stakeholders y se asegura de que el producto correcto se entregue con la mayor calidad posible. Entre otras cosas, el Scrum Master tiene que asegurarse que el equipo no tenga sobrecarga o interrupciones, por lo tanto, el Scrum Master no tiene nada que ver con el producto en sí mismo.

El Scrum Master se asegura que el equipo trabaje productivamente, cumpla los deadlines o aprenda de las retrospectivas y se vuelva más eficiente. En resumen, son los encargados de que el proyecto se maneje de manera ágil. Es un rol importante en un ambiente de agencias donde los Stakeholders y las condiciones cambian constantemente ya que el Scrum Master toma el rol de coaching para el cliente.

[Este artículo](https://www.agile42.com/en/blog/2016/11/04/scrum-master-vs-project-manager/) explica las diferentes funciones de el Scrum Master y el project manager tradicional con una analogía de tráfico fácil de entender.

## 3. No hay planeación de recursos (centralizado, al menos) al establecer el _pull principle_

En las agencias, a menudo se trabajan en varios proyectos simultaneamente, haciendo que la distribución adecuada de trabajo sea un reto para los empleados.

El acercamiento tradicional de agencia es la planeación de recursos: el project manager crea un plan para varios días o semanas con anticipación y asigna a los empleados sus proyectos o tareas respectivamente. Esto requiere tiempo para planeación y coordinación y resulta en falta de flexibilidad, ya que funciona asumiendo que todas las proyecciones y los planes para el tiempo definido se van a cumplir.

La experiencia nos dice que en la realidad, estos planes raramente se cumplen: una entrega importante se retrasa, los empleados se enferman u otras circunstancias imprevistas se presentan, lo que lleva a que las tareas individuales tomen más tiempo de lo esperado.

Este acercamiento (llamado push principle, ya que las tareas son "empujadas" hacia el empleado) no es óptima. entonces, cómo se distribuye el trabajo en un ambiente ágil sin un project manager? este problema requiere un acercamiento distinto:

### El pull principle
el trabajo en **agile** está basado en una mentalidad "pull"; esto significa que los empleados deciden de manera proactiva las tareas en las que se van a trabajar. Para que esto funcione, las tareas pendientes y su progreso deben ser comunicados de manera transparente.

En una situación ideal, esto no solo ocurre a nivel de proyecto sino para todas las tareas dentro de la compañía. Esto incluye la evaluación de alcances, creación de presentaciones, preparación de talleres, participar en entrevistas y reuniones, escribir artículos, etc. Esto se puede lograr con un tablero kanban:

El pull principle ayuda a asegurar una distribución equitativa de trabajo entre empleados donde todos tienen la libertad de decidir independientemente con responsabilidad, teniendo en cuenta su capacidad para trabajar en las tareas pendientes. Esto ayuda a eliminar la posibilidad de exceso de trabajo para ciertos empleados.

Para que el pull principle funcione correctamente se deben de cumplir las siguientes condiciones:

* La comunicación constante es crucial. En la agencia donde escribieron este artículo el status del proyecto se discute tres veces por semana en su tablero.
* Requiere gente con la capacidad de tomar la iniciativa en lugar de esperar que otros le digan qué hacer
* Favorece a las jerarquías horizontales y necesita de una voluntad para implementarlas.
* La administración de la compañía necesita tener confianza en sus empleados para permitirles asumir más responsabilidades

## 4. Crear propuestas ágiles

Una fase de propuesta clásica y simplificada usualmente toma la siguiente forma: el cliente tiene una ídea específica para un producto y un deadline de cuándo debe estar terminado.

El cliente después brifea a la agencia en los requerimientos (tal vez con un pitch) y solicita una propuesta especificando un precio definido para el desarrollo de su producto. Para protegerse a sí mismos, ambas partes dedican una considerable cantidad de tiempo para elaborar una propuesta evitando fallas potenciales de comunicación.

Desde la perspectiva del cliente esto se ve como una solución viable: ya que conocen lo que están recibiendo y a qué precio.

### Los requisitos cambian

Lo que muchos clientes no saben a este punto es que muy a menudo buscan algo muy distinto para el final del proyecto de lo que querían al inicio.

Como todo está definido concretamente en la propuesta es casi imposible cambiar algo en el proyecto sin una renegociación, por ejemplo:

* Otros features se vuelven más importantes conforme pasa el tiempo
* El proyecto deseado deja de ser técnicamente factible
* un competidor ha creado un producto similar que necesita un pivote estratégico

En este caso, hacer una nueva prioritización se vuelve complicado si el alcance anterior está especificado en la propuesta.

Otros aspectos mayores de ser ágil son socavados por este tipo de propuesta. Una mejora del producto continua y colaborativa es más difícil, ya que el producto debe estar claramente definido en el inicio para finalizar la propuesta. Esto lleva al típico flujo de trabajo en cascada. La planeación de sprints, incluyendo el poker de planeación (es donde se definen los alcances de cada tarea individual), pierde el sentido de igual manera ya que el deadline y el entregable ya están definidos.

Si el alcance, el deadline y el precio se han definido desde el inicio, no hace sentido tratar de implementar un framework ágil como Scrum.

En este caso, uno no puede aprovechar las principales ventajas de una entrega ágil, pero se sigue teniendo el coste extra de las reuniones de Scrum las cuales por sí mismas no proveen ningún valor real. Este proceso se suele conocer como "pseudo Scrum".

### Se requiere otro tipo de propuesta

Hace más sentido cobrar por la cantidad de trabajo hecho (llamados contratos por tiempo y materiales) en lugar de definir los entregables exactos en la propuesta. Solo entonces es posible ejecutar un proyecto de manera ágil.

Lo que recibe el cliente (y qué tanto) por su dinero es determinado por él mismo durante el transcurso del proyecto al mantener la lista de requerimientos al día y prioritizado de manera colaboratíva con el equipo.

Para que el cliente pueda tener una idea de lo que se puede esperar, uno puede hacer una aproximación de cuánto se puede lograr en un lapso de tiempo dado, o cuánto tiempo puede tomar hasta que cierto requisito sea implementado. Entre más tiempo un equipo ha trabajado en conjunto estas estimaciones se vuelven más precisas, ya que se vuelve más fácil medir el ritmo o la "velocidad" del equipo. Esto es una razón por la cual es preferible trabajar con equipos estables.

Dicho esto, redactar una propuesta sigue siendo uno de los elementos más difíciles de una transición a una metodología ágil. Difícilmente un cliente que no tiene experiencia en un entorno ágil querrá firmar un contrato abierto. Para convencerlos de su mérito, es vital demostrar habilidad y construir confianza con el cliente primero.

En su experiencia, este reto se vuelve fácil de superar una vez que uno haya completado un producto ágil en conjunto. Es ahí cuando el proceso habla por sí mismo, entregando resultados tangibles con rápidez a través del trabajo iterativo, colaboración cercana y ciclos de retroalimentación más cortos, que es lo más cercano a la visión del cliente que como hubiera sido en los típicos proyectos de cascada.

## 6. Involucra al equipo en la fase de adquisición tan pronto como sea posible

En agencias, las fases de adquisición y propuesta están generalmente aisladas de la implementación del proyecto. Un equipo de negocios es responsable de los nuevos proyectos y el equipo de proyecto no es confrontado con los detalles hasta la fase de implementación, aumentando la probabilidad de conflictos.

La fase de propuesta puede ser crucial para establecer si un proyecto será exitóso o no. Es entonces esencial que el equipo ágil sea incluído en la comunicación tan pronto como sea posible.

Como resultado, uno puede evaluar relativamente pronto si una implementación ágil es viable y cuánto tiempo se espera para eso. Los costes de tiempo, por ejemplo la cantidad de sprints requeridos en un proyecto de Scrum solo pueden ser evaluados por el mísmo equipo si sabe lo más posible acerca del proyecto.

Ocasionalmente habrá más peticiones de proyectos de los que se tiene capacidad de trabajar. Para poder implementar el pull principle y seleccionar el proyecto más apropiado el equipo debe saber tanto como sea posible sobre todos los proyectos pendientes. Solo entonces pueden tomar una decisión informada y signficativa de incorporar nuevos proyectos en los sprints de los proyectos actuales.

Cuando comienza el nuevo proyecto, el equipo debe conocer todos los stakeholders y sus requerimientos tan pronto como sea posible para poder entregar el producto correcto con la mejor calidad posible. Una medida efectiva para lograr esto es hacer un workshop con el equipo y los stakeholders del lado del cliente.

Adicionalmente, es importante comunicar los valores de la metodología ágil al cliente, identificar a la persona con la que se tendrá más contacto y explicar el procedimiento colaborativo a detalle.

## 7. Olvidar el rol de proveedor de servicio

Una relación cliente/proveedor es contraproducente ya que siempre está basada en la premisa de que el cliente ha otorgado un contrato y espera un resultado específico. Un resultado de proyecto exitóso, que satisface a todas las partes involucradas, usualmente requiere trabajo de ambos lados, en particular una comunicación regular uno con otro.

Un prerequisito escencial para un proyecto ágil exitóso es la comunicación al mismo nivel. Esto significa que el cliente y la agencia ven al otro como parte del mismo equipo, trabajando en conjunto e indentificando y apreciando las fortalezas del otro. La agencia usualmente es el experto en estrategia, experiencia de usuario, diseño e implementación técnica; el cliente, por otro lado, está familiarizado con sus propios procesos internos y requerimientos así como con su target. Solo cuando esta información se comparte, uno puede crear productos realmente orientados al usuario que satisface a todos los stakeholders.

Esto requiere que haya un contacto designado del lado del cliente, que esté disponible para responder preguntas acerca del proyecto o pueda proveer a la agencia con cualquier material faltante. No todos los clientes pueden o quieren investigar tanto tiempo en un solo proyecto porque sus propios procesos internos no lo permiten.

En su experiencia, los clientes usualmente se dan cuenta en una fase temprana qué tan rápido están recibiendo resultados de alta calidad a través de la cooperación ágil. Esto corresponde a sus espectativas y se muestran dispuestos a invertir el tiempo necesario.

## 8. Provee espacio para trabajo en equipo

Ser ágil significa trabajar interdisciplinariamente y con comunicación continua. Esto funciona mejor si el equipo ágil trabaja en el mismo lugar, lo que ayuda a coordinar fácilmente su trabajo. Idealmente cada equipo debe tener su propio espacio donde poder trabajar sin molestias, por ejemplo; cuando se discuten diseños y características del producto.

Las agencias usualmente muestran un escenario distinto: agrupan a los empleados de acuerdo a sus respectivas disciplinas. Esto significa que todos los diseñadores se sientan en una esquina de la oficina, los programadores se sientan en otra y los testers y administradores en diferentes oficinas. Aunque esto pueda hacer sentido en terminos de intercambio relacionados a su disciplina, complica la comiunicación entre los integrantes del equipo de proyecto. La comunicación escrita es una posibilidad, pero toma mucho más tiempo que hablarse directamente en persona.

Se vuelve incluso más difícil cuando todos los miembros del equipo no están en el mismo lugar. Todos sabemos cómo pueden ser las llamadas por teléfono o las videoconferencias.

## 9.Considerar cada disciplina y el proceso completo del proyecto.

Como Scrum nació del desarrollo de software, puede parecer conveniente solamente ejecutar el aspecto técnico del proyecto de manera ágil, dejando de lado la fase creativa. Esto, sin embargo, logra muy poco, ya que la estructura de cascada solo se resuelve al final del proyecto.

*un clásico proceso de estructura en cascada se basa en la aprobación de entregables específicos*

Asumamos que el equipo ágil está constituído puramente de programadores; el concepto y el diseño del cliente ya está completo, pero en medio del proceso de desarrollo se vuelve aparente que unos estados importantes del producto no se han definido o diseñado y el equipo creativo ya se encuentra trabajando en su sigiente proyecto. ¿Ahora qué? ¿Debería uno sacar gente de sus proyectos? ¿Continuar desarrollando un producto incompleto? No hay otra respuesta fácil además de involucrar a todas las disciplinas en el flujo de trabajo ágil desde el inicio.

## El feedback es MUY importante

Una gran fortaleza, y una razón importante del por qué la calidad del software hecho de manera ágil es mejor que la calidad del que está hecho en proyectos con el método tradicional de cascada, es la colaboración interdisciplinaria y la mejora iterativa de los productos basados en el feedback de todos los stakeholders.

De manera más simple, esto significa: todos revisan todo en cada fase del proyecto.

* El cliente y el equipo completo le dan al Product Owner feedback de las user stories.
* Los diseñadores de UI dan feedback a los wireframes y a la ejecución técnica.
* Los diseñadores UX dan feedback a los diseños de interface de usuario y a la ejecución técnica.
* Los desarrolladores de front-end le dan feedback a los wireframes, diseños de UI, interfaces de backend y, donde sea aplicable, la implementación de backend.
* Los desarrolladores de back-end dan feedback a los wireframes, diseños de UI y a la implementación de front-end.
* El departamento de control de calidad (QA) da feedback a los wireframes, diseños de UI y a la ejecución técnica.
* Los usuarios le dan feedback vía tests de usabilidad a través de las fases del proyecto (wireframes, diseño de prototipos, click dummies, implementación de front-end)
* El cliente da feedback a los crecimientos del producto durante los meetings de sprint review.

_En una metodología ágil, el equipo trabaja en conjunto en lugar de trabajar consecutivamente_

Dar feedback de manera regular es el asset más importante en un desarrollo ágil, y se asegura que el producto sea desarrollado a un nivel que satisface a todos los stakeholders. Naturalmente, esto solo funciona cuando todos están involucrados en cada fase del proyecto.

## No esperes que todo funcione de manera inmediata (comete errores y aprende de ellos)

Espero que las secciones anteriores hayan dejado claro que, en muchos niveles, es necesario tomar diferentes acercamientos a los que se han desarrollado y establecido a través de los años. El movimiento para volverse una agencia ágil es un proceso, y no necesariamente uno sencillo ni tampoco uno con un final definido.

La implementación de las medidas discutidas anteriormente no garantizan automáticamente la transición a ser una agencia ágil. Similarmente, no es suficiente solamente implementar los aspectos "técnicos", como la adopción de Scrum. Es más escencial cambiar la cultura de la compañía y establecer un sistema de valores ágiles común en todos los niveles jerárquicos.

Sería ingenuo esperar que cambios tan fundamentales puedan ser logrados de manera instantanea y sin ningún contratiempo. Los cambios que procesa la compañía también pueden ser tratados como un proyecto ágil y ser implementados de manera iterativa.

Por último, esto significa que uno no debería de tratar de cambiar todo de una sola vez, sino ir implementando una medida a la vez. De esta manera, uno aprende qué funciona, qué no y qué medidas se pueden mejorar. Sería equivocado quedarse con una medida que no se sienta bien, solo porque un libro o un blog lo recomendó.

Un coaching externo puede ser útil para iniciar los procesos de pensamiento de manera correcta, sin embargo, uno no puede esperar encontrar un remedio rápido que lo vuelva a uno ágil de la noche a la mañana.

Es igual de importante establecer un intercambio interno de conocimiento y concordar un enfoque común. Para lograr esto, es de mucha ayuda echar un vistazo de manera regular a los doce principios detrás del [manifesto ágil](http://agilemanifesto.org/iso/en/principles.html) y revisar hasta qué punto la compañía ya los ha adoptado.

En el caso de Aperto, adherirse estrictamente a las guidelines del framework Scrum ha probado ser la mejor solución. Cada vez que se desviaron de esos procesos, los llevó a complicaciones y esfuerzos más grandes. Eso, sin embargo, no significa que tenga que ser el caso de todos. Cada compañía necesita descubrir qué funciona mejor para ellos mismos.

## Conclusión

Incluso antes de que un proyecto de un cliente comience, ciertas condiciones estándar de una agencia pueden arruinar o incluso hacer que el éxito de proyectos ágiles sea imposible. Esto es cuando se requiere una nueva manera de pensar en todos los niveles y a través de todas las disciplinas, lo que implica cambios los cuales no pueden ser implementados de la noche a la mañana.

### Otras lecturas

* [How to Make Your Culture Work with Agile, Kanban & Software Craftsmanship](http://www.methodsandtools.com/archive/agileculture.php)
* [What is a sprint in Scrum?](https://www.scrum.org/resources/what-is-a-sprint-in-scrum)
* [The 2020 Scrum GuideTM](https://scrumguides.org/scrum-guide.html)
* [Scrum para novatos: Cómo usar Scrum para controlar el caos (del blog de Wrike)](https://www.wrike.com/es/blog/scrum-para-novatos-como-usar-scrum-para-controlar-el-caos/)