Es probable que la sola pregunta despierte los recelos de los “talibanes del Agile”, esos consultores/gurús que proclaman la Agilidad como única religión verdadera, y para quien cualquier cosa que exceda de lo estrictamente indicado en su sagrado texto es una blasfemia y está condenado a arder en el infierno del fracaso más absoluto. “¿Cómo pretendes desarrollar verdadero software si tu equipo no pertenece a la misma tribu urbana, si no comparte tu frikismo y gusto por los tatuajes?”
Pero cuando trabajas con empresas consolidadas, grandes y no tan grandes, con un legacy tecnológico, cultural y de gestión de varias décadas, te encuentras con una realidad insoslayable: La mayor parte de los productos y servicios de IT se provisionan mediante contratos. Uno puede llegar a permitirse el lujo de cuestionar si externalizar una actividad como IT es la mejor estrategia empresarial, dado que la teoría clásica del management te indica que debes hacerlo solo con actividades no core, y parece que en un entorno de Transformación Digital es complicado plantearse la tecnología como un área meramente de soporte. Pero la realidad es que cuando llegas a un cliente corporativo, tiene entre el 60 y el 95% de su desarrollo de software subcontratado, y tienes que ayudarle a gestionarlo sin obligarle a refundar su empresa.
En mi experiencia, hay unas pautas claves por dónde empezar una vez asumido que queremos trabajar con metodologías Ágiles, y hemos de hacerlo con outsourcers:
Externaliza por productos: Habrá aspectos que no puedas cambiar tan fácilmente, como lo relativo a RRHH, Finanzas o las relaciones con el negocio, pero ese nivel de la estrategia de externalización si es de tu ámbito, y te supondrá un gran cambio. Olvida la externalización por proyectos, es muy típico que el diseño y creación del producto se adjudique a un proveedor y el evolutivo a otro diferente (o al mismo proveedor pero a equipos distintos), lo que complica enormemente la gestión de un ciclo de vida completo que te permita un desarrollo iterativo incremental.
Provisiona por esfuerzo y tiempo: La tentación de tener un contrato cerrado, de “precio cierto” como establece la Administración Pública, es grande. Pero todos somos conscientes de que el alcance no está bien definido, ya sea porque no hemos tenido tiempo material para detallarlo o porque negocio abomina de nuestras sesiones de Design Thinking, pero lo cierto es que nuestras RFP son “manifiestamente mejorables”. Si en un contrato de desarrollo evolutivo o de soporte podemos provisionar por perfiles y bolsas de horas, ¿Por qué nos resistimos a hacerlo con el producto completo?
El Product Owner no se negocia: Una de las ventajas de Scrum es su simplicidad en lo relativo a roles: Product Owner, Scrum Master y Developers. Los Developers obviamente van a formar parte de la externalización del desarrollo, y parece evidente que en muchos casos el Scrum Master también podría, pues este deberá estar incrustado en el equipo y facilitar a sus miembros aquello que necesiten para que el avance no cese. Pero es muy distinto el rol de Product Owner, quien hace de negociador y pone el criterio entre negocio y el equipo de desarrollo. Ese es un rol que necesitas en exclusiva para ti, necesitas que comparta tu visión de negocio y tu estrategia tecnológica. La tentación de incluirlo en el mismo contrato del desarrollo de uno de los proveedores de desarrollo software es grande, ya que simple vista parece lo lógico y simplifica la contratación, pero en la práctica, donde un mismo Product Owner tiene que llevar la gestión varios productos, te encuentras con dos problemas que lo hacen inviable:• Si el Product Owner es de la misma empresa que te provee el desarrollo de ese producto, entonces les ayudará a ocultar los errores y estará más pendiente de ampliar el contrato con su empresa que de defender tu estrategia.
• Si el Product Owner es de una empresa de desarrollo de software diferente, entonces les hará más difícil su trabajo y su incentivo será mostrarte como el trabajo sería mucho mejor que lo desarrollase su empresa.
Mi recomendación en este caso es clara: No externalices tus Product Owners, y si estás obligado a ello, no lo hagas con una empresa que provea también desarrollo de software y perfiles, para evitar todo lo posible el conflicto de interés.
Como os decía al principio, Agile en entorno corporativo no se trata de la aplicación fundamentalista de una guía, sino de aplicar “el arte de lo posible”.
Pablo Grueso CEO. 20 de Junio de 2017.
