Saraclip

Always learning about UX, Agile & Psychology

Scrum

Cronología de la creación de Scrum

, ,

Scrum es un marco de trabajo creado antes que el Manifiesto agil (no olvidar que fue escrito en 2001, aunque sus creadores, Ken Schwaber y Jeff Sutherland participaron también en ello junto a otras personas).

A continuación detallo las fases que pasó:

1986

Aunque no lo denominan Scrum, Hirotaka Takeuchi y Ikujiro Nonaka presentan un paper llamado «New Product Development Game» donde comentan un nuevo enfoque en el desarrollo de productos flexible y holístico, con ideas muy claras que luego se aplicarían en Scrum.

Posteriormente explican que es una forma de creación de conocimiento en el ámbito organizacional perfecto para entornos en los que la innovación continua, incremental e iterativa deba estar presente.

En este nuevo framework, un equipo trabaja como una unidad para alcanzar un objetivo común, como oposición al enfoque tradicional donde se establece el desarrollo como una secuencia de fases independientes entre ellas.

1990

Ken Schwaber empieza a utilizar las primeras aproximaciones de lo que luego se llamaría Scrum como métodos de desarrollo avanzado. A la par, Jeff Sutherland, usa un enfoque similar en Easel Corporation junto a John Scumniotales y Jeff Mckenna, siendo el primero en utilizar la palabra Scrum (termino inglés de rugby para denominar a una melé).

Seguir leyendo «Cronología de la creación de Scrum»

Retro 2019

, , ,

Como ya sabéis para mí el trabajo en equipo es fundamental. No creo en otra forma de crear los mejores productos y servicios que no sea en base a la suma de los conocimientos de todos los miembros, personas totalmente involucradas y responsables y orgullosas de lo que están haciendo.

Por eso aprovechando que tenía que estar en Zaragoza, decidimos montar una retro del año 2019. En el trabajo no hacemos SCRUM, sino una mezcla de cosas de diferentes frameworks. Por ello, después de cada sprint no hacemos retros, y pensé que por lo menos podíamos hacer una general del año, para alinear ideas, expectativas, el estado de ánimo…

Y es que aunque tengamos una gran comunicación entre todos, nunca viene mal juntarnos y generar un espacio seguro dónde hablar.

Avisado al equipo y reservado la sala para el final de la mañana del viernes, lo primero que quería hacer era un juego introductorio para generar buen ambiente. No es que sea necesario, ya que de lo que más orgullosa estoy es del rollo que tenemos en los equipos, pero me apetecía sorprenderles con algo.

Seguir leyendo «Retro 2019»

3 consejos para escalar equipos técnicos por Jorge Gómez Sancha

, , , ,

Hola,
os recomemiendo mucho escuchar los PodKast de KFund ya que tratan muchos temas variados con gente super interesante. En concreto este de Jorge Gómez Sancha (@jorgesancha), actualmemnte trabajando en Carto como, hablando sobre «Escalando equipos técnicos», un tema que siempre me ha parecido super interesante ya que creo que uno de los mayores problemas de las empresas es la gestión del talento y del trabajo cuando comienzan a crecer.

Escalando equipos

Imagen extraída de la web de blog.kfund.vc

Como no, mucho mejor escucharlo en directo. Pero me he quedado con 3 consejos que da al final y que me gustaría resumir:

  1. Tener claro a quién reporta cada uno. Al crecer lo que funcionaba hacer 3 meses ya no funciona por lo que hay que ir definiendo la forma de trabajo continuamente.
  2. Un único sitio en el que saber que tiene que hacer cada persona. Que cualquiera de la empresa pueda mirar y sepa lo que esta haciendo y su siguiente prioridad. Parece fácil pero al crecer no lo es. Lo primero que hizo al entrar en Carto fie estandarizar el Kanban, con una única forma de gestionarlo. Luego cuando lo dominen que ya evolucionen (si te gusta esto te puede interesar este resumen sobre Equipos de alto rendimiento, de la genial charla de Israel Alcazar (@ialcazar) en la CAS 2017 ).
  3. Comunicar mucho más de lo que crees que tienes que comunicar. Por qué estamos haciendo las cosas «estamos haciendo esto porque la estrategia era uno, dos y tres», repetir las cosas mil veces… Nunca hay tiempo, nunca es prioritario pero hay que hacerlo.

Y es que como comenta Jorge, muchas veces en una empresa se asciende a alguien interno que está haciendo un buen trabajo y se le convierte en Manager o CTO, o VP…

Pero eso no quiere decir que se le de bien gestionar, saber tratar a la gente y todo lo que implica el trabajo además de que seguramente va emplear muchas más horas de lo que cree. Sobre todo en startups donde el perfil puede ser más joven, Sancha recomienda dedicar tiempo a darles pautas: tienes que hacer “One to one”, checkings….

Yo he estado en empresas que he visto como ponían a gestionar a magníficos desarrolladores, pero que no servían para nada sabiendo motivar al equipo, controlando el avance el trabajo en base al road map planteado, reportando al CEO o a Inversores las nuevas mejoras o los problemas encontrados, no sabiendo pedir ayuda al ver que todo se le escapaba de las manos…

Lo malo es que cuando el puesto es alto, aunque los de abajo vean lo que ocurre, desde arriba aun se puede tardar varios quarters en ver lo que pasa. Y eso es mucho dinero. ¿Y una vez detectado? Posibles soluciones: ponerle un coach que le enseñe, cambiarlo de posición al puesto que antes hacía tan bien, poner a otra persona a hacer la parte que menos controla…

Lo dicho, espero que os guste el podKast, a mi me ha parecido genial!

CAS 2017 (Conferencia Agile Spain)

, , , ,

La semana pasada asistí como voluntaria a la CAS 2017, la Conferencia Agile Spain 2017, como se deonominan ellos, la mayor y más importante conferencia sobre agilismo en España.

Me hacía especial ilusión porque, aunque en Valencia he coordinado los meetups de UX Academy, y he asistido a un montón de eventos (pagando entrada), me apetecía mucho vivir por dentro, desde la parte de la organización, un acontecimiento de tal tamaño.

¿Y el resultado?

3 días de locura nonstop, recortando pegatinas, montando urnas, haciendo chapas, doblando camisetas, montando el welcome pack (750 mochilas con agendas, cuadernos, flyers, macetas, libros, spinners…), gestionando las salas, haciendo de guardarropa de abrigos, maletas y mochilas…

Todo ello rodeada de gente genial, y conociendo a muchas personas relacionadas con el sector.

Os dejo el vídeo resumen realizado por l@s super chic@s de Autentia:


¿Me ves en el vídeo? 😉

2 días completos, 4 tracks paralelas más 2 salas de talleres, y unas 750 personas entre ponentes, asistentes y organizadores. ¿Te apuntas al del año que viene? Yo si puedo si!

Eventos en Scrum II

, , , ,

Seguimos hablando de los eventos en Scrum. En el anterior post hablé sobre el Sprint y el Sprint Planning. A continuación seguiré con Daily, Sprint Review y Sprint Retrospective.

3. Daily Scrum

Es un evento que se celebra cada día, de duración de 15 minutos, en el que el Development Team sincroniza las actividades y crea un plan para las próximas 24 horas. Lo ideal es que se haga siempre a la misma hora y en el mismo lugar para que todo el mundo lo recuerde de forma fácil

La Daily Scrum sirve para inspeccionar el progreso hacia el Sprint Goal y cómo avanza el progreso. Para ello, se inspecciona el trabajo realizado en el último día y se comenta el trabajo que se va a realizar ese día.

¿Cómo se realiza?

Durante la reunión, los miembros del Equipo de Desarrollo explican:

  • ¿Qué hice ayer para ayudar al Developement Team a cumplir el Sprint Goal?
  • ¿Qué voy a hacer hoy para ayudar al Development Team a cumplir con el Sprint Goal?
  • ¿Veo algún impedimento que me impida a mí o al Developement Team a cumplir con el
    Sprint Goal?

La Daily Scrum es una reunión clave para inspeccionar y adaptar.

La Daily Scrum optimiza la probabilidad de que el Development Team cumpla con el Sprint Goal, cumpliendo las siguientes funciones:

  • Ayuda a que la comunicación sea más fluida entre los miembros del Team
  • Se identifiquen impedimentos y se proceda a realizar las acciones necesarias para su eliminación
  • Se detecten antes las desviaciones (si existen)
  • Mejora el nivel de conocimiento de los miembros del equipo de lo que sucede diariamente
  • Promueve la toma de decisiones de forma rápida

El Scrum Master se asegura de que el equipo de desarrollo tenga la reunión, pero es el Development Team el que es responsable de realizar la Daily.

Sprint Review

La Sprint Review (Revisión del Sprint) se lleva a cabo al final del Sprint con el objetivo de inspeccionar el incremento y adaptar el Product Backlog si es necesario. El Sprint Team y los stakeholders revisan lo que se ha hecho en el sprint y en función de eso y de cualquier cambio producido en el Product Backlog, se decide cuales son las siguientes acciones para optimizar el valor.

El objetivo es obtener retroalimentación y fomentar la colaboración.

Es una reunión de 4 horas de duración máxima para Sprint de un mes, asegurándose el Scrum Master de que tiene lugar y que los asistentes entiendan su propósito. Es el Product Owner el que inivita a los stakeholders que cree conveniente a participar.

Seguir leyendo «Eventos en Scrum II»

Eventos en Scrum I

, , , , ,

Los eventos se usan en Scrum para crear un patrón constante y minimizar la necesidad de reuniones no definidas.

Todos los eventos son «time boxeados», es decir, tienen una duración máxima, pudiendo acabarse, siempre que se logre el objetivo del evento.

La idea es evitar el desperdicio de tiempo

El Sprint es un evento «contenedor«para todos los demás eventos, siendo cada uno de ellos una oportunidad formal para inspeccionar y adaptar algo. Y es que los creadores de Scrum,Jeff Sutherland y Ken Schwaber, diseñaron estos eventos para conseguir la máxima transparencia e inspección.

Scrum events

Existen 5 eventos diferentes:

  1. Sprint
  2. Sprint Planning, o Planificación del Sprint en castellano
  3. Daily Scrum, normalmente llamada Daily
  4. Sprint Review, o Revisión del Sprint
  5. Sprint Retrospective, o Retrospectiva del Sprint

He estado en algunas empresas que unifican Sprint Planning con Sprint Review, llamándo al evento «Syncro» o «Planificación» (adaptan Scrum a lo que han visto que mejor le funciona).

1. El Sprint

El Sprint es la base del Scrum. Es un periodo de tiempo de 1 mes, 3 o 2 semanas, durante el cual se crea un incremento de producto, utilizable y potencialmente liberable. Lo ideal es que siempre tengan la misma duración.

Para entender el párrafo anterior, debemos ver cada Sprint como un proyecto con un horizonte no mayor a un mes. Y al igual que un proyecto, el Sprint se utiliza para lograr algo. Cada Sprint tiene una definición de lo que se va a desarrollar, un diseño y un plan flexible que guiará su construcción, el trabajo y el producto resultante.

Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.

Un sprint está formado por el Sprint Planning, las Daily Scrums, el trabajo de desarrollo, Sprint Review y Sprint Retrospective.

Consideraciones a tener en cuenta durante el Sprint

  • No se realizan modificaciones que pongan en peligro el Sprint Goal.
  • Los objetivos de calidad no disminuyen.
  • El alcance (scope) puede ser clarificado y renegociado entre el Product Owner y el Developmente Team a medida que se descubren las cosas.

La limitación máxima de un mes es para minimizar riesgo y desperdicio. Si es más tiempo, en el mundo tan cambiante en el que estamos, la definición de lo que se está construyendo puede quedarse obsoleta, aumentando además la complejidad de lo creado.

Seguir leyendo «Eventos en Scrum I»

Funciones del Scrum Master

, , , ,

Seguimos con los post sobre Scrum (ver anterior post sobre los Roles de Scrum) en este caso explicando las funciones del Scrum Master, dentro de su dualidad sirviente-líder que ocupa para el Scrum Team y para la organización.

Scrum Master

Imagen obtenida www.scrumalliance.org

Cuando una organización cambia su modo de trabajo a Scrum todos deben aprender como integrarlo, que nuevas funciones tienen y cual va a ser la forma de desarrollar los productos.

El Scrum Master es la persona encargada de servir de apoyo a todos los integrantes en ese nuevo cambio.

Y es que por muchas ganas que tenga todos los integrantes de cambiar la forma de trabajar (no hablemos si alguien es reticente) la misión no es sencilla, por lo que el Scrum Master igual el que Product Owner deben ser personas empáticas, colaboradoras, pacientes, y con el coraje de defender los roles y funciones de Scrum.

Funciones del Scrum Master para el Product Owner

La persona que adquiere el rol de Scrum Master sirve al Product Owner de varias maneras, que incluyen:

  • Encontrar técnicas para una gestión eficaz del Product Backlog.
  • Ayudar al Scrum Team a entender la necesidad de elementos claros, concisos y bien definidos en el Product Backlog.
  • Comprender la planificación del desarrollo de productos en un entorno empírico.
  • Asegurar que el Product Owner sepa cómo organizar el Product Backlog para maximizar el valor.
  • Comprender y practicar la agilidad.
  • Facilitar eventos de Scrum según se solicite o necesite.

Funciones del Scrum Master para el Development Team

El Scrum Master sirve al Equipo de Desarrollo de varias maneras,  siendo para mi la más importante la de ayudarle a eliminar impedimentos. Y es que muchas veces el trabajo no sale porque las personas no saben como proseguir o si pueden hacer algo o no.

Seguir leyendo «Funciones del Scrum Master»

Roles en Scrum

, , , ,

A continuación voy a hablar de los roles que existen dentro del Scrum Team y que funciones y deberes tiene cada uno.

Scrum no tiene un rol llamado «Project Manager».

Scrum Team

Scrum Team

El Scrum Team se compone de 3 perfiles:

  1. Product Owner (1 persona)
  2. Development Team (Varias personas)
  3. Scrum Master (1 persona)

El Scrum Team debe ser auto-organizado y multifuncional. Lo primero para saber elegir cual es la mejor manera de hacer el trabajo, mejor que siendo dirigidos por otros externos. Multifuncionales porque el equipo debe tener las comptencias necesarias para realizar el trabajo sin depender de otras personas que no formen parte del equipo.

El equipo perfecto en Scrum está diseñado para optimizar flexibilidad, creatividad y productividad.

Es decir, debe ser capaz de poder entregar y publicar (si ha sido pasada a Done) esa nueva release lanzada.

No puede depender de otros equipos para subir a producción algo definido como «Done».

El equipo entrega productos cíclica e incrementalmenre, maximizando las oportunidades para obtener feedback. Entregas incrementales de productos con la etiqueta «Done» (Hecho) aseguran potenciales versiones usables del producto están siempre en activo.

Product Owner

El Product Owner , PO es el responsable de maximizar el valor del producto y el trabajo del Development Team (Equipo de desarrollo). Como se realiza esto, puede variar dependiendo de la empresa, los Scrum Teams y los inddividuos.

El Product Owner es la única persona responsable para gestionar el Product Backlog.

Entre las tareas que se realizan en esa gestión se encuentran:

  • Nombrar claramente los ítems del Product Backlog.
  • Ordenar los items en el Product Backlog priorizándolos para lograr los mejores objetivos y resultados.
  • Optimizar el valor del trabajo que realiza el Development Team.
  • Asegurarse de que el  Product Backlog sea visible, transparente y claro para todos, y que muestra en que va a trabajar el Scrum Team.
  • Asegurarse de que el Development Team comprende perfectamente los elementos del Product Backlog.

El PO puede hacer el trabajo anterior o hacer que lo haga el equipo de desarrollo, pero en ambos casos será el Product Owner responsable.

Seguir leyendo «Roles en Scrum»

Aprendiendo Scrum

, , , , ,

Scrum es un framework (marco de trabajo) dentro del cual las personas pueden abordar problemas complejos, a la vez que ofrecen productos de manera eficiente y creativa del más alto valor posible.

Scrum

Web de scrum.org

Scrum proviene del trabajo de Ikujiro Nonaka e Hirotaka Takeuchi cuando publicaron «The New New Product Development Game» en Harvard Business Review (HBR) en 1986.

Su forma final proviene de “Scrum Development Process” presentado por Ken Schwaber en OOPSLA 95. Tanto Ken Schwaber como Jeff Sutherland son considerados sus creadores oficiales.

Aunque para Takeuchi y Nonaka, Scrum está relacionado indirectamente con el software. Tiene que tiene más que ver con el liderazgo y el funcionamiento de las principales compañías del mundo, tal y como aparece su artículo en HBR llamado «The Big Idea: The Wise Leader».

En sí mismo, no es un proceso o una técnica, sino que como marco de trabajo, para desarrollar complejos productos de software, pudiendose emplear varias procesos y técnicas. Presenta varios componentes, roles, eventos, artefactos y reglas, que tienen un propósito muy claro y son esenciales para el éxito de Scrum.

Sirve especialmente para ver de forma clara la eficacia relativa de las prácticas de desarrollo y gestión de producto para que se pueda mejorar.

Si de verdad se quiere lograr un cambio en la forma de trabajar, éste debe contar con el apoyo de «los de arriba».

Los stakeholders deben respaldar al Product Owner con conocimientos e información de los productos o servicios a desarrollar y apoyar al Scrum Master para provocar un cambio organizacional que fomente el empirismo, la autoorganización, la inteligencia y el poder decidir de forma inteligente cuando el producto está listo para ser lanzado.

Los 3 pilares de Scrum

Dentro de los principios Agile, vivimos en un mundo de constante cambio e incertidumbre por lo que es imposible predecir a futuro cual va a ser la siguiente innovación.

Scrum se basa en la teoría empírica de control de procesos. El empirismo afirma que el conocimiento proviene de la experiencia y toma decisiones basadas en lo que se conoce.

Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad del mundo en el que vivimos y controlar el riesgo.

Tres pilares sostienen la implementación del control del proceso empírico:

Seguir leyendo «Aprendiendo Scrum»

Scroll hacia arriba