I'm Oriol

Seamos ágiles con Scrum (I)

on Wed May 06 2020

Gentil introducción

Esta es la primera de una serie de publicaciones que me he propuesto realizar, acerca de cómo aprender desde cero a implantar Scrum de forma exitosa en un equipo de trabajo real orientado a producto.

Está basada en la experiencia reciente que he tenido, y como tal es posible que se encuentren aspectos imprecisos u opinables, no soy ni el primero, ni el más experimentado, ni el último que se aventurará a escribir sobre desarrollo ágil. Quedo pues a vuestra disposición para poder escuchar vuestras sugerencias, críticas o debatir al respecto. Este contenido no es una fuente de información absoluta, y por supuesto está sujeto a cambios ante imprecisiones 🙂

En cualquier caso, aprovecho para recomendar los cursos de Management Plaza. Están actualizados, muy bien explicados, a precios accesibles, y el contenido es muy provechoso. Independientemente de si te estás planteando obtener alguna certificación de Scrum.org o simplemente quieres aprender más, son muy recomendables.

Antes de empezar

Antes de empezar a hablar sobre desarrollo ágil y sus fundamentos, permíteme aconsejarte: Si estás pensando en empezar a buscar información por primera vez sobre Scrum, mi recomendación es que te abstengas de ello. En el caso que quieras llegar a obtener una certificación, también es recomendable que de momento te abstengas en la realización de cualquier tipo de examen abierto de prueba, al menos hasta que:

  1. Hayas leído y entendido el manifiesto ágil y los conceptos clave.
  2. En el caso de los exámenes de prueba: Te hayas documentado en mayor medida sobre Scrum,
  3. Tengas claro qué certificación quieres obtener y dónde.

El motivo principal es que, pese a que podemos leer sobre Scrum, y entender sus eventos, artefactos, y roles, no es nuestro objetivo simplemente implantar una serie de procesos e ir repitiéndolos hasta el infinito sin más, o cambiarle el título a una persona del equipo para seguir la nomenclatura de Scrum.

Nuestro objetivo va mucho más allá: Scrum es una forma de lograr unos objetivos, de seguir una filosofía que en la práctica optimizará la planificación, el desarrollo, y la entrega de nuestro producto, y mejorará enormemente la forma con la que nos relacionamos con nuestro cliente final.

De forma muy abreviada, podemos decir que Scrum es un medio para llegar a un fin, y este fin son los conceptos clave que podemos encontrar en el manifiesto ágil. Si no conocemos lo que queremos lograr a través de Scrum, tan sólo lograremos implementar cambios procedimentales o de nomenclaturas, que difícilmente darán su fruto, y harán plantearse a la dirección de nuestra organización si el cambio merece realmente la pena. No sólo hemos de «implementar» Scrum. Hemos de ser conscientes de que desarrollar de forma ágil implica un posible cambio de mentalidad, que nosotros y el resto de la organización hemos de estar dispuestos a asumir.

¿Y por qué no realizar exámenes abiertos de inmediato? Existen dos motivos principales:

  1. Los exámenes abiertos tienen un número limitado de preguntas. Es muy sencillo repetir el examen hasta haberse aprendido las respuestas. No obstante, durante un examen real la cantidad de preguntas es enorme, es imposible aprendérselas ni bajarlas de Internet (por poner un ejemplo: Scrum.org vigila constantemente aquellas páginas que publican las preguntas de sus exámenes, y cursan denuncias por infracción de derechos de autor para asegurarse que las preguntas se retiran con diligencia).

    Si insistes en realizar el examen abierto, lo aprenderás de memoria bastante pronto, pero no habrás interiorizado nada (o muy poco) sobre Scrum, y no te habrá servido para hacerte una idea de tu capacidad real de conocimiento.

    Dicho esto, la recomendación es entonces que primero te documentes sobre los pilares, sobre el manifiesto ágil, para después aprender sobre Scrum, y finalmente cuando estés pensando en certificarte, comprobar tu nivel a través de los exámenes abiertos.

  2. Existe otro motivo sobre el que no lanzarse a buscar información o hacer exámenes de prueba. Existen diversas organizaciones certificadoras de Scrum (ScrumAlliance y Scrum.org son quizás las más importantes), y aunque todas coinciden en la interpretación de los aspectos más básicos de éste, la interpretación de algunos aspectos muy (muy) concretos puede diferir. Si vas a certificarte en Scrum.org, puede llegar a ser contraproducente que empieces a realizar exámenes abiertos en otro lugar que no se ha diseñado siguiendo las directrices de interpretación de Scrum.org. E inclusive, que leas información aleatoria de Internet.

