×
×

Cómo se aplica Scrum en proyectos no TIC

Scrum es una metodología extremadamente popular en desarrollo de software que ahora empieza a aplicarse en áreas de negocio para gestionar sus proyectos. Algunos de los ámbitos en los que se está aplicando con éxito son las campañas de márketing para mejorar las ventas, mejora de procesos, reducción de costes, ejecución de planes estratégicos o reestructuraciones y transformaciones organizativas.

Así pues, una de las cuestiones básicas respecto a Scrum que se preguntan los responsables de los diferentes Departamentos de las empresas es cuál es la forma de aplicarlo en sus áreas.

Scrum se aplica en proyectos que no son de TI de forma similar a cómo se hace en proyectos de tecnologías de la información. Dado que en este modelo no existen prácticas específicas de TI, se debería poderlo aplicar sin excesivos problemas en otro tipos de proyectos.

Pero -y esto es un gran PERO- hay que ser consciente de que en Scrum hay integrados determinados supuestos que sí que nacen del entorno TIC. Si éstos no se entienden plenamente, se puede acabar implementando Scrum de forma subóptima en otros tipos de proyectos.

¿Cuáles son estos supuestos de Scrum?

Un primer aspecto es el alto coste de la reversibilidad que existe en determinados proyectos no TI. Los proyectos de desarrollo de software tienen bajos costes de reversibilidad, al menos hoy en día aunque no en el momento en que se crearon los métodos en cascada. En software es relativamente barato modificar el trabajo ya realizado. Pero en determinados proyectos (p. ej. de desarrollo de nuevos productos) existen algunos hitos que, una vez pasados, incrementan enormemente los costes de cambiar el trabajo de fases anteriores.

Un segundo aspecto es que Scrum es excelente para proyectos en los que el equipo o el cliente no saben al principio realmente todo lo que se necesita de la solución. Esto sucede en proyectos muy innovadores, entornos muy fluidos o con proyectos en los que el cliente no está muy familiarizado. Para resumir, en proyectos en los que habrá mucha experimentación, mucho ensayo y error. En muchos productos maduros que no son de software existen arquitecturas de producto dominantes que evitan gran parte de esta incertidumbre.

En tercer lugar está el supuesto de la agilidad que el valor de la solución se puede entregar incrementalmente a través de iteraciones. Esto es cierto en software, donde se puede empezar con una solución muy sencilla y entonces entregar un contínuo de versiones que son mejores y más complejas que las anteriores. Pero cuando el proyecto implica desarrollar sistemas enormes, complejos y altamente integrados -como, por ejemplo, aviones, coches o plantas de generación eléctrica- no es tan fácil descomponer el producto para desarrollarlo incrementalmente.

Pese a este impedimento, existen muchas situaciones en las que se puede aplicar la lógica iterativa o bien la incremental. Así, en el desarrollo de nuevos productos (incluso en el caso de los altamente integrados con arquitecturas dominantes bien conocidas) existen determinadas fases fases del desarrollo que requieren una mayor fase de experimentación (p. ex. la fase de exploración y descubrimiento, o bien el diseño) y las iteraciones son una forma de afrontar los retos de moldear una solución en condiciones de alta incertidumbre. Por otro lado, cuanto mayor es la novedad del producto, mayor será la lejanía de las arquitecturas y soluciones ya probadas y, consecuentemente, mayor importancia tendrá la experimentación y la prueba y error.

En cuarto lugar, está el supuesto del bajo coste de los errores. Cuando se desarrolla una aplicación o portal web gratuito el cliente no será tan exigente como cuando se está entregando un producto extremadamente caro cuyos errores pueden costar cantidades masivas de dinero e incluso vidas. En el segundo caso se deberán realizar unas pruebas muy extensas de calidad antes de la entrega. En este caso se puede desarrollar el producto incrementalmente pero el alto coste del testing puede dificultar la entrega de versiones intermedias al cliente.

En quinto lugar, el dimensionamiento de las historias de usuario es tal que a veces no pueden ser divididas de forma que puedan ser desarrolladas en un sprint. Un ejemplo son ciertos componentes de alta tecnología.

En sexto lugar, un proyecto de software necesita menos roles y son mucho más versátiles que en otras disciplinas de desarrollo de nuevos productos. En un típico proyecto de ingeniería se pueden requerir ingenieros con especialidades en mecánica, electrónica, en software, materiales,… con conocimientos y habilidades que están radicalmente mucho más diferenciados que en software. Esto permite que los equipos de software sean mucho más pequeños y simples que en otras disciplinas.

Todos los supuestos anteriores no impiden que se aplique Scrum y enfoques ágiles fuera del software.

Al contrario, éstos son excelentes si se entienden realmente cuáles son las variaciones a adoptar respecto a la metodología básica. Existen soluciones -p. ej. feature toggles, Scrums de Scrums, release trains, component teams, metodologías escaladas,…- para obtener las máximas ventajas ajustándose a sus peculiaridades del tipo de proyecto y solución a desarrollar.

De hecho, las metodologías en cascada presentan estos mismos problemas y los mecanismos que utilizan (planificación previa detallada, procedimientos de gestión del cambio, etc.) no sólo no los solucionan sino que son mucho más pesados que los utilizados por la agilidad.

Por otro lado, Scrum se adapta de forma excelente a ámbitos que admiten un enfoque progresivo e iterativo como el márketing y las ventas, la mejora de procesos, la organización y el cambio estratégico, la investigación más básica o el desarrollo de tecnologías. Son ámbitos en los que el éxito del proyecto depende enormemente de la capacidad de adaptación a circunstancias cambiantes y la explotación de oportunidades no planificadas.

Es por esto por lo que aplicar Scrum y la agilidad a áreas de negocio requiere especialistas tanto en las metodologías como en estas áreas que dispongan de una experiencia amplia fuera del software para extraer de la agilidad el máximo valor para su empresa.

 ¿Quieres saber más sobre aplicar Scrum fuera de software?

Si quiere saber más sobre como aplicar Scrum a sus áreas de negocio, pídanos más información haciendo click aquí.