kanban

Professional Scrum with Kanban – Virtual Edition

Virtual Evento

23 noviembre, 2020 a las 3:00 pm al 25 noviembre, 2020 a las 8:00 pm

Professional Scrum with Kanban

Professional Scrum with Kanban™ (PSK) es un curso de 2 Dias de duración que enseña como aplicar prácticas de Kanban a participantes experimentados con Scrum. A través de teoría, casos y ejercicios, los alumnos entienden la importancia de la transparencia y el flujo como parte del uso de Scrum.

Scrum es el standard de facto para equipos Ágiles. Para funcionar, necesita usarse al completo y es un gran contenedor para otras técnicas y prácticas. Los equipos Scrum siguen mejorando como trabajan, basándose en lo que aprenden e inspeccionando y adaptando frecuentemente.

¿Qué voy a aprender?

En esta clase, los alumnos aprenden como equipos Scrum pueden introducir prácticas adicionales de Kanban mientras continúan trabajando de la misma forma que con Scrum, sin cambiarlo.

Scrum.org y el equipo de Professional Scrum Trainers han estado trabajando con Daniel Vacanti para diseñar este curso. En 2007, Daniel ayudó a dar forma al método Kanban para trabajo basado en el conocimiento. Gestionó la primera implementación de Kanban ese año y ha seguido trabajando para introducir Kanban como trainer, coach, consultor y mentor desde entonces.

Objetivos del curso

Conseguir entender como funciona el Flow dentro del contexto de Scrum

Exposición a prácticas de Kanban que los equipos de Scrum pueden adoptar para ayudar a mejorar su efectividad y eficiencia

Entender como usar de manera efectiva estas prácticas sin cambiar Scrum

Aprender un enfoque práctico para mejorar la transparencia y la visibilidad del trabajo

¿Para quién es este curso?

El curso Professional Scrum with Kanban™ es para cualquier que use Scrum. Es particularmente beneficioso para aquellas personas dentro de una organización que utilizan Scrum para entregar productos, incluyendo Product Owners, miembros del Equipo de Desarrollo y Scrum Masters.

Temas del curso

Rompiendo mitos comunes
Entendiendo Professional Scrum
Teoría de Kanban, principios y prácticas
Kanban en la práctica
Scrum con Kanban

Certificación Professional Scrum with Kanban

Todos los participantes que completan el curso Professional Scrum with Kanban™ reciben dos intentos para la certificación Professional Scrum with Kanban I (PSK I). Este examen sólamente está disponible para alumnos que participan en la clase actualmente. Si intentas el test y no pasas durante los siguientes 14 días del curso, tienes un siguiente intento sin coste adicional.

Hola, soy Nacho

Professional Scrum Trainer

Jerónimo Palacios

Edición Virtual

Curso realizado a través de una plataforma virtual para clases en directo. + Google Map

+34 689 399 468
Ver la web Local

995,00€

Eventos Relacionados

Kanban y la transformación digital

Hoy me gustaría compartir con vosotros un error que cometí hace tiempo y que a día de hoy sigue siendo uno de lo que más me encuentro a la hora usar el método Kanban como palanca de transformación en las organizaciones.

Hace pocos días mi compañero Jero nos contó qué es la transformación digital en un post altamente recomendable. Otra de las consecuencias de todo lo que explica Jero en ese post es que en las grandes organizaciones todo empezó a gestionarse con Silos Técnicos. Es muy tentador pensar que así está todo muy bien ordenadito. Front por un lado, backend por otro, middleware y los gestores de infraestructuras por otro. De hecho, puedo externalizar todo cómodamente y controlar la productividad de mis proveedores con puntos función, número de historias de usuario, o cualquier otra métrica de actividad (y no de valor).

Como ninguno de estos silos es capaz de producir valor al usuario final por sí mismo debemos crear una entidad que aglutine el trabajo de todas estas islas tecnológicas y lo entregue al usuario final. Y así surge la figura del Proyecto. Cuando alguien tiene una idea de negocio solicita a todos los silos el impacto que tienen en el proyecto y una estimación de en qué release podrán tener lista su parte. Tras un mes de reuniones se les comunica si realmente ese proyecto ha sido aprobado en el comité y en qué release esperan liberarlo.

Kanban como solución

Esta forma de trabajar genera miles de dependencias y bloqueos, además de un “Time to market” que, por experiencia personal, supera ampliamente el año. Esta claro que hay que hacer algo. Las organizaciones se suman al carro de la transformación digital y comienzan a apostar por métodos Ágiles.

Uno de los métodos Ágiles más conocidos es Kanban y a las oficinas de Transformación les suele encajar cuando hablamos de un silo tecnológico que da servicio al resto de la compañía.

Pero pensemos por un momento el ciclo de los proyectos. Separaremos en dos alturas cuando hay alguien trabajando en el proyecto y cuando está esperando a que alguien realice otro trabajo:

Este es el escenario en el mejor de los casos. Generalmente las releases tienen una fecha a la que algunos silos llegarán con el trabajo terminado y otros no. Lo que nos va dejando proyectos incompletos dentro de nuestro sistema durante meses y meses. Esto hace competir a las grandes en la carrera de la innovación entregando al usuario ideas que tuvieron hace más de 12 meses.

Obteniendo beneficio limitado de Kanban

Cuando se empieza a trabajar con Kanban en muchas organizaciones se piensa que el problema está en los equipos. Que no sacan el trabajo suficiente y se pone el foco en mejorar esos pequeños picos de actividad que vemos en la imagen anterior en vez de en los periodos de espera. Trabajar en tratar de mejorar esa eficiencia de recurso en vez de la eficiencia de flujo de todo el proceso nos hace desperdiciar mucho dinero y tiempo obteniendo pocos beneficios.

Si comenzamos a trabajar con Kanban solamente a nivel de silos seguramente habremos ganado en visualización de nuestro trabajo, gestionaremos mejor los riesgos y hasta podremos aumentar nuestra tasa de entrega. Pero lamentablemente esto apenas impactará en el time to market global, en que el número de bloqueos baje o en que generemos más valor. En definitiva, nuestro impacto en aumentar beneficios en la empresa será prácticamente nulo.

¿Cómo podemos lidiar con esto?

Un buen Agile Coach debe buscar la visión sistémica y ayudar a la organización a entregar más y más valor al usuario. Agile es un medio para maximizar revenue, gestionar riesgos y aprovechar oportunidad de mercado. Pero Agile no es un fin en sí mismo. Hay que tener cuidado de caer en la trampa de tener una lista de checks de si los equipos tienen tableros o no, si hacen dailies o no, si hacen retrospectivas o no, y quedarnos ahí. Cuidado con la vanidad de las métricas de actividad. (Aquí te dejo el enlace a nuestro Kanban Metric Layout por si te interesa)

Soluciones hay muchas y depende del contexto. Te puede ayudar:

Que la organización sepa hablar de “flujo” a todos los niveles. Y entiendan cómo funciona.
Tener métricas orientadas a flujo: Lead time, throughput, tiempo medio de bloqueo, etc.. en los equipos, y a nivel programa o portfolio.
Poner el foco en eficiencia de flujo en vez de en eficiencia de recurso.

Entendiendo el concepto de flujo, visión sistémica y usando correctamente el método Kanban se puede obtener un alto impacto en un tiempo reducido. Si quieres saber más:

El Scrum Master vs el Agile Coach

En Septiembre estuve unos días trabajando en Colombia con el equipo de Scotia Bank, formando a futuros Scrum Masters y Product Owners. También estuve en las oficinas de Everis en Bogotá en un Meetup organizado por Agiles Colombia.

En ambos sitios me hicieron una pregunta que creo ronda la cabeza de más de uno, así que me anoté hacer la primera newsletter después de las vacaciones sobre este tema: ¿Que diferencia al Scrum Master del Agile Coach?

Los orígenes

Cuando Takeuchi y Nonaka, con la ayuda de Ken-Ichi Imai hicieron una investigación en 1986 sobre el rendimiento de determinados equipos de compañías líderes en el desarrollo de producto, hicieron un símil con el Rugby, y específicamente con las Melées (Scrum) para definir lo que hacía distintas a estas compañías de otros equipos.

En ese momento no hay ninguna mención a roles fuera del equipo de desarrollo de producto.

Posteriormente, cuando Ken Schwaber y Jeff Sutherland modelan y prueban un proceso de desarrollo de Software que presentan en 1995, tampoco incluyen la necesidad de un actor externo al equipo. Hay que hacer notar que Scrum podía basarse en los roles propuestos por Ian Graham y estaba fuertemente ligado a la programación orientada objetos.

En la primera versión de Scrum, no hay una mención explícita al Scrum Master. Tampoco hay una práctica de retrospectiva, pero de eso hablaré más adelante.

En 1999, Kent Beck publica el libro sobre Extremme Programming. Describe la necesidad de incluir roles claros dentro de XP, entre ellos el de Coach. Por primera vez menciona la necesidad de una persona que se encargue de tomar el rol de “Acompañar y entrenar” a los miembros del equipo. Durante los años 1999 a 2004, XP fue mucho más popular que Scrum.

Después de crear Scrum y con las experiencias acumuladas de Jeff Sutherland en Easel y Ken Schwaber en Fidelity, además de los trabajos de Kent Beck en XP y Martin Fowler sobre la integración continua, todos estos actores, junto con aquellos que había tenía mucho éxito en XEROX y 3M durante finales de los 80 y los 90, empezaron a intercambiar experiencias que dirigirían de manera definitiva todos estos marcos, metodologías y librerías de prácticas.

Un ejemplo de esto es el uso de retrospectivas, que sólamente se popularizó con la publicación del libro de Norman Kerth en el año 2002. Para entonces la Agile Alliance y la Scrum Alliance hacía tiempo que eran una realidad.

Ken Schwaber ya daba cursos de Scrum y hacía tiempo que había incorporado la figura del Scrum Master dentro de sus materiales, como se puede comprobar en este PDF que utilizaba para training en el año 2002.

De hecho, la figura de coach ya era popular en el año 2003 cuando se debatía sobre su rol en el éxito de compañías, como se puede comprobar en este paper resumen de la 18ª conferencia de la ACM.

¿Quien era un Agile Coach? Alguien que tiene una visión global y es capaz de promover cambios competitivos en una compañía a través de su experiencia en el campo de la gestión de desarrollo de producto.

¿Y el Scrum Master? Es, quien siendo miembro de un equipo Scrum, ayuda a éste y a la organización a mejorar el valor entregado a través de la entrega rápida de producto terminado.

Entonces la principal diferencia es que mientras el Agile Coach actúa principalmente a un nivel de departamento o de organización, el Scrum Master lo hace desde la entrega (delivery) y también la organización.

El Scrum Master y el Agile Coach en 2020

Recuerdo poco antes de la última CAS, cuando cenando con unos amigos, uno me dijo: “Después de escucharte he llegado a la conclusión de que yo también soy Agile Coach”. Eso me produjo una sensación de desasosiego. Estaba claro que algo había explicado mal cuando una persona que definitivamente no tenía ninguna característica que la resembrara a esos Agile Coaches de 2003 pudiera pensar que transformaba organizaciones.

Existe una confusión entre disciplinas. Aquellos que llegan de fuera del mundo del Software tras haber recibido una extensa formación de coaching que en algunos casos conlleva hasta cinco fines de semana, comprueban como no hay mercado más allá de formar a otros coaches, consideran que el Agile Coaching es una mezcla de Agile con técnicas de Coaching.

Mientras que las técnicas de Coaching pueden ser ciertamente efectivas como complemento, la figura de Agile Coach necesita tener un conocimiento profundo de Negocio, Procesos y Transformación como parte de su abanico de propuestas.

Es por eso que un rol de Scrum Master puede ser más asequible. Desde un equipo Scrum, es relativamente más sencillo aprender, practicar y adquirir experiencias transformadoras desde la entrega de valor para luego exportarlas al resto de la organización.

Sin embargo, ocurre una paradoja. Mientras que parece que el siguiente paso natural para un Scrum Master es convertirse en Agile Coach, no lo es en absoluto. Esto es porque estos roles se solapan, no expanden uno sobre otro. En ocasiones, el Agile Coach puede carecer incluso de conocimientos necesarios para mejorar el valor de la organización. En otras palabras: Puede que ni siquiera pueda justificar su alto coste.

Por lo contrario, un buen Scrum Master no solamente tendrá una gran demanda, sino que muy posiblemente sea capaz de hablar con distintas capas de la organización. A diferencia del Agile Coach, donde puede (o no) hacerlo en función de su experiencia para transformar, para el éxito de Scrum dentro de la organización, no queda más remedio que hacerlo.

Resumiendo, un buen Scrum Master siempre será un buen Agile Coach, mientras que un Agile Coach será bueno o no dependiendo de sus experiencias, que en mi observación, son extremadamente variables.

Uno de los motivos por los que en Otoño celebramos la primera edición del curso de Professional Scrum Master II es dar la oportunidad a aquellos que ya están experimentando cambios de relevancia en su organización una oportunidad para poder tener un espacio donde reflexionar más allá de las prácticas y aprender nuevas formas de facilitar el cambio en su trabajo diario. Este curso, al igual que el de Professional Agile Leadership, no está tan centrado en el conocimiento como en la práctica.

Como dice Ken Schwaber: “Scrum es simple de entender y muy difícil de dominar”. Hemos querido crear un espacio donde el acompañamiento y la mentorización sean el ingrediente fundamental para proporcionar a nuestro alumnos la posibilidad de seguir creciendo acompañados por nosotros.

Scrum y Kanban, lo peor de los dos

No se en cuantas ocasiones es escuchado -y me han preguntado- si la solución a un equipo de soporte es hacer Kanban en lugar de Scrum, o si un equipo que recibe muchas interrupciones debería de pasarse a un sistema Kanban en lugar de Scrum, o hacer Scrumban.

Scrum bien hecho. Scrum mal hecho.

Scrum tiene una serie de premisas:

Tienes un producto con un Product Owner que se encarga de maximizar su valor.
Tienes un equipo de desarrollo que trabaja para ese producto.
Tienes un Scrum Master que gestiona Scrum y sirve al equipo de desarrollo.

Si no tienes un producto, no vas a obtener valor de Scrum. Si no tienes un Product Owner, no vas a obtener valor de Scrum. Si no tienes un equipo de desarrollo, no vas a obtener valor de Scrum. Si no tienes un Scrum Master, no vas a obtener valor de Scrum.

Sí, vale. Puedes hacer Daily Scrums, o Retrospectivas. Pero eso no es Scrum. Simplemente, no lo llames Scrum. Scrum es gratuito y libre para su useo, pero para hacer Scrum necesitas tres roles, tres artefactos y cinco eventos. Puedes hacerlo sin Definition of Done, Sprint Goal o Refinamiento y aún así seguiría siendo Scrum. Pero eso son los básicos.

Kanban bien hecho. Kanban mal hecho.

Kanban necesita una serie de premisas:

Tienes un flujo de trabajo que puedes visualizar
Puedes limitar el trabajo en curso (p.e. decir NO cuando algo que alguien considera urgente entra al flujo)
Tienes control para cambiary gestionar ese flujo de trabajo
Puedes establecer políticas explícítas (Clases de servicio, Cadencias, etc…)
El ritmo de llegada de nuevo trabajo es similar al ritmo de salida del trabajo.

