La apertura al cambio es un requisito previo para la “Transición ágil” (Imagen de Julia Lingertat)

Cómo volverse ágil: una guía de agencia

Crear condiciones ideales para proyectos de clientes ágiles

Este artículo también está disponible en alemán.

En los últimos años, "ágil" se ha convertido en una palabra de moda cada vez más popular en la escena de la agencia. Apenas hay una sola empresa que no profese trabajar ágilmente. Pero, ¿qué significa realmente? ¿Cómo se puede saber cuán ágil es realmente una empresa? Si uno está trabajando en sprints, ¿significa que ya es ágil? (Respuesta: no.)

En Aperto Move, hemos analizado y perfeccionado constantemente nuestros métodos de trabajo en los últimos dos años y medio, impulsando nuestra visión de agilidad en el lugar de trabajo. Una de las realizaciones más irrefutables ha sido que la transición a ágil requiere tiempo y experiencia. Uno no puede hacer que el cambio sea ágil. Si bien aún no estamos donde nos gustaría estar, las mejoras son claramente notables.

Aplicar métodos ágiles en una agencia es mucho más difícil que, por ejemplo, en el desarrollo de productos; a medida que uno crea productos para diferentes clientes, donde las condiciones pueden variar drásticamente entre proyectos. Por lo tanto, es difícil creer que todas las agencias de repente parecen ser ágiles. Afortunadamente, hay factores que pueden ayudar a determinar fácilmente qué tan lejos ha llegado una empresa a ser ágil.

El consejo presentado en este artículo se basa en escenarios comunes para la mayoría de las agencias, que surgieron en nuestro trabajo diario y se resolvieron una vez que los identificamos como problemas. No son soluciones curativas, sino más bien una colección de aprendizajes que funcionan mejor para nosotros.

1. Aclarar la terminología.

Al presentar ágil, es crucial que todos en la empresa tengan el mismo entendimiento del término, de lo contrario, corre el riesgo de una falta de comunicación peligrosa. Me he encontrado con personas que confunden el enfoque ágil con la renuncia a todas las fases conceptuales, la planificación y las reuniones periódicas a favor de sumergirse directamente en un proyecto y ver qué sucede. No es difícil imaginar que tal proyecto fuera cualquier cosa menos fácil.

Otros simplemente han oído hablar de "Scrum" y albergan cierta reticencia hacia él, descartándolo como "algo para desarrolladores" que sofoca el proceso creativo. En su mayor parte, estas declaraciones provienen de personas que no han explorado Scrum o métodos ágiles. Además, aquellos que no están familiarizados con él, a menudo no pueden distinguir entre ágil y Scrum, y clasificarlos como uno solo.

Scrum y ágil no son lo mismo

Scrum es un marco que define reglas específicas, roles y procesos de trabajo para desarrollar software. Un ejemplo es la definición de intervalos de tiempo en los que se entrega un producto en funcionamiento (los llamados sprints). La implementación de Scrum contribuye al desarrollo ágil de software, por lo que los términos a menudo se consideran sinónimos, pero no lo son.

"Ágil", por otro lado, es una forma de pensar o de cultura, que encapsula mucho más que simplemente lo que hace Scrum. Los principios que definen la cultura ágil se establecen en el Manifiesto Ágil y se muestran en el siguiente video:

Scrum es solo un enfoque posible para seguir los principios ágiles. También se puede ser ágil sin usar Scrum. Por otro lado, solo porque uno se adhiere a las reglas de Scrum, no significa que uno realmente esté trabajando ágilmente.

2. Despídase del rol de gerente de proyecto (saluda a los roles ágiles)

En Scrum, se definen los siguientes roles:

  • Dueño del producto
  • Scrum Master
  • Equipo de desarrollo
  • Otros interesados, como el usuario final o aquellos involucrados en el lado del cliente

No hay otros roles, ni son necesarios. El administrador de proyectos clásico ya no es necesario en esta configuración. Solo obstaculizaría el proceso, ya que todas las tareas previamente realizadas por el gerente del proyecto ahora están cubiertas por los puestos enumerados anteriormente. La responsabilidad del éxito del proyecto ya no recae en una sola persona, sino en todo el equipo.

Cada función adicional que existe en el proyecto, y se interpone entre el equipo Scrum y el cliente, es un obstáculo para la comunicación directa y efectiva entre el equipo y el cliente.

Tomar en serio los roles y las responsabilidades.

Si uno no necesita un gerente de proyecto, ¿no tendría sentido emplear gerentes de proyecto anteriores en una función combinada de Scrum Master y Product Owner?

No. Por un lado, tanto los roles Scrum Master como Product Owner implican suficientes tareas que ejecutar ambos resultarían en el descuido de uno de los roles. En definitiva, los dos roles tienen intereses contradictorios. El propietario del producto permanece en contacto constante con todas las partes interesadas y se asegura de que el producto correcto se entregue con la mejor calidad. Entre otras cosas, el Scrum Master debe asegurarse de que el equipo no esté sobrecargado o interrumpido. Por lo tanto, el Scrum Master no tiene nada que ver con el producto en sí.

Una idea aún peor sería omitir el Scrum Master por completo. Sin un Scrum Master en funciones, no hay ninguna función para garantizar que el equipo trabaje productivamente, cumpla con los plazos o aprenda a través de retrospectivas y se vuelva más eficiente. En resumen, son los que garantizan que el proyecto se realice de forma ágil. En nuestra experiencia, es un papel particularmente importante en un entorno de agencia con clientes, partes interesadas y condiciones cambiantes, porque el Scrum Master también asume un papel de entrenador para el cliente.

Este artículo explica las diferentes funciones del Scrum Master y el administrador de proyectos clásico en términos de una analogía de tráfico fácil de entender:

3. No más planificación de recursos (establezca el principio de extracción)

En las agencias, a menudo se trabajan varios proyectos para varios clientes simultáneamente, lo que hace que la distribución efectiva del trabajo entre todos los empleados sea un desafío.

El enfoque clásico de la agencia es la planificación de recursos: un gerente de proyecto crea planes para varios días o semanas y asigna a los empleados a proyectos o tareas, respectivamente. Esto requiere mucho tiempo para la planificación y la coordinación y da como resultado la inflexibilidad, ya que funciona bajo el supuesto de que se cumplen todas las proyecciones y planes para el tiempo asignado.

La experiencia nos enseña que, en realidad, tales planes nunca llegan a buen término: una entrega importante se retrasa, los empleados se enferman o surgen otras circunstancias imprevistas, lo que lleva a que las tareas individuales demoren más de lo esperado. Las consecuencias son una distribución desigual del trabajo entre colegas, más estrés y horas extras.

Por lo tanto, este llamado "principio de empuje" (porque los empleados tienen tareas únicas "presionadas" sobre ellos) no es óptimo. Entonces, ¿cómo se distribuye el trabajo sin un gerente de proyecto en la constelación ágil? Este problema requiere un enfoque diferente:

El principio de atracción

El trabajo ágil se basa en una mentalidad de "atracción". Esto significa que los empleados deciden de manera proactiva qué tareas quieren asumir. Para que esto funcione, las próximas tareas y su progreso deben comunicarse de manera transparente.

En una situación ideal, esto no solo ocurre en el nivel del proyecto sino en todas las tareas futuras dentro de la empresa. Esto incluye la evaluación del alcance, la creación de presentaciones, la preparación de talleres, la participación en entrevistas o incluso la redacción de este artículo. Esto se puede lograr con un tablero Kanban, por ejemplo:

El principio de extracción ayuda a garantizar una distribución uniforme del trabajo entre los empleados, donde todos tienen la libertad de decidir de forma independiente, cuando tienen la capacidad de trabajar en sus tareas. Esto ayuda a eliminar la posibilidad de sobrecargar a ciertos empleados.

