El Sprint Backlog es el subconjunto de ítems que un equipo "toma" del Product Backlog como compromiso de trabajo para un Sprint, con algunos agregados.
Esta selección de ítems se realiza durante la Sprint Planning, y los agregados que el equipo hace representan la estrategia para cumplir con esos ítems y alcanzar el Objetivo del Sprint y entregar el Incremento de Producto.
La Guía de Scrum no entra en detalle específico de esa estrategia, pero en muchos casos se trata de una desagregación de tareas para cada ítem, de acuerdo a diversas perspectivas como componentes, especialidades, áreas de trabajo, u otras que el equipo determine.
Es recomendable tener en cuenta que aunque cada ítem se descomponga en tareas, el equipo tiene como objetivo principal lograr ítems completos, que ayuden a alcanzar el objetivo, y tiene que evitar caer en la trampa de dedicarse a completar tareas en cualquier orden, según la especialidad de cada uno, sino en colaborar activamente para terminar ítems, respetando el orden de prioridad original.
El Sprint Backlog usualmente se hace visible a través del uso de un tablero, físico o electrónico, y es importante que esté disponible para todos los interesados y permita ver claramente el estado de cada ítem, de manera transparente.
También es recomendable que junto a los ítems del Sprint Backlog, el tablero mantenga altamente visible al menos un elemento de mejora decidido en la última retrospectiva.
Es común que el equipo modifique y complete detalles del Sprint Backlog a medida que avanza en el Sprint, posiblemente como resultado de la Daily Scrum. Todo ajuste tiene por objetivo mejorar las posibilidades de alcanzar el Objetivo del Sprint.
El Development Team es el único que puede alterar el Sprint Backlog, agregando, actualizando o removiendo detalles. El resto del Scrum Team y los Stakeholders sólo tienen acceso a éste para ver el estado de avance, sobre el que pueden pedir más detalles al equipo. En mi opinión no es bueno tomar el estado de actualización del Sprint Backlog como única fuente de información, sobre todo en caso de notar algo fuera de ciertas expectativas. En un ambiente colaborativo como el de Scrum, la comunicación cara a cara siempre brinda detalles que nos dan una visión más clara de las cosas.
jueves, 5 de marzo de 2020
miércoles, 4 de marzo de 2020
Scrum: Product Backlog
Para poder desarrollar un producto con Scrum, un equipo necesita tener un Product Backlog.
Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.
Esa evolución se da a través de los Sprints, a medida que:
La recomendación de involucramiento del Development Team en esta actividad es que no exceda el 10% del tiempo disponible del Sprint, pero eso es usualmente bastante tiempo.
Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.
Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).
También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.
Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.
Esa evolución se da a través de los Sprints, a medida que:
- Se pasan ítems al Sprint Backlog, durante la Planning.
- Se agregan nuevos ítems que sean valiosos para el producto
- Se eliminen ítems cuyo valor ya no es relevante
- Se descompongan ítems grandes en otros más pequeños
- Se cambian las prioridades de los ítems, al reconsiderar su valor actual
Una idea central es que el Product Backlog es la única fuente de trabajo relativa al producto para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.
Cuando un producto es muy grande, el esfuerzo puede distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.
El Product Owner es el responsable por su contenido, visibilidad y priorización.
El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.
Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.
Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:
El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.
Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.
Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:
- Con su valor establecido (y ordenados en consecuencia)
- Divididos en los ítems más pequeño posibles
- Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)
- Detallados (suficiente como para que nada se bloquee en la Planning)
Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:
- Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.
- Evitar analizar ítems que pueden variar (o desaparecer)
La actividad de agregar estos detalles al Product Backlog no es un "evento" sino una tarea permanente del Product Owner, llamada Product Backlog Refinement, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.
Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.
Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).
También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.
miércoles, 26 de febrero de 2020
La estructura de Scrum
Siguiendo con la premisa de que Scrum es "fácil de entender, pero difícil de dominar", avancemos con la parte fácil. 😁
Scrum está compuesto, además de sus pilares y valores, por una serie de artefactos, eventos y roles.
Los llamados "artefactos" de Scrum son elementos mínimos para lograr alto grado de transparencia respecto al planes, trabajo pendiente y resultados obtenidos.
El Backlog (o Pila) de Producto es una lista ordenada de todo lo que el producto pueda necesitar. Es una lista en constante evolución, dinámica, y es la única fuente de trabajo para el equipo.
El orden en que están los ítems del Product Backlog transparentan la visión y estrategia de producto que clientes, gente de negocio y equipo comparten, poniendo énfasis en que lo que está en los primeros lugares es lo que queremos que el producto tenga en el más corto plazo.
El Backlog (o Pila) del Sprint es un subconjunto del Product Backlog, seleccionado por el equipo para trabajar en un Sprint (o iteración), al que se agrega un plan de cómo convertir esos ítems en un incremento de producto cumpliendo el objetivo del Sprint.
El Sprint Backlog transparenta el trabajo del equipo durante el sprint, incluyendo el objetivo general y otros indicadores que sirvan al equipo y al resto de la organización.
El Incremento de Producto es la suma de todos los ítems del Product Backlog terminados durante el Sprint, agregado al valor obtenido en todos los Sprints anteriores.
Este Incremento transparenta de manera radical el estado del producto. Es una versión del producto utilizable y completa, independientemente de que se decida entregarlo o no a la audiencia final.
Para asegurar esa usabilidad, el Incremento debe cumplir con la Definition of Done (definición de terminado) que el equipo tiene acordada.
Cada Sprint comienza con una planificación de su Objetivo y su Sprint Backlog, trabajo de desarrollo de producto, que se sincroniza diariamente, un Incremento de Producto que es revisado sobre el final, y un espacio de reflexión para la mejora continua.
En la Planning el equipo inspecciona las expectativas de corto plazo sobre el producto y adapta su estrategia para lograr un resultado concreto.
El resto del día, a excepción de los eventos de inicio y fin del Sprint, el equipo se dedica al desarrollo del producto mismo.
Es el momento principal en que el equipo decide cómo le conviene hacer todo lo que Scrum no dice, como temas de relacionamiento, técnicos, de comunicación, organizacionales, y otros.
Scrum está compuesto, además de sus pilares y valores, por una serie de artefactos, eventos y roles.
AVISO
Este artículo es una guía inicial, que se irá completando con links a detalles más completos (en artículos separados) a lo largo de las próximas semanas.
Este artículo es una guía inicial, que se irá completando con links a detalles más completos (en artículos separados) a lo largo de las próximas semanas.
Artefactos -> Transparencia
Los llamados "artefactos" de Scrum son elementos mínimos para lograr alto grado de transparencia respecto al planes, trabajo pendiente y resultados obtenidos.
Product Backlog
El orden en que están los ítems del Product Backlog transparentan la visión y estrategia de producto que clientes, gente de negocio y equipo comparten, poniendo énfasis en que lo que está en los primeros lugares es lo que queremos que el producto tenga en el más corto plazo.
Sprint Backlog
El Backlog (o Pila) del Sprint es un subconjunto del Product Backlog, seleccionado por el equipo para trabajar en un Sprint (o iteración), al que se agrega un plan de cómo convertir esos ítems en un incremento de producto cumpliendo el objetivo del Sprint.
El Sprint Backlog transparenta el trabajo del equipo durante el sprint, incluyendo el objetivo general y otros indicadores que sirvan al equipo y al resto de la organización.
Product Increment
El Incremento de Producto es la suma de todos los ítems del Product Backlog terminados durante el Sprint, agregado al valor obtenido en todos los Sprints anteriores.
Este Incremento transparenta de manera radical el estado del producto. Es una versión del producto utilizable y completa, independientemente de que se decida entregarlo o no a la audiencia final.
Para asegurar esa usabilidad, el Incremento debe cumplir con la Definition of Done (definición de terminado) que el equipo tiene acordada.
Eventos -> Inspección y Adaptación
Los eventos de Scrum brindan la estructura temporal mínima, evitan reuniones adicionales, y tratan de minimizar el desperdicio de tiempo y esfuerzo.Sprint
El Sprint (iteración) es el corazón de Scrum. Es un contenedor de todos los demás eventos más el trabajo regular de desarrollo. Marca el pulso de trabajo, siendo su duración inalterable y estable a lo largo del ciclo de vida del producto.Cada Sprint comienza con una planificación de su Objetivo y su Sprint Backlog, trabajo de desarrollo de producto, que se sincroniza diariamente, un Incremento de Producto que es revisado sobre el final, y un espacio de reflexión para la mejora continua.
Sprint Planning
Al inicio de cada Sprint, el equipo se reúne para definir el Objetivo del Sprint, y seleccionar los ítems del Product Backlog en los que trabajarán para cumplirlo. Esos ítems, junto con información adicional de cómo desarrollarlos, se convierten en el Product Backlog.En la Planning el equipo inspecciona las expectativas de corto plazo sobre el producto y adapta su estrategia para lograr un resultado concreto.
Daily Scrum
Todos los días a la misma hora y el mismo lugar, el equipo se reúne durante un máximo de 15 minutos para inspeccionar cómo avanza hacia el objetivo del Sprint y adaptar sus planes para alcanzarlo.El resto del día, a excepción de los eventos de inicio y fin del Sprint, el equipo se dedica al desarrollo del producto mismo.
Sprint Review
Sobre el final del Sprint, el equipo colabora con clientes, gente de negocios u otros interesados para inspeccionar el Product Increment, de manera de poder adaptar, a través de actualizaciones al Product Backlog y un entendimiento común, los planes hacia adelante.Sprint Retrospective
La "Retro" es una oportunidad para que el equipo se auto-inspeccione, y adapte su manera de trabajar, mejorando de manera continua.Es el momento principal en que el equipo decide cómo le conviene hacer todo lo que Scrum no dice, como temas de relacionamiento, técnicos, de comunicación, organizacionales, y otros.
Roles
Un equipo Scrum tiene solamente tres roles internos: el Development Team (o equipo de desarrollo), formado por múltiples profesionales, y otros dos que son individuales, el Product Owner y el Scrum Master.
La suma de las personas cubriendo estos tres roles en un equipo es lo que se llama Scrum Team (o equipo Scrum).
Todas las personas interesadas en el producto que pueden interactuar con el Scrum Team pero no forman parte de él son llamados Stakeholders, o involucrados. Entre ellos puede haber clientes, personas de negocios, personas de otras áreas de la organización que tienen influencia sobre el producto, como marketing, legales, tecnología, atención a clientes, y también personas externas a la organización como consultores, auditores, analistas de mercado, y muchos otros.
Development Team
Es un grupo multi-disciplinario de profesionales que se encargan de entregar un incremento de producto utilizable al final de cada Sprint.Product Owner
Es la responsable de maximizar el valor del producto que entrega el Development Team. La manera en que lo hace es muy diferente en cada equipo, pero se centra alrededor de la administración del Product Backlog.Scrum Master
Es la responsable de promover y dar soporte a Scrum, ayudando a que todos comprendan y usen apropiadamente sus valores, prácticas y reglas.martes, 25 de febrero de 2020
Pilares y Valores de Scrum
Una contradicción frecuente en personas y organizaciones interesadas en adoptar Scrum es que no se resignan a dejar de preguntar cosas como: "¿Cuándo va a estar lista exactamente ésta característica del producto tal cuál yo pedí?"
La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.
Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.
No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:
De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.
La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.
Procesos de Control Empírico
Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.
No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:
- Volatilidad
- Incertidumbre
- Complejidad
- Ambigüedad
De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.
Pilares de Scrum
Transparencia, Inspección y Adaptación |
Podemos recorrer estos tres principios pensando en la pregunta original. Si el problema es complejo y la solución es incierta, ¿cómo podemos entonces saber cómo vamos?
La transparencia en Scrum es de doble vía: los clientes o el "negocio" deben brindar información concreta al equipo sobre sus hipótesis, objetivos y dependencias, y el equipo debe dar transparencia de sus planes, decisiones y sobre todo, resultados.
En base a esos datos, y en iteraciones cortas, el equipo mostrará resultados concretos (no planes, diseños ni porcentajes, sino un producto funcional) que inspeccionarán junto a los clientes o "negocio", entendiendo:
- Decisiones acertadas o no
- Hipótesis de negocio comprobadas o no
- Calidad del producto
- Estado actual frente a un contexto volátil
- Comprensión correcta entre todos, en un entorno ambiguo
Basados en este aprendizaje, el equipo y sus clientes adaptan su plan hacia adelante, poniendo en juego una nueva serie de premisas, objetivos de corto plazo y estrategias.
Todo esto se repite en ciclos permanentes, ya que los procesos empíricos se basan casualmente en la iteración continua.
Pero Scrum agrega a estos pilares una serie de principios que se encuentran detrás de cada uno de los roles, eventos y artefactos, junto con los pilares.
Valores de Scrum
Compromiso, Coraje, Foco, Apertura, Respeto |
Estos valores, que muchas veces se ignoran en adopciones de Scrum, tomando solamente la parte mecánica (los roles, eventos y artefactos) son los que revelan la intención detrás del marco de trabajo, y permiten entender mejor el porqué de cada pieza.
Veamos un poco el origen de estas palabras (en su versión inglesa original) y porqué tienen tanta importancia en Scrum:
Compromiso (commitment)
Viene de "confiar a alguien, delegar autoridad", y refiere a unirse por un objetivo común.
En Scrum, los miembros del equipo se comprometen de manera personal, para cumplir con un objetivo colectivo. Dentro del equipo cada uno es responsable y rinde cuentas a los demás, pero hacia fuera comparten una responsabilidad y rinden cuentas como grupo.
La importancia de este principio es que no se puede afectar la autonomía del equipo como tal, tratando de "gestionar" a miembros individuales, ni se puede reducir ese compromiso haciendo que los miembros tengan responsabilidades fuera de su equipo.
Coraje (courage)
Originalmente, "desde el corazón", se entiende como el tomar acción en base a nuestras creencias o principios.
En Scrum, se espera que el equipo mantenga los principios de Scrum y sus acuerdos, sobre todo cuando no sea fácil hacerlo. Tiene que ver con "hacer lo correcto, de la manera correcta", y refiere a mantener el objetivo común y la calidad técnica, pero implica un alto nivel de autonomía.
Un equipo Scrum no puede sentirse limitado por decisiones externas, y constantemente cuestionará normas o políticas que no considere positivas para alcanzar sus resultados de manera sostenible.
Foco (focus)
Proviene de "fuego", y tiene que ver con reunirse alrededor de la fuente de calor. Por eso lo usamos para algo que nos mantiene "mirando hacia ese lado".
Scrum es una manera de mantener al equipo permanentemente enfocado en el trabajo de la iteración actual (sin preocuparse por detalles de lo que vendrá, más allá de la visión de conjunto) y de sus objetivos como equipo, que surgen siempre de lo que es importante "ahora" para el producto.
Apertura (openess)
Algo abierto es algo expuesto y evidente.
En Scrum (dado el pilar de transparencia) se expone abiertamente tanto el plan, el trabajo en marcha, los resultados, y sobre todo, los desafíos (del equipo, de la organización, del producto, del mercado, de los clientes, y otros).
La apertura en cuanto a todo, incluyendo feedback abierto sobre todos los temas, permiten efectuar todo el tiempo el proceso de inspección y adaptación.
Respecto (respect)
Refiere originalmente a "ver" o "volver a mirar", y significa apreciar sinceramente las características únicas de otras personas.
En Scrum se propicia el respeto cruzado, de los clientes hacia la capacidad y autonomía del equipo, del equipo al entendimiento del negocio y sus desafíos de los clientes, pero también entre cada miembro del equipo, y por sus roles y responsabilidades.
Pero ese respeto implica que todo está abierto a cuestionamientos, de manera amable, con el objetivo de que las partes se entiendan lo mejor posible, elevando siempre la transparencia.
¿Y cuál es la respuesta?
Antes de comprender la estructura de Scrum, entonces, es importante entender que podemos preguntar o no.
Esto no quiere decir que no podamos tener fechas límites, o limitaciones de presupuesto. Lo que no trata de hacer Scrum es predecir nada.
Scrum no es un modelo predictivo, es un modelo adaptativo.
Las preguntas constantes en Scrum serán entonces, inspeccionando el producto frecuentemente:
- ¿El producto agrega valor?
- ¿Estamos más cerca de resolver el problema?
- ¿Vale la pena seguir adelante, o hay otro problema más valioso por resolver?
Y así, mediante continua inspección y adaptación, en muchos casos podremos tener resultados mejores a los que tenemos tratando de cumplir con predicciones que ya no son relevantes.
lunes, 24 de febrero de 2020
¿Qué es Scrum y para qué se usa?
Aquí comienza una serie de artículos en que intentaré describir el marco de trabajo Scrum, cubriendo temas que en su momento no quedaron incluidos en el libro "Proyectos Ágiles con Scrum" que escribimos con mi amigo Martín Alaimo. Tal vez al terminar la serie tenga el material para una nueva edición, o para un libro nuevo, pero eso ya lo veremos.
Según la Scrum Guide (la guía oficial que mantienen Ken Schwaber y Jeff Sutherland, los desarrolladores originales) Scrum es (mi traducción):
Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco intencionalmente incompleto.
Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.
Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en graves problemas.
Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una herramienta de management, al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.
Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.
Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.
Pero tampoco es una definición exacta. Por la dificultad de determinar qué es un productoy que no. Y también porque nuestro contexto es cada vez más complejo.
El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese problema adaptativo complejo.
La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.
Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.
Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere menos supervisión y más delegación de responsabilidades.
Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.
Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.
(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)
Sitio de la Guía de Scrum |
¿Qué es Scrum?
Un marco de trabajo en el que las personas abordan problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa.Me gusta esa definición que fue evolucionando a lo largo del tiempo, pero voy a tratar de analizarla por partes, para evitar algunas confusiones comunes.
Un marco de trabajo...
Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco intencionalmente incompleto.
Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.
Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en graves problemas.
...en el que las personas...
Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una herramienta de management, al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.
...abordan problemas adaptativos complejos, mientras entregan productos...
Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.
Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.
Pero tampoco es una definición exacta. Por la dificultad de determinar qué es un productoy que no. Y también porque nuestro contexto es cada vez más complejo.
...del mayor valor posible de manera productiva y creativa
El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese problema adaptativo complejo.
La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.
Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.
Otras características
Una a frase adicional que destaca otras características de Scrum es que "es un marco de trabajo liviano, simple de comprender, pero difícil de dominar".Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere menos supervisión y más delegación de responsabilidades.
Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.
Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.
Hacia adelante
Esta definición es de muy alto nivel, y lo que queda para entender Scrum, a través del resto de esta serie, son sus elementos:(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)
- Pilares: Transparencia, Inspección y Adaptación
- Valores: Compromiso, Coraje, Foco, Apertura y Respeto
- Estructura general
- Artefactos: Product Backlog, Sprint Backlog, Product Increment
- Eventos: Sprint, Planning, Daily Scrum, Review, Retrospective
- Roles: Development Team, Product Owner, Scrum Master (y stakeholders)
- y las pocas reglas que los vinculan:
Suscribirse a:
Entradas (Atom)