¿Es Scrum para la innovación?

Aunque Scrum fue pensado para proyectos de desarrollo de software, puede aplicarse con éxito en muchos proyectos de innovación.

¿Cuáles son las características de Scrum que son útiles para proyectos de innovación?

• Flexibilidad para adaptarse a los cambios a medida que aprende más sobre las posibilidades técnicas y las necesidades del cliente.
• Flexibilidad para adaptarse a las fases inciertas e impredecibles que necesitan un ensayo y error continuo.
• Un enfoque para descomponer problemas complejos en problemas manejables.

Scrum tiene prácticas y principios integrados que ayudan con ese retoque, aprendizaje y experimentación como:

• los sprints
• retrospectivas y revisiones de sprint.
• el producto y la acumulación de sprint.
• las historias de los usuarios
• El producto se incrementa.

Cuanto más inestable sea la solución / arquitectura del sistema, más útil será Scrum porque habrá más incertidumbre.

Mi experiencia en llevar a Scrum a la innovación y la I + D fuera del software es que produce algunos resultados sólidos en métricas duras (tiempo de entrega, costo) y suaves (satisfacción del cliente).

Pero el principal factor de éxito es la subcultura y el estilo de gestión de la empresa de I + D. Si es una metodología rígida, basada en el libro, impulsada, será difícil. Si se trata de una cultura orientada a los resultados, podrá ofrecer excelentes productos.

Si trabaja en biotecnología, productos químicos, nuevos materiales o está tratando de refinar una nueva tecnología, Scrum se adaptará de manera muy natural a la experimentación necesaria.

Si desea entregar nuevos productos de hardware discretos (mecánicos, eléctricos, electrónicos) más rápido, Scrum también puede ser muy útil.

Si desea innovar en el proceso y el modelo de negocio, Scrum está bien.

Finalmente, aunque los proyectos de entradas enormes como el aeroespacial parecen el ámbito natural de los proyectos de cascada tradicionales, algunos de los proyectos más exitosos (Skunk Works o el Programa Espacial Soviético con Korolev) han aplicado al menos una mentalidad ágil.

David Coloma

Consultor en agilidad para negocios en Itnove.

Aquí están mis dos centavos. Estoy de acuerdo con usted en lo que dijo: Scrum es un enfoque incremental para el trabajo a realizar. Pero no solo se limita al desarrollo de productos, creo que con pequeños ajustes puede aplicarlo en cualquier cosa tangible o no tangible. Supongamos que quiere construir una estrategia. Puede crear una cartera de pedidos con todas las ideas posibles y luego trabajar / investigar / debatir sobre el conjunto de esas ideas en iteraciones. También scrum o, para el caso, Agile promueve equipos autónomos y los equipos autónomos aportan naturalmente innovación a la organización.

Si observa la estrategia de aplicación en capas de ritmo de Gartner, notará tres capas:

La capa intermedia es el punto ideal para las metodologías ágiles / iterativas, y la capa inferior también puede ser una cascada; su pregunta, sin embargo, se relaciona con la capa superior: innovación

A menudo, cuando las organizaciones saben que necesitan algo pero aún no pueden articularlo, necesitan invertir en investigación rápida, prototipos descartables, necesitan ver algo en cuestión de semanas y financiarlo con los gastos operativos (es decir, no es un proyecto ) Vi esto al configurar y guiar la innovación de productos en una importante empresa de telecomunicaciones en Nueva Zelanda, y al consultar posteriormente a varias otras organizaciones de productos.

En ese entorno, definitivamente puede beneficiarse de algunas técnicas ágiles, como el boxeo temporal, pero no tiene el espacio o el tiempo para establecer un ecosistema formal de scrum. De hecho, la sobrecarga de construir un equipo con las habilidades necesarias para una idea particular consumiría el tiempo en el que deberías producir maquetas desechables y prototipos de papel. Por lo tanto, podemos ser ágiles, sin duda, pero solo podría considerar scrum si su base tecnológica es limitada (es decir, siempre será un droide / iOS) y podría establecer un equipo de innovación / I + D para ubicarse permanentemente.

Escribí sobre esto en:
http://davidjcmorris.com/index.p …

No puedo decir que sea por innovación, pero sí puedo decir que Scrum es bueno para la entrega rápida y eficiente del proyecto, especialmente los pequeños.
El progreso en Scrum se divide en sprints (2 semanas de duración). Las especificaciones en términos de cada sprint se describen en una cartera de productos. Se incluyen características, diseños, correcciones de errores, trabajo técnico y requisitos no funcionales. Después de cada sprint, el equipo lanza una versión demo con un cierto conjunto de características, completas y probadas. Scrum es simple, todo está determinado y definido.

