Hay ciertos principios que proceden el desarrollo del software y que han acabado trasladándose a las metodologías de gestión empresarial y de negocio de cualquier tipo de empresa.

Una primera aproximación a las formas “ágiles” de gestión de proyectos es aplicando algunos de sus principios generales, por ejemplo estos principios básicos:

• KISS: Mantener los procesos lo más simples posible. (Keep It Simple, Stupid)
• YAGNI: Evitar perder tiempo en cosas innecesarias. (You Aren't Gonna Need It)
• DRY: Evitar duplicidades. (Don't Repeat Yourself)

Ver 5 principios muy ágiles que deberías tener presentes

Además, los “frameworks” (también llamados “marcos conceptuales”) ágiles, por ejemplo Scrum, se han mostrado muy útiles en organización de equipos y procesos fuera del mundo del desarrollo del software, como muestran las siguientes referencias.

Ver Scrum Master: El nuevo líder que las empresas quieren

Sin embargo también es posible hacer “postureo ágil”, recaer en viejos métodos del management o usar los métodos ágiles de formas rígidas. Por eso hay que evitar el “lado oscuro” de la agilidad.

Es bastante difícil diseñar la cultura de una empresa, porque la cultura nos confronta como el reflejo completo de las operaciones, prácticas y comportamientos diarios en la empresa. Una forma de trabajar (cultura) que no se adapte a la mentalidad ágil será el obstáculo más grande y difícil para convertirse en una empresa ágil. Por lo tanto, los estudios son muy importantes para el cambio cultural. Sin embargo, la cultura no es un fenómeno que se puede cambiar escribiendo palabras sexys en las paredes o definiendo con algunas presentaciones. La cultura de una empresa es creada por prácticas y comportamientos colectivos en el flujo de trabajo diario, no por los discursos o frases geniales. Por lo tanto, es necesario trabajar en los puntos de vida de la cultura en las prácticas diarias. ¿Me pregunto como? No existe una sola forma de hacer esto, sino que si está interesado, le recomiendo que lea los temas de ValuesJams y Values Practices Map.

Fuente: https://www.scrum.org/resources/blog/agile-hr

Pongamos un ejemplo de otra compañía. IBM Es la quinta marca más valiosa del mundo. Superando una grave crisis en la década de 1990, la compañía pudo recuperarse a principios de la década de 2000 y comenzar a crecer nuevamente. En este punto, no se puede negar el papel de Samuel Palmisano, quien llegó a la compañía como CEO en 2002, en el crecimiento de la compañía. En una entrevista con Harvard Business Review en 2004, Palmisano esencialmente dice lo siguiente:

‘… Podría emplear todo tipo de procesos de gestión jerárquicos tradicionales. Pero no funcionarían en IBM, o, argumentaría, en un número cada vez mayor de empresas del siglo XXI. Simplemente no se pueden imponer mecanismos de “comando y control” (ordeno y mando) a una fuerza laboral grande y altamente profesional… Pero incluso si nuestra gente aceptara este tipo de sistema de gestión jerárquico tradicional, nuestros clientes no lo harían. Como aprendimos en IBM a lo largo de los años, un sistema de arriba hacia abajo puede crear una burocracia sofocante que no permite la velocidad, la flexibilidad y la innovación que los clientes esperan hoy… Necesitamos un sistema de gestión basado en valores, un sistema de gestión para empoderar a las personas mientras nos aseguramos de que están haciendo las llamadas correctas de la manera correcta… Los valores son la base de lo que hacemos, nuestra misión como empresa. Son una piedra de toque que permite la toma de decisiones descentralizada…’

A partir de esta visión Palmisano comenzó a trabajar en la creación de una nueva cultura y sistema de valores de IBM en 2003, donde se esperaba que todos los empleados participaran. Si lo desea, puede leer la entrevista que he compartido o visitar el sitio web de la compañía para ver las reflexiones de este ejercicio hoy. Sin embargo, me gustaría llamar su atención sobre otro detalle aquí. Este ejercicio, redefiniendo los valores de la empresa, se realizó con el liderazgo del CEO personalmente y con la inclusión de la mayor cantidad posible de empleados de la empresa. Palmisano organizó un ejercicio en línea 'ValuesJam' de tres días de duración para facilitar la participación de todos los empleados y reunir sus opiniones e ideas. ValuesJam es en realidad una práctica que proviene de Jam Sessions de grupos de música, donde los músicos se juntan e improvisan. ValuesJam es el nombre dado a los empleados que se unen para debatir libremente los valores de la compañía sin que haya una agenda establecida. Al final de este ejercicio de 3 días en IBM, en palabras de Palmisano, se reunió “una montaña” de comentarios. Los comentarios fueron luego examinados por un grupo de expertos y después se hizo un análisis resumido que se distribuyó entre los empleados para su finalización.

Fuente: https://www.linkedin.com/pulse/agile-company-identity-mehmet-yitmen/

Ver también La remontada de IBM y cómo definir los valores

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. 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.

Fuente: https://www.itnove.com/es/blog/como-aplicar-scrum-fuera-del-software

En concreto, H. Takeuchi e I. Nonaka, en el artículo “The New New Product Development Game” , 1986, describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales. Este famoso artículo analizaba las características comunes en el proceso de desarrollo de productos exitosos en los sectores de la automoción, el hardware y la electrónica, concluyendo que los procesos que diferenciaban estos proyectos, respecto de otros menos exitosos, fueron el enfoque iterativo de prueba y error, el solapamiento de las distintas fases y su gestión por equipos de desarrollo multidisciplinares y autogestionados. Este enfoque en el desarrollo de nuevos productos implicaba la interacción constante del equipo de principio a fin “desplazando la melé” (scrum), en contraposición al enfoque secuencial de las metodologías tradicionales.

La principal diferencia entre las metodologías tradicionales de gestión de proyectos y Agile radica en el papel que juegan las iteraciones durante el proyecto. Los proyectos relacionados con contenido inmaterial, como el software y el desarrollo de conocimiento, tienen mayor facilidad para iterar, y aprovechan la flexibilidad que les proporciona Agile. Es evidente, que los cambios constantes y las iteraciones en este tipo de proyectos son asumibles y técnicamente viables. Por el contrario, en los proyectos cuyo resultado hace un uso intensivo y caro de materiales, como los proyectos de construcción, las iteraciones son irrealizables por la propia naturaleza del edificio, o el coste derivado de los cambios durante el desarrollo del proyecto.

Ver “Scrum (rugby)” en Wikipedia: https://es.wikipedia.org/wiki/Scrum_(rugby)

Imagen representativa de los métodos “cascada” (secuencia de trabajos)

Imagen representativa de métodos “scrum” (desplazar al grupo)