automovilJoe Justice, tras años de trabajo en el desarrollo y gestión de proyectos de software fundó Wikispeed en 2006, un innovador proyecto para desarrollar prototipos de automóviles aplicando los principios de scrum, TDD y programación orientada a objetos.
 
Combinando estos métodos Wikispeed construyó en 3 meses un automóvil modular con un consumo de 2,3 litros a los 100 kmts. Actualmente Wikispeed trabaja en proyectos como el desarrollo de un modelo de furgoneta para servicios postales a nivel mundial, un taxi de nueva generación, un automóvil de carreras ultraligero y un sedán de 5 plazas.

 

 

De todas formas no debería sorprendernos el uso de scrum en la manufactura industrial. Fue allí donde surgió ;-)

icebergHay proyectos que gestionan los requisitos con una pila de producto, y otros emplean un SRS (Software Requirements Specification).

La pila de producto es un formato ligero de documentación empleado en gestión ágil, mientras que el SRS es un modelo formal para la especificación requisitos de un proyecto de software empleado en gestión predictiva. Pero la característica que diferencia a los dos modelos de gestión no es el usar pilas de producto o documentos de requisitos.

 La clave no está en las prácticas que emplean los modelos de gestión, sino en los principios en los que éstas se basan.


En este caso, el principio ágil que está en la base es: “desarrollo incremental”. La agilidad produce y entrega el resultado en incrementos, siguiendo la evolución y concreción parelela de los requisitos. Por esa razón resultan más apropiados formatos como pilas de producto, que facililan la adaptación continua de los requisitos.

La gestión de un proyecto no es ágil por emplear prácticas ágiles, sino por aplicar principios ágiles. En este caso, la agilidad del proyecto no se debe al uso de una pila de producto, sino a realizar el desarrollo de forma incremental.

De esta forma, la agilidad en la en la dimensión operativa (agilidad técnica) se debe a los principios de gestión empleados, y éstos se llevan a cabo mediante prácticas de trabajo. Cuanto más apropiadas al tipo de proyecto y empresa sean las prácticas, y mayor el conocimiento y la experiencia de las personas que las ejecutan, mayor será el grado de agilidad técnica.

 

agilidad: principios valores y soporte

 

 

no ganttHay dos estrategias habituales para planificar y seguir el avance de un proyecto, que no se deben emplear en scrum.

La primera es calcular la duración de las tareas empleando unidades de tiempo concretas para predecir la ejecución como si fuera un proceso, y dibujarla en un diagrama de Gantt.
Esta estrategia es coherente para planificar trabajos "mecánicos": trabajos compuestos por actividades de ejecución procedimentada, pero no es adecuada para trabajos del conocimiento ni para trabajos creativos.

novela gantt

 

 

fractalEn la empresa conviven dos dimensiones: la operativa, que realiza los productos o servicios de la compañía; y la organizativa, que define y gestiona la cultura, estructura y modelo de gobernanza con el que se dirige .

A menudo se aborda la agilidad conjuntamente en las dos dimensiones, introduciendo modificaciones tanto en la gestión de proyectos y procesos de desarrollo, como en la cultura y modelo de gobernanza  (Agilidad en la empresa: ¿en el producto, en la cultura o en todo?).

Al considerar que la agilidad implica cambios operativos y organizativos de forma simultánea, no se valora por separado:

a) Si el producto servicio o proyecto de la empresa se puede construir de forma evolutiva, y si el hacerlo proporciona ventajas a los clientes o la comercialización.
b) Si la propiedad de la empresa desea cambios en la estructura o en el modelo de gobernanza, y si es consciente de las implicaciones de esos cambios.

Cuando lo que se quiere es crear entornos potenciadores de creación de valor, basados en las personas y su motivación, pero no se necesita o no se puede entregar de forma incremental, hacer ágil la empresa no consiste en institucionalizar prácticas de desarrollo evolutivo, sino estructuras organizativas fractales y modelos de gobernanza dinámica. Es el caso, por ejemplo, de AES (sector energético, 40.000 empleados), Heiligenfeld (Hospitales de salud mental, 600 empleados) o Zappos.com (venta de zapatos on line, 1.500 empleados)  Laloux, F. (2016).