Si no tienes un flujo de trabajo, Kanban no te va a aportar valor. Si tienes que decir que SI a todo el trabajo que te entra, Kanban no te va a aportar valor. Si no tienes control sobre tu sistema porque otro decide como funciona, Kanban no te va a aportar valor. Si no puedes decidir sobre las políticas del sistema, bueno… creo que ya está claro.

Si, puedes tener un tablero con Post-its y moverlos de un sitio a otro, asignando avatares y haciendo Daily Stand-ups y simulando que eres ágil. Pero si no cumples esas tres condiciones, a pesar de que hagas un Proto-kanban, nunca obtendrás ningún valor.

Scrumban: Lo peor de lo peor, junto.

Cuando la gente me pregunta por Scrumban, siempre me temo lo peor. El caso genérico, con ciertas variaciones es:

“Scrum no funciona para nosotros porque no tenemos un producto, nosotros trabajamos por proyectos. El Product Owner es un Project Manager reconvertido que se encarga de hacer una lista de las cosas que hay que hacer. Además tenemos un SLA y salen un montón de bugs durante el Sprint que tenemos que arreglar, así que hemos incorporado un carril de urgentes en el Sprint Backlog en el que además de hacer los bugs, vamos metiendo lo que se la ha olvidado al Product Owner. Los Stakeholders no vienen a nuestras “demos” y las retrospectivas son para el equipo de desarrollo y para el Scrum Master.

Vemos que es muy difícil saber cuanto estimar en el Sprint Planning y las cosas no salen nunca, por eso empezamos a usar Scrumban.”

Esto no es Scrumban, no es Kanban y tampoco es Scrum.

Lamentablemente esta no es una situación que se arregle con ningún método ágil, así como ningún consultor o Scrum Master va a ser capaz de hacer nada por esta organización.

La solución

El primer paso para arreglar un problema es aceptar que existe un problema. Generalmente en este tipo de organizaciones tienen claro en todas las capas que las cosas van mal, pero hay poca voluntad de solución.

Los problemas aquí deben ser atacados desde la parte ejecutiva de la organización. De nada sirve que un equipo lo haga mejor si la cultura es: “Lo quiero, y lo quiero para ayer”.

Todo lo demás son castillos en el aire.

El primer tablero Kanban del equipo

Desde la experiencia con varios equipos, hoy me gustaría hablarte de la evolución de un tablero Kanban concreto. Es cierto que las decisiones de unos equipos a otros no se parecen, ni las necesidades o su trabajo. Pero he vivido una serie de momentos que se repiten en el tiempo. Algo así como El día de la marmota para un Agilista

Podríamos llamarlo “los primeros escalones” cuando un equipo empieza a usar cualquier metodología, marco de trabajo o mentalidad Agile. Y el tablero es una de las herramientas más valiosas como comentaba en mi artículo anterior.

De menos a más

Todos empiezan con algo muy sencillo, normalmente por consejo del Scrum Master o el Agile Coach que les esté acompañando. Entonces, lo primero será visualizar el flujo de trabajo del equipo en cuestión. El equipo prepara un tablero y te enseña esto:

Ahora es cuando te toca hacer preguntas. ¿Solo tenéis 3 pasos en vuestro flujo?¿Quién pone esas tarjetas ahí?¿tienen orden alguno o prioridad?… pero voy a hablar de la primera para empezar.

Visualiza tu workflow o flujo de trabajo

Al principio los miembros de un equipo tienen oxidado este tipo de análisis. Porque no suelen analizar como trabajan, sino el trabajo en sí. Así que, a ti, que estás intentando ayudarles a crear un tablero Kanban útil, te costará muchas preguntas, algunos momentos incómodos, un poco de presión y mucha paciencia.

Tras una buena charla con todos los miembros del equipo, incluyendo siempre al Product Owner o Manager que tiene visión de negocio, se han añadido nuevas columnas. Ahora en algunos de los miembros del equipo puedes ver cierto brillo en los ojos, ¡incluso alguna sonrisa!. Esto se debe a que han tratado temas que les suelen doler, porque se atascan, donde no tienen mucho poder y ahora es visible. Así que el equipo trae esto:

Evitemos el caos

Ahora sabemos que hay más pasos en el flujo de trabajo. Pasos que son importantes porque se toman decisiones que no son solo técnicas, sino de negocio.

Al final muchos equipos deciden meter una columna de “Test” para la comprobación de que todo está como debería, pero pocas veces se trata de un test técnico. Es algo que al principio me sorprendía, ahora ya se que es uno de esos “primeros pasos”. Duele menos llamar así a la comprobación del Manager o el PO de que ese item es lo que ellos habían pedido.

Añadir WIP limits al tablero kanban

Como puedes observar, en el segundo tablero, hay mas columnas con el mismo número de tarjetas. Y casi todas las subtareas técnicas están en la columna “test” provocando de esta manera, un pequeño embudo que acumula tareas sin terminar. Por otro lado, todas las subtareas ya están en proceso o en test, pero algunas no se están avanzando. Toca sesión de preguntas incómodas de nuevo. ¿Esto es real? ¿se está trabajando en todas y cada una de las subtareas?

Si queremos que el tablero kanban sirva para algo y nos haga mejorar, hay que cambiar de mentalidad. Kanban nos ayuda a trabajar con una mentalidad pull y evitar el empezar mucho y acabar poco.

Hace unos días, mi compañero Nacho Navarro publicó un post interesante que te recomiendo acerca de elegir los WIP limit. Básicamente un WIP limit es un límite del trabajo activo que puede existir. Se puede limitar por columnas, por personas, el sistema completo, etc.. Por ejemplo, un equipo con 3 desarrolladores podrían decidir que no hubiera más de 3 tareas en curso en la columna “doing” a la vez. De esta forma nos asegurarnos de que creamos un sistema pull real.

Gestión del flujo de trabajo

Es importante que el mensaje de la mentalidad pull haya calado. En este tablero mejorado vimos muchos cambios:

Priorización de los elementos y sus tareas.
Orden para terminar más trabajo que antes.
Problemas de estancamiento o embudos.
Posibles necesidades de mejora para el tablero del equipo.
Métricas. Ahora podemos medir cuánto tardamos en entregar algo.

Políticas explícitas para usar bien el tablero

Esta vez, y solo para evitar tentaciones, hay que añadir las reglas del juego. Si queremos que esto funcione de verdad, necesitamos ser legales. Nada de decir que una tarea está “casi hecha” en la columna de “Done”.

Estas son una serie de requisitos que una subtarea debe cumplir si queremos pasarla a la siguiente columna. Si no los cumple, no está lista para pasar a la siguiente columna. Del mismo modo que si la columna siguiente tiene el WIP limit ocupado, tampoco puede pasar aunque las políticas se cumplan.

Esto nos ayuda a funcionar mejor con el sistema pull de Kanban. Así nos centramos en acabar el trabajo ya empezando en lugar de empezar otra tarea nueva. El equipo entendió que era necesario poner unas políticas explícitas en cada columna de paso. Así se aseguraban un mínimo en la nueva columna. El tablero quedó así:

Mejora continua de verdad

El último paso también es muy importante, ya que nos permite ir viendo estas evoluciones a lo largo del tiempo y los proyectos. Un ejemplo de ello es que en este último cambio, también añadieron algunas clases de servicios con diferentes colores en las tarjetas. Así se aseguraban que si alguna tenía fecha fija o era prioritaria, la vieran antes. Es necesario tomarse un tiempo de reflexión de todo el equipo en conjunto para tratar posibles mejoras.

Por supuesto esto es una versión reducida de un sistema que se puede complicar todo lo que necesitemos. Para ello podéis pasaros a leer la guía de Kanban que tenemos en la web, que es muy completa.

Espero que te sirva de inspiración este pequeño resumen en base a mi experiencia. En próximos post escribiré otros ejemplos, hablaremos de las tarjetas Kanban y de posibilidades dentro de un tablero kanban.