Puede consultar este artículo para obtener más información sobre Scrum, sus beneficios y dificultades, miembros del equipo y peculiaridades: metodología ágil para la gestión de proyectos | Scrum y Kanban | YourServerAdmin

Estoy muy interesado en este tema. Incluso hice una pregunta relacionada: ¿Cuál sería un enfoque práctico para gestionar la innovación en una empresa de software de tamaño mediano a pequeño?

Solo un par de citas de Mike Cohn (uno de los contribuyentes a la invención del Scrum):

1. Lea en ¿Deberían los proyectos ágiles ser innovadores?

Scrum a mediados de la década de 1990 (cuando lo implementé y lo vi implementado en ese entonces) se trataba de encontrar soluciones innovadoras. Los equipos recibieron un problema y un mes (o cuatro semanas) para resolver el problema. Con tanto tiempo, los equipos pudieron probar uno o más enfoques innovadores potenciales antes de tener que volver a un enfoque más seguro y probado.
En la versión actual de Scrum, muchos equipos se han obsesionado demasiado con poder decir que terminaron todo lo que pensaban que harían. Esto lleva a esos equipos a comenzar con el enfoque seguro. Muchos equipos nunca prueban ideas descabelladas que puedan conducir a soluciones verdaderamente innovadoras.

2. “The plus 1 week”, una técnica que proviene del libro de Mike Cohn “Agile Estimating and Planning” (leer en el blog de Ron Miller: Innovación en Scrum: The plus 1 week).

Cada miembro del equipo elegiría uno o dos proyectos que podrían completar dentro del tiempo de la semana. Luego trabajarían de manera independiente durante la semana y al final de la semana celebraríamos una sesión “Show N Tell” donde invitaríamos a todos los otros equipos de scrum a ver el trabajo realizado.

Algunas famosas políticas de gestión de la innovación que podrían combinarse con Scrum:

1. Política del 20% de Google: ¿Cómo funciona en la práctica la política de Google Innovation (Google Innovation Time Off) (20% de tiempo)?

2. Programa Blue Sky de Apple: Blue Sky de Apple proporciona más beneficios a los empleados

3. Hackatones corporativos (generalmente con precios) utilizados en empresas como Twitter, Facebook, Google, Yahoo, LinkedIn, eBay y Atlassian.

Me encantaría conocer más políticas como estas.

Muchas compañías realmente no usan SCRUM, pero lo usan solo para la implementación de algún elemento del trabajo atrasado. Adoptan la filosofía, y es bueno, pero muchas veces se olvidan de analizar el “por qué” como usted dice.
Hablando en términos de reuniones, no hacen la revisión del sprint ni la preparación del trabajo atrasado. Esta última reunión es realmente importante para la innovación, pero no es un estándar en SCRUM, por lo que a menudo se ignora.

Desde mi perspectiva, Scrum está específicamente diseñado para fomentar la innovación en el desarrollo de productos. Sus raíces se derivan de “The New New Product Development Game”, que requiere un enfoque ágil e iterativo incremental para crear nuevos productos. Se basa en los principios de colaboración, inspección y adaptación, retroalimentación y experimentación para desarrollar un producto con un conjunto incierto de requisitos, en un entorno en rápido cambio donde las necesidades finales finales no se pueden predecir de antemano.

Utilizamos Scrum para la entrega, no para la innovación.
Solo asignamos ~ 80% del tiempo de los desarrolladores a cada Sprint.
El otro 20% es para que hagan lo que quieran.

Conocen nuestro plan de negocios, nuestra estrategia, nuestra hoja de ruta.
Conocen a nuestros clientes, nuestros productos y nuestra industria.
Confiamos en que hagan algo útil.

La innovación ocurre en este 20%.

Como resultado, prácticamente no tenemos “picos de investigación” en el Sprint.
La productividad ha aumentado dramáticamente.
Tenemos soluciones innovadoras, ideas y algoritmos.
El equipo también es mucho más feliz.

Solo donde scrum se implementa la práctica de ingeniería dentro de una empresa que practica técnicas Lean Startup.

Scrum no te dice qué construir. La innovación tiene que venir del equipo. Con un buen proceso de hoja de ruta con visión de futuro y una transición bien pensada de la idea a la hoja de ruta al scrum de backlog de Sprint, se puede dar a los equipos un amplio margen para innovar. Scrum no te dice cómo innovar; pero, los equipos scrum comprometidos y autodirigidos, con una visión clara y una hoja de ruta, están en la mejor posición para innovar.