¿Agile está obstaculizando la creatividad y la innovación?

Ágil define cómo un equipo organiza y controla el trabajo. La creatividad requiere libertad (tiempo, pensamiento), por lo tanto, cualquier tipo de control va en contra de la creatividad. Como señala correctamente, no puede trabajar solo en una función arbitraria que concibe como buena para el producto o la empresa, sino que debe adherirse a una acumulación prioritaria. La creatividad se limita a las formas en que abordas la tarea en sí.

La pregunta es, ¿de dónde provienen las historias de usuario, las tareas o lo que sea? Un buen gerente de producto escucharía al equipo, un buen equipo hablaría si descubre una extensión útil. Entonces debería ser un problema de priorización cuando la tarea estará en la cartera de pedidos. De esta forma, las ideas del equipo se introducen en el producto, pero el negocio sigue impulsando la decisión, y a veces será difícil de entender si su proyecto favorito está enterrado bajo una tonelada de otras tareas.

Creo que las metodologías ágiles tienen un gran potencial para fomentar la creatividad o extinguir las barreras (ver el trabajo de Amabile sobre las barreras de la creatividad). A largo plazo, los procesos de gestión de la innovación deben inculcarse dentro de los procesos ágiles, aparte de las revisiones y retroactivos, para equilibrar el poder de las partes interesadas en esta parte del proceso (y también hay otras necesidades de equilibrio en otras áreas).

En muchos casos, la ejecución de Scrum llega demasiado lejos y toma el proceso demasiado importante con una tendencia a micro-administrar cada aspecto de un proyecto (tiranía de la historia del usuario) o controlar cada minuto dedicado a las tareas.

También tiene razón en que, si bien ágil se concibió para dar poder a los desarrolladores, hasta cierto punto los ha debilitado, ya que los procesos de toma de decisiones se definen de una manera en que la información que flota en el negocio es muy limitada. Los mecanismos de control estrictos (gráficos de quemado, stand-ups diarios, retros, etc.) inculcan aún más esta impresión. Tenga en cuenta que Scrum es un enfoque para estructurar algo que de todos modos debería estar allí en un proyecto (pero a veces se olvida, por ejemplo, ciclos cortos de retroalimentación) y no deshacerse de ningún patrón de comunicación. ¡Cuando haces lo ágil y de repente el equipo solo habla en los momentos definidos en que lo estás haciendo mal!

Creo que hay dos partes aquí. Una es la idea de explorar generalmente fuera del trabajo normal, y la otra es innovar como parte del trabajo. Agile puede ser la tiranía de lo urgente, pero no necesariamente mata la innovación / creatividad. Con algunas pautas, creo que en realidad promueve la innovación / creatividad.

Date tiempo. En Scrum, los equipos explícitamente son los que deciden cuánto trabajo realizar. Si siente que necesita tiempo para pasear, haga menos trabajo. ¿Es este motín? Si el equipo solo tomó una pequeña historia cada sprint y pasó todo su tiempo aprendiendo cosas no relacionadas con el negocio, sí, podría ser un problema, pero ¿existe realmente un riesgo de esto? Confíe en que el equipo se autorregulará. Aunque Agile no otorga explícitamente este derecho a los equipos como lo hace Scrum, creo que se deduce con bastante facilidad de: “Desarrolle proyectos en torno a individuos motivados. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo”.

Pregunta porque. Asegúrese de comprender por qué está construyendo cosas, en lugar de solo construir lo que le dicen. Si el por qué es “para que el usuario pueda llegar a un lugar rápido”, eso abre la puerta a ideas sobre mochilas propulsoras y montar canguros, mientras que el “construir una bicicleta” cierra esas opciones. En última instancia, debe acordar como equipo lo que está construyendo, pero comprender el por qué le da la oportunidad de desafiar las suposiciones sobre lo que está construyendo. Puede repetir esto a cualquier escala, lo que permite la innovación en todas sus actividades.

Concéntrese en objetivos, no en listas. Si está creando una lista de características, es probable que reprima la creatividad. Si, en cambio, te enfocas en objetivos más amplios (objetivos de sprint a nivel de iteración o cosas como OKR en un nivel de iteración múltiple), te das libertad para maniobrar. Claro, puede tener una lista de historias o características al principio, pero deje que estas se dobleguen al servicio de los objetivos, no al revés. Además, tenga cuidado de definir objetivos basados ​​en el por qué (por ejemplo, para resolver el problema x) en lugar de qué (por ejemplo, implementando la solución y), o caiga en la misma trampa de sofocante creatividad.

No confunda creatividad / innovación con indulgencia. La creatividad puede venir en un instante, y puede ser fea. Por ejemplo, sugerir que codifique un valor en un prototipo temprano (en lugar de pedirle al usuario) no es emocionante, sexy o incluso escalable; sin embargo, en términos de llegar a una respuesta sobre el valor de un trabajo, uno puede ver fácilmente cómo es un ángulo creativo. Piensa un poco de innovación aquí y allá todos los días, no saltos masivos.

Recuerde que los límites pueden mejorar la creatividad. Escribir un poema en metros estrictos te obliga a ser creativo. Las limitaciones de presupuesto en la película inicial de Star Wars obligaron a Lucas a tomar decisiones creativas que le dieron a la película algunos de sus toques únicos. Tener tres segundos para que la pelota baje al campo puede obligar a un equipo a plantearse enfoques inteligentes.

