¿Qué ocurre con las tareas de un jefe de proyecto en Scrum?

En Scrum no existe la figura del jefe de proyecto, y siendo así ¿qué ocurre con las tareas que implican sus funciones?

En los cursos dirección de proyectos PMP un jefe de proyecto aprende a dar respuesta a cuestiones como:

• ¿Qué es lo que se va a hacer?
• ¿Cuándo se va a hacer?
• ¿Por qué se va a hacer?
• ¿De cuánto presupuesto se dispone para hacerlo?
• ¿Cómo se está desarrollando el proyecto?

Scrum busca optimizar el flujo del trabajo, para ello descentraliza la toma de decisiones, ya que la forma más rápida de tomar una decisión es que la tome quién tenga la información local, y un jefe de proyecto puede convertirse en un cuello de botella si no está en contacto directo con esta. Por tanto en Scrum las tareas de gestión del mismo se distribuyen en sus roles, en aquel rol que tenga la responsabilidad y la información en su desempeño. Por tanto todos los roles gestionan y ejecutan.

Cómo se distribuyen las tareas en los diferentes roles de Scrum
Imágenes cortesía de Pixabay (Jefe de proyecto,
Propietario del Producto, Equipo de desarrollo y Scrum Master)

Tareas de gestión de los diferentes roles
de un ejercicio de Alexandre Magno

El Propietario del Producto es quién desempeña las tareas de macrogestión, al fin y al cabo es el responsable de comprometerse con el objetivo que se quiere lograr, elaborar y comunicar la visión de negocio, definir los requisitos de lo que hay que hacer y dar el contexto en el cuál se va a utilizar lo que ha de construir el equipo de desarrollo. Se encarga de tareas, que en un contexto clásico hace un jefe de proyecto, como:

• Comunicación con el cliente
• Definición de requisitos
• Gestión de prioridades
• Retorno de inversión
• Estrategias de entrega del producto
• Planificación del proyecto
• Costes/tiempos/alcance
• Gestión de dependencias
• Pruebas de aceptación
• ...

El equipo de desarrollo es quién hace la microgestión, son los que estiman y deciden lo que cabe en la pila de sprint, para luego construir el incremento a lo largo del sprint, son ellos los que seleccionan las tecnologías adecuadas y organizan su trabajo de la forma más óptima posible, y lo hacen a través de microplanificación diaria. Asumen tareas de una jefe de proyecto como:

• Definición y estimación de tareas
• Asignación/planificación de tareas
• Calidad del software
• Coordinación del equipo (autoorganización)
• ...

Ejemplo de ejercicio resultante en
compañías españolas

Finalmente está el Scrum Master quién desempeña las tareas de gestión de personas y del proceso. Él es quién se encarga de formar y acompañar al equipo en su camino hacia la autoorganización, impulsa su desarrollo profesional y desbloquea sus motivaciones intrínsecas. También es quien se encarga de optimizar el proceso a través de la mejora continua. Se encarga de tareas de un jefe de proyecto como:

• Gestión de personas
• Motivación de equipos
• Desarrollar competencias en los miembros del equipo
• Promover la autoorganización
• Asegurar la Agilidad en la organización
• Gestionar bloqueos e impedimentos
• ...

La imagen de la derecha es un clásico resultado de este ejercicio, resaltar que la tarta del área del Scrum Master es un añadido del trainer. Hay un solo post-it original de los asistentes, todos ellos profesionales, lo que pone de relieve la mayor carencia de gestión en las compañías tradicionales españolas: la gestión del proceso y la gestión de las personas.

Como podemos ver en Scrum todas estas tareas las realizan los roles que tocan las realidades que requieren las mismas.

---

Para aquellos que queráis ejecutar este ejercicio de forma remota, tal como ocurre en esta época de COVID-19, podéis utilizar un tablero de EasyRetro, como el de la imagen inferior. Al igual que el ejercicio en presencial y con post-its, identificamos tareas de forma individual en la primera columna, luego consolidamos las que signifiquen lo mismo y finalmente las llevamos de forma colaborativa y de una en una a la columnas de tipos de gestión.

Ejemplo del ejercicio con un tablero de EasyRetro

Mi agradecimiento a Alexandre Magno quién arrojó mucha luz sobre esta cuestión.

¿Qué hace un Chapter Lead para coordinar los equipos en la disciplina en que es experto?

Chapters transversales por equipos en una tribu
Henrik Kniberg & Anders Ivarsson

Vivimos en tiempos en que los equipos Scrum, más o menos bien entendidos, ya son una realidad, y en diversidad de casos ya nos encontramos ante la necesidad de que los especialistas de diferentes equipos se encuentren alineados y coordinados. Para ello quiero hablar del Chapter Lead, un rol transversal entre squads (equipos) de una tribu, originario del modelo de Spotify.

Recordemos que los chapters los forman miembros de equipos que trabajan dentro de una misma disciplina. Los equipos podrían estar formados por ejemplo por desarrolladores de front, algunos del back, DBAs y QA. En ese caso un chapter podría ser el del front, donde los desarrolladores de los diferentes equipos se reúnen para intercambiar ideas, obtener ayuda en sus retos y compartir y discutir sobre nuevas tecnologías.

De ahí nace el rol del Chapter Lead, un experto y responsable del chapter para esa disciplina específica. Es un líder al servicio que se centra en entrenar y ayudar a los miembros del chapter a crecer en su función. Un experto de este calibre tiene la responsabilidad de desarrollar la competencia de los demás.

Responsabilidades

• Ser líder al servicio del chapter, ser responsable de, inspirar y hacer crecer al equipo, ser punto de referencia dentro del chapter
• Ayudar a los miembros del chapter en su desarrollo, tanto en sus habilidades duras como en las blandas, a explotar sus fortalezas y a manejar sus debilidades, a través del coaching, tutoría y feedback
• Ayudar a miembros individuales del equipo a asistir a diferentes eventos de capacitación y formación
• Organizar, estimular y alentar la colaboración entre los miembros del chapter
• Impulsar la creación de un enfoque similar para tareas similares
• Asegurarse de que los miembros están debidamente equipados para realizar su trabajo lo mejor que puedan y entregar grandes cosas
• Ayudar a desarrollar y evangelizar grandes prácticas de ingeniería así como impulsar las prácticas de desarrollo más punteras en el equipo y la organización
• Dado que tiene visibilidad en varios equipos, aplicar estrategia a los diferentes desarrollos transversales en su disciplina y asegurarse de que todos los miembros del chapter estén alineados
• Garantizar que los miembros del chapter respeten los valores, normas y políticas definidas por la organización
• Formular proactivamente recomendaciones sobre cuestiones de organización y posibles cambios en la organización de los equipos como intercambiar miembros del chapter de un equipo a otro
• Colaborar con los demás roles de la tribu, como Propietarios del Producto, Scrum Masters, Agile Coaches, Tribe Leads... para liderar la tribu
• Trabajar con el equipo de recursos humanos para atraer, reclutar y retener a los mejores talentos de su disciplina
• Ayudar a establecer salarios y aprobar vacaciones

Chapter Meeting :-D

Un Chapter Lead pertenece a uno de los equipos de la tribu, por tanto, a diferencia de un jefe de desarrollo técnico, es un miembro más de su equipo que está involucrado en el diseño y la construcción de lo que está desarrollando en su equipo.

Una parte de su tiempo, entre un 20% y un 40%, la dedica a liderar el chapter, no interviene directamente en lo que otros equipos estén desarrollando, pero si puede apoyar y ser consultado si se le solicita.

Un buen Chaper Lead siente completitud con como los miembros de chapter crecen y se desarrollan, con lo que entre todos se construye y aporta al propósito de la organización. Si fue un jefe de desarrollo técnico debe de comprender que debe de abrazar esta nueva mentalidad y alejarse de darle importancia a la autoridad implícita que pudiera tener como experto y sentir el impulso de llevar al equipo por el camino adecuado, más bien se trata de hacer que encuentren el mejor camino acompañándolos y guiándolos como experto.

¿Cómo representar Scrum técnico en una imagen?

El póster Scrum - @mariadelamareria

Habéis oído el refrán "Una imagen vale más que mil palabras". Yo andaba hace tiempo dándole vueltas a tener una imagen que sirviese para explicar lo que es Scrum técnico.

Según Scrum Manager hay dos formas de adopción de Scrum: técnica y pragmática. Cuando se adopta Scrum técnico se siguen unas reglas definidas, mientras que en la pragmática los equipos basándose en la experiencia acumulada pueden ir rompiendo las reglas para ejecutar un Scrum más acorde a sus necesidades específicas.

Ha sido hace unas semanas cuando María Robles (Trabajos María), me dijo: "si quieres preparo las imágenes". Y hala, nos pusimos a trabajar. Aunque esto no ha sido un desarrollo de software, la forma de trabajo se ha ajustado a los valores y principios del Manifiesto Ágil.

Empezamos por tener tres charlas a modo de sprints en las que le explicaba a la diseñadora cual es el proceso a seguir para desarrollar software con Scrum. Después de cada charla, ella me enseñaba algunos personajes y dibujos que representaban lo que le explicaba. Cuando ya tenía algunos personajes y dibujos seleccionados, me pidió que escribiera el proceso que le estaba contando. Tras esto realizó el diseño y me mostró la primera versión del póster. Sobre este le pedí cambios y este proceso lo repetimos 3 veces. En todo momento durante el proceso, aclarábamos las dudas que surgían manteniendo comunicación cara a cara o por whatsapp.

Tras esto le pedí su visto bueno a mi amigo Alex que puso su granito de arena, sugiriendo el cambio de algunos textos.

Tras este proceso en el que empleamos una gran dosis de ilusión obtuvimos el póster de la imagen.

Descargas / Downloads

Pincha aquí para ver el póster Scrum

¿Cómo aplicar Agile y Scrum en proyectos de infraestructura?

Proyecto de actualización en el CPD - Cortesía de Pixabay

Los proyectos de infraestructura son aquellos que se producen en las áreas de sistemas y de arquitectura, suelen ser cosas como:

• Actualizaciones de hardware o de software
• Instalación de la infraestructura necesaria para que una aplicación de producto se pueda desarrollar y/o ejecutar
• Instalación masiva de BBDDs distribuidas
• Cambios de plataformas de correo
• Migraciones masivas de BBDDs por cambio de versión del SGBD

A diferencia de los proyectos de producto, en los que siempre se construye algo "nuevo", los proyectos de infraestructura no siempre implican algo nuevo, pueden tener requisitos bien definidos y dependencias conocidas, lo que ocurre es que la incertidumbre emerge en forma de problemas imprevisibles. Por tanto la complejidad de los proyectos de infraestructura puede ser de menor grado, pero cosas como los problemas y otras restricciones, como que algunas de sus tareas solo se puedan realizar dentro de ventanas permitidas (fines de semana o fuera de horas de oficina) por ejemplo, hacen que Agile y Scrum puedan aportar grandes beneficios. También aquí la creatividad de las personas es esencial para la resolución de problemas, así como para encontrar maneras de hacer el trabajo de la forma más eficiente posible.

En este tipo de proyectos hay que averiguar qué ofrece valor, habitualmente suele tratarse del ahorro de costes o del coste de la demora para habilitar la construcción de funcionalidades de producto que si tienen valor de negocio. En un proyecto de migración a la nube por ejemplo, puede medirse el ahorro de costes asociado con el espacio de disco y la utilización de la CPU, y en un proyecto de infraestructura para un producto puede medirse el coste que representa el retraso en la puesta en marcha de una determinada funcionalidad.

La ejecución de Scrum se hace de la misma manera que en un proyecto de producto, la clave siempre está en los puntos de feedback y de integración que ocurre a final de cada uno de los sprints. Por ejemplo, si te tratara de un cambio de la plataforma de correo, se puede empezar por un grupo reducido de usuarios, los que estén a favor del cambio, se migran y se toma feedback, se hacen los ajustes correspondientes y se migra el siguiente grupo. Lo mismo para las BBDD, se empieza por una, se comprueba, se toma feedback y a por la siguiente.

Nunca es buena idea cambiar todo a la vez, cuando puede haber imprevistos es mejor empezar de forma acotada y expandir paso a paso, a través de sprints y priorizando por criticidad, ahorro de costes, coste de la demora, valor... una migración de servidores, por ejemplo, se podría afrontar incrementalmente incorporando en cada sprint nuevos servidores para dar servicio a los productos de más valor en función de los segmentos de cliente que más importen.

¿Cuáles son las 50 mejores prácticas de Scrum para un Dream Team?

El otro día estábamos compartiendo un post de Kevin Wood, publicado en febrero de este año, que nos habla de las 50 mejores prácticas de Scrum "50 Best Scrum Practices for Dream Team" y nos pareció tan útil y tan relevante para cualquiera que esté involucrado con Scrum, que decidimos traducirlo al castellano para que todos los interesados puedan tener acceso a él. Aquí os compartimos nuestra traducción:

---

Scrum es uno de los frameworks más populares para implementar Agilidad. De hecho, muchas personas creen que Scrum y Agilidad son la misma cosa, aunque definitivamente no lo son. Agilidad es una mentalidad reforzada grupo de métodos de desarrollo de software basado en el desarrollo iterativo, y Scrum es un subconjunto de Agilidad pero con sus propias peculiaridades debido al compromiso con iteraciones cortas.

Con Scrum, los productos se construyen en una serie de iteraciones de longitud fija (sprints). Esto permite a los equipos entregar software a intervalos regulares, recibir retroalimentación rápida y adaptarse rápidamente a los requisitos cambiantes.

Aquí se presenta una lista de las mejores prácticas de Scrum que han demostrado su efectividad para ayudar a mejorar la calidad y aumentar la productividad, para entregar un producto que aporte valor y que cumpla con los objetivos de negocio.

Equipo

• Los miembros del equipo trabajan en roles multifuncionales
• El equipo tiene el equilibrio adecuado entre los desarrolladores y el QA (2: 1 o 4: 1)
• Los miembros del equipo colaboran para entregar en primer lugar historias de alta prioridad
• Los miembros del equipo piden ayuda proactivamente
• Los miembros del equipo se dan feedback constructivo mutuamente y de manera oportuna

Scrum Master (SM)

• El SM facilita la autoorganización del equipo
• El SM se enfoca en remover impedimentos (problemas de recursos, problemas o desobediencia en la implementación de prácticas de Scrum)
• El SM protege al equipo de distracciones externas e internas
• El SM permite una estrecha cooperación en todos los roles
• El SM interactúa con la alta dirección

Propietario del Producto (PP)

• El PP interactúa con el equipo y todas las partes interesadas (Stakeholders) para crear el backlog o la pila de producto
• El PP escribe historias de usuario y criterios de aceptación
• El PP prioriza la pila de producto y decide sobre las fechas de lanzamiento de las diferentes versiones
• El PP acepta o rechaza historias de usuario
• El PP cancela el sprint si piensa que el objetivo del sprint ya no tiene sentido

Definición de Hecho o Definition of Done (DoD)

• Cada historia de usuario cumple los criterios del DoD
• Todos los miembros del equipo y el PP conocen de memoria el DoD y lo respetan

Estimación

• El PP obtiene estimaciones a partir del equipo
• Sólo estima el equipo
• Cada miembro del equipo participa en la estimación
• El equipo estima usando la técnica del planning poker

Reunión de planificación de Sprint

• Todos los miembros del equipo participan
• El PP presenta las historias de usuario priorizadas al equipo
• Todas las historias del sprint están estimadas
• La reunión da como resultado un plan de sprint

Sprint

• El equipo entrega algo después de cada sprint
• El equipo sigue las prioridades marcadas por el PP
• El equipo alerta al PP cuando tienen problemas
• El equipo trata los problemas cuando ocurren (no más tarde)
• La longitud de sprint no cambia después de cada sprint
• Las historias que se han empezado terminan dentro del mismo sprint

Pila de Sprint (PS)

• La PS está visible y es de fácil acceso para el equipo
• La PS se actualiza todos los días
• Las estimaciones de las tareas se actualizan todos los días
• Los miembros del equipo actualizan la PS por ellos mismos
• Las historias están claramente mapeadas

Scrum Diario (SD)

• El SD tiene ocurre a la misma hora y lugar todos los días
• El SD comienza y termina puntualmente
• Todos los miembros del equipo están involucrados
• El PP participa en la reunión por lo menos unas pocas veces por semana
• El equipo revisa el gráfico de burndown y toma medidas si van retrasados
• El SD dura como mucho 15 minutos – todas las discusiones tienen lugar después

Revisión de Sprint

• La demo formal se realiza después de cada sprint
• Sólo las historias aceptadas por PP se demuestran
• Todos los interesados se han invitado para la demo con antelación
• Se anima a las partes interesadas a dar su opinión durante la demo

Retrospectiva

• La retrospectiva tiene lugar después de cada sprint
• Todos los miembros del equipo y el PP comparten el feedback
• El equipo analiza los datos y decide que acciones emprender
• Las acciones se priorizan e implementan en los próximos sprints

Sobre el autor: Kevin Wood es Gerente de Desarrollo de Atlaz y tiene una gran experiencia en finanzas y administración de negocios. Su profunda comprensión de los principios de mercadotecnia y sus excelentes habilidades analíticas, le ayudan a identificar ideas de tendencia, a evaluar riesgos y a encontrar los mejores potenciales para las necesidades y metas de sus socios.

Mis agradecimientos a Gertrudis López por la traducción conjunta, link al post en su blog "Agile: lo bueno, lo feo y lo malo"

¿Las historias de usuario son el mejor tipo de elementos para la pila de producto?

PBIs de la pila de producto

Siempre que pensamos en pilas de producto pensamos en historias de usuario. En esas historias de usuario representadas por post-its y usando la técnica de las 3 C's, esa forma excelente que se basa en mucha conversación y una comunicación muy cercana entre el Propietario del Producto y el equipo de desarrollo. Pero, ¿son siempre la mejor forma para recoger y gestionar requisitos?

Diapositivas con el mensaje concentrado versus libro con el mensaje detallado

Vamos a hacer una par de analogías para ayudar a dar respuesta a la pregunta del post. La analogía para las historias de usuario sería con las diapositivas de una clase o de un seminario, no tratan de añadir detalle, sino de proporcionar claridad. Contienen gráficos y palabras clave que asientan la comunicación presencial cara a cara del ponente, podemos preguntarle directamente, y él puede resaltar partes en función de su audiencia e introducir cosas que no estén en las diapositivas.

Pensemos ahora en los requisitos tradicionales, éstos serían más bien como un libro en el que todo viene escrito con todo detalle, tiene que ser así ya que como lectores no tenemos posibilidad de preguntarle al autor.

Por tanto las historias de usuario son la mejor solución cuando el camino de la comunicación es reducido, cuando el Propietario del Producto es un miembro más del equipo, está presente y es fácilmente accesible, lo que es una de las piedras angulares de Scrum y la Agilidad.

Puede haber situaciones y proyectos en los que el Propietario del Producto no pueda estar muy cercano al equipo y donde las historias de usuario no sean una buena solución. En este caso necesitaríamos una solución de requisitos autoexplicativos como lo son los casos de uso, estos implican más transmisión de conocimiento escrita con el consecuente empobrecimiento de la comunicación. Todo ello merma las posibilidades de Scrum y de la Agilidad, pero sin duda aporta los beneficios de los puntos de aprendizaje y de integración que conllevan los sprints.

Historias de usuario versus casos de uso

Es por todo ello que la Scrum Alliance habla de PBIs (Product Backlog Items), o elementos de la pila de producto, que define como unidades de trabajo lo suficientemente pequeñas como para ser completadas por un equipo en un sprint.