Table of Contents
Cada día, más empresas confían en los contratistas cuando quieren flexibilidad organizativa pero necesitan recursos altamente cualificados para crear productos digitales. Ser capaz de aumentar su fuerza de desarrollo en muy poco tiempo sin la molestia de la formación y la contratación tiene un increíble atractivo para las empresas grandes y pequeñas. Sin embargo, para las empresas que ya están aplicando Agile (o que quieren sumergirse en él), añadir contratistas a sus equipos de producto supone un reto interesante. Agile es más que una metodología, es la forma de describir a las organizaciones comprometidas con las premisas del manifiesto Agile. Cuando hablamos de Agile, nos referimos a:
- La satisfacción del cliente como principal motor y métrica
- Entrega frecuente de actualizaciones de software en funcionamiento
- Cuando te enfrentes a la incertidumbre, no te quedes paralizado: prueba algo, obtén información y ajústalo en consecuencia.
- Equipos autogestionados y capacitados
- Alta transparencia y comunicación
- Autoevaluación continua del rendimiento, por lo que el equipo siempre está mejorando.
Si eres una empresa que usa o está considerando usar Agile, y estás pensando en contratar contratistas en un futuro próximo, sigue leyendo.
Elegir el socio adecuado
Tu contratista debe dominar el método Agile. Los responsables técnicos y los desarrolladores deben tener ya una mentalidad Agile y experiencia de trabajo en entornos Agile. De lo contrario, tendrás que invertir tiempo en introducirlos en la metodología, que probablemente saldrá del presupuesto de tu empresa. Además, no hay garantía de que haya un compromiso con la metodología Agile si el contratista no lo tiene ya integrado en el ADN de su cultura de empresa. El socio ideal querrá saber todo lo que pueda sobre tu negocio y mostrará un compromiso con su éxito a largo plazo, alineándose con tus objetivos.
Contratación Agile
Si tu empresa es nueva en Agile y/o quiere beneficiarse de la experiencia de un socio Agile para subir de nivel, esta podría ser una oportunidad de oro. Además de desarrolladores expertos, un socio Agile puede incluir un Product Owner y un Scrum Master en el equipo, con el objetivo de formar a tu personal en el desarrollo Agile. De esta manera, desde los interesados hasta los desarrolladores, pasando por los gerentes, pueden beneficiarse del coaching Agile durante el proceso de desarrollo del producto hasta que el equipo interno se sienta lo suficientemente cómodo como para dar un paso adelante y ocupar los roles de PO y SM por sí mismos.
Pero, ¿está bien tener un Product Owner externo?
No te dejes engañar por el nombre. Tener al Product Owner en el lado del proveedor tiene sus ventajas:
- Ya conoce las mejores prácticas de product ownership y probablemente tenga mucha experiencia de proyectos anteriores.
- Puede contribuir al diseño del producto y a la toma de decisiones de la hoja de ruta, aportando comentarios, ideas frescas y posibilidades que resultan de la iteración ágil y de las métricas de valor actualizadas.
- Alto nivel técnico y familiaridad con el proceso de desarrollo interno, lo que les da una visión de 360 grados del proyecto.
- Al apoyar tanto las necesidades de la empresa como las del equipo de desarrollo, el PO puede ser un poderoso enlace entre ambas, especialmente porque la confianza de este último ya es un hecho.
Por supuesto, también tiene inconvenientes. Veamos algunos de ellos, así como las formas de mitigarlos:
- No está familiarizado con el mercado y el negocio: Si los proyectos anteriores de tu socio y su experiencia incluyen proyectos similares y/o pueden denotar una gran adaptabilidad en una amplia gama de productos y mercados, no tendrán problemas para familiarizarse con el mercado de tu empresa en muy poco tiempo.
- No conocer la cultura de la empresa: Un buen PO puede captar las señales culturales muy rápidamente, especialmente con la alta frecuencia de intercambios personales asociados al proceso Agile.
- El papel de líder podría ser difícil de asimilar para las partes interesadas de la empresa: La clave para mitigar esto es entender que el PO es un líder servidor. Un PO es alguien que pretende alcanzar la autoridad, no el poder, centrando esa autoridad en responder a las necesidades de la organización y del equipo. Si las partes interesadas pueden medir el impacto de esta confianza rápidamente, empezarán a confiar en este agente en su círculo cercano y se beneficiarán de su ayuda.
Al dejar que un proveedor experto en Agile ayude al equipo, una empresa nueva en Agile podría beneficiarse de ella más rápidamente que si partiera de cero. Incluso si la empresa ya ha empezado a utilizar el método ágil, podría aprender de los métodos de un socio con más experiencia como forma de formar a sus empleados clave. Uno de los requisitos más importantes para un equipo Agile de alto rendimiento es contar con un backlog bien cuidado, compuesto por historias de usuario de tamaño adecuado y bien escritas. Contar con un PO que esté estrechamente relacionado con el aspecto técnico del desarrollo y que tenga una buena y estrecha relación con los desarrolladores ha demostrado con el tiempo ser uno de los factores más importantes del desarrollo Agile de software.
El enfoque del PO cambiará con el tiempo, según la etapa en que se encuentre tu producto:
- Durante la fase de descubrimiento: el PO estará cerca del negocio, trabajando en la visión, las necesidades, el backlog y las estrategias de producto.
- Durante la fase de inicio del proyecto: el PO estará cerca del equipo de desarrollo, revisión de la visión, hojas de ruta, evaluaciones técnicas, perfeccionamiento de la estrategia del proyecto.
- Después de la fase de producción: el PO estará donde se le necesite, siendo un líder al servicio de los usuarios finales, de otras partes interesadas o del equipo de desarrollo.
¿Qué ocurre si ya tengo un PO? ¿Puedo utilizar vuestro PO como apoderado?
Tener un PO apoderado suele debilitar su papel en el equipo, porque su función es meramente de filtro de requisitos, cuando en realidad debería ser responsable y estar en posición de tomar decisiones rápidas y significativas. Podría ayudar al PO existente en la gestión del backlog y en la creación de historias de usuario, pero sus talentos estarían infrautilizados y se generaría una sobrecarga en el proceso ágil. Contar con un PO altamente cualificado que forme al PO de la empresa podría suponer una mejor inversión para el futuro.
Si confías lo suficiente en tu contratista, su visión puede ser muy beneficiosa para el futuro de tu producto. Considera la posibilidad de incluir un PO externo, incluso si ya tienes uno, ya que podría quitarle un peso considerable a tu PO y convertirlo en un aliado inestimable en el camino que tiene por delante. Y, ¿por qué no?, entrenarlo para que sea un PO aún mejor.
¿Qué se necesita para que funcione?
Transparencia: Todo equipo Agile debe tener acceso a las métricas de rendimiento. Tanto el cliente como el proveedor deben acordar los objetivos correctos y los resultados clave. Si el proveedor es tu socio en Agile y su PO es una parte clave de tu producto, debería comprometerse a una métrica basada en los resultados. Los comentarios de los usuarios, los indicadores de valor y las métricas de uso de las features deben estar a disposición de todo el equipo para autoevaluar su rendimiento y ajustar iteración tras iteración para impulsar su rendimiento en función del valor del producto (métrica). Desconectar al equipo del valor entregado y limitar su visión del rendimiento a sólo «puntos de historia entregados a lo largo del tiempo» sería un enorme desperdicio del valor de Agile.
Empoderamiento: La empresa debe facultar a sus socios para que tomen decisiones y avancen entre reuniones, en lugar de esperar el permiso de las partes interesadas. Si cometen un error, se puede arreglar, gracias a las rápidas iteraciones de la metodología ágil. Dar a un PO externo la confianza y el poder que necesita para avanzar, dará lugar a iteraciones más rápidas y a un mejor rendimiento. El porcentaje de errores será mínimo comparado con el enorme progreso que hará el equipo, al no estar limitado a largas esperas de respuestas que pueden ser fácilmente proporcionadas por su propio PO.
El reto de la cultura unificada
Al implementar Agile, una de las principales prácticas es construir una cultura compartida, donde todos entiendan la importancia de las prácticas ágiles y la responsabilidad de cada uno. Con la nueva realidad del trabajo a distancia, es aún más difícil pensar en esto, especialmente si el equipo de desarrollo está compuesto por una mezcla de desarrolladores de la empresa y de los socios, interactuando con varios departamentos de la empresa. Las ceremonias ágiles podrían ser la base de una cultura compartida: las reuniones diarias y las retrospectivas pueden crear un terreno común y un espíritu de equipo, aunque los desarrolladores no compartan oficina ni pertenezcan a la misma empresa. Aunque dediquen sus esfuerzos diarios al mismo objetivo, también es importante que celebren juntos cada logro. Es un error común dirigirse a ellos por separado a la hora de felicitarlos e informarles de los problemas. Si quieres que sientan que están en el mismo equipo, deben sentirlo así. No descartes las actividades periódicas en persona que puedan servir de ejercicios de creación de equipo que unan a los empleados de la empresa y a los contratistas.
Intenta mantener una baja rotación en el equipo: por tu parte, debes esforzarte en mantener a los desarrolladores y gestores el tiempo suficiente para aprovechar su experiencia en conocimientos tanto técnicos como ágiles. Pide a tu socio una permanencia razonable de sus desarrolladores, PO y Scrum Masters también.
Fuentes:
Agile Contract Models – Working with Cross-Corporate Teams
IT Outsourcing: Should the Product Owner come from the Client or the Provider?