Esta es una muy buena pregunta. La respuesta depende menos del ágil en sí mismo y más del entorno en el que se está utilizando el ágil. Por ejemplo, a las grandes empresas en particular a menudo les resulta difícil familiarizarse con Agile rápidamente. Tienden a estar anclados en las técnicas tradicionales de gestión de proyectos que no conducen a la innovación rápida. En este tipo particular de entorno, si comienza en pequeña escala, puede usarse ágil para aumentar la tasa de innovación y ayudar a las grandes empresas a lanzar nuevos productos y servicios al mercado más rápido.

Si estás interesado en aprender más, mira esto: 3 formas de innovar más rápido usando Agile | Waracle

Esto no es diferente a la cascada, bienvenido a la ingeniería de software.

Su trabajo como ingeniero es implementar las funciones que la administración considera importantes, no explorar su propia creatividad. si desea hacerlo, debe ser en su propio tiempo, no en el de la empresa. Trabajé en el servidor que se convirtió en Project Darkstar at Sun durante 5 años noches y fines de semana hasta que tuve la oportunidad de traerlo a la oficina.

AHORA * algunas * compañías con visión de futuro tienen una política llamada “20%” de tiempo en el que obtiene 1 día a la semana para trabajar en lo que USTED desea trabajar. Esto es mucho más común en la investigación, así que si eso es lo que quieres hacer, te sugiero que busques un Máster o un Doctorado si aún no los tienes.

PD: Por eso se llama “trabajo”. Llegar a hacer lo que * tú * quieres hacer se llama jugar. Incluso su jefe tiene un jefe que establece sus objetivos para ellos. Todo el camino hasta los niveles C que tienen que responder a los inversores.

La autoeducación constante es importante para construir una carrera, pero es * su * carrera, no sus jefes y debe hacerse en * su * tiempo, no en el suyo.

En un trabajo anterior al que asistí, este problema se abordó utilizando varios métodos:

– al final de cada iteración basada en la semana tuvimos una breve demostración por la mañana. Por la tarde asistimos a una retrospectiva. Mientras tanto, teníamos algo de tiempo libre para trabajar en lo que creíamos necesario. 4 o 5 horas de tiempo libre pueden no parecer mucho, pero aún es un comienzo para explorar nuevos caminos.

– algunas tareas exploratorias o de aprendizaje se insertaron en el trabajo atrasado como picas en el tiempo si el equipo pensaba que era útil. Por lo general, estos comenzaron con una reunión de tormenta de ideas, donde decidimos qué debería probarse y quién debería hacerlo y por cuánto tiempo. Estas tareas generalmente terminaban con una presentación de los resultados de la exploración al equipo.

En este entorno, no sentí que el equipo fuera menos creativo que en otros equipos más tradicionales (todo lo contrario) y en lo que todos estaban trabajando todavía era transparente entre sí.

También estoy de acuerdo con Berk en que trabajar el 100% del tiempo del equipo en la cartera no es razonable de todos modos. Siempre hay otras tareas que realizar que deben tenerse en cuenta, que pueden estar trabajando en la infraestructura, explorar nuevos marcos o herramientas, o incluso socializar con compañeros de té. Todo eso es necesario en un equipo que funcione sin problemas. No hacerlo es desmotivador, pero no se trata de Agile, sino de una buena gestión del equipo.

No es ágil, sino la mentalidad. Ninguno de los principios te pide que seas monótono. Pero la mentalidad obstaculizará no solo la innovación, sino también la adopción.

Aquí hay más sobre los elementos disuasivos: http://www.prasadgupte.com/blog/

Primero, es normal que en un entorno de trabajo quede poco espacio para sus propias cosas. Esa es solo la naturaleza del trabajo.

Pero ágil y especialmente scrum están diseñados para entregar software bajo alta presión con requisitos de cambio rápido, que no son demasiado complejos. Es realmente eficiente en eso, pero superará la creatividad de un equipo.

No soy fanático de ágil. Creo que lleva demasiado fácil al mal software. He visto a buenos programadores convertirse en cazadores de puntos de historias salvajes y dejar atrás un devastador. Debido a que corta las tareas, hace que falte una descripción general de una tarea. El impulso de elegir implementaciones concretas sobre las abstracciones hace que los cambios sean cada vez más difíciles de realizar. Junto con la baja cantidad de documentación y diseño, la cantidad de código incorrecto o “deuda técnica” se acumulará.

Thomas Kutschi tiene razón. Solo agregaría que puede agregar tareas de refactorización a una historia si es necesario (y la refactorización es bastante creativa); puede agregar picos arquitectónicos a su cartera de pedidos (donde un pico es una investigación de una solución a un problema); puede sugerir mejores formas de hacer una historia (y si está de acuerdo, hágalo) y puede sugerir nuevas historias al propietario del producto (y hacerlas si está de acuerdo).

Lo que no puede hacer es pasar el tiempo que otra persona está pagando por hacer lo que quiera. Para eso es tu tiempo libre.

No es el método, es el verdugo.
Si su organización implementa ágil con sentido común, no obstaculizaría la creatividad.
Si tenemos menos tiempo para procesar y más tiempo para proyectar, podemos desarrollar la creatividad. Es hasta la gestión.

PD: Causa de las guerras: las ideas son pocas pero las interpretaciones son muchas.