Para que el principio de extracción funcione, se deben cumplir las siguientes condiciones:

  • La comunicación constante es crucial. En Aperto Move, el estado del proyecto se discute tres veces por semana en la junta
  • Requiere personas con la capacidad de tomar la iniciativa en lugar de esperar a que otros les digan qué hacer.
  • Favorece las jerarquías planas y requiere la voluntad de implementarlas.
  • La gerencia de la empresa necesita confiar en sus empleados para que puedan asumir más responsabilidades.
  • Es necesario que haya una clara diferenciación entre tareas individuales y proyectos. Los proyectos no los realiza una sola persona, sino un equipo. Esto se explorará más a fondo en la siguiente sección.

4. Establecer equipos estables

Es típico en las agencias trabajar para varios clientes simultáneamente y las tareas urgentes (como evaluaciones de alcance, lanzamientos o correcciones de errores) a menudo surgen con poca antelación. Por lo tanto, los equipos de proyecto a menudo se crean de acuerdo con la disponibilidad actual. Este tipo de planificación de recursos previene efectivamente proyectos ágiles.

Los equipos ágiles deben ser estables e idealmente encontrarse a sí mismos. Solo los equipos cercanos pueden desarrollarse de manera óptima y mantener o incluso acelerar su ritmo aprendiendo unos de otros, coordinando sus procesos y comunicación, e identificando y resolviendo problemas a través del análisis retrospectivo.

Los equipos pueden identificar y resolver problemas a través de retrospectivas regulares (Imagen de Andreas Plath)

Para evitar interrumpir equipos efectivos de colegas que trabajan bien juntos y, por lo tanto, eliminar todos los efectos de aprendizaje y de rutina, los próximos proyectos no deben planificarse con individuos en mente, sino con equipos estables.

Sin embargo, no es realista pensar que la transformación de una agencia completa con todas las disciplinas en equipos estables y equilibrados puede ocurrir de la noche a la mañana. Es concebible que no todos quieran trabajar permanentemente en el mismo equipo. Por lo tanto, es crucial encontrar un equilibrio que funcione bien para todos.

5. Crear propuestas ágiles

Una fase de propuesta clásica y simplificada entre los clientes y una agencia generalmente toma la siguiente forma: Un cliente tiene una idea específica para un producto y un cronograma sobre cuándo debe terminarse.

Luego, el cliente informa a la agencia sobre los requisitos (tal vez con una presentación) y solicita una propuesta que especifique un precio fijo para el desarrollo de este producto. Para protegerse, ambas partes dedican una cantidad considerable de trabajo a elaborar la propuesta para evitar posibles problemas de comunicación.

Desde la perspectiva del cliente, esto generalmente parece una solución viable: saben lo que obtienen cuándo y a qué precio.

Cambio de requisitos

Lo que la mayoría de los clientes no saben en este momento es que a menudo quieren algo muy diferente al final del proyecto como lo hicieron al principio.

Como todo se define concretamente en la propuesta, es casi imposible cambiar algo dentro del proyecto más adelante sin renegociación, como:

  • otras características se hicieron más importantes mientras tanto
  • el proyecto deseado ya no es técnicamente factible
  • las pruebas de los usuarios revelaron que el producto no se entiende o que no tiene sentido
  • un competidor ha creado un producto similar que requiere un pivote estratégico

En este caso, una nueva priorización no es fácil si el alcance revisado anterior se especifica en la propuesta.

Otros aspectos importantes de ser ágil se ven perjudicados por este tipo de propuesta. Una mejora continua y colaborativa del producto es mucho más difícil, ya que el producto debe estar claramente definido al principio para finalizar la propuesta. Esto conduce a un flujo de trabajo típico en cascada. La planificación de Sprint, incluida la planificación de póker, se vuelve igualmente inútil porque ya se ha definido un plazo final y entregables.

Si el alcance, la fecha límite y el precio ya se han establecido al principio, ya no tiene sentido intentar implementar un marco ágil como Scrum.

En este caso, uno ya no puede usar las principales ventajas de la entrega ágil, pero aún tiene un gasto adicional de reuniones Scrum que no proporcionan ningún valor real. Este proceso también se conoce como "pseudo Scrum".

Se necesita otro tipo de propuesta

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

La cantidad y lo que obtiene el cliente por su dinero lo determina él mismo durante el curso del proyecto, manteniendo la lista de requisitos actualizada y priorizada junto con el equipo.

La elaboración de propuestas ágiles requiere práctica (Fuente: https://unsplash.com/?photo=OQMZwNd3ThU)

Para que el cliente tenga una idea de lo que puede esperar, se puede dar una estimación aproximada de cuánto se puede lograr en un período de tiempo determinado, o cuánto tiempo tomará hasta que se implemente un determinado requisito. Cuanto más tiempo haya trabajado un equipo en conjunto, más precisa será esta estimación, ya que es más fácil medir el ritmo general o la "velocidad" del equipo. Esta es otra razón por la cual es preferible trabajar con equipos estables.

Dicho esto, la elaboración de una propuesta sigue siendo uno de los elementos más difíciles de la transición ágil. Apenas un solo cliente que aún no ha acumulado experiencia en un entorno ágil, quiere firmar un contrato abierto. Para convencerlos de su mérito, es vital demostrar habilidad y generar confianza primero con el cliente.

En nuestra experiencia, este desafío se supera fácilmente tan pronto como uno ha completado un proyecto ágil juntos. Es entonces cuando el proceso del proyecto habla por sí mismo; produciendo resultados rápidos y tangibles a través del trabajo iterativo, colaboración cercana y ciclos de retroalimentación más cortos, que están mucho más cerca de lo que el cliente imaginó de lo que serían en los proyectos típicos en cascada.

Hay mucha literatura útil disponible sobre el tema de propuestas ágiles como este libro:

6. Involucre al equipo del proyecto en la fase de adquisición lo antes posible.

En las agencias, la fase de adquisición y propuesta a menudo está aislada de la implementación del proyecto. Un nuevo equipo de negocios es responsable de los nuevos proyectos y el equipo del proyecto no se enfrenta a los detalles hasta la fase de implementación, lo que aumenta la probabilidad de conflictos.

La fase de propuesta ya puede ser crucial para establecer si un proyecto tendrá éxito o no. Por lo tanto, es esencial que el equipo ágil se incluya en la comunicación lo antes posible.

Como resultado, uno puede evaluar relativamente temprano si una implementación ágil es viable y cuánto tiempo se puede esperar para ello. El gasto de tiempo, p. El número de sprints requeridos en un proyecto scrum solo puede ser evaluado por el propio equipo, si sabe lo más posible sobre el proyecto.

Ocasionalmente habrá más solicitudes de proyectos que capacidad para trabajar en ellas. Para implementar el principio de extracción y seleccionar el proyecto más adecuado, el equipo necesita saber lo más posible sobre todos los proyectos pendientes. Solo entonces pueden tomar una decisión informada e incorporar significativamente nuevos proyectos en sprints de los actuales.

Cuando comienza el nuevo proyecto, el equipo debe conocer a todas las partes interesadas y sus requisitos lo antes posible para entregar el producto adecuado con la mejor calidad posible. Una medida efectiva para lograr esto es realizar un taller con el equipo y las partes interesadas del lado del cliente.

Además, es importante comunicar los valores ágiles al cliente, identificar a la persona de contacto principal y explicar el procedimiento de colaboración en detalle.

7. Olvídese del rol de proveedor de servicios (y trabaje en equipo con su cliente)

Una relación cliente / proveedor de servicios es contraproducente ya que siempre se basa en la premisa de que el cliente ha adjudicado un contrato y espera un resultado específico. Un resultado exitoso del proyecto, que satisfaga a todas las partes involucradas, generalmente requiere trabajo de todas las partes, en particular una comunicación regular entre sí.

Un requisito previo esencial para un proyecto ágil exitoso es la comunicación en el mismo nivel. Esto significa que el cliente y la agencia se consideran mutuamente como un solo equipo, trabajando conjuntamente en un proyecto e identificando y apreciando las fortalezas de cada uno. La agencia suele ser experta en estrategia, experiencia del usuario, diseño e implementación técnica; el cliente, por otro lado, está familiarizado con sus propios procesos y requisitos internos, así como con su público objetivo. Solo cuando se comparte esta información, se puede crear un producto verdaderamente orientado al usuario que satisfaga a todos los interesados.

Esto requiere que haya una persona de contacto designada en el lado del cliente, que esté disponible para responder preguntas sobre el proyecto o pueda proporcionar a la agencia cualquier material que falte. No todos los clientes pueden o quieren invertir tanto tiempo en un solo proyecto porque sus propios procesos de trabajo internos no lo permiten.

En nuestra experiencia, los clientes generalmente notan en una etapa temprana cuánto más rápido obtienen resultados de alta calidad a través de una cooperación ágil. Esto corresponde a sus expectativas y están dispuestos a invertir el tiempo.

8. Proporcione espacio para el trabajo en equipo.

Ser ágil significa trabajar interdisciplinariamente y con comunicación continua. Esto funciona mejor si el equipo ágil se sienta junto, lo que ayuda a coordinar fácilmente su trabajo. Idealmente, cada equipo debe tener su propio espacio donde puedan trabajar sin ser molestados mientras minimizan las molestias para otros, p. cuando se discuten diseños o características.

Los equipos ágiles deberían poder trabajar sin ser interrumpidos (Fuente: https://unsplash.com/photos/5T6lSk2uI1A)

Las agencias a menudo pintan una imagen diferente: la agrupación de empleados de acuerdo con sus respectivas disciplinas. Esto significa que todos los diseñadores se sientan en una esquina de la oficina, los desarrolladores en otra esquina, y los evaluadores y gerentes de cuentas a menudo en diferentes salas por completo. Aunque esto puede tener sentido en términos de intercambio relacionado con la disciplina, complica la comunicación dentro de un equipo de proyecto. Escribir uno al otro es una posibilidad, pero lleva mucho más tiempo que hablar directamente el uno al otro.

Se vuelve aún más difícil cuando todos los miembros del equipo no están en la misma ubicación. Todo el mundo sabe cuán malas son las conferencias telefónicas o las videoconferencias, y si no ha tenido que sufrirlas antes, se recomienda este video:

9. Considere cada disciplina y el proceso completo del proyecto.

Como Scrum nació del desarrollo de software, puede parecer conveniente ejecutar solo el aspecto técnico del proyecto de manera ágil, dejando intacta la fase creativa. Sin embargo, esto logra relativamente poco, ya que la estructura de la cascada solo se resuelve al final de un proyecto.

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

Supongamos que el equipo ágil está compuesto exclusivamente por desarrolladores; El concepto y el diseño del sitio web del cliente ya están completos, pero en el medio del desarrollo se hace evidente que no se han definido o diseñado estados importantes y que el equipo creativo ya está involucrado en su próximo proyecto. ¿Ahora que? ¿Se debería sacar a la gente de otros proyectos? ¿Continuar desarrollando un producto incompleto? No hay una respuesta fácil que no sea involucrar a todas las disciplinas relevantes en el flujo de trabajo ágil desde el principio.

El intercambio regular dentro del equipo del proyecto mejora la calidad del producto (Fuente: https://unsplash.com/photos/gN_nIUnjYJI)

Comentarios, Comentarios, Comentarios

Una gran fortaleza y una razón importante por la cual la calidad del software desarrollado ágilmente es mejor que la de los proyectos en cascada bajo la gestión clásica de proyectos, es la colaboración interdisciplinaria y la mejora iterativa de los productos basados ​​en la retroalimentación temprana y regular entre todos los interesados.

En pocas palabras, esto significa: todos revisan todo en cada fase del proyecto.

  • El cliente y todo el equipo brindan al Propietario del producto (PO) comentarios sobre las historias de los usuarios.
  • Los diseñadores de UI brindan retroalimentación a los wireframes y la ejecución técnica
  • Los diseñadores de UX dan retroalimentación a los diseños de interfaz de usuario y la ejecución técnica
  • Los desarrolladores front-end brindan retroalimentación a los wireframes, los diseños de interfaz de usuario, las interfaces de back-end y, cuando corresponde, la implementación de back-end
  • Los desarrolladores de back-end dan retroalimentación a wireframes, diseños de interfaz de usuario e implementación front-end
  • El control de calidad (QA) brinda retroalimentación a los wireframes, diseños de interfaz de usuario y ejecución técnica
  • Los usuarios dan su opinión a través de pruebas de usabilidad a lo largo de las fases del proyecto (wireframes, prototipos de diseño, maniquíes de clic, implementación frontal)
  • El cliente brinda retroalimentación a los incrementos de producto durante las reuniones de revisión de sprint
En una configuración ágil, el equipo trabaja en conjunto en lugar de consecutivamente

La retroalimentación regular es el activo más importante en el desarrollo ágil y garantiza que el producto se desarrolle a un nivel que satisfaga a todos los interesados. Naturalmente, esto solo funciona cuando todos participan en cada fase del proyecto.

10. No esperes que todo funcione de inmediato (comete errores y aprende de ellos)

Afortunadamente, las secciones anteriores transmitían que, en varios niveles, es necesario adoptar enfoques diferentes a los que probablemente se han desarrollado y establecido a lo largo de los años. Esto hace que sea aún más importante comprender que el movimiento para volverse ágil es un proceso, y no necesariamente uno fácil, ni uno con un fin definido.

La implementación de las medidas discutidas anteriormente no garantiza automáticamente la transición a ser ágil. Del mismo modo, no es suficiente implementar solo aspectos "técnicos", como la adopción de Scrum. Es mucho más esencial cambiar la cultura de la empresa y establecer un sistema de valores común y ágil en todos los niveles jerárquicos.

Sería ingenuo esperar que tales cambios fundamentales pudieran lograrse instantáneamente y sin problemas. Los cambios en los procesos de la empresa también pueden tratarse como un proyecto ágil y desplegarse de forma iterativa.

En última instancia, esto significa que no se debe intentar cambiar todo de una vez, sino implementar una medida a la vez. De esta manera, uno aprende qué funciona, qué no funciona y qué se puede mejorar. Sería un error apegarse a una medida que no se siente bien, solo porque un libro o blog lo ha recomendado.

El entrenamiento externo puede ser igualmente útil para iniciar los procesos de pensamiento correctos, sin embargo, uno no puede esperar encontrar un remedio de solución rápida, lo que lo hace a uno repentinamente ágil.

Es igualmente importante establecer un intercambio interno de conocimiento y experiencia y acordar un enfoque común. Para lograr esto, es útil echar un vistazo regular a los doce principios detrás del Manifiesto Ágil y revisar en qué medida la compañía ya los ha adoptado:

En nuestro equipo, la estricta adherencia a las pautas del marco Scrum ha demostrado ser la mejor solución. Cada vez que estos procesos se desviaban, generaba complicaciones y más esfuerzo. Sin embargo, ese no tiene que ser el caso con todos. Cada empresa necesita descubrir por sí misma lo que funciona mejor.

Conclusión

Incluso antes de que comience un proyecto de cliente, ciertas condiciones estándar de la agencia pueden poner en peligro o incluso hacer imposible el éxito de proyectos ágiles. Aquí es donde se requiere una nueva forma de pensar en todos los niveles y en todas las disciplinas, lo que implica cambios que no se pueden implementar de la noche a la mañana.

Los puntos señalados en este artículo pueden servir como una guía para reconocer y discutir situaciones y problemas en la planificación de proyectos ágiles, antes de que comiencen.

¿Cuáles son sus experiencias sobre este tema? ¿Conoces otras circunstancias que dificultan los procesos ágiles? Háganos saber en la sección de comentarios de este artículo.

Otras lecturas

Aperto Move - An IBM Company es una agencia de Berlín para servicios digitales y móviles con alrededor de 30 empleados. ¿Qué hay de tí?

Síguenos: apertomove.com / Facebook / Twitter