¿El Rol de Scrum Master en Peligro?
PEDRO BALLESTEROS HERRANZ
Hola,
Al final me voy a atrever a plantear aquí un tema que me lleva preocupando bastante, aun a sabiendas que voy a recibir duras críticas, pero así es como se aprende.
En mi empresa le han ido dando a la figura del Scrum Master un papel bastante relevante, pero últimamente algunos compañeros comentábamos que se estaba perdiendo esta fuerza. Después de años trabajando en Scrum, parece que a la figura del SM estaba en peligro de perder la importancia que algunos consideramos que tiene.
En el día a día del scrum nos olvidamos que el SM tiene tareas bastante importantes, consumidoras de tiempo, que requieren habilidades de SM y que no se reducen a una simple moderación/organización de meetings o protección del equipo frente a peligros.
Tengo la mala fama de enrollarme con emails excesivamente largos, por lo que acabé planteando a mis compañeros el tema en formato blog, que parece más permisible con la extensión que un email:
http://theprogrammingchronicles.com/2011/03/10/scrum-master-especializado/
A ver qué os parece mi argumentación (para el que no se aburra leyendo), estoy deseoso de recibir cualquier tipo de críticas malas o buenas.
S2,
Pedro
------------------------------------------------------------------------------------------------------------
"Hello. My name is Inigo Montoya. You broke my tests. Prepare to die!"
-- Agile Movie Quote from Kanban process Designer "Mike Burrows" (@asplake )
------------------------------------------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Gustavo Cebrian Garcia
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
Juan Carlos Quijano Abad
Tu argumentación rezuma sentido común y experiencia. Estoy de acuerdo al 98%.
Y el 2% que falta es porque en mi opinión el trabajo principal y único de un SM es eliminar impedimentos. Que el Product Backlog mál construido, mantenido u actualizado es un impedimento muy importante, toda la razón del mundo.
Pero también el SM debe colgar por los pulgares al de Sistemas para que la impresora funcione, o al de mantenimiento para evitar un frio polar en la sala, o facilitar el uso de SCRUM, o detener la derivación hacia ASM. Incluso, como parte del equipo, asegurarse del uso de buenas prácticas de desarrollo. Cualquier cosa que sea un impedimento, por grande o pequeño que sea, para el fluido trabajo del equipo.
Alfredo Casado
El Scrum Master es el responsable de organizar junto con el Product Owner un buen Product Backlog.
Es el responsable de que al llegar al Estimation Meeting (o Sprint Planning Parte I), las User Stories estén priorizadas y con tamaño de Sprint.
Durante los sprints el Scrum Master sigue trabajando con el Product Owner en el crecimiento y mantenimiento del Product Backlog.
Jose R.
Y me falta una importante para el ScM: la de lider/coach del equipo.
Un saludo
PEDRO BALLESTEROS HERRANZ
Si el 2% que falta consideras que es el único trabajo de un SM entonces muy de acuerdo no estas ;), muy ingeniosa la respuesta ;).
Yo considero que el trabajo de tener un PB en condiciones y el de eliminar impedimentos, ambos son importantes, pero en mi opinión yo le doy mucho más peso a lo del PB. Si el SM no hace bien su trabajo de eliminar impedimentos, puedo sobrevivir, pero si empezamos el Estimation Meting y nos encontrabos con un PB de 4 pretendidas historias de usuario que en realidad son megaepics, no acabamos ni en varios días.
Nosotros tenemos una reunión de 4 horas, para el Sprint Planning Parte I o Estimation Meeting, el PO cuenta una por una todas las historias y la gente va votando con el planning pocker, en la votación nos salen las dudas, y además medimos esfuerzo subjetivo.
En los primeros intentos de Scrum estas reuniones eran un infierno, no había manera de entender las US, de hecho no eran US, porque no había manera de decidir en cuantos sprints se necesitaban, la reunión se convertía en dividir esas mega US en historias, con todo el equipo presente, discutiendo durante una hora una sola US, super ineficiente.
La conclusión era que el asignar puntos no servia para nada, y menos con las cartas.
Después de esta reunión empieza el verdadero SP, aquí decimos SP Parte II. Dividimos las historias en tareas técnicas, y mejor que el PO se vaya. Si no hemos podido hacer bien la primera imaginaros la segunda.
Mi conclusión: Nuestro problema era que nadie había llegado al SP con un PB que no hubiera que trasformar, simplemente votar entender y decidir el corte del sprint. Si no se puede hacer eso no hay Sprint, no hay scrum, por eso le doy una importancia vital.
Todo el mundo habla de “eliminar impedimentos”, pero el principal impedimento que debe eliminar es tener un PB en condiciones, nos centramos tanto en impedimentos que olvidamos lo importante de tener un PB.
S2,
Pedro
PEDRO BALLESTEROS HERRANZ
En general comparto vuestra opinión, pero en algunos puntos concretos lo veo de otra forma, quizás son matices, y quizás estemos hablando de lo mismo.
Cierto que el SM tiene muchas misiones, quitar impedimentos, coach del equipo, etc. Respecto a lo de Leader yo discrepo, Leader Project me suena igual que Project Manager. En scrum el leader es el equipo, y el SM es un coach porque vigila que se hace bien el scrum (por cierto, nosotros en los primeros sprints tenemos en los primeros un agile coach que apoya al scrum master).
Pero yo no trataba de resumir o plasmar todas las tareas del SM. Las que comentáis las doy por superaprendidas, en nuestros equipos son las que menos se ponen en duda.
Lo pongo sobre la mesa son tareas que yo considero que también debe realizar el SM y que para mí son las más críticas, y se maltratan mucho. La gente que rechaza Scrum lo primero que empieza a eliminar es el planning pocker, o cualquier otra asignación de puntos, con lo que el PO y el equipo pierden el mecanismo para explicar, dar a entender las US, medir velocidad en base a esfuerzo subjetivo, etc.
En nuestros proyectos los primeros sprints detectamos que iban muy mal precisamente por fallar en esas tareas.
Tenéis razón, son responsabilidades del PO. Y es cierto que si el PO hiciera muy bien esas tareas, él SM no tendría que hacer eso. Siempre he entendido que el PB es propiedad del PB. Pero yo creo que es responsabilidad de ambos. Es un trabajo conjunto entre mucha gente: PO, SM, QA, técnicos del equipo, técnicos del negocio, de todos los que puedan participar en una captura de requisitos.
Hacer el PB es hacer la especificación de requisitos de toda la vida. Averiguar lo que el cliente quiere y que lo entienda el equipo. Y siempre ha sido el fallo de todo el proceso el cliente no sabe lo que quiere y el equipo no lo entiende. Vale que ahora reaccionamos al final de cada sprint para no perder el target, pero no podemos convertir cada sprint en volver a intentar lo que no se entendió bien.
Si quieres saber lo que el PO (cliente) quiere te tienes que juntar con él en entrevistas, hacerle las preguntas adecuadas, enseñarle a hacer el PB, si llevas gente de QA mejor porque deberían ser expertos en hacer las preguntas adecuadas, incluso plasmarlas en test de aceptación. Si llevas gente del equipo podemos detectar cosas raras en las US a nivel técnico.
Durante el Sprint-0 (otro gran olvidado) podríamos hacer gran parte de este trabajo. El SM obliga al PO a participar en la creación del PB, no lleva a todo el equipo, solo a los que considera necesarios para cada tema o epic.
Tenéis razón, el PO debería hacer todo esto y hacerlo bien, ¿pero confiáis en vuestros PO?. El PO es el representante del cliente, ¿desde cuándo el cliente sabe lo que quiere? ¿Desde cuándo es capaz de explicar bien lo que quiere? ¿Desde cuándo sabe plasmar las cosas con US? ¿Desde cuándo sabe crear buenos test de aceptación?
En el mundo real el primer impedimento que debe resolver el SM es que al SP se llegue con un PB que se pueda usar, y normalmente para eliminar ese impedimento debe trabajar junto con el PO. Y la mayoría de las veces seguro que las reuniones acaban con el SM diciendo “bueno, ya meto yo todas estas US en la excel, en postits, en Banana Scrum, en JIRA o en lo que quieras”.
En nuestros primeros intentos de scrum todos los sprints se iban al garete porque no teníamos buenos PB, hasta que el SM no tomó el control de esas tareas no empezamos a funcionar bien.
S2,
Pedro
De: agile...@googlegroups.com [mailto:agile...@googlegroups.com]
En nombre de Jose R.
Enviado el: miércoles, 23 de marzo de 2011 17:41
Para: agile...@googlegroups.com
CC: Alfredo Casado
Asunto: Re: [agile-spain] ¿El Rol de Scrum Master en Peligro?
Coincido con Alfredo respecto a la visión de casi el ScM como ayudante del PO, que no me encaja demasiado.
Alfredo Casado
No te discuto la importancia de tener el PB bien cuidado. Coincido contigo en que es algo fundamental y he visto problemas similares a los que comentas.
En lo que no estamos de.acuerdo es en quien es el responsable de hacerlo. El PB es como el código, un jardin que tenemos que mantener bien cuidado, si no es responsabilidad del SM cuidar un jardin taampoco lo es cuidar el otro.
> Si el 2% que falta consideras que es el único trabajo de un SM entonces muy de acuerdo no estas ;), muy ingeniosa la respuesta ;).
>
> Yo considero que el trabajo de tener un PB en condiciones y el de eliminar impedimentos, ambos son importantes, pero en mi opinión yo le doy mucho más peso a lo del PB. Si el SM no hace bien su trabajo de eliminar impedimentos, puedo sobrevivir, pero si empezamos el Estimation Meting y nos encontrabos con un PB de 4 pretendidas historias de usuario que en realidad son megaepics, no acabamos ni en varios días.
>
> Nosotros tenemos una reunión de 4 horas, para el Sprint Planning Parte I o Estimation Meeting, el PO cuenta una por una todas las historias y la gente va votando con el planning pocker, en la votación nos salen las dudas, y además medimos esfuerzo subjetivo.
>
> En los primeros intentos de Scrum estas reuniones eran un infierno, no había manera de entender las US, de hecho no eran US, porque no había manera de decidir en cuantos sprints se necesitaban, la reunión se convertía en dividir esas mega US en historias, con todo el equipo presente, discutiendo durante una hora una sola US, super ineficiente.
>
> La conclusión era que el asignar puntos no servia para nada, y menos con las cartas.
>
> Después de esta reunión empieza el verdadero SP, aquí decimos SP Parte II. Dividimos las historias en tareas técnicas, y mejor que el PO se vaya. Si no hemos podido hacer bien la primera imaginaros la segunda.
>
> Mi conclusión: Nuestro problema era que nadie había llegado al SP con un PB que no hubiera que trasformar, simplemente votar entender y decidir el corte del sprint. Si no se puede hacer eso no hay Sprint, no hay scrum, por eso le doy una importancia vital.
>
> Todo el mundo habla de "eliminar impedimentos", pero el principal impedimento que debe eliminar es tener un PB en condiciones, nos centramos tanto en impedimentos que olvidamos lo importante de tener un PB.
>
> S2,
> Pedro
>
>
>
> De: agile...@googlegroups.com [mailto:agile...@googlegroups.com] En nombre de Juan Carlos Quijano Abad
> Enviado el: miércoles, 23 de marzo de 2011 12:04
> Para: agile...@googlegroups.com
> Asunto: Re: [agile-spain] ¿El Rol de Scrum Master en Peligro?
>
> Buenas,
>
> Tu argumentación rezuma sentido común y experiencia. Estoy de acuerdo al 98%.
>
> Y el 2% que falta es porque en mi opinión el trabajo principal y único de un SM es eliminar impedimentos. Que el Product Backlog mál construido, mantenido u actualizado es un impedimento muy importante, toda la razón del mundo.
>
> Pero también el SM debe colgar por los pulgares al de Sistemas para que la impresora funcione, o al de mantenimiento para evitar un frio polar en la sala, o facilitar el uso de SCRUM, o detener la derivación hacia ASM. Incluso, como parte del equipo, asegurarse del uso de buenas prácticas de desarrollo. Cualquier cosa que sea un impedimento, por grande o pequeño que sea, para el fluido trabajo del equipo.
>
> --
> Un saludo
> Juan Quijano
>
> Blog de opinión social<http://unmalnacido.blogspot.com/>
> Blog de World of Warcraft<http://historiasdesdeazeroth.blogspot.com/>
> Blog de Tiro con Arco<http://litelllon.blogspot.com/>
>
>
> El 23 de marzo de 2011 10:52, Gustavo Cebrian Garcia <g.cebria...@gmail.com<mailto:g.cebria...@gmail.com>> escribió:
> Hola,
>
> Bueno, hemos hablado de esto en otros posts, de las responsabilidades del Scrum Master.
>
> ( a ver si lo encuentro )
>
> De todas formas, me encanta que hayas sacado el tema otra vez. Me lee tu post y ya te digo...
>
> Gustavo.
> Hola,
>
> Al final me voy a atrever a plantear aquí un tema que me lleva preocupando bastante, aun a sabiendas que voy a recibir duras críticas, pero así es como se aprende.
>
> En mi empresa le han ido dando a la figura del Scrum Master un papel bastante relevante, pero últimamente algunos compañeros comentábamos que se estaba perdiendo esta fuerza. Después de años trabajando en Scrum, parece que a la figura del SM estaba en peligro de perder la importancia que algunos consideramos que tiene.
>
> En el día a día del scrum nos olvidamos que el SM tiene tareas bastante importantes, consumidoras de tiempo, que requieren habilidades de SM y que no se reducen a una simple moderación/organización de meetings o protección del equipo frente a peligros.
>
> Tengo la mala fama de enrollarme con emails excesivamente largos, por lo que acabé planteando a mis compañeros el tema en formato blog, que parece más permisible con la extensión que un email:
>
> http://theprogrammingchronicles.com/2011/03/10/scrum-master-especializado/
>
> A ver qué os parece mi argumentación (para el que no se aburra leyendo), estoy deseoso de recibir cualquier tipo de críticas malas o buenas.
>
> S2,
> Pedro
>
>
>
>
> ------------------------------------------------------------------------------------------------------------
> "Hello. My name is Inigo Montoya. You broke my tests. Prepare to die!"
> -- Agile Movie Quote from Kanban process Designer "Mike Burrows" (@asplake )
> ------------------------------------------------------------------------------------------------------------
>
>
> ________________________________
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
> Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com<mailto:agile-spain%2Bunsu...@googlegroups.com>
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
> Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com<mailto:agile-spain%2Bunsu...@googlegroups.com>
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
>
> ________________________________
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
Juan Carlos Quijano Abad
Si el 2% que falta consideras que es el único trabajo de un SM entonces muy de acuerdo no estas ;), muy ingeniosa la respuesta ;).
PEDRO BALLESTEROS HERRANZ
De: agile...@googlegroups.com [agile...@googlegroups.com] En nombre de Alfredo Casado [casado....@gmail.com]
Enviado el: miércoles, 23 de marzo de 2011 18:32
Para: agile...@googlegroups.com
Asunto: Re: RE: [agile-spain] ¿El Rol de Scrum Master en Peligro?
PEDRO BALLESTEROS HERRANZ
De: agile...@googlegroups.com [agile...@googlegroups.com] En nombre de Juan Carlos Quijano Abad [juancarl...@gmail.com]
Enviado el: miércoles, 23 de marzo de 2011 21:10
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
Ángel Medinilla
partiendo de la base de que respeto mucho las opiniones, si Scrum es un marco definido lo primero sería recurrir a la definición, y luego opinar desde esa base. Scrum Guide, Ken Schwaber y Jeff Sutherland:
El ScrumMaster
El ScrumMaster es responsable de asegurar que el equipo Scrum se adhiere a los valores, prácticas y normas Scrum. El ScrumMaster ayuda a que el Equipo Scrum y la organización adopten Scrum. El ScrumMaster enseña al Equipo Scrum mediente entrenamiento y liderándolo para que sea más productivo y a construya productos de mayor calidad. El ScrumMaster ayuda a que el Equipo Scrum comprenda y utilice la auto-gestión y a ser multidisciplinar.El ScrumMaster también debe ayudar al Equipo Scrum a entregar lo mejor de si mismo en un entorno de organización que posiblemente aún no esté optimizado para el desarrollo de productos complejos. Cuando el ScrumMaster ayuda a realizar estos cambios, esto recibe el nombre de "eliminar impedimentos." El papel del ScrumMaster es el de servidor y líder del equipo de Scrum. Sin embargo, el ScrumMaster no gestiona el Equipo Scrum, el equipo Scrum es auto-gestionado.
El ScrumMaster explica al Propietario del Producto cómo hacer su trabajo. Se espera que los Propietarios del Producto sepan cómo gestionar para optimizar el valor utilizando Scrum. Si esto no se cumple, podría ser responsabilidad del ScrumMaster.
"
----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com
Juan Carlos Quijano Abad
Juan Carlos Quijano Abad
José Manuel Beas
jorge
Jorge Uriarte Aretxaga
> Amén, Angel.
> ¿Cómo puede hacer el SM para ayudar al PO a priorizar? Entiendo que para eso se trabaja (más o menos) diariamente la pila de producto, pero eso exigiría del SM que, además, tuviera un gran conocimiento del negocio. ¿O no? Lo pregunto porque ese requisito en el rol de SM no lo he visto nunca y no sé si sería algo excepcional o, por el contrario, se trataría más bien de que es necesario otro rol o algo que se me escapa.
>
Si me permitís terciar, yo creo que NO requiere eso.
Ayudar a definir y cuidar del backlog no implica conocimiento en
profundidad del dominio del problema, de la misma manera que facilitar
un proceso no implica necesariamente un conocimiento en detalle de
todas las áreas involucradas.
A menudo, disponer de ese conocimiento puede ayudar pero... ¿No es esa
la historia de nuestra profesión?
Si hay un "soft-skill" que debe tener alguien que se dedica a
implantar soluciones es la capacidad de empatizar con problemáticas
ajenas, y de aprender lo necesario para poder hacer de puente entre el
mundo de la necesidad y el de la solución.
El SM sigue, vigila la calidad de las historias, acompaña al PO y se
asegura de que se priorice. Si algo no va, en su mano está buscar las
soluciones. En ese sentido, vuelve a ser más un facilitador que un
ejecutor.
Y aquí es donde se marca la diferencia; el momento donde el valor que
aporta un buen SM - a menudo ridiculizado como alguien que hace tres
preguntas diarias y mueve los post-its - puede determinar el destino
del proyecto. En la capacidad de hacer de los que le rodean un mejor
equipo,
("Menuda chapa que les he soltao...")
--
_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte
Ángel Medinilla
1. ¿Es correcta la visión de Scrumalliance de que los equipos de Scrum son auto organizados pero no auto dirigidos
Oh, sí. Si no, podrían decidir que no les gusta hacer aplicaciones CRM y que prefieren hacer clones de los Angry Birds, y eso a lo mejor no es una buena idea... ;))
(labor del SM)?
Oh, no. No creo que la SA diga eso. Dirigir es labor de la Dirección (gerencia). BTW, El Agile Management es un hot topic ahora mismo...
¿Hasta que punto el SM considera que debe tomar decisiones de liderazgo?
Uno: liderar no es decidir. Un lider es aquel a quien seguimos porque, de alguna forma, queremos seguirle. Este papel, que sería emergente y orgánico en la naturaleza, ha sido impuesto en la empresa moderna en la forma de gerentes o jefes, por lo que debemos seguir a personas que, en muchas ocasiones, no seguiríamos de motu propio. El SM lidera mediante el ejemplo, viviendo según los valores y principios Ágiles. Si el equipo *no quiere* hacer Agilidad, ya puedes poner al SM que quieras. No va a funcionar por mucho que el SM *decida* que hay que hacer Scrum. No obstante, si se ha decidido hacer Scrum, el SM tiene ámbito para decidir en aspectos relativos a la correcta aplicación de Scrum (por ejemplo, el equipo no debería poder decidir "dejar de hacer Scrum diario", aunque podrían covencer al SM para tal cosa y evolucionar hacia algo distinto de Scrum si el SM lo ve conveniente).
Dos: el problema cuando hablamos del SM es que hay muchos tipos de SM. Para mi (o mejor dicho, en la escuela de pensamiento en la que yo milito) el SM no es un estado, sino un camino. Este camino tiene varios estadíos:
0) "Scrunch Master" - El SM convoca las reuniones y poco más. Como no tiene mucha dedicación, suele ser alguien que trabaja en el equipo y, a ratos, hace de SM. Quizás actua como portavoz del grupo. Se habla de rotar el puesto de SM entre los miembros del equipo.
1) "SM Mamá": El SM comienza a tomar decisiones para el equipo en lo relativo a Scrum / Agile y a los impedimentos a los que el equipo se enfrenta. Elimina impedimentos para el equipo en la forma de "Ya lo hago yo". Si el equipo o el P.O. no cumplen con alguna de sus responsabilidades también las asume él ("ya reporto yo en el tablón", "ya escribo yo las historias de usuario"). Mayordomo y secretaria del equipo "para que el equipo no se desconcentre y no pierda el tiempo", línea de pensamiento preliminar en las implementaciones que, si bien puede ser necesaria al principio, es peligrosa a largo plazo, ya que puede conducir a que el equipo no sea convocado a las reuniones por lo mismo. Interlocutor / Interfaz del equipo (misma consideración respecto a peligrosidad en el largo plazo). Comienza a moderar las reuniones. Es un avance respecto al Scrunch Master, pero no debería quedarse aquí.
2) Scrum Master: Facilita y dinamiza las reuniones. Actúa de formador y mentor: enseña a cada uno a ejecutar su papel dentro de Scrum. Evangeliza en la organización y en el equipo sobre las prácticas ágiles, no solo Scrum (programación por parejas, refactorización, TDD, propiedad colectiva de código, estimación en puntos, planning poker, Kanban...). Es un agente del cambio organizativo. Es un lider del equipo. Mantiene y ejecuta con el equipo un plan de mejora continua. Diagnostica problemas y propone soluciones.
3) Scrum Sensei / Agile Coach: Maestro de la escucha. Nunca decide ni sugiere soluciones: hace preguntas. Pero son las preguntas correctas. Respeta las decisiones del equipo, pero hace al equipo responsable de ellas. Ayuda al equipo a identificar problemas, descubrir soluciones e implementarlas por ellos mismos. Trabaja aspectos como el trabajo en equipo, la comunicación, la colaboración... Bajo su influjo emergen equipos de alto rendimiento con el máximo nivel de compromiso, motivación y rendimiento.
DISCLAIMER: utilizar la estrategia del Agile Coach con un equipo principiante solo conduce al desastre. Al igual que el SM, el equipo debe andar un camino.
2. ¿Vale esta frase dentro del concepto de impedimento?"Pero también el SM debe colgar por los pulgares al de Sistemas para que la impresora funcione, o al de mantenimiento para evitar un frio polar en la sala, o facilitar el uso de SCRUM, o detener la derivación hacia ASM. Incluso, como parte del equipo, asegurarse del uso de buenas prácticas de desarrollo. Cualquier cosa que sea un impedimento, por grande o pequeño que sea, para el fluido trabajo del equipo."
Aplíquese el párrafo anterior. Mira también la definición de Impedimento de la Scrum Guide y verás que va mucho más allá de "la impresora no funciona". Si la impresora no funciona y necesitamos al Scrum Master para que lo solucione, equipo y SM están en la fase pre-Scrum ("SM Mamá").
Sorry for the tocho, espero que lo consideréis de utilidad en vuestro periplo... ;))
Ángel Medinilla
¿Cómo puede hacer el SM para ayudar al PO a priorizar? Entiendo que para eso se trabaja (más o menos) diariamente la pila de producto, pero eso exigiría del SM que, además, tuviera un gran
conocimiento del negocio. ¿O no?
Se escapa un poco del hilo, IMHO, pero por no dejarlo en el aire, yo creo que no. En mi caso particular, ayudo a, literalmente, cientos de PO a priorizar sus pilas de producto, y evidentemente no tengo un gran conocimiento de todos estos negocios. Preguntas del estilo "si solo pudieras tener cuatro o cinco de todos estos cromos dentro de quince días, ¿cuáles serían los más valiosos para la compañía?" las puedes hacer sin entender una papa de lo que pone dentro de las tarjetas.
Donde sí se necesita más conocimiento (y donde me doy de capones) es a la hora de dividir un proyecto o una feature grande en historias de usuario más pequeñas, pero para ayudar al PO con eso cuento con un arma secreta a la que llamo "equipo". De hecho, cada vez más recomiendo la instauración de sesiones regulares de "backlog grooming" con el PO.
A los que vayan a argumentar que "el equipo pierde mucho tiempo con tantas reuniones" tendría que explicarles tantas cosas... :))
Lo pregunto porque ese requisito en el rol de SM no lo he visto nunca
Chico, lo pone en la Scrum Guide... :-(
José Manuel Beas
Donde sí se necesita más conocimiento (y donde me doy de capones) es a la hora de dividir un proyecto o una feature grande en historias de usuario más pequeñas, pero para ayudar al PO con eso cuento con un arma secreta a la que llamo "equipo". De hecho, cada vez más recomiendo la instauración de sesiones regulares de "backlog grooming" con el PO.
Ángel Medinilla
Genial, Angel, es justo la respuesta que necesitaba. :-D(Perdón por salirme del topic, pero ya sabes...) ;-)
Si con eso he ayudado en algo a alguien, que le den al topic (con perdón)... :))
PEDRO BALLESTEROS HERRANZ
¡Vaya!, ya llego al hilo con 10 respuestas de retraso!
Gracias por la aportación Ángel, muy útil. Me gusta esto de “si Scrum es un marco definido”. Para mí está empezando a ser una gran duda ¿es un marco definido?
Últimamente oigo tanto eso de que los métodos agile se pueden flexibilizar que me da miedo cada vez que lo oigo, scrum se me está haciendo un marco bastante indefinido. Cada vez que intento buscar la solución en lo que dice scrum me saltan con lo de flexibilizar, pero ¿cuál es el límite? ¿quién dice si esa flexibilización está matando scrum?
La definición del Scrum Master que adjuntas ayuda bastante, en mi opinión incluso ni siquiera invalida ninguna de las opiniones expresadas. Pero como en muchas otras prácticas Agile, deja mucho abierto a la interpretación, y es en esa interpretación donde surge la polémica.
De todas formas cuando comencé este hilo más que un debate sobre lo que debe o no hacer el SM, yo quería plantear un debate sobre quien trabaja el PB, la gran importancia del PB y lo maltratado que está en muchos proyectos.
¿Quién es el que hace el trabajo de creación y mantenimiento del Product Backlog? Para mí el PB es un artefacto fundamental, y en muchos proyectos muy descuidado. No es trivial, consume mucho tiempo, alguien tiene que hacerlo. Yo lo consideraba como una colaboración PO + SM, siendo el SM el que arrastra al PO que suele ser siempre el que se intenta escaquear.
Como miembro del equipo quiero un buen PB, y el SM debería preocuparse de que el Sprint Planning no se convierte en una reunión de creación del PB, que es lo que ocurre muchísimas veces.
Un impedimento que me gustaría que mi SM eliminara es tener que ir a un montón de reuniones con el PO para tener un buen PB, de hecho que incluso el SM pudiera convencer al PO de priorizar las historias de usuario relacionadas con la calidad interna, esas historias que hacen un software de calidad y que el PO nunca considera importantes.
Saludos,
Pedro
PEDRO BALLESTEROS HERRANZ
Buenísimo lo de los tipos de scrum master,
¿Por qué no lo cuelgas en tu blog y así puedo enviar el enlace a mis compañeros de trabajo? (Imagino que tienes blog)
Gracias,
Pedro
De: agile...@googlegroups.com [mailto:agile...@googlegroups.com]
En nombre de Ángel Medinilla
Enviado el: viernes, 25 de marzo de 2011 18:24
Para: agile...@googlegroups.com
CC: Juan Carlos Quijano Abad
Asunto: Re: [agile-spain] ¿El Rol de Scrum Master en Peligro?
IMHO:
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
PEDRO BALLESTEROS HERRANZ
Me sumo al “genial” de JMBeas.
¡Cuánto aprendido en un ratillo revisando el hilo!!!. Me apunto el “backlog grooming”. Angel, escribe también un artículo del “backlog grooming” y lo enlazo ;)
Saludos,
Pedro
De: agile...@googlegroups.com [mailto:agile...@googlegroups.com]
En nombre de José Manuel Beas
Enviado el: viernes, 25 de marzo de 2011 19:08
Para: agile...@googlegroups.com
Asunto: Re: [agile-spain] ¿El Rol de Scrum Master en Peligro?
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
Ángel Medinilla
----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com
José Manuel Beas
Juan Carlos Quijano Abad
Ángel Medinilla
----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com
Como toda tarea que se mantiene en el tablero, debiera tener su estimación.
Eso lo dirá usted... ;))
Muchos de mis equipo shan dejado (a consejo mío) de estimar las tareas. Sólo la historia, sobre la que se van haciendo estimaciones diarias de "cuanto queda". Resultado: menos presión para estimar, menos sensanción de "Hay que acertar con las estimaciones"... Y entre una hora y media o dos horas menos por Sprint Planning :)
Eso no quita para que, como bien dices, se vigilen tareas que no progresan y se hagan tareas tirando a pequeñitas. Un tablón con varios estados también ayuda (en vez del típico "Pendiente-En curso-Terminada").
¿Spin-off del topic?