En cualquier caso, y para dejar constancia de ello: Estas publicaciones se realizan conforme a mi experiencia reciente, y conforme al curso de PSM1 y PSPO1 de Management Plaza, que se imparte según la interpretación de Scrum.org.

¿Realmente queremos ser ágiles?

Bien, hemos decidido que queremos ser ágiles. Tal vez llevamos trabajando un tiempo siguiendo metodologías ágiles, y por fin tenemos la oportunidad de organizar un equipo from scratch.

O simplemente queremos aprender y profundizar más en los conocimientos que ya tenemos, asegurarnos que realmente exprimimos al máximo los beneficios del desarrollo ágil.

En ambos supuestos existe un objetivo, una premisa, sin la que nuestra tarea va a resultar mucho más difícil, sino casi inalcanzable: Debemos asegurarnos que cada persona implicada directa o indirectamente en nuestro proyecto conoce los objetivos y beneficios del agilismo. No sólo al equipo de desarrollo hace referencia esta premisa, todos aquellos con quienes vamos a interactuar: Dirección, Marketing, Operaciones, Ventas, etcétera. Todos han de comprender el porqué del agilismo, entenderlo y apreciarlo.

No hace falta siquiera que empecemos a hablar aún de Scrum. Por supuesto que también es conveniente que sepan cómo funciona Scrum llegado el momento, y por ende cómo trabajamos. Pero la clave reside en que ellos, al igual que nosotros, conozcan qué queremos lograr y mejorar gracias a un desarrollo ágil, para que así entiendan y respeten los procesos que vamos a implementar a posteriori.

En caso contrario, fácilmente más pronto o más tarde se adoptarán decisiones que quedarán fuera del ámbito de decisión del Scrum Team (o incluso se producirán desde el propio Scrum Team, si no hemos sabido transmitir bien este conocimiento al resto de compañeros), que perjudicarán a la esencia del desarrollo ágil, e irán en detrimento de los beneficios que éste nos aporta.

Si algo queremos asegurar mediante este punto, es que Scrum genere el impacto positivo, y el retorno que se espera de él. No queremos que el resto de la organización perciba Scrum cómo «la forma en que se ha organizado el equipo de desarrollo», como algo ajeno a ellos de forma aislada.

Muchas organizaciones presumen en ser ágiles, pero en la práctica posteriormente todo se reduce a la forma en que trabajan los equipos de desarrollo de software, que son quienes en un momento dado pueden haber impulsado este tipo de cambios, mientras que el resto de la organización ignora o menosprecia (de forma inconsciente) los beneficios que nos aporta ser ágiles.

Dicho esto, la capacidad para que el resto de la organización aprecie y adopte algunos cambios, variará según la mentalidad de la propia empresa. No obstante, existe un trabajo previo de coaching a realizar muy importante, tanto con el propio equipo más cercano, como con todas las partes implicadas de la organización. Y es importante reiterar: Es bueno y necesario conocer y que el resto de personas conozcan como funciona Scrum (al fin y al cabo es lo que queremos implementar), pero carece de sentido si no explicamos con concisión qué queremos lograr, qué va aportarnos ser ágiles, y qué cambios hemos de estar dispuestos a realizar si queremos recibir en contraprestación esos beneficios.

¿Y qué queremos lograr? El manifiesto ágil

En febrero de 2001, un grupo de personas redactó, subscribió y publicó el manifiesto ágil. Se trata de un documento que plantea que el Software debe desarrollarse siguiendo unas premisas generales. Veámoslas:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Lo anterior es el manifiesto ágil. Tiene un apartado de «doce principios del Software ágil» que también es recomendable leerlo en detalle, y viene a describir las conclusiones que podemos extraer del propio manifiesto.

¿Y qué significa cada uno de los puntos del manifiesto? Tal y cómo reza el texto:

1 – Individuos e interacciones sobre procesos y herramientas: No viene a decirnos que no necesitemos procesos, o no necesitemos herramientas (¡Es obvio que los necesitamos!). Sino que ante estos dos aspectos, las personas, su trabajo e interacciones deben ser más valoradas, y deben tener cierta capacidad de influencia sobre esos procesos y herramientas.

2 – Software funcionando sobre documentación extensiva: De nuevo: ¿Significa esto que no debamos realizar documentación? Ni de lejos, pero nuestro éxito se basa en desarrollar software. Software de calidad y que cumpla las necesidades del cliente. Implícitamente, al producir software de calidad implementaremos buenas prácticas; código cuyo flujo sea auto-descriptivo, que disponga de tests, comentado según necesidad, y cómo es obvio, con la documentación que sea necesaria. Pero al no haber documentado de forma excesiva, cuando estos requerimientos provenientes del cliente cambien, la documentación no actuará como un impedimento para seguir avanzando.

3- Colaboración con el cliente sobre negociación contractual: En este punto aplica un acercamiento similar: Las negociaciones contractuales van a existir, y van a ser una parte importante del proceso. Pero el desarrollo ágil pretende evitar que toda comunicación con el cliente se limite a lo especificado estrictamente en éstas. Debemos comunicarnos con el cliente, conocer sus cambiantes necesidades, adaptarnos a este cambio, y enseñarle nuestros progresos frecuentemente y obtener feedback de éste. En resumen: Nuestra relación con el cliente no debe limitarse a la entrega del producto según se especifique en el contrato, sino que el cliente debe formar parte en mayor o menor medida de nuestro flujo de desarrollo y entrega de producto.

4 – Respuesta ante el cambio sobre seguir un plan: Al hilo de lo comentado con anterioridad: Cuando desarrollamos de forma ágil, hemos de ser conscientes, y tener la mentalidad, y en definitiva asumir, que las necesidades que motivan nuestro desarrollo son cambiantes, o pueden ser más concisas conforme avanzamos. Debemos tener cierta valentía para asumir que van a producirse cambios de requisitos, y aceptarlos de buen grado. El manifiesto ágil da por hecho que durante el desarrollo de software no es válido idear un plan que pretenda preveer todas las casuísticas y requisitos de principio a fin de proyecto. Más bien, el approach que sugiere es el de realizar un plan menos extenso, que será desarrollado durante las semanas subsiguientes, para después poner el resultado en común con las partes implicadas (inclusive el cliente), y elaborar otro pequeño plan para las siguientes semanas. De esta forma, nos adaptaremos constantemente a los cambios, y nuestro producto responderá realmente a las necesidades finales del cliente.

Pequeños comentarios sobre los principios de desarrollo

Es muy recomendable leer los doce principios del manifiesto ágil. Este punto ofrece a modo de pequeños comentarios, determinadas formas de interpretar lo que puede extraerse de estos principios (interpretaciones de cosecha propia, ergo pueden ser cuestionables). Pero por supuesto no sustituye su lectura, que es necesaria y enriquecedora.

  • Todo el equipo debe mantener una actitud orientada a cliente. Su satisfacción es el objetivo.
  • Debemos asumir que van a producirse cambios. Y adaptarnos a ellos para cubrir las necesidades existentes.
  • Liberamos Software funcional frecuentemente. No cuando el proyecto está completamente finalizado, sino en intervalos de tiempo comprendidos entre dos semanas y dos meses. Esto coincide con el punto previamente comentado, que decía que debíamos «realizar un plan menos extenso, que será desarrollado durante las semanas subsiguientes, para después poner el resultado en común con las partes implicadas (inclusive el cliente), y elaborar otro pequeño plan para las siguientes semanas» .
  • Los responsables de negocio trabajan cotidianamente con el equipo de desarrollo.
  • Debemos confiar en el equipo que desarrolla el proyecto, motivarles y asegurar que esta confianza es real y tienen margen de maniobra para tomar las decisiones oportunas relativas al desarrollo.
  • La conversación cara a cara es el mejor medio de comunicación.
  • Podemos medir el progreso de muchas formas, pero al final nuestro éxito se basa en la satisfacción del cliente que a su vez se basa en un software funcionando que cubre sus necesidades. Ergo, tenemos éxito si desarrollamos software funcional.
  • Debemos ser capaces de mantener nuestro ritmo de desarrollo a un ritmo sostenible durante el tiempo de forma indefinida.
  • Debemos simplificar: Centrarnos en detallar los requisitos que aportan más valor al producto desarrollado, y maximizar la simplicidad de todo aquel trabajo pendiente que no vamos a desarrollar de inmediato.
  • El equipo ha de ser auto-organizado. Y todo esto casa con lo que ya hemos dicho: El equipo de desarrollo debe ser en su conjunto capaz de desarrollar el producto, y además auto-organizarse para ello. Esto no significa que no puedan existir ciertas premisas que provengan de la propia organización, sino que en líneas generales, el equipo va a disponer de cierta libertad para tomar decisiones relativas al proceso de desarrollo y el propio equipo.
  • Y por último, algo realmente importante. De la misma forma que constantemente analizamos los requisitos cambiantes del cliente, constantemente debemos analizar nuestra forma de trabajar, nuestra forma de afrontar los retos que surgen diariamente, y tras este análisis, realizar los ajustes necesarios para mejorar. De forma recurrente, poco a poco, sin grandes cambios y por supuesto sin cambios improvisados, pero con honestidad, recurrencia, y profesionalidad.

¿Sirve el desarrollo ágil para todo?

Aunque existe cierta tendencia a aplicar el desarrollo ágil a otros aspectos ajenos al desarrollo de Software, lo cierto es que el agilismo no sirve para todo.

Quizás la clave se encuentra en el constante cambio: Cuando desarrollamos un producto de software, las necesidades del cliente pueden cambiar constantemente. ¡E incluso el propio cliente puede cambiar de idea conforme le vayamos enseñando los resultados!

Con lo cual, lo ideal en estas situaciones es utilizar una metodología o framework ágil para el desarrollo: Realizaremos pequeños planes (a los que denominaremos iteraciones o Sprint, aunque este tipo de términos lo empezaremos a emplear en las sucesivas publicaciones) que consistirán en el desarrollo de una pieza de software terminada, una pequeña parte, una funcionalidad delimitada del proyecto que nos comprometeremos a diseñar, desarrollar, y testear en ese pequeño periodo de tiempo, para después mostrársela a personas implicadas y al cliente.

No obstante, y utilizando una analogía muy popular: ¿Qué pasa si queremos construir un cohete? Existen las mismas fases de desarrollo: Diseño, desarrollo, pruebas, etcétera. (Okey, lo he simplificado quizás demasiado, pero nos sirve para el ejemplo)

En este caso, sabemos que queremos construir un cohete, realizaremos un diseño que será aprobado, realizaremos la construcción y pruebas sobre este cohete, y al finalizar, éste será completamente operativo. Es un cohete al fin y al cabo, sabemos que debe ser capaz de realizar ciertas operaciones que no cambian constantemente, y podemos idear un «plan más extenso» en lugar de realizar pequeños plantes reiterados en el tiempo. Ergo no es necesario ni beneficioso aplicar desarrollo ágil para un proyecto en el que las necesidades no sean cambiantes.

Disclaimer: Disculpad por la enorme simplificación de este punto. Especialmente a las personas de aeronáutica que hipotétiamente puedan acabar leyendo esto.

Frameworks y metodologías

Esta publicación ha pretendido analizar el manifiesto ágil: Los pilares del desarrollo ágil. Aprovecho para disculparme por adelantado por aquellos puntos que haya podido interpretar erróneamente, e insisto en que estoy abierto a comentarios, críticas y sugerencias.

Sobre este manifiesto se constituyen diversas metodologías y frameworks que amplían cada uno de estos puntos, y definen los procesos y formas de actuar para poder lograr estos objetivos.

En las próximas publicaciones empezaremos a tratar Scrum, no obstante, existen numerosas metodologías, a las que tal vez te interese echar un vistazo. Incluso algunas organizaciones implementan distintas formas de ser ágiles, y no por ello son menos ágiles que otras organizaciones que siguen Scrum con máxima fidelidad.

By Oriol Egea, 2016 - 2020, (CC BY-SA 4.0)