Estructuras fractales

Margaret Wheatley introduce en 1992, el concepto de organización fractal (Wheatley, 1992).

Las mejores organizaciones tienen una naturaleza fractal... El patrón de su comportamiento es coherente y predecible... Las organizaciones fractales, aunque jamás hayan oído hablar del término fractal, han aprendido a confiar en fenómenos naturales de organización"


Vas al comité:
—Entonces la decisión es esta.
—¿Pero esa decisión?
—La ha tomado Franken & Goursen.
Cuantos más apellidos tenga la consultora, más chula es la decisión; más millones inviertes.
—¡Franken & Goursen & Young!, ¡joder, pues hay que tomarla!
Luego si la decisión sale bien, te pones una medalla. La decisión es un análisis, un "benchmark"; se tiene que llamar "benchmark" no se puede llamar análisis, o... (ni me sale la palabra en español de benchmark) bueno, un contraste, ¡o como sea!
Entonces, si la decisión sale bien, te pones una medalla. La empresa se pone una medalla porque ha hecho lo que todo el mundo sabía. Si la decisión sale mal:
—¡Pero tío, han sido los consultores!
Y vas a los consultores, a los "Fransen & Goursen & Young":
—No, has implementado mal, porque el mercado ha hecho esto y ha funcionado.
Es la cobardía de que no puedes tomar una decisión que sea diferente o que sea natural por el mero hecho de que te van a poner en la calle.
Entonces si quitas todo eso la gente vuelve a descubrir un mundo normal:
—¿Y esta decisión?.
—Pues porque yo creo que es la correcta.

De la mesa redonda de Agile Spain 2014 - Pedro Serrahima - Director General Grupo Globalia.

bricks"¿Te comprarías una casa nueva en construcción sin haber visto los planos? Seguramente la respuesta es no. De hecho, seguro que al vendedor le exiges que te muestre los planos a escala de lo que va a ser tu nueva vivienda"... "Sin embargo, hasta hace poco la situación con las aplicaciones software no era así. Aunque en algunos casos la inversión en un sistema software podía ser superior al precio de una vivienda, a los ingenieros de software no se nos exigía que entregásemos los planos de la aplicación antes de empezar a construirla."

Esta cita es de un artículo publicado el pasado 21 de noviembre en El País. Una muestra de que en 2016 la Ingeniería del Software continúa insistiendo en que los programas se deben construir con la misma planificación que las casas.

Pero no nos engañemos, queremos tener los planos completos desde el principio y saber cómo va a ser toda la casa, porque es algo que nos van a entregar en una sola vez, cuando esté completamente terminada y que luego no podremos modificar.

Si las casas no fueran estructuras físicas de cemento, sino lógicas, el razonamiento sería algo así:

¿Comprarías una casa si te obligaran a firmar un proyecto con las dimensiones y todos los detalles cerrados, como si fuera un contrato en el que no pudieras cambiar nada. Y que si a mitad vieras que el comedor resulta pequeño no pudieras ampliarlo moviendo el muro exterior y quitando un poco de jardín, o incluso si necesitaras más, no pudieras pedir una planta subterránea con una bodega?
¿Comprarías una casa si te dijeran que no te la van a entregar hasta que esté toda terminada? Que no te van a dar primero el dormitorio y el baño para que puedas tener cuanto antes un mínimo viable, y luego mes a mes te irán entregando o modificando las partes que tú quieras hasta que decidas que ya está terminada.

Falacia: argumento que parece válido, pero no lo es. Algunas falacias se cometen intencionalmente para persuadir o manipular a los demás, mientras que otras se cometen sin intención debido a descuidos o ignorancia. En ocasiones las falacias pueden ser muy sutiles y persuasivas, por lo que se debe poner mucha atención para detectarlas.

(Wikipedia, Falacia, dic 2016.)