En la historia de la humanidad lo nuevo siempre entierra a lo viejo, pero lo nuevo no siempre es mejor que lo viejo. Y aún diría más, a veces es solo una nueva forma de vender algo aún más viejo que no funcionó porque no era su momento. Que se lo digan a Microsoft, ahora pocos lo recuerdan, pero hubo una versión Windows XP Tablet Edition que funcionaba razonablemente bien en portátiles con pantalla táctil y stylus incorporado. Por ejemplo, el modelo T5010 de Fujitsu, un adelantado a su tiempo. Años después todo el mundo reconoce como referencia las tablets de Apple y Samsung pero no las de Microsoft. No era su momento ni tampoco dieron con la combinación de características adecuada, tipo de usuario, comodidad, rendimiento, software disponible, peso del portátil. Hay muchas explicaciones, pero eso pertenece al terreno del análisis post mortem.

La organización de las empresas se mueve al ritmo de un corazón humano, sístole y diástole. Contracción y relajación. Siempre oscilando entre el modelo centralizado, donde se agrupan las actividades comunes por área con el objetivo de aumentar el control, o bien el modelo distribuido, donde se permiten reinos de taifas en aras de una mayor independencia y rapidez. Ocurre en las compañías y en cualquier actividad humana. Control versus libertad. Siempre encontrarás personas que confían ciegamente en uno u otro modelo. Recomiendo ignorar ambas por igual.

En el desarrollo de software lleva imponiéndose lentamente en los últimos diez años en España un modelo basado en un marco de trabajo ágil. Podríamos llamarlo el diástole del desarrollo. La libertad, la confianza y la colaboración frente al sístole que era el desarrollo basado en cascada, donde cada etapa del ciclo de vida se ejecutaba una sola vez, se validaba y sólo entonces se pasaba a la siguiente. Todo perfectamente planificado y por supuesto perfectamente falso.

En un artículo anterior critiqué la puesta en práctica que se hacía del agilismo en las empresas. Mantengo mi crítica y de hecho he endurecido mi visión al respecto de un año a esta parte. Algunos entendieron ese artículo como una crítica al agilismo, pero era una crítica a las implantaciones del agilismo, cuando lo perviertes y llegas a algo peor que lo anterior. La adopción de formas de trabajo ágiles en las empresas está siendo muy desigual en cuanto a sus resultados, por no entender realmente lo que están haciendo.

La razón real para el uso de la presión y trabajar más horas puede que sea para que cada uno se sienta mejor cuando el proyecto esté fallando. Tom DeMarco.

En esta ocasión, quiero ser más constructivo y no quedarme en la crítica. Hay una gran oportunidad, si quieres diferenciarte de la competencia y ser más productivo. Pero hay que hacer un esfuerzo, lo primero, leer. El primer error que encuentro en aquellos que quieren adoptar una forma de trabajo basada en criterios ágiles es que creen saberlo todo y sólo han leído cuatro cosas. Para ser bueno en algo hay que dedicarle tiempo. Lee los principios que sustentan el agilismo, lee sobre las experiencias que han tenido otros y, por último, para hacer el cambio apóyate en personas que ya tengan experiencia en ello, porque te ayudará a ir más rápido y asegurará una transición menos traumática.

¿Qué demonios es el agilismo?

Que no te vendan la cantinela de que el agilismo es algo nuevo y va a solucionar todos los problemas de gestión que tienes. Si escuchas eso de alguien, echa a patadas a ese encantador de serpientes rápidamente. Como ya explicó Frederick P. Brooks en 1975, no hay bala de plata. No existe una forma fácil de desarrollar software. Pero sí podemos aprovechar lo que hemos aprendido en el último medio siglo sobre cómo desarrollamos software.

Como escribía al principio del artículo, este nuevo tema del agilismo en realidad no lo es tanto. Un señor llamado Winston Royce en 1970 escribió «Managing the development of large software systems» (Gestionando el desarrollo de grandes sistemas software). En este trabajo argumentaba que desarrollar software no era como construir un automóvil, donde puedes seguir una serie de pasos secuenciales perfectamente delimitados como una cadena de producción. Criticó el desarrollo secuencial (cascada) y abogó por una aproximación más iterativa e incremental. Había algo también interesante y es que defendía que el usuario se involucrase en el proceso.

Lamentablemente hubo que esperar hasta la década de los 90, en el siglo pasado, coincidiendo con el auge de Internet, para que se sentasen las bases de lo que se conoce como agilismo:

Individuos e interacciones por encima de los procesos y herramientas.
Software que funciona por encima de la documentación extensiva.
Colaboración con el cliente por encima de la negociación contractual.
Respuesta ante el cambio por encima del seguimiento del plan.

El agilismo no es una metodología, es una forma de entender el trabajo que se puede aplicar no solo al desarrollo de software, sino a cualquier actividad de la empresa. Lo que buscan las metodologías ágiles es reducir el trabajo no útil y desarrollar formas de trabajo que respondan con rapidez a los cambios. En lugar de pensar que hay un futuro definido y claro y que soy capaz de predecirlo y controlarlo, sé que no soy capaz de hacer eso y entonces me organizo conforme a esa situación, para que no sea un problema sino que sea justamente el cambio lo que alimenta y dirige el trabajo.

Para poder aplicar unos principios necesitamos saber cómo hacerlo. Y uno de los marcos de trabajo más sencillos, extendidos y exitosos que ha demostrado su valía en innumerables proyectos y empresas distintas es Scrum.

Scrum, un buen lugar de inicio

Pasar de unos principios a una organización del trabajo que respete esos principios no es algo a lo que se llegue en dos tardes, por eso es recomendable seguir un marco de trabajo que se haya probado de forma consistente y que funcione. Scrum es una buena forma práctica de poner en marcha los principios del agilismo sin tener que pensarlo todo desde cero.

Lo más importante que hay que conocer en Scrum es lo siguiente:

Roles:

Scrum Team: lo que se denomina equipo de trabajo es una estructura plana donde no hay jerarquía y lo más relevante es que se trata de un equipo multidisciplinar, autónomo y capaz de organizarse él mismo.
Scrum Master: es la persona que ayuda al equipo a seguir las buenas prácticas de Scrum, les guía y aconseja, es el responsable de que se cree el espíritu de equipo y de trabajo adecuado para que el equipo trabaje de forma satisfactoria y mejore su productividad con el paso del tiempo.
Product Owner: es el responsable del producto que se está construyendo, marca las prioridades del producto y proporciona información constante al equipo sobre los resultados de lo que se va desarrollando.

Conceptos que se deben conocer en Scrum:

Sprint: intervalo de tiempo (2 a 4 semanas) durante el que el equipo se centra en trabajar en lo que se ha acordado que sea el objetivo de ese sprint y nada más, permaneciendo centrado, sin distracciones y minimizando el concepto de multitarea que tanto daño ha hecho al ser humano a lo largo de la historia.
Tablero: pizarra con carriles donde se refleja el trabajo que se está haciendo en el sprint. Al menos debe haber tres carriles -trabajo pendiente, en progreso y hecho- y sirve para tener una imagen de lo que está haciendo cada persona del equipo así como del avance del trabajo en el sprint actual.
Product backlog: es el total de trabajo que hay identificado en un momento dado.
Sprint backlog: el trabajo que se está haciendo en el sprint, es en definitiva el alcance del sprint actual
Refinement backlog: consiste en trabajar lo que hay en el product backlog, con el objetivo de detallarlo, dividirlo y hacerlo manejable para que el equipo lo pueda incluir en un sprint.

Reuniones:

Daily Scrum Meeting: reuniones diarias de 15 minutos donde cada miembro del equipo cuenta lo que hizo el día anterior, lo que hará en el día y si tiene algún impedimento para hacerlo. El objetivo es que el equipo conozca lo que hacen todos los demás y se mantenga la visión de equipo por encima de la individual.
Sprint Planning: sesión de trabajo al inicio del sprint donde se decide qué trabajo hacer en el siguiente sprint y se organiza dicho trabajo para que pueda comenzarse.
Sprint Review (demo): al finalizar el sprint, el equipo hace una demo de lo que ha trabajado a la que asiste tanto el Product Owner como cualquier otra persona relacionada con el producto. El objetivo es mostrar el trabajo y obtener información sobre si el avance es bueno y minimizar así las desviaciones de lo que se está haciendo con respecto a lo que los usuarios del producto quieren y necesitan.
Sprint Retrospective: sesión de trabajo al finalizar cada sprint donde el equipo hace autocrítica con el objetivo de mejorar. Se identifican los aspectos que han ido bien, los que habría que mejorar y finalmente se definen unas tareas y responsables para llevar a la práctica esas mejoras.

Si se quiere aprender y entender el origen de Scrum, recomiendo leer la obra de uno de sus creadores, Jeff Sutherland, «Scrum – El nuevo y revolucionario modelo organizativo que cambiará tu vida». Es posiblemente el mejor libro que explica el porqué de Scrum, cómo nació y se ve claramente que puede ser utilizado no solamente para desarrollar software, sino también para organizar el trabajo en multitud de áreas.

Las personas no abordan varias tareas a la vez porque sean buenas en eso. Lo hacen porque son más distraídas. Les resulta difícil inhibir el impulso de hacer otra actividad. David Sanbonmatsu (enero-2013).

Scrum está muy relacionado con LEAN, cuya idea es maximizar el valor que se da al usuario mientras se minimiza lo que no aporta valor. Recomiendo, si se quiere profundizar en LEAN, el libro «Lean Enterprise – How high performance organizations Innovate at Scale«. De hecho, se puede ver una correspondencia entre el principio PDCA (Plan, Do, Check, Act – Planificar, Hacer, Verificar, Corregir) que busca la mejora continua y Scrum.

Fuente: Diagrama Scrum (Mountain Goat Software), Diagram PDCA by Karn G. Bulsuk

Plan > Sprint Planning: la planificación del sprint.
Do > Sprint Backlog: se hace el trabajo planificado en el sprint.
Check > Sprint Review: se hace la demo de lo que se ha hecho a todos los interesados y se tienen en cuenta sus opiniones y comentarios.
Act > Sprint Retrospective: se revisa cómo se ha trabajado en el último sprint y se definen acciones de mejora para el siguiente.

En resumen, Scrum no es solamente una buena forma de desarrollar software. Es una buena forma de organizar el trabajo en las empresas. En Microsoft hay miles de personas trabajando así, en Amazon hay cientos de equipos Scrum. Si aún no has dado el paso y estás interesado en profundizar en esto, o ya has comenzado a trabajar en modo scrum y te interesa mejorar tus conocimientos y, en definitiva, mejorar en tu trabajo, te dejo algunos enlaces con información muy útil sobre una forma de trabajo que, sin ser el escalón final de nada -eso no ocurrirá hasta que llegue el punto de singularidad tecnológica-, sí es una mejora palpable sobre otras formas de trabajo donde la burocracia y el exceso de planificación han sido las tumbas de proyectos interesantes en demasiadas ocasiones.

Enlaces de interés: