Sprint, bucles de retroalimentación — Scrum desde el Sprint 1 (parte 3)
Tercera parte de una serie de entregas destinadas a profundizar en la implementación del marco de trabajo Scrum. Si no haz visto las entregas anteriores, puedes pinchar en parte 1, parte 2.
Un conjunto de células forma un órgano. Un conjunto de órganos componen un sistema. Múltiples sistemas conforman el cuerpo humano. Nosotros como humanos, interactuamos con otros humanos en metasistemas: nuestras sociedades. Hoy, nuestras sociedades forman redes por el mundo. Todo sistema está interconectado: al interferir una de las partes, la consecuencia será reflejada en todo el sistema, regresando luego a su fuente de origen. ¿Te suena conocido? parte de la filosofía india le llama a este mismo fenómeno: Karma, siendo una relación de causa y efecto entre lo que hemos hecho y lo que haremos, es decir, todo lo que sucedió en el pasado tendrá una implicación en el futuro. También lo conocemos como la ley de reciprocidad: “lo que usted hace, le hacen” e inclusive lo encontramos en la tercera ley de Newton: “Principio de acción-reacción” que dice: “a toda acción le corresponde una reacción de igual magnitud y en sentido contrario”. En pensamiento sistémico, esto se conoce como: bucle de retroalimentación.
Bucle = Sprint
Imaginemos una caja. En Scrum todas las cosas que ocurren se remiten a una caja. La caja tiene un tiempo máximo de duración. Así, una caja de tiempo indica los límites para distintas cosas. Veamos un ejemplo: existe un bucle llamado Sprint, que es la caja de tiempo principal del marco de trabajo. Esta caja se recorre en iteraciones de tiempo fijo que van desde una a cuatro semanas.
Entonces, decide que con qué frecuencia se repetirán tus Sprints. Cuando digo repetir, no me refiero a que siempre estaremos trabajando en las mismas cosas. Sino qué haremos pasar las nuevas cosas que estemos desarrollando, por el mismo flujo para favorecer la consistencia y mantener un ritmo. Vamos a suponer que tus Sprints duran dos semanas, como en la figura 1. Una vez expira dicho tiempo, significa que inmediatamente ha de comenzar otro recorrido por la caja desde el principio y así sucesivamente, pasando por todos los eventos (reuniones informales que ocurren en Scrum) para construir nuestro producto de manera iterativa incremental.
Si hacemos doble click sobre la caja del Sprint, en su interior el contenido serán cuatro cajas de tiempo (eventos) que son las siguientes:
Según lo comenta Jeff Sutherland en su libro “Scrum, el arte de hacer el doble de trabajo en la mitad del tiempo”, el marco implementa dentro su bucle el ciclo PDSA de Deming, que es famoso por ser el que llevó a Toyota a convertirse en uno de los gigantes de la industria automotriz y es el medio para hacer cualquier manufactura saneada (Lean) o desarrollo de productos con Scrum.
De este modo, en cada Sprint planificas, desarrollas lo que planificas, estudias su resultado y actúas en consecuencia de dicho resultado. Para que la planificación no se convierta en un quebradero de cabeza utilizando este método, debes limitar la cantidad de cosas que pretendes hacer, no puedes hacerlo todo, mucho menos al mismo tiempo. Utilizando el sentido común, entonces la idea es que planifiques que cosas podrías hacer durante estas dos semanas de duración que tendrá tu caja de tiempo.
“La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial”.(Manifiesto ágil por el desarrollo de software)
Más adelante iremos profundizando los conceptos con algunas técnicas, sin embargo está claro que en tu primer Sprint (sobre todo) no tendrás forma alguna de comparar contra nada a modo de calcular cuanto trabajo podría realizarse en dos semanas. Pero no te preocupes por eso, no es realmente importante. Lo realmente importante acá, es que métodos como el PDSA nos entregan la oportunidad de practicar e ir aprendiendo en pro del dominio y la maestría de lo que hacemos, una y otra vez. Scrum no se trata de fallar rápido, se trata de: aprender rápido. Piensa un momento en tu vida: ¿Cuándo sientes que haz aprendido más, cuando haz obtenido el éxito o en la veces que fracasaste antes de conseguir dicho éxito? No es la meta, es el camino lo realmente valioso. Cuando se alcanza el éxito, sientes que ya dominas lo conseguido y es momento de ir por otra cosa. Si te interesa, Daniel Pink tiene un libro llamado “Drive” dedicado completamente al tema de las motivaciones que nos impulsan en la vida, con muchos datos de experimentos científicos que han demostrado información relevante, totalmente recomendado y te servirá bastante para mirar con otros ojos la época que estamos viviendo, es una lectura imprescindible en nuestro rubro.
Al final de cada Sprint la meta es entregar algo “Terminado”. Lo ideal es que podamos llegar con todo lo que planificamos el primer día, sin embargo comprendemos que el grado de complejidad de las empresas (silos, sobrecarga de trabajo, falta de foco, burocracia, rotación de personal, etc) afectan los planes y es imposible anteponernos a ello. El terminar y empezar en tiempo fijo nos ayuda a encontrar un ritmo. En cierta forma eso nos ayudará también a ser más predecibles. Lo que en gestión tradicional de proyectos veías como un proyecto, ahora lo ves como mini proyectos. Cada Sprint es un mini proyecto que nace y muere. Esto logra que al poco tiempo quienes trabajan con Scrum comiencen a experimentar el tiempo de manera peculiar ya que dejamos de ver el desarrollo de proyecto como algo lineal y proyectado. En su lugar, comenzamos a experimentar la circularidad.
Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.(Manifiesto ágil por el desarrollo de software)
Se debe tener cuidado respecto a la forma de concebir la productividad. Arrastramos vicios lamentables respecto a ese tema. Por ejemplo, no es productivo quién trabaja hasta la madrugada por entregar lo planificado. Eso demuestra que el plan fue deficiente y que no somos capaces de ser honestos con los problemas y el pedidas de ayuda. Trae consecuencias negativas por que ese “logro” la gerencia lo aprecia como tal cuando en realidad se tuvieron que hacer malabares para obtener el resultado. Eso no es sostenible y le hace mal a los ambientes laborales. Fui integrante de un equipo de desarrollo Scrum para un gigantesco producto de una enorme empresa chilena. Para el gerente, irse a la hora de término de un horario habitual de oficina, era símbolo de falta de motivación por parte de los ingenieros. Alentaba a las personas a llegar lo más temprano posible, por que esas cosas eran señal del éxito. En los pasos a producción, había que quedarse prácticamente toda la noche (y al otro día ir a trabajar). Luego te daban un diploma por tu destacada participación. Hay mejores formas de motivar a la gente y lograr rendimiento. tal vez las mencionadas funcionaron en otra época, pero debemos actualizarnos. Hoy entendemos perfecto que las personas son el centro de las empresas. Debemos sentirnos bien para trabajar bien. Está bueno mencionar que un Scrum Master también debe ayudarnos en eso.
Como nuestro ejemplo de Sprint dura dos semanas, sabemos que disponemos de diez días para trabajar. Así, el primer día del Sprint, el primer evento que debe ocurrir comenzando nuestro día es la planificación del Sprint o Sprint Planning. Todos los siguientes días del Sprint, habrá una pequeña reunión diaria llamada Daily Scrum. El último día del ciclo tendremos un evento que se encarga de la revisión del Sprint o Sprint Review y como broche de cierre, un último evento llamado Retrospectiva o Sprint Retrospective. Las retrospectivas permiten en base a patrones, encontrar causas a los efectos una vez les hemos visto. Generalmente los efectos podamos verlos en bastantes Sprints más adelante que la causa, pero el hecho de estar constantemente haciendo el estudio, facilita que podamos detectar los cambios. Esto convierte al proceso en empírico ya que la evidencia nos permite adaptar nuestra forma de hacer las cosas y pronosticar ajustando las expectativas con ritmos sostenibles y demostrados en las experimentaciones previas. Ken Schwaber tiene una forma muy interesante de describir el empirismo: Scrum es una promesa de hacer lo mejor que podamos con lo que tenemos.
Retroalimentación
El control del proceso empírico es retrospectivo y no predictivo (cómo en la gestión tradicional) lo que implica que las decisiones se toman en base a evidencia y el conocimiento se nutre de la experiencia. El estado ACT del ciclo PDSA será cuando implementamos las acciones que darán retroalimentación a nuestro sistema. Podemos ver dos tipos de retroalimentación, la de refuerzo (positiva) y la de compensación (negativa). Es vital entender los conceptos y como poder utilizarlas al momento de re alimentar nuestro flujo de cara al siguiente Sprint.
Retroalimentación positiva (refuerzo)
Es aquella que se amplifica cuándo ocurre. Su resultado vuelve al sistema y continúa aumentando en la misma dirección. Un ejemplo de esto es cuando alguien inicia una acción y los demás le siguen en forma exponencial. Estás en una fiesta y nadie está bailando. De pronto, una pareja se atreve y comienza a bailar. Al poco tiempo se van sumando mas y luego más personas, hasta que la fiesta toma una fuerza exponencial e inclusive quienes estaban sentados, deciden sumarse. Scrum trae por defecto un efecto de retroalimentación positiva puesto que facilita el conocimiento en las personas al disponer un ambiente horizontal y con acceso a la información. A mayor conocimiento y aprendizaje que permite nuevo conocimiento, vas mejorando tu capacidad de aprendizaje, lo que se transforma en mayor conocimiento. A continuación el ejemplo ilustrado:
Scrum tiene un enfoque de mejora continua (Kaizen) que implica introducir mejoras al proceso de producción cada vez que vamos retroalimentando nuestro sistema. Está claro que para amplificar lo que consideremos una mejora, debemos abordarlo desde el punto de vista sistémico a modo de comprender el cambio inyectado al flujo y entender su naturaleza de refuerzo. Por ejemplo, la implementación de un nuevo patrón de diseño para escribir software. Fomenta el cambio y se afirma de un plan autoorganizado para amplificarlo.
Retroalimentación negativa (compensación)
La retroalimentación de compensación es que la se encarga de mantener al sistema estable. Inhibe los cambios. Esto es vital para asegurar la supervivencia del sistema. Por ejemplo: Estoy en estado de vigilia, tengo sueño, entonces duermo para luego estar nuevamente en estado de vigilia y repetir el ciclo.
En la próxima entrega, veremos la diferencia entre mirar el desarrollo como un proyecto versus un producto y comenzaremos a levantar la planificación de un producto. Hasta pronto!
Agregame a Linkedin y estemos en contacto.
Continúa leyendo:
