Cómo superar el examen PSK-I – Parte 3

Recuerda, el examen tiene tres bloques principales, en la parte 2 hemos visto las métricas, ahora vamos a ver las prácticas.

• Teoría de Scrum
• Prácticas de Kanban
• Métricas de Kanban (En la parte II)

Prácticas de Kanban

Según la guía oficial de Kanban para equipos Scrum, estas son las prácticas

• Visualización del Workflow
• Limitar el Trabajo en Progreso (WIP)
• Gestión Activa de los elementos de trabajo en progreso
• Inspeccionar y adaptar la definición de “Workflow” del equipo

Ojo, pregunta de examen: las prácticas que no aparecen aquí no forman parte de la guía, así que nada de identificar cuellos de botella.

El Workflow

La definición del workflow pertenece al equipo Scrum, es la forma en la que entienden las políticas que van a seguir para aplicar las prácticas de Kanban. Crear y adaptar el workflow es responsabilidad del equipo Scrum (Product Owner, Deverlopers)

Ojo: esto va más allá de la definition of done dado que el alcance del flujo de trabajo puede ir más allá del equipo. El workflow puede incluir tareas anteriores o posteriores que queden fuera del Sprint.

Responsabilidades

• Si el trabajo está dentro del Sprint Backlog, es propiedad de los desarrolladores.
• Si el workflow está relacionado con trabajo que se expande más allá del Sprint, se debería definir por el equipo Scrum.

Visualización del Workflow

Es una práctica que implica transparencia. La visualización debería incluir lo siguiente. No voy a añadir nada que no salga en la guía.

• Puntos definidos en los cuales el Scrum Team considera que el trabajo ha comenzado y ha acabado.
• Una definición de los ítems de trabajo – las unidades individuales de valor (para los stakeholders, conocimiento o mejora de procesos) que están fluyendo a través del sistema del Scrum Team (más probablemente ítems del Product Backlog (PBIs)).
• Una definición del workflow establece que los ítems de trabajo fluyen de inicio a fin (de los cuales debe haber al menos un estado activo).
• Políticas explícitas respecto a cómo el trabajo fluye por cada estado (que puede incluir ítems de la Definition of Done de un Scrum Team).
• Políticas explícitas respecto a cómo fluye el trabajo por cada estado (que puede incluir ítems de la Definition of Done de un Scrum Team y políticas pull entre estados).
• Políticas para limitar el Work in Progress (WIP)

Gestión activa del Work Items in Progress

• Asegurar que los ítems de trabajo solo se arrastran al Workflow a un ritmo parecido al que dejan el Workflow. Asegurar que los ítems de trabajo no se dejan envejecer innecesariamente.
• Responder rápido a ítems de trabajo bloqueados o en cola, así como aquellos que están superando los niveles esperados de Tiempo de Ciclo del equipo (ver Expectativa de Niveles de Servicio – SLE en inglés).

Aquí entra algo importante, los SLE:

• Un SLE es una predicción sobre el tiempo requerido desde el inicio hasta el final del workflow para un elemento de trabajo.
• La definición del SLE debe incluir un periodo de días y una probabilidad de que ese periodo se cumpla.
• El objetivo de los SLE es mantener al equipo centrado

Inspeccionar y adaptar la Definición de Workflow

Esta práctica habla de cómo el equipo Scrum mejora y adapta el Workflow:

• Políticas de visualización:
  • Estados del workflow, transparencia. En Kanban la visualización de las políticas es importante, definir qué significa cada estado y qué transiciones se pueden dar.
• Políticas de trabajo
  • Incluyen los SLE, los límites de WIP y el tamaño de los lotes de trabajo.
  • tienes que tener en cuenta que se debe definir cómo fluye el trabajo (definition of done extendida) que deben crearse definiciones para los estados y cómo se pasa de estado a estado
  • que debes definir los límites del WIP
  • cómo fluyen los elementos de inicio a fin
• Limitar el WIP
  • Una vez limitado el WIP debería mantenerse.
  • Limitar el WIP crea un sistema Pull
  • Limitar el WIP mejora la capacidad de autogestión, foco y compromiso
    • Recuerda que foco y compromiso son dos valores de los equipos Scrum
  • El equipo puede alterar el WIP en el momento que quiera, aunque lo ideal sería analizar esto en una retrospectiva.
  • Se pueden ‘etiquetar’ excepciones al WIP

Cambios en los eventos de Scrum

Recuerda la guía Scrum no se ve alterada, aquellas definiciones que aplicaban a los eventos siguen siendo válidas. La guía Kanban para equipos Scrum no afecta a:

• La duración de los eventos.
• El número de eventos
• El momento de los eventos
• Los participantes de los eventos

Así que todo lo que dice la guía Scrum sigue siendo 100% válido. Ojo al examen con las respuestas que incluyan frases como «Kanban reduce la duración de los eventos» o «El refinement se elimina en Kanban» o «la duración de los eventos disminuye».

• El Sprint:
  • Se puede entregar valor más de una vez por Sprint, de hecho en la guía Scrum no se limita esto, pero la guía Kanban para equipos Scrum lo enfatiza aún más.
  • Ojo: en el examen aparece una pregunta curiosa (me apareció en mis dos intentos: ¿qué sucede si el equipo se guarda parte de su capacidad para eventos inesperados? -> en este caso la respuesta es que el sprint goal se convierte en más importante, haremos pull de los elementos que nos permitan llegar al sprint goal frente a otros elementos.
• Sprint planning
  • Usaremos las métricas de flow para ayudarnos, nos centraremos en el throughput (qué capacidad tiene el equipo) y en caso de arrastrar elementos de anteriores sprints veremos también la edad de esos elementos.
• Daily
  • Recuerda que la guía Scrum no se ve alterada. Así que el Daily se basará en inspeccionar el tablero y ver ítems bloqueados, edad de los ítems en el tablero, si algún ítem ha violado ya el ENS, si estamos respetando el WIP
  • Nos centraremos en las métricas WIP y edad de los pbi
• Review:
  • Inspeccionaremos el rendimiento, podemos empezar a ver valores de tiempo medio de ciclo
• Retro:
  • Revisaremos nuestras métricas, especialmente el throughput, y si es necesario podemos ajustar el WIP.