Scrum Teams

Hola de nuevo!

Ya vamos por mi tercer post después de mi vuelta al blog, y llega en un momento muy específico  debido al Covid-19 y los impactos relativos en la economía... Pero hoy no os voy a hablar de eso, tampoco de digitalización, (este será otro post posterior, una vez haya acabado de elaborar el modelo digital de seguros en el que estoy trabajando) sinó que continuaremos con los posts relativos a business agility.

Hoy, hablaremos de  Scrum ya que me he certificado recientemente como Scrum Master y tenía ganas de explicaros mis aprendizajes, así como la experiencia. En primer lugar decir que me certifiqué con la Scrum Alliance y la verdad es que fue un curso de unos pocos días, muy interesante y práctico. Os lo recomiendo!

Me gustaría empezar por recordaros que Scrum es una de las técnicas más utilizadas en compañías que aplican metodologías Agile, pero no la única. Tampoco es siempre la más indicada. En mi opinión Scrum es una metodología que funciona muy bien para la gestión de proyectos de negocio, o en start ups ya que ayuda a definir un método de trabajo muy colaborativo, ordenado y enfocado a resultados, sin embargo no es suficiente para cambiar la cultura organizacional en grandes corporaciones... no quiere decir que no ayude, pero necesita de otras técnicas cómo Kanban, design thinking etc, que ayudan mucho en el change management de grandes empresas.

No voy a entrar en detalle de todos los aspectos de Scrum, para eso enviarme un mensaje privado en Linkedin y os enviaré el toolkit (un pequeño xls. que creé para estudiar para el examen), pero sí que me gustaría dejaros unos pocos conceptos básicos.

Para empezar a operar un proyecto en Scrum, te recomiendo que sigas los siguientes 10 pasos:

1. Organiza tu compañía por value streams (flujos generadores de valor a la compañía)
2. Facilita el proceso de selección de un product owner
3. Asegúrate que tienes los perfiles necesarios para completar tu Dev. Team
4. Identifica los stakeholders
5. Provee el training necesario y explica la metodología al equipo
6. Define los inputs/ outputs de las reuniones periódicas que debes realizar
7. Define cómo será la logística para el primer Sprint
8. Desarrolla el product backlog: descripción, valor y esfuerzo
9. Crea la definición de Ready y Done
10. Define la misión del equipo

En Scrum tenemos básicamente 4 roles principales:

• Product Owner: Es la persona responsable de maximizar el valor del dev. team. Él o ella, es el máximo responsable de la priorización del backlog, gestión de los stakeholders, definición de los sprints, y proveer transparencia y visibilidad al proceso.
• Scrum Master: El Scrum Master es el facilitador del proyecto. Es un sirviente líder  que ayuda al Scrum Team a utilizar las técnicas Scrum, así como a retirar las dificultades del camino.
• Dev. Team: Son equipos cross-funcionales, auto-organizados con las skills adecuadas y empoderados para conseguir el objetivo marcado en el sprint, por el cuál, el equipo es el responsable como un todo.
• Stakeholders: Son los representantes de los responsables de negocio. Participan en los Sprint Reviews para dar feedback al Scrum Team sobre las soluciones.

Para acabar, os detallo las principales reuniones que debemos realizar en un proyecto Scrum:

• Sprint Planning: Reunión para organizar el trabajo del Sprint y definir el backlog, el objetivo y las tareas necesarias para cumplir el objetivo.
• Daily Scrum: Reunión diaria de sincronización del equipo Scrum.
• Sprint Review: Reunión para la revisión del producto finalizado y recibir feedback de los stakeholders y retroalimentar el backlog.
• Sprint Restrospective: Revisión del equipo Scrum para crear una agenda de mejora continua del funcionamiento del proceso, las herramientas, las personas y equipos para el siguiente sprint.

Y os recuerdo, si queréis que os pase mi toolkit, enviarme un privado por Linkedin.

Saludos.

Marc

BUSINESS AGILITY

Más de seis años después de mi último post en este blog, me gustaría retomarlo con un enfoque un poco diferente. Mientras en su inicio, este blog nació como una manera de compartir mis experiencias, básicamente personales en USA, ahora me gustaría retomarlo para reflexionar sobre  determinados temas profesionales también. La idea es que no sólo sean mis ideas sino que en la medida que la gente tenga cosas a aportar, también participe con sus opiniones.

Hoy me gustaría hablar de agilidad empresarial, (o agility en inglés) enfocada a grandes empresas. Mientras business agility nació como un conjunto de principios y métodos para mejorar el desarrollo de software, con métodos como SCRUM, Kanban, Lean Start Up, Extreme Programming… esta receta por sí sola no funciona en grandes empresas con una cultura empresarial e historia amplia.

Para conseguir verdadera agilidad empresarial, es necesario realizar un cambio cultural en todos los niveles de la organización y eso requiere darle la vuelta a la teoría, y no (sólo) centrarla en desarrollo de software, sino en una verdadera transformación del negocio enfocado a la generación de valor.

Aquí van algunas reflexiones:

·         El liderazgo de un cambio como éste debe ser de la más alta dirección, y debe darse después de una profunda reflexión y entendimiento de la profundidad de los cambios en la organización y los trade offs derivados de los mismos (por ejemplo, en costes en un primer momento).

·         Comenzar por implantar métodos que trabajen más allá de “proyectos”, y transformen grandes áreas, métodos como Kanban, Lean six sigma, herramientas de visual management… Estas herramientas son menos prescriptivas que otras metodologías como SCRUM, pero a la vez, tienen la virtud de que empodera a los equipos para liderar el cambio en la organización.

·         Cambios en las estructuras empresariales enfocados a la generación de valor e incremento del flujo de implementación de cambios (sobretodo de software, pero también de otras iniciativas) a través de los “value streams” generadores de la P&L. Algunas empresas llaman a estos nuevos equipos multidisciplinares con voluntad de permanencia, como “tribus”.

·         Mayor integración de los departamentos de desarrollo de software en las áreas de negocio o en las tribus, siguiendo el value stream de generación de valor para la compañía (Profit & Loss). Estos equipos de software deberán integrar el run y el change para asegurar la adecuada evolución de la tecnología.

·         Otro de los aspectos importantes es acotar los desarrollos a MVPs (minimum viable products), que nos permitan realizar inversiones tácticas que testeen los conceptos en el mercado, y por otro lado nos permitan comenzar a generar valor de manera más rápida.

·         Plataformas tecnológicas que permitan un desarrollo ágil, siguiendo el value stream (las diferentes P&Ls de la compañía) limitando las interdependencias con las necesidades de otras áreas de la compañía.

·         Adaptación de los espacios y cambiar la cultura empresarial es tan importante como los conceptos que hemos detallado arriba, por lo que es conveniente acompañar el cambio  a través del training adecuado a todos los empleados, comunicaciones claras de lo que se pretende conseguir, así como espacios que permitan un trabajo más colaborativo.