miércoles, 10 de abril de 2013

Outsourcing y prácticas ágiles: ¿pueden convivir?


El ourtsourcing es una práctica muy extendida, especialmente en grandes empresas, donde las ventajas de su aplicación pueden ser más atractivas. El outsourcing implica que parte o todo el desarrollo de un producto (o la prestación de un servicio) es encargada a un proveedor externo.

Pero ¿es incompatible el enfoque ágil con el outsourcing? la respuesta no es inmediata pues existen diferentes grados y situaciones de outsourcing. La cuestión clave para responder es cómo queda constituido el equipo encargado de ejecutar el trabajo (desarrollar cierto producto o proveer cierto servicio) y su relación con la parte cliente (uienes reciben/utilizan en última instancia el producto o servicio). Veamos los siguientes casos:
  • Con outsourcing parcial (Op). Una parte del equipo ejecutor es personal de la empresa responsable del producto/servicio y otra parte es personal de una o más empresas proveedoras. 
  • Con outsourcing total (Ot). Todo el equipo ejecutor es personal de una o más empresas proveedoras. 
Además, el personal de la empresa proveedora puede estar en la empresa que contrata el outsourcing (Oin) o fuera de ella (Oout).

Las prácticas ágiles (de entre las presentadas en Carta de prácticas ágiles) que podrían verse afectadas en mayor medida, y dependiendo del escenario de outsourcing, son las siguientes:
  • Equipo Cross-functional; que el equipo sume entre sus miembros las habilidades para abordar todas las actividades necesarias para terminar el trabajo.  
  • Cliente (PO, Product Owner) en estrecho contacto con el equipo y altamente disponible, incluso si es posible, que esté in-situ.
  • Promover que los miembros del equipo en su trabajo lleguen a conocer todas las partes del producto o servicio que han sido encargadas al equipo.
  • Co-localización de los miembros del equipo, todo el equipo trabajando en el mismo espacio físico.
Nótese que se trata solo de 4 prácticas de entre las 42 presentadas en dicha Carta de prácticas ágiles. Con lo cual podemos afirmar que el outsourcing no impide totalmente la implantación del enfoque ágil, sino que puede constituir un obstáculo para algunas prácticas.

A continuación veremos el impacto que puede tener cada uno de los escenarios de outsurcing respecto de las prácticas señaladas, y lo haré estableciendo tres niveles de impacto: no afecta, puede afectar y afecta, caracterizados con emoticonos en la siguiente tabla resumen. Supondré que en cualquiera de los anteriores escenarios de outsourcing el PO (quien decide qué es lo que debe hacerse en términos del producto o servicio) no está en la empresa proveedora sino en la empresa que contrata a dicho proveedor. Además, por simplicidad asumiré que el trabajo se deja en manos de una sola empresa proveedora (si fuesen varias probablemente se amplificaría el efecto negativo).

La tabla refleja una cuestión obvia: si el personal externo está en la empresa contratante (y está integrado como parte del equipo, o es en sí mismo todo el equipo) el outsourcing no tendría efectos negativos. Otra reflexión derivada de la tabla es que si todo el trabajo lo realiza el proveedor fuera de las instalaciones del contratante, esto afectará negativamente al contacto entre el cliente y el equipo. Pero respecto de otras prácticas, puede que no se vean afectadas (y son prácticas que se podrían aplicar en el equipo del proveedor). Finalmente, como era de esperar, el escenario que afecta más negativamente es el de outsourcing parcial y con personal fuera de las instalaciones de la empresa contratante.  Desgraciadamente, este último escenario es el más frecuente. Sin embargo, según lo visto hay dos alternativas que se podrían intentar: trasladar al personal del proveedor a las instalaciones del contratante, o si tiene sentido, externalizar todas las actividades (no solo parte de ellas) y promover el agilismo en la empresa proveedora y en su relación con la empresa contratante.

Según lo anterior, el factor más determinante que conlleva que el outsourcing afecte negativamente a prácticas ágiles es la deslocalización del equipo encargado del producto o servicio. Sin embargo, la deslocalización es ya un desafío para equipos distribuidos geográficamente aun sin practicar outsourcing.

Finalmente, hay que reconocer que, si bien no es determinante, la comunicación (entre los miembros del equipo y con el cliente) y la actitud del equipo, en presencia de outsourcing, requieren una mayor atención y esfuerzo para evitar que se vea afectada por protocolos de interacción.

jueves, 4 de abril de 2013

Agile Roadmap: el primer paso para la implantación de prácticas ágiles

Un Agile Roadmap es la hoja de ruta para la implantación de prácticas ágiles en un equipo de trabajo. Es equivalente a un Improvement Backlog para un equipo de trabajo, es decir, una lista ordenada de mejoras de proceso que se quiere ir implantando a lo largo del tiempo en el equipo de trabajo.

Para poder elaborar un Agile Roadmap se necesita conocer y entender el conjunto de prácticas ágiles que ofrecen los métodos ágiles. En Carta de Prácticas Ágiles: Arma tu propio menú ágil propongo una lista de prácticas ágiles, y además, éstas están planteadas y descritas de forma general para que puedan ser comprendidas y aprovechadas por equipos de trabajo cuyo ámbito no es de desarrollo o mantenimiento de software (la mayoría de la bibliografía ágil es del ámbito software). Comentaré al final de este post acerca de AGILE Roadmap+, un sitio que hemos desarrollado para apoyar en el diagnóstico y evaluación de prácticas ágiles.

Un Agile Roadmap implícitamente reconoce el hecho que es difícil y muchas veces no recomendable implantar muchas prácticas a la vez y en toda su profundidad (lectura recomendada ¿Revolución o evolución hacia el agilismo?). Por esto es útil tener una lista ordenada de prácticas candidatas que podrían irse implantando paulatinamente. También implícitamente un Agile Roadmap centra el foco en la aplicación de prácticas, NO en conseguir aplicar una metodología ágil en particular.

Un Agile Roadmap debería ser el resultado de un diagnóstico y evaluación del contexto del equipo de trabajo. En nuestra experiencia en implantación de prácticas ágiles hemos ido refinando un protocolo para este trabajo de diagnóstico y evaluación, el cual consta de los siguientes pasos:
  1. Seleccionar el equipo de trabajo en el cual se aplicarán las prácticas ágiles. Nuestra aproximación al respecto es siempre bottom-up, es decir, implantar trabajando muy estrechamente con cada equipo. Si bien es necesario hacer un trabajo previo de promoción hasta un determinado nivel directivo (el suficiente para conseguir el apoyo de la iniciativa), el trabajo de implantación se hace con el equipo como un todo, no debe ser impuesto desde "arriba" ni debe dejarse a la motivación y esfuerzo heroico de algunos integrantes del equipo.
  2. Estudiar los productos, servicios y/o proyectos encargados al equipo seleccionado. Obviamente lo ideal sería que el equipo sólo trabajase en un producto, servicio o proyecto, pero desgraciadamente suele ser frecuente que el equipo es responsable de varios trabajos diferentes. Esto puede constituir un mayor desafío para la implantación y puede que nos lleve a centrarnos en la aplicación de prácticas en solo algunos de los trabajos del equipo, ir paulatinamente aplicando prácticas a los distintos ámbitos de trabajo del equipo. 
  3. Evaluar globalmente el tipo de trabajo encargado al equipo y su posible diversidad. Hay dos factores determinantes: (a) si se trata de un producto (desarrollo y/o mantenimiento del producto) o de un servicio y (b) cómo se organiza el trabajo, si se quiere (y puede) planificar el trabajo o si lo que interesa en atender el trabajo en la medida que se recibe. Respecto de (a), si el trabajo del equipo no está asociado a un producto simplemente se deberían descartar ciertas prácticas que son claramente orientadas a trabajo con productos. En el caso (b), dependiendo de si el trabajo se planifica o si se atiende según se recibe, correspondientemente hay ciertas prácticas aplicables a uno o a otro caso. Para un mismo equipo puede haber mezclas de situaciones respecto de (a) o (b), por ejemplo, el equipo se encarga del desarrollo de cierto producto pero también es responsable de unos servicios, o si además, para unos casos de producto o servicio interesa planificar y para otros no. Es muy importante que para cada caso se adapte adecuadamente el proceso, es decir, que se apliquen las prácticas más adecuadas. Por esto, si hay una diversidad de trabajos encargados al equipo (cada uno con diferentes características) sería conveniente tener diferentes Agile Roadmaps para cada tipo de trabajo del equipo. Por ejemplo, sería un error que todo el trabajo del equipo se estime y planifique siendo que, también el equipo está encargado de un servicio cuya demanda no es previsible ni se quiere agrupar y planificar. 
  4. Establecer los objetivos que pretende la iniciativa de mejorar de proceso. Este paso obliga a una reflexión y diagnóstico respecto del desempeño del equipo en en contexto del producto/servicio estudiado. Cada práctica ágil contribuye en cierta medida a ciertos objetivos con lo cual, evaluando la importancia de los objetivos en el contexto del equipo de trabajo se pueden seleccionar prácticas candidatas según su contribución a dichos objetivos. 
  5. Acotar las prácticas candidatas. Las prácticas candidatas estarán acotadas por la evaluación realizada en el paso 3, es decir, según los factores (a) y (b) algunas prácticas candidatas serían descartadas para los pasos siguientes.
  6. Establecer el nivel de aplicación de cada práctica. Es importante evaluar si una práctica está ya aplicada, no aplicada, parcialmente aplicado o simplemente no interesará aplicarla. Un práctica no aplicada tendrá un mayor efecto que una práctica que se está ya aplicando de forma parcial.
  7. Establecer el nivel de dificultad que tendrían los desafíos de implantación de cada práctica. Las prácticas no aplicadas o parcialmente aplicadas ofrecen un margen de mejora si se implantan, sin embargo, hay que tener presente los desafíos que normalmente debe enfrentar cada práctica.
  8. Evaluar la aplicabilidad de cada práctica. Con toda la información recopilada en los pasos anteriores puede establecerse una valoración de la aplicabilidad de la práctica, siguiendo las siguientes directrices: valorar positivamente la importancia de los objetivos a los que contribuye la práctica y valorar también la propia contribución, valorar positivamente el nivel de aplicación actual de la práctica (mayor si la práctica no está siendo aplicada), valorar el nivel de dificultad de los desafíos de la práctica (mientras menos mejor), valorar el esfuerzo de aplicación de la práctica (mientras menos mejor).
Una ayuda adicional para elaborar tu Agile Roadmap la tienes en el sitio agile-roadmap.tuneupprocess.com. Allí tienes disponible gratuitamente la automatización parcial de los pasos 1 al 8, que de forma asistida te permitirán conseguir un Agile Roadmap.

Además, a continuación dos enlaces relacionados: