Scrum master como coach (Era: Oferta de trabajo: Scrum Master en Telefonica I+D)

62 views
Skip to first unread message

Jorge Uriarte Aretxaga

unread,
Feb 9, 2011, 10:14:09 AM2/9/11
to agile...@googlegroups.com
2011/2/9 Gustavo Cebrian Garcia <g.cebria...@gmail.com>
Según la filosofía Scrum, yo creo, un Scrum Master, nunca puede ser un bottle neck, si no quitar bottle necks.
Por eso me suena raro. La responsabilidad debería ser, en mi opinión: 
-Identify the bottle neck and find solutions to sort it out.

Mira por dónde, a mí me ha gustado ver ese requisito escrito :)

Existe un riesgo de que un SM de perfil "solucionador" elimine problemas, consiga que el trabajo fluya, pero termine haciendo que el equipo dependa de él en lugar de conseguir un equipo capaz de mejorar por sí mismo y resolver los problemas en su contexto organizacional.

Fue un tema discutido en el Agile Coaches Gathering, e incluso después ha habido algunas conversaciones sobre el papel del SM como Coach, y el objetivo último de un coach de *no ser necesario*.

Es decir... que en mi opinión el que ha escrito/sugerido ese párrafo tiene un objetivo clarito-clarito; no quieren heroes ;)

_
Jorge Uriarte Aretxaga
http://www.gailen.esS
http://www.linkedin.com/in/jorgeuriarte

12th Internt. Conf. on Agile Software Development http://xp2011.org 

Juan Carlos Quijano Abad

unread,
Feb 9, 2011, 10:59:01 AM2/9/11
to agile...@googlegroups.com
Buenas,

A mi me encanta eso de que el scrum master debe ser como una mosca en una pared... :)
--
Un saludo
Juan Quijano
 



--
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.

Gustavo Cebrian Garcia

unread,
Feb 9, 2011, 11:05:37 AM2/9/11
to agile...@googlegroups.com
Entiendo.
 
Veo compatible que el Scrum Master solucione y enseñe a solucionar...

2011/2/9 Juan Carlos Quijano Abad <juancarl...@gmail.com>

Gustavo Cebrian Garcia

unread,
Feb 9, 2011, 11:08:02 AM2/9/11
to agile...@googlegroups.com
Y claro, con el objetivo de que la gente solucione, más bien que el solucione...
 
Yo le digo a mi gente que ellos son los Managers ( y claro, hay cosas que no ven y les digo que tienen que ver... )
 
...

Ángel Águeda

unread,
Feb 10, 2011, 1:29:25 AM2/10/11
to agile-spain
Lo curioso de un Scrum Master en nómina es que trabaja para que al
final su trabajo sea prescindible. Por lo tanto, la empresa que lo
contrata debería tener un plan a medio plazo para que esa persona
ocupe otro rol en la organización.

En el caso de Telefónica, por su tamaño, quizás lo anterior no sea una
cuestión de urgencia.

Ángel Medinilla

unread,
Feb 10, 2011, 3:02:48 AM2/10/11
to agile...@googlegroups.com
 
2011/2/10 Ángel Águeda <angel....@gmail.com>

Lo curioso de un Scrum Master en nómina es que trabaja para que al
final su trabajo sea prescindible. Por lo tanto, la empresa que lo
contrata debería tener un plan a medio plazo para que esa persona
ocupe otro rol en la organización.

¿Porque el equipo ha alcanzado la perfección absoluta y ya no puede mejorar más? ¿Porque llega un momento en que el equipo es tan bueno que hace de coach de sí mismo? ¿Es esa una buena idea (ser coach de uno mismo)? ¿Hemos entendido lo que es un Scrum Master o un Coach Ágil (me remito a otro hilo)?

Suponiendo que esta persona sea capaz de trabajar con un equipo hasta llevarlo a la perfección e independencia absoluta ("a medio plazo" ¿?), ¿a la empresa le interesa presecindir de esta persona?

¿Por qué los fundadores de Google o Apple siguen teniendo un Coach que les ayuda a trabajar ? Google y Apple ya son la pera, ¿por qué no despiden al coach?

http://money.cnn.com/2008/07/21/technology/reingold_coach.fortune/index.htm

Creo que hay que entender un poco mejor lo que es un Scrum Master antes de decir que las empresas deberían tener planes para que estas personas ocupen otro rol en la organización. No entender este rol es lo que hace que mucha gente dude sobre si es una dedicación al 100% o algo que "algún miembro del equipo puede hacer en sus ratos libre" (OMG).


Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 3:11:15 AM2/10/11
to agile...@googlegroups.com
Eso apuntaba Juan Palacio en su curso... y sé que muchas empresas contratan así, ( traemos un Scrum Master 6 meses y que nos enseñe, y luego fuera ) pero...
 
Un Scrum Master, como tal, es un trabajo temporal, en teoría. Si decir que un Scrum Master puede estar trabajando mucho tiempo
y no haber implementado en su empresa todo lo que tiene en mente.
 
Simplemente hacer trabajar a una empresa madura en historias de usuario, puff, cuesta !
La metodología tradicional del taco de folios para estimar está todavía muy presente, incluso en Inglaterra, que es más ágil,
pero vamos, queda mucho camino...
 
Es decir, veo los dos puntos de vista de los dos Angeles, jeje, pero, si decir que hay un camino muy muy muy muy largo, y creo que el Scrum Master tiene trabajo siempre. Pero vamos, es una cuestión de dinero. Decir que en mi opinión el Scrum Master puede aportar valor infinito en pura gestión de tiempo, costes, alcance y también técnicamente, TDD, XP.
( Esa es la otra historia, hay muchos tipos de Scrum Master y el mejor Scrum Master intenta ser técnico )
 
Yo, por ejemplo, después de 8 años sin programar, intento leer de TDD, XP etc, intento ser un poco mejor...
El Scrum Master es el arquitecto que tiene que supervisar cuantos más ladrillos mejor...
 
Estoy con Angel Medinilla, mucha gente no entiende lo que es un Scrum Master, ni siquiera las ofertas de trabajo lo describen bien ( en mi opinión )
 
Gustavo.
 


 
2011/2/10 Ángel Águeda <angel....@gmail.com>

jorge

unread,
Feb 10, 2011, 3:30:15 AM2/10/11
to agile...@googlegroups.com
+1

2011/2/10 Ángel Medinilla <angel.m...@gmail.com>

 
2011/2/10 Ángel Águeda <angel....@gmail.com>

Lo curioso de un Scrum Master en nómina es que trabaja para que al
final su trabajo sea prescindible. Por lo tanto, la empresa que lo
contrata debería tener un plan a medio plazo para que esa persona
ocupe otro rol en la organización.

¿Porque el equipo ha alcanzado la perfección absoluta y ya no puede mejorar más? ¿Porque llega un momento en que el equipo es tan bueno que hace de coach de sí mismo? ¿Es esa una buena idea (ser coach de uno mismo)? ¿Hemos entendido lo que es un Scrum Master o un Coach Ágil (me remito a otro hilo)?

no creo que estemos hablando de una verdad grabada en una piedra, cada uno tiene su manera de entenderlo y algunas serán mejores que otras en según qué contextos o no. Lo que está claro es lo que pone en el libro.
 

Suponiendo que esta persona sea capaz de trabajar con un equipo hasta llevarlo a la perfección e independencia absoluta ("a medio plazo" ¿?), ¿a la empresa le interesa presecindir de esta persona?

Es un crack, mejor que se vaya, no? ;o)
 

¿Por qué los fundadores de Google o Apple siguen teniendo un Coach que les ayuda a trabajar ? Google y Apple ya son la pera, ¿por qué no despiden al coach?

Perdona pero estos *viejos fantasmas* son guays o son guays sus productos...¿? o algunas cosas son guays y otras no... parece que son la isla de utopía.
 
 

Esto está inventado y bueno, conozco grandes FIRMAS de abogados que trabajan con gente de los NY yankees... casualmente sería como si el real madrid hubiese ganado 20 o 30 champions, por comparar.

Con esto quiero decir sí y que no, que cada uno tiene su forma de llegar a hacer las cosas y este que apuntas en un caso similar pero que habrá otros... mejores? ;)
 


Creo que hay que entender un poco mejor lo que es un Scrum Master antes de decir que las empresas deberían tener planes para que estas personas ocupen otro rol en la organización. No entender este rol es lo que hace que mucha gente dude sobre si es una dedicación al 100% o algo que "algún miembro del equipo puede hacer en sus ratos libre" (OMG).

Insisto: +1, pero que cada uno tiene su PoV.

Para mi, un SM puede ser un coach del equipo a modo XP o a modo 37signals http://www.nfib.com/mybusiness-magazine/operational-insight pero me parece que es un miembro más del equipo con diferente nivel de interlocución para garantizar que el resto puede seguir trabajando (no blocks).

David Palomar

unread,
Feb 10, 2011, 7:16:31 AM2/10/11
to agile-spain
Coincido con la reflexión de Angel, pero a medias, o mejor aún la
completaría.
Si una persona o equipo piensa que ha alcanzado la perfección
seguramente se ha quedado obsoleto.
Otra cosa diferente es que una vez alcanzado un grado de perfección,
quiera por su cuenta y riesgo nuevos niveles de perfeccionamiento por
su cuenta y esa es la labor del coach agile.

Según mi criterio, no hay que confundir un Agile Coach, con un
Scrummaster. el segundo se dedica a hacer que el equipo adopte las
prácticas de Scrum y guiarles, enseñarles y apoyarles para que lo
logren. El primero guiará al equipo a conseguir ser un equipo
autogestionado en prácticas agiles, sean cuales sean.

No cabe duda de que un SM, debería tener destrezas técnicas, pero
también competencias no técnicas orientadas al coaching, ese sería el
ideal.
Creo nuevamente que las reticencias a emplear un SM, o un Agile coach
vienen del modo "tradicional" de pensar, en las asignaciones
temporales de un jefe de proyecto, donde en muchos casos se le asigna
un 20% del tiempo al proyecto y por tanto se intenta que el SM haga su
labor de igual manera, y una vez hecha su labor re-localizarle en otro
puesto.

Nuevamente hay diferencias: Un jefe de proyecto cumple con cada
proyecto, un SM cumple con cada equipo agile basado en Scrum (es el
equipo el que cumple con el proyecto), un Agile coach cumple con la
mejora continua. No hay porqué descartar a nadie, sin embargo, en
muchos casos el negocio manda y es necesario establecer alcances
temporales, que es algo que hecho de menos en la oferta, tipo de
contrato y alcance temporal del mismo.


On 10 feb, 09:02, Ángel Medinilla <angel.medini...@gmail.com> wrote:
> 2011/2/10 Ángel Águeda <angel.agu...@gmail.com>
>
> > Lo curioso de un Scrum Master en nómina es que trabaja para que al
> > final su trabajo sea prescindible. Por lo tanto, la empresa que lo
> > contrata debería tener un plan a medio plazo para que esa persona
> > ocupe otro rol en la organización.
>
> ¿Porque el equipo ha alcanzado la perfección absoluta y ya no puede mejorar
> más? ¿Porque llega un momento en que el equipo es tan bueno que hace de
> coach de sí mismo? ¿Es esa una buena idea (ser coach de uno mismo)? ¿Hemos
> entendido lo que es un Scrum Master o un Coach Ágil (me remito a otro hilo)?
>
> Suponiendo que esta persona sea capaz de trabajar con un equipo hasta
> llevarlo a la perfección e independencia absoluta ("a medio plazo" ¿?), ¿a
> la empresa le interesa presecindir de esta persona?
>
> ¿Por qué los fundadores de Google o Apple siguen teniendo un Coach que les
> ayuda a trabajar ? Google y Apple ya son la pera, ¿por qué no despiden al
> coach?
>
> http://money.cnn.com/2008/07/21/technology/reingold_coach.fortune/ind...

Juanjo Falcon

unread,
Feb 10, 2011, 7:35:06 AM2/10/11
to agile...@googlegroups.com
Yo creo aun estando de acuerdo en que hay muchas tareas para el SM, creo que eso de buscar la segunda derivada no es muy práctico.

En mi idea práctica de un equipo ágil, me basta con tener un equipo eficaz, autónomo y autogestionado. Para lograrlo partiendo de poco conocimiento es necesario distintos perfiles xternos, desde formadores técnicos, SrumMaster, y Coachers. Pero en un plazo razonable (de 2 meses a 2 años) debería de conseguir que el equipo funcione solo, porque de lo contrario más vale que cambie de equipo, o de formadores.

Dicho esto, también entiendo que el rol de SM siempre debe estar integrado dentro de un equipo ágil, ya sea de una forma explicita, donde algún componente asume ese rol de forma continua o periodica, o de forma implicita por la propia madurez del equipo. Lo que no veo en mi caso, es que en un equipo ágil maduro se necesita la disponibilidad de un SM a tiempo completo.

Alfredo Casado

unread,
Feb 10, 2011, 7:44:32 AM2/10/11
to agile...@googlegroups.com
Utilizando términos de Lean, tener una persona en exclusiva para cumplir con el rol de SM en un equipo maduro me parece puro waste. Sin embargo es un figura muy importante en un equipo que esta empezando para ayudarles a alcanzar esa madurez, yo estoy más de acuerdo con la idea de que el buen scrum master es aquel que sabe hacerse prescindible. 

Cuando un equipo funciona bien los miembros pueden ir rotándose el papel de SM, o incluso prescindir de ese rol, en realidad, lo que ellos decidan, si se trata de un equipo maduro sus decisiones serán mejores que las que cualquiera pueda tomar desde fuera.

Juan Carlos Quijano Abad

unread,
Feb 10, 2011, 8:51:42 AM2/10/11
to agile...@googlegroups.com
Buenas,

Creo que es waste situar al SM fuera del equipo. Por muy maduro que esté un equipo, se necesita una persona en exclusiva para eliminar los impedimentos, provengan de donde sean. De echo, una de las muestras de madurez es que el sm sea parte del equipo.

Pensar que el SM es prescindible, en mi opinión, es tener un entendimiento erroneo de lo que es scrum y que representa la figura del SM. También opino que no es un trabajo que cualquiera puede hacer y que no se debe hacer por turnos rotando a la gente del equipo. Para todo se necesita conocimientos, experiencia y talento. Y nadie es capaz de hacerlo todo bien. Porqué? Por la misma razón que no se pone a los diseñadores apicar código, ni a los desarrolladores a traer cafés ni hablar con el del aire para que la habitacion no sea un horno.

En otros contextos profesionales, cuanto mejor es el equipo mejor es el entrenador, coach, director, organizador o llamemoslo como queramos. Por ejemplo, a nadie se le ocurriria quitar el entrenador de la selección española, por mucho que ganen la copa del mundo siendo, por ende, los mejores. O el director de una orquesta, aunque sean los virtuosos de moscú.

La "comuna" es una idea muy bonita, pero en mi experiencia y opinión, simplemente no funciona más que en casos extraordinarios y temporales.

Laura Morillo-Velarde

unread,
Feb 10, 2011, 9:11:40 AM2/10/11
to agile...@googlegroups.com
Si no me equivoco tanto un entrenador de fútbol como un director de orquesta ordenan, mientras que un Scrum Master no, así que la comparación creo que no es muy válida.

Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 9:15:01 AM2/10/11
to agile...@googlegroups.com
Alfredo, me puedes por favor enumerar las funciones del Scrum Master? :-)
 
o mejor dicho, para encontrar es madurez, que tiene que hacer el Scrum Master.
 
Poniendo ejemplos comprenderemos más de lo que estamos hablando.
 
Otra cosa, de cuanta gente son vuestros equipos?
 
( solo intentando ayudar )

2011/2/10 Alfredo Casado <casado....@gmail.com>

Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 9:16:24 AM2/10/11
to agile...@googlegroups.com
haha, no seamos tiquismikis, tu entiendes lo que quiere decir Juan Carlos?

2011/2/10 Laura Morillo-Velarde <laura.mori...@gmail.com>

Harald Messemer

unread,
Feb 10, 2011, 9:24:49 AM2/10/11
to agile...@googlegroups.com
Pienso que el concepto de coaching y el SM como coach en si son
conceptos temporales porque persigen conseguir que uno aprende a
solucionar una solucion que sola no puede y tardaria mas tiempo.

Dicho esto. Si un equipo decide que quiere quedarse con el coach
porque aporta al equipo a conseguir sus objetivos y siendo
productivos, bienvenido sea. En consecuencia no sera Waste tener a
esta persona en el equipo, sea Scrum Master o Poppa Chubby.

En resumen. Creo en esto no hay verdad absoluta.

Un saludo,
Harald

2011/2/10, Juan Carlos Quijano Abad <juancarl...@gmail.com>:


> Buenas,
>
> Creo que es waste situar al SM fuera del equipo. Por muy maduro que esté un
> equipo, se necesita una persona en exclusiva para eliminar los impedimentos,
> provengan de donde sean. De echo, una de las muestras de madurez es que el
> sm sea parte del equipo.
>
> Pensar que el SM es prescindible, en mi opinión, es tener un entendimiento
> erroneo de lo que es scrum y que representa la figura del SM. También opino
> que no es un trabajo que cualquiera puede hacer y que no se debe hacer por
> turnos rotando a la gente del equipo. Para todo se necesita conocimientos,
> experiencia y talento. Y nadie es capaz de hacerlo todo bien. Porqué? Por la
> misma razón que no se pone a los diseñadores apicar código, ni a los
> desarrolladores a traer cafés ni hablar con el del aire para que la
> habitacion no sea un horno.
>
> En otros contextos profesionales, cuanto mejor es el equipo mejor es el
> entrenador, coach, director, organizador o llamemoslo como queramos. Por
> ejemplo, a nadie se le ocurriria quitar el entrenador de la selección
> española, por mucho que ganen la copa del mundo siendo, por ende, los
> mejores. O el director de una orquesta, aunque sean los virtuosos de moscú.
>
> La "comuna" es una idea muy bonita, pero en mi experiencia y opinión,
> simplemente no funciona más que en casos extraordinarios y temporales.
>
> --
> Un saludo
> Juan Quijano
>

> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> 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/>

--
Gesendet von meinem Mobilgerät

Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 9:31:34 AM2/10/11
to agile...@googlegroups.com
Harald, definimos las tareas del Scrum Master y me dices cuanto tiempo se tardan en inculcarl los valores?
:-)
Gustavo.

2011/2/10 Harald Messemer <harr...@gmail.com>

Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 9:34:10 AM2/10/11
to agile...@googlegroups.com
Por cierto, os doy un adelanto, Mike Cohn dijo cuando le hicieron esta pregunta:
 
"That is rubbish !"    ( Esto lo dijo en mi curso de Scrum Master, cuando yo comía con Mike y otros dos... )
 
Tengo que decir que los mejores del mundo están con Medinilla y con Juan Carlos.
 
Gustavo.

2011/2/10 Gustavo Cebrian Garcia <g.cebria...@gmail.com>

Juan Carlos Quijano Abad

unread,
Feb 10, 2011, 9:35:50 AM2/10/11
to agile...@googlegroups.com
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Laura, un poquillo si que debe mandar para poder hacer que las reglas se cumplan y para poder actuar de protección. ;)


--
Un saludo
Juan Quijano
 

Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 9:43:58 AM2/10/11
to agile...@googlegroups.com
Está muy bien la definición, pero descoponer todas las responsabilidades... Aparte de las ya comentadas:
 
-Tiene el Scrum Master que enseñar XP?
-Tiene el Scrum Master enseñar cuando una historia de usuario está bastante cubierta con TDD?
.
.
.
.
.
Podría hacer una lista muy larga.
 
y sinceramente, para mi, yo he visto Scrum master preocuparse de las tareas del Jefe de Proyecto tan criticado:
-Tiempo
-Costes
-Alcance
-Beneficios
-Riesgos
 
Aunque el equipo está disciplinado, mi realidad, es que mucho equipos no tienen visión de lo que he mencionado arriba ( algunos si )
 
 
Gustavo.

2011/2/10 Juan Carlos Quijano Abad <juancarl...@gmail.com>

Laura Morillo-Velarde

unread,
Feb 10, 2011, 10:05:08 AM2/10/11
to agile...@googlegroups.com

Si manda sobre el equipo ya no se autoorganizan, así que algo no encaja.

angel.m...@gmail.com

unread,
Feb 10, 2011, 10:14:33 AM2/10/11
to agile...@googlegroups.com
+100 salvo por la necesidad del SM como miembro del equipo: hay varias escuelas de pensamiento al respecto, todas ellas con buenos argumentos...

Enviado desde mi HTC


----- Reply message -----
De: "Juan Carlos Quijano Abad" <juancarl...@gmail.com>
Para: <agile...@googlegroups.com>
Asunto: [agile-spain] Re: Scrum master como coach (Era: Oferta de trabajo: Scrum Master en Telefonica I+D)
Fecha: jue., feb. 10, 2011 14:51


Buenas,

Creo que es waste situar al SM fuera del equipo. Por muy maduro que esté un equipo, se necesita una persona en exclusiva para eliminar los impedimentos, provengan de donde sean. De echo, una de las muestras de madurez es que el sm sea parte del equipo.

Pensar que el SM es prescindible, en mi opinión, es tener un entendimiento erroneo de lo que es scrum y que representa la figura del SM. También opino que no es un trabajo que cualquiera puede hacer y que no se debe hacer por turnos rotando a la gente del equipo. Para todo se necesita conocimientos, experiencia y talento. Y nadie es capaz de hacerlo todo bien. Porqué? Por la misma razón que no se pone a los diseñadores apicar código, ni a los desarrolladores a traer cafés ni hablar con el del aire para que la habitacion no sea un horno.

En otros contextos profesionales, cuanto mejor es el equipo mejor es el entrenador, coach, director, organizador o llamemoslo como queramos. Por ejemplo, a nadie se le ocurriria quitar el entrenador de la selección española, por mucho que ganen la copa del mundo siendo, por ende, los mejores. O el director de una orquesta, aunque sean los virtuosos de moscú.

La "comuna" es una idea muy bonita, pero en mi experiencia y opinión, simplemente no funciona más que en casos extraordinarios y temporales.

--
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.

--
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.

--
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.

David Palomar

unread,
Feb 10, 2011, 10:19:46 AM2/10/11
to agile-spain

Creo que un error de concepto es que el SM sea una persona, es un rol
y por tanto puede ser asumido por cualquier miembro del equipo.
Si pensamos en que el SM debe de tener una asignación de un 100% al
principio del proyecto, un 50% durante la mitad del proyecto y un 20%
al final del mismo, o incluso desaparecer, entonces no aplicamos
agilidad, puesto que estamos aplicando un paradigma predictivo, lo que
no encaja con los principios ágiles.

Por tanto, si el SM es un rol asumido por cualquier miembro del equipo
en cualquier momento, eso significa que el SM tiene una asignación
constante en todo el equipo y en todo momento y por tanto no
desaparece. Si el SM original logra el objetivo de generar un equipo
autogestionado, eso no significa que el rol de SM desaparezca, si no
que ha sido capaz de lograr que el equipo asuma las funciones de SM.
Eso es la verdadera autogestión.

Para que eso ocurra, el SM debe ser un creador de SMs, y pese a quien
le pese, a veces hay que dirigir, de lo contrario dejamos que el barco
se estrelle contra las rocas.

On 10 feb, 16:05, Laura Morillo-Velarde
<laura.morillovela...@gmail.com> wrote:
> Si manda sobre el equipo ya no se autoorganizan, así que algo no encaja.
>
> El 10 de febrero de 2011 15:35, Juan Carlos Quijano Abad <
> juancarlosquij...@gmail.com> escribió:
>
>
>
>
>
>
>
> > El *Scrum* es facilitado por un *ScrumMaster*, cuyo trabajo primario es
> > eliminar los obstáculos que impiden que el equipo alcance el objetivo del
> > sprint. El *ScrumMaster* no es el líder del equipo (porque ellos se
> > auto-organizan), sino que actúa como una protección entre el equipo y
> > cualquier influencia que le distraiga. El ScrumMaster se asegura de que el
> > proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que
> > las reglas se cumplan.
>
> > Laura, un poquillo si que debe mandar para poder hacer que las reglas se
> > cumplan y para poder actuar de protección. ;)
>
> > --
> > Un saludo
> > Juan Quijano
>
> > Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> > 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/>

Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 10:34:04 AM2/10/11
to agile...@googlegroups.com
"Para que eso ocurra, el SM debe ser un creador de SMs"
Eso me ha gustado David.
 
Gustavo.
2011/2/10 David Palomar <dpal...@gmail.com>

Alfredo Casado

unread,
Feb 10, 2011, 11:03:31 AM2/10/11
to agile...@googlegroups.com
Si asumimos que el trabajo del SM es más o menos:

- eliminar impedimentos.
- asegurarse que el equipo cumple con las reglas de scrum (y XP también si queréis añadirlo).

A grandes rasgos es esto ¿no?. Si el equipo es maduro no necesita un vigilante de las reglas de scrum, el equipo las asume y forman parte del equipo, ese es el objetivo, por lo tanto alcanzarlo supone que el SM pierde una de sus funciones. Si creéis que el equipo siempre necesita un vigilante de las reglas entonces no creéis en la auto-organización, en la auto-exigencia, en la auto-disciplina, y en consecuencia, tampoco os creéis mucho scrum aunque sigáis sus reglas. (scrum versión cargo-cult en mi opinión). Si por ejemplo el equipo tiene 5 miembros (contando al SM) ¿no será mejor cinco vigilantes que uno?.

Sólo nos queda eliminar impedimentos. Esto dependerá de cada organización,  si los impedimentos son externos probablemente la organización tenga problemas.  Si tu organización es sana tendrás pocos impedimentos externos (los internos los resuelve el equipo que recordemos que es maduro). En el caso de organización sana tener una persona para resolver los pequeños impedimentos del día a día a tiempo completo me parece un waste. (ponerme ejemplos de impedimentos que tengáis que resolver que no sean culpa de la falta de madurez de la empresa o el equipo, yo no me he encontrado con muchos).

Si pensáis en organizaciones poco maduras con equipos poco maduros, entonces esta claro que la figura del SM es imprescindible, y es posible que ni siquiera se atisbe el día en el que será prescindible porque hay muchas cosas que arreglar al mismo tiempo que quieres seguir produciendo, difícil. Pero si pensáis en equipos maduros en organizaciones maduras, el SM tiene tan poco trabajo que pagar una persona a tiempo completo para hacerlo es puro waste. 

Es difícil de creer si nunca has visto uno, pero os aseguro que estos equipos existen.

Jorge Baez

unread,
Feb 10, 2011, 11:09:26 AM2/10/11
to agile...@googlegroups.com
puedes añadir dirigir la planificación, la demo, objetivos del sprint, la retrospectiva, la reunión diaria, ayudar al po a organizar el backlog, servir de barrera ante interrupciones...

lo puede hacer cualquiera del equipo? casi cualquiera? uno cada sprint o varios? se puede rotar entre todos? y entre casi todos?

yo no creo que sea una labor prescindible en el tiempo aunque si se puede rotar... no en todos los miembros, EMO.

Harald Messemer

unread,
Feb 10, 2011, 11:43:06 AM2/10/11
to agile...@googlegroups.com
aunque no creo que ese sea al afán, pero ma la impresión que estas enumeraciones al final nos llevan a delimitar las tareas técnicas (o de programación) de las tareas no técnicas y concentrarlas en el SM.

De algún modo me parece bastante parecido a un modelo no Agile con silos de conocimiento, poca polivalencia en el equipo y con nadie conociendo todo el proceso.

En mi opinión es fundamental que todo el equipo conozca el proceso de trabaja y cuales son las diferentes funciones. A mi me gusta Scrum y Agile porque ayuda a romper este sistema y sus ineficiencias.

Por el mismo argumento estoy en contra de mantener de forma perpetua un SM en el equipo para que haga estas tareas.

Un saludo,
Harald

2011/2/10 Jorge Baez <jorge...@gmail.com>

Gustavo Cebrian Garcia

unread,
Feb 10, 2011, 12:04:59 PM2/10/11
to agile...@googlegroups.com
Harald, que quieres decir?
 
El mejor Scrum Master es el que sabe de más prácticas, no? prácticas que van a llevar a valor.
 
Hay Scrum Masters no técnicos y más técnicos..
 
Gustavo.

2011/2/10 Harald Messemer <harr...@gmail.com>
aunque no creo que ese sea al afán, pero ma la impresión que estas enumeraciones al final nos llevan a delimitar las tareas técnicas (o de programación) de las tareas no técnicas y concentrarlas en el SM.

Alfredo Casado

unread,
Feb 10, 2011, 12:08:16 PM2/10/11
to agile...@googlegroups.com
jorge:

dirigir la planificación, la demo, retrospectiva, reunión diaria: En general llevar las reuniones es algo que lo puede hacer cualquiera que sepa como se organizan, y si hablamos de un equipo maduro se lo saben de memoria. Además se da una circunstancia, todos los miembros del equipo están en la reunión, así que esta tarea seguro que la puede asumir cualquiera sin perder tiempo que necesite para otras cosas.

objetivos del sprint: Esto es cosa del PO.

ayudar al po a organizar el backlog: El PO es parte del equipo, y hemos supuesto equipo maduro, esto logicamente incluye al PO. No necesita ayuda de un SM para definir historias porque tu PO es el mayor experto en definir historias que tienes, es como si me dijeras que el SM tiene que ayudar al equipo a hacer TDD. Al principio puede, pero luego caminan solos y de eso se trata, no pensemos que esto no afecta también al PO. 

servir de barrera ante interrupciones: Lo de antes, si tu organización es madura no hay que estar de barrera mucho rato, tener una persona sólo para esto no te parece un poco de waste?. Además ese SM podría estar ayudando a otros equipos que quizá estén en una etapa previa de su adopción de agile y le necesiten más. Tener un experto en SCRUM aburrido la mitad del día y la otra mitad haciendo cosillas como avisar a los del aire o pedir a sistemas que monten no se que, me parece un desperdicio importante la verdad.

Ángel Medinilla

unread,
Feb 10, 2011, 12:34:09 PM2/10/11
to agile...@googlegroups.com
 

2011/2/10 David Palomar <dpal...@gmail.com>


Creo que un error de concepto es que el SM sea una persona, es un rol
y por tanto puede ser asumido por cualquier miembro del equipo.

Entonces el Product Owner igual, ¿no? Es un rol y lo puede hacer cualquiera del equipo... 
 


Juan Carlos Quijano Abad

unread,
Feb 10, 2011, 12:36:24 PM2/10/11
to agile...@googlegroups.com
Buenas,
 
Si el equipo es lo suficientemente maduro no necesitara scrum. De echo no necesitará métodología. De echo ni tan siquiera necesita ser Agile. Son todos tan buenos y válidos y con tantísimo talento en todas las areas que ni tan siquiera necesitan una empresa, porque ellos son capaces de asumir de forma rotatoria todos los roles necesarios e, incluso, lo que no conocen también lo van a hacer bien.
 
Yo no conozco ninguno más que de oidas (como aquel de google que dio para un hilo en nuestro foro). Y, por la navaja de Occam, es mucho más probable que el equipo CREA que es el summun de auto-gestion a causa de un ego desmedido y que no tiene nada que mejorar dentro de su mediocridad. De esos si que conozco unos cuantos, aunque siempre ruego no encontrarmelos.
 
Creo que todos estaremos de acuerdo que no hablamos de equipos maduros, al nivel que indica Alfredo. Hablamos de nuestros contextos en donde los equipos deben crecer, y mucho. Y que somos la inmensa mayoría. Y que aún estamos muy lejos de que Angel se quede sin trabajo... si es que algún dia se consigue.
 
Es esa realidad cotidiana, es necesario scrum con su SM.
--
Un saludo
Juan Quijano
 

Ángel Medinilla

unread,
Feb 10, 2011, 12:37:17 PM2/10/11
to agile...@googlegroups.com
 
2011/2/10 Jorge Baez <jorge...@gmail.com>

puedes añadir dirigir la planificación, la demo, objetivos del sprint, la retrospectiva, la reunión diaria, ayudar al po a organizar el backlog, servir de barrera ante interrupciones...

Desde mi punto de vista (y esto es sólo una escuela de pensamiento, no un Dogma Ágil de los que le gustan a algunos), el SM debe tambien ayudar al equipo a mejorar su rendimiento y su calidad de vida. Hay quien (legítimamente) considera que el SM y el Agile Coach son dos personas distintas, yo creo que un SM debe aspirar a convertirse con el tiempo en un Agile Coach. Un punto de partida puede ser "hacer que se haga Scrum", poco a poco puedes ir mejorando como facilitador, moderador... Y con el tiempo evolucionar hacia Agile Coach. Lyssa Adkins (y los que seguimos su línea de pensamiento) consideramos el SM un camino, no un estado... Como la Agilidad.

Un saludo,

Ángel.

Ángel Medinilla

unread,
Feb 10, 2011, 12:39:47 PM2/10/11
to agile...@googlegroups.com
 
2011/2/10 Juan Carlos Quijano Abad <juancarl...@gmail.com>

Buenas,
 
Si el equipo es lo suficientemente maduro no necesitara scrum. De echo no necesitará métodología.

Shuhari ! :) 

 
Yo no conozco ninguno más que de oidas

Muy buen argumento, Juan Carlos. +1 :)
 
 
Creo que todos estaremos de acuerdo que no hablamos de equipos maduros, al nivel que indica Alfredo. Hablamos de nuestros contextos en donde los equipos deben crecer, y mucho. Y que somos la inmensa mayoría. Y que aún estamos muy lejos de que Angel se quede sin trabajo... si es que algún dia se consigue.
 

Jijiji... Ojalá me ocurra eso, Juan Carlos, sería tan bonito... :-D

Corolario: El mejor equipo del mundo... Puede seguir necesitando al mejor SM del mundo para mejorar :)


 

Alfredo Casado

unread,
Feb 10, 2011, 1:29:43 PM2/10/11
to agile...@googlegroups.com
Corolario: El mejor equipo del mundo... Puede seguir necesitando al mejor SM del mundo para mejorar :)

Pues no lo veo, por ejemplo:

Si ponemos a alguien a ayudar al equipo con las practicas técnicas (tdd, ci, propiedad colectiva, buenas practicas...) cuando el equipo interioriza estas prácticas (lo que conlleva interiorizar el aprendizaje continuo) estaremos de acuerdo en que esa persona ya no es necesaria en ese equipo ¿no?.

Si ponemos a alguien a ayudar al equipo con scrum, los principios, las reuniones etc,etc. Cuando el equipo interioriza esto esa persona dejaría de ser necesaria ¿no?

Aunque en realidad, si tuviera que definir un equipo maduro no lo haría solo por la calidad de sus practicas, más bien la madurez esta en cosas como la responsabilidad, la transparencia y la auto-exigencia. Si ponemos a alguien a ayudar al equipo a conseguir estos valores, cuando el equipo los interiorize esta persona dejaría de ser necesaria ¿no?

El mejor equipo del mundo es seguro que cumplirá con los 3 puntos anteriores (y algunos más), ¿entonces en que ayuda el SM?

Otra cosa es la figura de un coach, que pueda puntualmente acercarse a un equipo y sacarles de un atasco, o ayudarles a ver con la frescura de tener una perspectiva externa al equipo cosas que ellos no están viendo con claridad. Pero es muy distinto un coach que aporte ayuda puntual a una persona en plantilla y formando parte de un equipo para cumplir con un rol que el equipo ya tiene más que interiorizado.

Harald Messemer

unread,
Feb 10, 2011, 2:15:06 PM2/10/11
to agile...@googlegroups.com
Siendo del bando de Alfredo y sin dogmas, a ver si lo visualiza:

-tengo el mejor equipo del mundo trabajando 8 horas / dia y todos agiles
-anado un agile coach las mismas 8 horas / dia exclusivamente haciendo
coaching en Agile 3.0
-el mejor equipo sera mejor y suficientemente mas productivo para
compensar el Agile Coach

Es eso?

2011/2/10, Alfredo Casado <casado....@gmail.com>:
> *Corolario: El mejor equipo del mundo... Puede seguir necesitando al mejor
> SM del mundo para mejorar :)*
> *
> *

--
Gesendet von meinem Mobilgerät

Juan Carlos Quijano Abad

unread,
Feb 10, 2011, 2:15:18 PM2/10/11
to agile...@googlegroups.com
Buenas,
 
Incluso en el hipotético caso de que el equipo sepa hacer scrum sin necesidad del rol del sm, lo que no va a cambiar es la necesidad de un rol que mitigue y/o haga desaparecer los impedimentos. Que es el motivo principal de la existencia del rol.
 
Vamos, que no veo en qué punto deja de ser imprescindible un SM en un equipo Scrum.
 
También pienso que equipo no significa que todos hagan de todo. Pienso que nuestro trabajo requiere especialización y que un "informático" debe dejar de valer para todo. Y no quisiera que el programador de mi equipo dedique su tiempo a arreglar cosas de sistemas, o que el diseñador gráfico se ponga a tirar lineas de código, o el SM pinte pantallas. Equipo es un conjunto de especialistas, que sumando sus capacidades trascienden a la suma de su trabajo. No creo que valga el concepto de "comuna" en donde todos hacen de todo porque al final nadie hace nada bien o excelente.
 
La otra opción es pensar que el trabajo del SM es tan sencillo que cualquier persona, sin cualificación, experiencia o talento, es capaz de realizarlo en su tiempo libre... lo cual es un error. Es tan pretencioso como pensar que cualquier persona se puede poner a programar por su cara bonita :)

Alfredo Casado

unread,
Feb 10, 2011, 2:43:02 PM2/10/11
to agile...@googlegroups.com
Harald:

el mejor equipo sera mejor y suficientemente mas productivo para compensar el Agile Coach

jeje, y entonces llegará el punto en el equipo interiorize el 3.0 y ese coach será otra vez innecesario y necesitaremos al mega-coach 4.0 ¿no?

Entonces estamos hablando de que el SM es necesario para que el equipo este en un estado de evolución permanente, que es como debería estar, lo que yo quiero decir es que si los propios miembros de equipo tienen asumidos valores como responsabilidad y auto-exigencia, forman parte de las comunidades sobre agilismo y están al día de esto y aquello, ellos mismos son más que capaces de mantener ese aprendizaje continuo. Esto no quita para que recibir ayuda puntual pueda estar bien, pero no necesitas un miembro del equipo cuya única labor sea buscar la mejora continua porque esa labor ya la realizan todos y cada uno de los miembros de tu equipo. 

Harald Messemer

unread,
Feb 10, 2011, 2:44:45 PM2/10/11
to agile...@googlegroups.com
Creo que ya hay consenso sobre la necesidad y utilidad de tener el rol
de SM en un equipo cuando sea necesario.

La cuestion, asi por lo menos entiendo la discusion, es que este rol
tiene que estar asumido necesariamente por una persona a tiempo
completo durante la permanencia del equipo o puede si alguien puede
asumir el rol en cuando se necesite (sea siempre la misma persona del
equipo, cualquier persona del equipo o alguien externo).

Yo pienso que llega el momento donde el incremento de productividad no
paga la estancia de un SM o AC a tiempo completo y que en este caso es
preferible, perder este incremento en productividad y ahorrarse la
pasta.

Un saludo,
Harald

2011/2/10, Juan Carlos Quijano Abad <juancarl...@gmail.com>:
> Buenas,
>


> Incluso en el hipotético caso de que el equipo sepa hacer scrum sin
> necesidad del rol del sm, lo que no va a cambiar es la necesidad de un
> rol que mitigue y/o haga desaparecer los impedimentos. Que es el motivo
> principal de la existencia del rol.
>
> Vamos, que no veo en qué punto deja de ser imprescindible un SM en un equipo
> Scrum.
>
> También pienso que equipo no significa que todos hagan de todo. Pienso que
> nuestro trabajo requiere especialización y que un "informático" debe dejar
> de valer para todo. Y no quisiera que el programador de mi equipo dedique su
> tiempo a arreglar cosas de sistemas, o que el diseñador gráfico se ponga a
> tirar lineas de código, o el SM pinte pantallas. Equipo es un conjunto de
> especialistas, que sumando sus capacidades trascienden a la suma de su
> trabajo. No creo que valga el concepto de "comuna" en donde todos hacen de
> todo porque al final nadie hace nada bien o excelente.
>
> La otra opción es pensar que el trabajo del SM es tan sencillo que cualquier
> persona, sin cualificación, experiencia o talento, es capaz de realizarlo en
> su tiempo libre... lo cual es un error. Es tan pretencioso como pensar que
> cualquier persona se puede poner a programar por su cara bonita :)
>
> --
> Un saludo
> Juan Quijano
>

> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> 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 10 de febrero de 2011 19:29, Alfredo Casado
> <casado....@gmail.com>escribió:
>

>> *Corolario: El mejor equipo del mundo... Puede seguir necesitando al mejor
>> SM del mundo para mejorar :)*
>> *
>> *

--
Gesendet von meinem Mobilgerät

Juan Carlos Quijano Abad

unread,
Feb 10, 2011, 3:08:15 PM2/10/11
to agile...@googlegroups.com

Buenas,

"Yo pienso que llega el momento donde el incremento de productividad no
paga la estancia de un SM o AC a tiempo completo y que en este caso es
preferible, perder este incremento en productividad y ahorrarse la
pasta."

Que gracia, es el mismo argumento con que me tengo que enfrentar muchas veces pero tratandose de programadores. Prefieren ahorrarse la pasta y contratar a un junior. Totál, el trabajo sale igual :(

--
Un saludo
Juan Quijano
 

Harald Messemer

unread,
Feb 10, 2011, 3:19:59 PM2/10/11
to agile...@googlegroups.com
Hola Juan Carlos,

Creo que no es el mismo argumento. Si tu fichas una persona para 10€
en vez de fichar alguien para 5€, este fichaje te sale a cuenta si la
persona que has fichado hace el mismo trabajo en menos que la mitad
del tiempo que la otra persona.

Lo que digo yo es que llega el momento que para conseguir 5€ mas en
productividad tienes que invertir 10€ en coaching.

Vamos, son cosas diferentes.

Saludos,
Harald

2011/2/10, Juan Carlos Quijano Abad <juancarl...@gmail.com>:
> Buenas,
>

> "Yo pienso que llega el momento donde el incremento de productividad no
> paga la estancia de un SM o AC a tiempo completo y que en este caso es
> preferible, perder este incremento en productividad y ahorrarse la
> pasta."
>
> Que gracia, es el mismo argumento con que me tengo que enfrentar muchas
> veces pero tratandose de programadores. Prefieren ahorrarse la pasta y
> contratar a un junior. Totál, el trabajo sale igual :(
>
> --
> Un saludo
> Juan Quijano
>

Juan Carlos Quijano Abad

unread,
Feb 10, 2011, 3:44:12 PM2/10/11
to agile...@googlegroups.com
Buenas,
 
Perdón Harald. Yo seguía empecinado con el SM.
 
Te doy la razón pero renqueante. A mi entender en este pais lo que falta es muchisima más inversión en formación. Los títulos y las certificaciones no es que estén muy bien vistas. Y las empresas les cuesta horrores entender que un profesional bien formado es un mucho mejor profesional.
 
Yo soy de los que piensan que la diferencia en productividad para un equipo "normal" entre tener un coach o buscarse la vida en foros o libros, es enorme. La productividad se dispara en valores muy superiores a un 10% y, por lo menos aquí, un coach cuesta "dos duros".
 
Lo dificil es encontrar a alguién de confianza. Y tengo la suerte de, al menos, conocer tres o cuatro por los que poner la mano en el fuego.  
--
Un saludo
Juan Quijano
 

Ángel Medinilla

unread,
Feb 10, 2011, 3:43:46 PM2/10/11
to agile...@googlegroups.com
Si ponemos a alguien a ayudar al equipo con las practicas técnicas (tdd, ci, propiedad colectiva, buenas practicas...) cuando el equipo interioriza estas prácticas (lo que conlleva interiorizar el aprendizaje continuo) estaremos de acuerdo en que esa persona ya no es necesaria en ese equipo ¿no?.

Si ponemos a alguien a ayudar al equipo con scrum, los principios, las reuniones etc,etc. Cuando el equipo interioriza esto esa persona dejaría de ser necesaria ¿no?

¡Oh! ¿Hay un momento en la vida en el que ya no se aprende nada más? Que tremenda decepción, que inmensa tristeza... :(

 

Ángel Medinilla

unread,
Feb 10, 2011, 3:44:48 PM2/10/11
to agile...@googlegroups.com

Que gracia, es el mismo argumento con que me tengo que enfrentar muchas veces pero tratandose de programadores. Prefieren ahorrarse la pasta y contratar a un junior. Totál, el trabajo sale igual :(

Punto, set y partido... XDDD
 

Harald Messemer

unread,
Feb 10, 2011, 4:11:58 PM2/10/11
to agile...@googlegroups.com
Yo pienso tambien que comprar un libro en vez de probar o fotocopiar, contratar un coach para dinamizar, formar bien al personal, ... sale muchas veces a cuenta, si lo calculas friamente. Y para llegar al extremo que realmente no sale a cuenta contratar un coach, tenemos bastante por mejorar aún para ocupar a este colectivo durante unos añitos más :-)

Lo que pasa es que muchas veces te encuentras en esta altura de la pelicula con personas que están convencidos que todo se puede arreglar trabajando más horas y no pagar las.

Un saludo,
Harald

jorge

unread,
Feb 10, 2011, 4:13:03 PM2/10/11
to agile...@googlegroups.com
Siento el retraso...

2011/2/10 Alfredo Casado <casado....@gmail.com>

jorge:

dirigir la planificación, la demo, retrospectiva, reunión diaria: En general llevar las reuniones es algo que lo puede hacer cualquiera que sepa como se organizan, y si hablamos de un equipo maduro se lo saben de memoria. Además se da una circunstancia, todos los miembros del equipo están en la reunión, así que esta tarea seguro que la puede asumir cualquiera sin perder tiempo que necesite para otras cosas.

Creo que es bueno que el equipo decida quién hace las cosas con cierta periodicidad. Si está tan maduro como dices, yo al menos no lo dejaría al azar, que sea alguien en concreto el que prepare las reuniones, reserve las salas...
 

objetivos del sprint: Esto es cosa del PO.

Claro, el dueño del backlog... pero el SM facilita, coordina la reunión.
 

ayudar al po a organizar el backlog: El PO es parte del equipo, y hemos supuesto equipo maduro, esto logicamente incluye al PO. No necesita ayuda de un SM para definir historias porque tu PO es el mayor experto en definir historias que tienes, es como si me dijeras que el SM tiene que ayudar al equipo a hacer TDD. Al principio puede, pero luego caminan solos y de eso se trata, no pensemos que esto no afecta también al PO.

Solución muy concreta. Yo no veo el PO como parte del equipo de desarrollo y sí como parte del equipo del proyecto. En mi opinión, puede ser el equipo el que lleve esa parte de definición de historias ayudando al PO a no tener que encorsetarse en US, UC, F o lo que sea y que nos cuente de qué se trata. Nosotros, el equipo de desarrolladores, le podemos enseñar el trabajo, si quiere colaborar en ese camino mejor, pero vamos, que me parece accesorio.
 

servir de barrera ante interrupciones: Lo de antes, si tu organización es madura no hay que estar de barrera mucho rato, tener una persona sólo para esto no te parece un poco de waste?. Además ese SM podría estar ayudando a otros equipos que quizá estén en una etapa previa de su adopción de agile y le necesiten más. Tener un experto en SCRUM aburrido la mitad del día y la otra mitad haciendo cosillas como avisar a los del aire o pedir a sistemas que monten no se que, me parece un desperdicio importante la verdad.

Yo no he hablado de tener una persona sólo haciendo esto... ;) puede hacer esto y desarrollo, por ejemplo. Aunque seguro que en algún lado están pintando paredes o comprando bollos.
 

El 10 de febrero de 2011 17:43, Harald Messemer <harr...@gmail.com> escribió:

aunque no creo que ese sea al afán, pero ma la impresión que estas enumeraciones al final nos llevan a delimitar las tareas técnicas (o de programación) de las tareas no técnicas y concentrarlas en el SM.

El SM, para mí, es un rol de gestión. Si lo combinas con XP o con líder técnico o lo que quieras tú es otro cantar... que me parece bien, pero ponle apellido a SM.
 

De algún modo me parece bastante parecido a un modelo no Agile con silos de conocimiento, poca polivalencia en el equipo y con nadie conociendo todo el proceso.

Esto me parece una extrapolación poco acertada y me parece un caso concreto... extremo aunque puede ser habitual. Lo que quiero decir es que sacas conclusiones particulares de una generalización. Personalmente, he cuestionado que sea una sola persona aunque me parece un acierto mantener el foco: unos desarrollan y otro, además, hace de SM. No creo que nadie esté de acuerdo con los silos de conocimiento ;)
 

En mi opinión es fundamental que todo el equipo conozca el proceso de trabaja y cuales son las diferentes funciones.[...]

En cualquier contexto lo es, creo.
 

Por el mismo argumento estoy en contra de mantener de forma perpetua un SM en el equipo para que haga estas tareas.

Como se ha dicho, no conozco el caso de equipos sin capitán (cualquiera puede elegir campo o sacar, no?) ni sin entrenador... Sí con entrenador-jugador... Qué bueno es el fútbol para poner ejemplos!!! viva el fútbol!
 

jorge

unread,
Feb 10, 2011, 4:17:13 PM2/10/11
to agile...@googlegroups.com
oooooooooooh!!!

Me he permitido la licencia de poner enter paréntesis la coletilla pero vamos... frase para el recuerdo ;)

+1

2011/2/10 Harald Messemer <harr...@gmail.com>
[...]
 
Lo que pasa es que muchas veces te encuentras en esta altura de la pelicula con personas que están convencidos que todo se puede arreglar trabajando más horas( y no pagarlas.)

David Palomar

unread,
Feb 10, 2011, 5:46:09 PM2/10/11
to agile-spain
> Entonces el Product Owner igual, ¿no? Es un rol y lo puede hacer cualquiera
> del equipo..

No sé, nunca he sabido sumar peras y manzanas

On 10 feb, 18:34, Ángel Medinilla <angel.medini...@gmail.com> wrote:
> 2011/2/10 David Palomar <dpalo...@gmail.com>

Alfredo Casado

unread,
Feb 10, 2011, 6:23:28 PM2/10/11
to agile...@googlegroups.com
¡Oh! ¿Hay un momento en la vida en el que ya no se aprende nada más? Que tremenda decepción, que inmensa tristeza... :(

¿ein?, angel si quieres sacar cosas de contexto y poner en boca de otras cosas que no han dicho pues muy bien, pero no si has leido el parrafo entero que has copiado de mi mensaje donde pone explicitamente "interiorizar el aprendizaje continuo", obviamente aplica tanto a las practicas técnicas como al resto de aspectos de desarrollo.

En serio, uno hace el esfuerzo de debatir en esta lista de forma constructiva pero no hay forma, mejor lo dejo y me dedico a cosas más productivas, au revoir.

Gustavo Cebrian Garcia

unread,
Feb 11, 2011, 3:36:37 AM2/11/11
to agile...@googlegroups.com
Hola,
 
Creo que hay que entender a Angel también, y creo que él, sinceramente y sin ánimo de subir emociones, quiere decir, que un Scrum Master siempre es necesario, como lo piensan Mike Cohn, Google, y Yahoo... Lo que pasa es que el se expresa de esa forma tan poética, jeje.
 
Sin más. Claro que el equipo puede aprender mucho, y seguir ellos su ruta, pero la calidad, en mi opinión, siempre se va a notar, pero claro, estas cosas son difíciles de medir, y creo que es lo que quiere transmitir Angel. Es decir, en mi opinión, siempre que un buen buen buen Scrum Master salga, el equipo lo sufrirá, creo yo. Yo entiendo
 
No te enfades Alfredo !!  :-) Yo creo que estamos muchos de acuerdo. En lo que si que discrepamos algunas en en decir que el role ( digamos role, y no persona ) es temporal, y la verdad, es que se por experiencia que no es temporal. Claro, que tenemos que intentar sacar a 7 Scrum masters en el equipo...
 
Saludetes.

2011/2/11 Alfredo Casado <casado....@gmail.com>

Raquel Laina

unread,
Feb 11, 2011, 3:39:49 AM2/11/11
to agile...@googlegroups.com
Creo que deberías abrazar más a menudo vuestro lado femenino...

2011/2/11 Gustavo Cebrian Garcia <g.cebria...@gmail.com>

Gustavo Cebrian Garcia

unread,
Feb 11, 2011, 3:46:43 AM2/11/11
to agile...@googlegroups.com
:-)
 
Quieres decir que tenemos que ser más razonables, comprensivos? Raquel...

2011/2/11 Raquel Laina <rla...@gmail.com>

Raquel Laina

unread,
Feb 11, 2011, 3:47:46 AM2/11/11
to agile...@googlegroups.com
Tal vez... :)

Harald Messemer

unread,
Feb 11, 2011, 4:06:04 AM2/11/11
to agile...@googlegroups.com
Una vez uno de mis jefes (y no era el mejor, mas bien no), me dijo que
"no seas tan susceptible". El contexto era un enfado que al final no
aportaba mas que despistarse del objetivo. En terminos agiles los
enfados me parecen WASTE.

Un saludo,
Harald

2011/2/11, Raquel Laina <rla...@gmail.com>:

>>>> *¡Oh! ¿Hay un momento en la vida en el que ya no se aprende nada más?
>>>>> Que tremenda decepción, que inmensa tristeza... :(*
>>>>> *
>>>>> *

--
Gesendet von meinem Mobilgerät

Juan Carlos Quijano Abad

unread,
Feb 11, 2011, 4:13:48 AM2/11/11
to agile...@googlegroups.com
Buenas,

Viendo que hemos aprendido mucho de este excelente post. Y que poco más queda por decir...

Una vez más, muchas gracias a todos.

A los que tienen un punto de vista diferente al mio porque me hacen estudiar mis argumentos desde el punto de vista de  los suyos.
A los que tienen un punto de vista similar al mio porque refuerzan con sus argumentos mis conclusiones.
Y sobre todo a los que vamos matizando hasta encontrar argumentos y conclusiones mejores que con las que iniciamos el debate.

Los que se van enfadados menospreciando al resto por "cosas mejores que hacer": una tila y te esperamos en el siguiente debate si te viene bien.

Vicenç Garcia

unread,
Feb 11, 2011, 7:41:31 PM2/11/11
to agile...@googlegroups.com
Buenas,

Perdonad si es un poco offtopic, però estaba leyendo una entrevista a
Menotti y me ha venido a la cabeza este hilo.

“Un buen entrenador ayuda un cien por ciento en el crecimiento del
jugador, contribuye a que resuelva más rápido dificultades que sin él
le llevarían más tiempo aprenderlas, por la sola experiencia de sumar
partidos”.
“Es un cuento que el técnico tiene que trabajar sin parar. Lo que
tiene que hacer es trabajar bien. No es cuestión de hablar pavadas:
triple turno, paracaídas, chaleco con pesas, es todo un verso que
impone la moda”.
“Existen dos clases de entrenadores: los que entrenan para entrenar y
los que entrenan para enseñar. Para mí los que valen son los últimos.
Y ese objetivo es en la actualidad de difícil concreción”.

Saludos

On Friday, 11 February 2011, Juan Carlos Quijano Abad


<juancarl...@gmail.com> wrote:
> Buenas,
>
> Viendo que hemos aprendido mucho de este excelente post. Y que poco más queda por decir...
>
> Una vez más, muchas gracias a todos.
>
> A los que tienen un punto de vista diferente al mio porque me hacen estudiar mis argumentos desde el punto de vista de  los suyos.
> A los que tienen un punto de vista similar al mio porque refuerzan con sus argumentos mis conclusiones.
> Y sobre todo a los que vamos matizando hasta encontrar argumentos y conclusiones mejores que con las que iniciamos el debate.
>
> Los que se van enfadados menospreciando al resto por "cosas mejores que hacer": una tila y te esperamos en el siguiente debate si te viene bien.
> --
> Un saludo
> Juan Quijano
>

> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>


> 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/>

> --
> 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.
>

--
Vicenç García
http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

Ángel Medinilla

unread,
Feb 12, 2011, 2:59:22 AM2/12/11
to agile...@googlegroups.com
 
2011/2/12 Vicenç Garcia <vincen...@gmail.com>

Buenas,

Perdonad si es un poco offtopic,

Para nada. Buen texto, pardiez. Otro ejemplo más de que el mejor equipo del mundo se sigue beneficiando de un buen entrenador.
 

jcesarperez

unread,
Feb 12, 2011, 5:40:14 AM2/12/11
to agile-spain
¿Otro ejemplo más? No lo capto.

Si te refieres a Menotti, llevará 2 décadas sin conseguir buenos
resultados como entrenador, no sé siquiera si habrá aguantado todo un
año en el mismo equipo.

Si te refieres a los entrenadores de fútbol, son todo lo contrario a
esa figura que busca volverse prescindible. El entrenador es el Jefe
en su equipo. El mismo equipo con un entrenador puede ser campeón del
mundo y con otro descender de categoría.

Si te refieres a que los equipos de fútbol necesitan de un entrenador
de forma perenne, es rarisimo el entrenador que aguanta más de 2 años
en el mismo equipo. Lo normal es que sus métodos de motivación dejen
de ser efectivos y obtenga malos resultados, cuando no es el propio
equipo el que le hace la cama.

Yo no creo que sea útil hacer comparaciones con el fútbol. De hecho,
la historia más reciente favorece a Alfredo. España, el mejor equipo
del mundo, ha ganado la Eurocopa con un entrenador totalmente distinto
a con quien ha ganado el Mundial. De hecho uno de esos que no se ha
dedicado precisamente a enseñar. Y son muchos, yo incluido, los que
piensan que el Mundial lo habría ganado casi con cualquier entrenador.
Pero esto ya sí que se sale de offtopic. Mis disculpas, pero tenía que
decirlo. Eso sí, el texto de Menotti es muy poético e inspirador. A
César lo que es del César.

Volviendo un poco al tema, ¿por qué nos empeñamos en que tiene que
existir un Scrum Master en cualquier equipo que pretenda ser ágil? Si
Ágil es un camino y no un estado -por cierto, me encanta esa frase-,
¿por qué tengo que recorrer ese camino con zapatillas Scrum, cuando
hay muchos tipos de calzado, muchos incluso sin Marca? ¿Nos estamos
centrando más en cómo recorremos el camino que en el destino?

Saludos,
Julio.

On 12 feb, 08:59, Ángel Medinilla <angel.medini...@gmail.com> wrote:
> 2011/2/12 Vicenç Garcia <vincentred...@gmail.com>

José Manuel Beas

unread,
Feb 13, 2011, 9:54:10 AM2/13/11
to agile...@googlegroups.com
Me gustaría añadir a este hilo un recurso que creo que puede aportar algo. Es una entrevista a Rachel Davies (que como algunos sabéis es co-autora de un libro titulado "Agile Coaching", que estuvo recientemente en Madrid impartiendo un taller titulado "Agile Coaching Skills" y con la que coincidimos en el Agile Coaches Gathering que organizaron Raquel Laina y Enrique Comba). En esta entrevista (en inglés y subtitulada) justamente hay una pregunta que creo que viene muy al hilo de esta cuestión: "¿Hay alguna diferencia entre coach y scrum master?".


Juan Carlos Quijano Abad

unread,
Feb 13, 2011, 4:35:42 PM2/13/11
to agile...@googlegroups.com

Buenas solamente dos cosilas, Julio.

1. Alfredo argumenta que el sm sobra, tarde o temprano. Si no le he entendido mal, es incluso un objetivo y simbolo de madurez el no necesitar SM. Osea, nada que ver con el ejemlo del futbol que, venga de donde venga, el entrenador es parte indispensable del equipo.

2. SM es una figura de Scrum. Creo que nadie se confunde con que para ser Agile debes de hacer Scrum. Por lo cual igualar Agile = Scrum es erroneo. como bien dices y, como creo que nadie más que tú has señalado. Necesitas un SM si vas a hacer Scrum, eso si.

--
Un saludo
Juan Quijano
 
Reply all
Reply to author
Forward
0 new messages