Product Owner: "Hoy me han echado de dailys y retrospectivas"

[David Albert]

Esto es sólo un caso que ma acaba de pasar. No estoy seguro de que sea interesante para la comunidad, pero valoro mucho vuestra opinión, así que ahí va:

(también es un poco 'compartir penas' XD)

Soy Product Manager en una empresa de software, y siempre he estado muy implicado y ligado al equipo de desarrollo.

Desde hace como medio año propuse dar un paso en la dirección Agile y empezar a aplicar algunos principios y hacer un tablero y dailys.

Hace unos meses se nombró un director técnico, que se ha marcado como misión aplicar Scrum, y hacerlo de manera minuciosa. Creo que es un buen camino y está bien ser un poco estrictos con la metodología al menos al principio.

En un curso de Agile, este director técnico/scrummaster aprendió ayer que el Product Owner no tiene que estar en los dailys ni en las retrospectivas, creo que principalmente por el efecto 'Invisible gun'.

Hoy ha enviado un email informando a todos de los cambios.

Es extremadamente estricto, así que hoy cuando he ido al daily... me ha echado. Le he dicho que estaria bien comentar estas decisiones con el equipo, que la comunicación del daily me parece muy positiva, y que incluso estoy realizando tareas 'semi-técnicas' y de test. Pero he terminado volviendo a mi sitio.

Luego he contestado su email expresando mi disconformidad, y adjuntando algunos enlaces que  abren la puerta a la presencia del PO en dailys y retros. Además he resaltado la importancia de tomar las decisiones en equipo y de la importancia de "Individios e interacciones sobre procesos y herramientas". Se ha mantenido firme en su decisión.

No sé cómo acabará esto... pero a mi me parece un caso de gran rigidez alejado de los principios Agile.

Espero no haber sido muy pesado.

Gracias por vuestra atención!

Pdta: Si este no es el lugar para estas cosas, por favor decídmelo!

[Alberto Gomez]

Hola , bajo mi punto de vista, el scrum master esta cometiendo un error, ya que yo lucho cada dia para que el PO venga a los Dailys porque es uno de los puntos donde se pueden desatascar US con dudas que solo el PO puede responder.

Al respecto de las retros, yo entiendo que en alguna retro puntual pueda ser exclusiva del equipo pero en lineas generales puede acudir quien quiera para mejorar.

La transparencia es uno de los valores Agiles mas importantes, yo en todas la liturgias Agile invito a todo el mundo puesto que mientras mas personas esten implicadas en nuestro dia a dia, mayor adeptos , aceptacion , entendimiento y comprension van a tener cuando tengamos problemas en los sprints, etc.

Me da la impresión y siempre desde las lineas que estas comentando, que:

Tenemos un Command Scrum Master donde el Framework de Scrum se esta comiendo los Valores y Principios donde se sutenta y eso es muy peligroso, porque Scrum es solo una base para aplicar otro tipo de conceptos que nada tienen que ver con dividir equipos y generar distancia entre las personas que participan en la elaboracion del producto.

Saludos y sobretodo habla con el Equipo, es el equipo no el Scrum Master quien tiene que tomar ese tipo de decisiones, el Scrum Master vela por que el proceso funcione, pero es el equipo quien debe tomar las decisiones la mayoria de asuntos el Scrum Master solo debe ayudar a conseguirlas dentro del marco de Agile ( Iteraciones, Calidad, Personas, MPV, etc.,,,)

Un Salu2
Alberto

[Leo Antoli]

Hola, 

es difícil dar valoraciones sin estar allí  pero es cierto que suena a "bad smell" y como dice Alberto parece un SM un poco "command&control" que está dejando de lado los valores para enfocarse en las prácticas.  

Seguramente la causa principal sea que es un SM con poca experiencia en ese rol. Las tareas de SM distan mucho de las tareas de un director técnico, de hecho incluso puede ser contraproducente porque se corre el riesgo de que el equipo no se pueda auto-organizar y el SM les "imponga" muchas cosas. 

Scrum es simple pero muy difícil :-)

Parecido al ajedrez, las reglas son muy fáciles de aprender pero es muy difícil jugar bien.

Te recomiendo mejor hablar estas cosas en persona con el SM y no por mail.

Como dice Mike Cohn aquí para retrospectivas y creo que aplica igual a dailys: http://www.mountaingoatsoftware.com/blog/the-product-owner-in-a-sprint-retropsective

"I can't think of a single good reason why a team would want to hold a retrospective without the product owner present. I can think of many bad reasons why they may want to--but each of those should be the topic of a retrospective!"

Lo cual no quiere decir que sea obligatorio que el PO esté en las dailys o retrospectivas, pero si quiere ir se le debe dejar ir, de hecho puede ir quien quiera.

Tú eres de la misma empresa que el SM y los desarrolladores, ¿ verdad ? ¿ o son de un proveedor vuestro ?

Tampoco se si tú tienes una posición de jerarquía sobre el SM y equipo, y el SM piensa que les puedes "intimidar" y que no se sientan libres de hablar.   

Desde luego Scrum no dice que el PO no pueda estar en las dailys, tienes más información por ejemplo aquí:

http://agileatlas.org/atlas/scrum#daily-scrum

Saludos,

Leo

 

[Ignasi Marimon-Clos i Sunyol]

Totalmente de acuerdo con Alberto y con Leo.
Dejad que comparta una experiencia similar (pero distinta, no quiero
hacer comparacaiones!).




Hola, me llamo Ignasi y yo fuí un SM que expulsó al PO de las dailys y
de las retros.

Buf, ya lo he dicho. Tan Control que suena, en realidad tiene una
historia de fondo. Se resume rápido diciendo que más que un PRODUCT
owner, el PO que teníamos era un TASK Owner. Las dailys se alargaban
con constantes 'matices', interrupciones, etc... y en las retros pocos
compartían su opinión por miedo a su réplica.
Yo no tengo mucho idea de Scrum y sigo haciéndolo mal pero echar al PO
de las liturgias marcó una diferencia. Finalmente le dejamos volver a
las dailys pero con la condición de solo escuchar... Wow! Qué
avanzados éramos!




Alberto lo ha resumido:

"... habla con el Equipo, es el equipo no el Scrum Master quien tiene

que tomar ese tipo de decisiones, el Scrum Master vela por que el
proceso funcione, pero es el equipo quien debe tomar las

decisiones..."



Cada situación es distinta porque las personas que la viven son
distintas. David, no sé si hay mar de fondo en vuestro equipo o si
vuestro SM sufre C&C.
Que te 'prohiban' es un síntoma. Sigue buscando. ;-)


Saludos,

> --
> Heu rebut aquest missatge perquè esteu subscrit al grup
> "agile-spain-barcelona" de Google Groups.
> Per anul·lar la subscripció a aquest grup i deixar de rebre els seus
> missatges, envieu un correu electrònic a
> agile-spain-barc...@googlegroups.com.
> Si voleu publicar missatges en aquest grup, envieu un correu electrònic a
> agile-spai...@googlegroups.com.
> Visiteu aquest grup a http://groups.google.com/group/agile-spain-barcelona.
> Per veure més opcions, visiteu https://groups.google.com/d/optout.



--
Ignasi Marimon-Clos
@ignasi35

[Jaume Jornet]

+1 a todo lo dicho. Lo unico que añadiria es 'Take it to the team'. Las retrospectivas, los daily, no son 'propiedad' del SM, sino del equipo. Si ellos consideran que es beneficioso poder tener con ellos al PO, para aclarar dudas, para compartir acciones de mejora, etc adelante. Si creen que (como el caso de Ignasi) puede ser perjudicial, es su decisión y en mi humilde opinión como SM intentaria trabajar con el PO al máximo para que la situación se normalizase lo antes posible. Uno de los valores de Scrum es la transparencia, como bien dice Leo solo se me ocurren malos motivos con raíz en otros problemas para que no se quiera ejercer haciendo todo visible.

Por favor no lo tomes como un consejo, no es bueno darlos sin conocer el contexto, solo mi opinión basada en experiencias previas: en la medida de lo posible no ataques el tema demasiado frontalmente con el director técnico ( por ejemplo no le envies todo lo que se comenta aqui diciendo 'mira lo que opinan en la comunidad') Intenta ponerte en su lugar y comprenderle, pidele que te ayude a hacerlo, seguro que él lo hace pensando que es lo mejor y buscando el beneficio del equipo. Tomaros un cafe, compartir los motivos de ambos y entender y aceptar los argumentos del otro sin juzgarlos o discutirlos. A partir de ahi seguro que podeis construir la mejor solución juntos :)

Gracias!!

Un abrazo,

Jaume

Sent by mobile. Please excuse shortness and typos.

Heu rebut aquest missatge perquè esteu subscrit al grup "agile-spain-barcelona" de Google Grups.

Per anul·lar la subscripció a aquest grup i deixar de rebre els seus missatges, envieu un correu electrònic a agile-spain-barc...@googlegroups.com.

Per publicar a aquest grup, envieu un correu electrònic a agile-spai...@googlegroups.com.

[Alex Muntada]

Hola David,
creo que deberías hablar en persona con el SM para averiguar qué le preocupa del hecho que el PO (o tal vez tu) esté presente.

También sería interesante saber si su apuesta es a largo plazo o sólo por un tiempo para probar lo contrario a lo que hacíais hasta ahora, tal como algunos recomiendan.

Por otro lado, sería interesante saber lo que opina el resto del equipo al respecto. No vaya a ser que el invisible gun lo tenga el SM ;-)

Un saludo y ánimo!
Alex

[David Albert]

GRACIAS!!

Por 2 cosas:

1- Compartir vuestra opinión y experiencia

2- Vuestro apoyo (que no dar la razón) y hacerme sentir la presencia de esta comunidad y así evitar la sensación de aislamiento y de estar 'solo ante el peligro'.

Respondiendo a Leo, sí, somos de la misma empresa. De hecho trabajamos en la misma sala y llevamos mucho tiempo trabajando juntos día a día. No tengo más jerarquía general que el director técnico/SM, y no la tengo sobre equipo de desarrollo. 

Sí que llevo mucho tiempo en la empresa, y además en algunos momentos he hecho 'oficiosamente' funciones de gestión del equipo técnico ante carencias en este sentido y necesidades planteadas por el mismo equipo. Últimamente he hecho un proceso de cierta 'retirada' para centrame en tareas puras de PO, y dejar que el nuevo director técnico haga su trabajo.

Si el equipo decide que es mejor probar un tiempo 'apartándome', lo acepto. Aunque en este caso ha sido una decisión unilateral del director técnico/SM, sin ningún apoyo (ni posibilidad de debate) por parte del equipo.

 

Creo que los motivos del SM son:

- 'invisible gun' (no tengo claro para quien)

- hacer más rápidos y centrados los dailys (aunque uno de sus motivos para echarme es que normalmente no digo nada)

- no perder horas de trabajo (si quito 2 personas del daily, al mes he ganado 2*20dias*0.25h= 10h de trabajo)

Al leer los emails, lo primero que se me ha ocurrido es hacer un reenviar. Pero Jaume me ha "leido la mente" y sugiere abordarlo con más tacto y empatizando. Sería temerario no hacer caso  a su experiencia, así como a la opinión generalizada de hablarlo en persona, tranquila y razonadamente. Así que el lunes será coffe time, a ver si conseguimos acordar un 'take it to the team' :-)

Os mantendré informados.

Perdón por el rollo! 

GRACIAS!!

--

[David Albert]

Bueno, después del "café" de hoy con el Director técnico/SM:

- Hemos acordado que pueda estar en las retrospectivas. Reconoce que había entendido mal.

- Sigue firme en bloquearme en los dailys, sin preguntar al resto del equipo (aunque se lo ha explicado).

 

La base de su razonamiento es que como director técnico tiene la obligación de garantizar que los procedimientos se hagan bien, y ahora (hace poco que hacemos sprints) eso implica ser estricto con lo que dice la scrum guide (https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf). Concretamente esta frase:

"The Scrum Master enforces the rule that only Development Team members participate in the 

Daily Scrum. "

La verdad es que la frase suena bastante clara, aunque hay discusiones abiertas por la red sobre eso.

Defiende que no hay que consultar la opinión del equipo porque ellos ahora de eso no saben, y la 'norma' de la scrum guide está muy clara.

No ha servido de mucho hablar del "take it to the team", de que lo importante es la comunicación y las interacciones concretas de cada equipo, o de que hay alternativas como incluso asistir en silencio.

En fin, esperaremos a la próxima retrospectiva para volver a sacar el tema. Al menos tendré ocasión de hablarlo directamente con el equipo.

Saludos!

Gracias!

[Marc Mauri Alloza]

Siempre se le puede rebatir con un "individuals and interactions over processes and tools" su actitud da en una de las línias de flotación del manifesto àgil.

El dia 24/03/2014 23:34, "David Albert" <sisisi...@gmail.com> va escriure:

[Adrian Perreau de Pinninck]

Creo que el director técnico no ha entendido bien la frase en inglés. Lo cual es razonable ya que la palabra "participate" usada como "participar" puede llevar a error porque en español participar tiene más de una acepción que en inglés no es el caso.

Participate en inglés implica tomar parte activa.

Attend puede ser activa o pasivamente.

Fijate que el Scrum Guide dice: "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum." No attend.

Aunque todo sea dicho, un tipo que quiere ser muy estricto cuando no tiene mucha experiencia va a ser complicado de convencer.

Adrián Perreau de Pinninck Bas, Ph.D

LinkedIn - Blog - Twitter

[David Albert]

Sí. De hecho, el viernes mismo colgué al lado del panel los 4 puntos del manifiesto ágil bien grandes... a ver si van permeabilizando.

También hemos tenido alguna discusión con el punto 4 (respuesta ante el cambio), ya que se niega a cualquier pequeño cambio durante los sprints de lo acordado en el planning meeting.

Espero que nos vayamos ajustando.

[David Albert]

Muy buen punto el del "attend vs participate". Cuando alguien es tan estricto, algun detalle así puede salvar los muebles XD

Gracias!

[Samuel Casanova]

En el Agile Atlas de la ScrumAlliance lo pone bien claro: Actividad Daily Scrum "Only the Scrum Team members, including ScrumMaster and Product Owner, speak during this meeting".
Fuente: http://agileatlas.org/atlas/scrum
Yo a la retro no me llevaría al PO, por eso de que el equipo se pueda cohibir, pero en el daily debería estar.

Per anul·lar la subscripció a aquest grup i deixar de rebre els seus missatges, envieu un correu electrònic a agile-spain-barcelona+unsub...@googlegroups.com.

[Daniel Ceillan]

Hola!

Veo que con tus preguntas has enriquecido mucho la lista, ya que te han dado respuestas muy nutritivas!

Estoy encantado de haber recibido este hilo... y de estar compartiendo este espacio con ustedes...

El 21 de marzo de 2014, 12:12, David Albert <sisisi...@gmail.com> escribió:

Esto es sólo un caso que ma acaba de pasar. No estoy seguro de que sea interesante para la comunidad, pero valoro mucho vuestra opinión, así que ahí va:

(también es un poco 'compartir penas' XD)

Soy Product Manager en una empresa de software, y siempre he estado muy implicado y ligado al equipo de desarrollo.

Desde hace como medio año propuse dar un paso en la dirección Agile y empezar a aplicar algunos principios y hacer un tablero y dailys.

Muy bien!

 

Hace unos meses se nombró un director técnico, que se ha marcado como misión aplicar Scrum, y hacerlo de manera minuciosa.

Primer error a mi juicio, poner de scrum master a alguien que no es scrum master. (no me refiero a la certificacion, sino al mindset)

El rol de scrum master es uno de los pocos en un equipo que no se puede permitir tener a un junior (junior respecto al rol). Paradoja! como voy a tener un senior si nunca transito el camino de junior?

Sencillo, se puede. Tienes que contratar un coach externo que haga de chief-scrum-master y mentoree a los sms. Hasta que se hayan hecho al fuego.

Esa es una opcion, la otra es contratar sms de verdad.

Y el peor perfil para poner de SM es el lider tecnico.

 

Creo que es un buen camino y está bien ser un poco estrictos con la metodología al menos al principio.

Correcto, pero de la mano de un experto.

Se puede experimentar con Agile, totalmente y descubrirlo desde la experimentacion. Siempre y cuando no signifique poner en riesgo el negocio.

 

En un curso de Agile, este director técnico/scrummaster aprendió ayer que el Product Owner no tiene que estar en los dailys ni en las retrospectivas, creo que principalmente por el efecto 'Invisible gun'.

Ahi entramos en un tema interesante. ¿que es resolver los problemas?

Si es un proceso causa-efecto, es inhibir o disimular los efectos? ¿como encontramos la causa raiz?

¿cual es nuestro impedimento, la causa o el efecto?

¿estamos analizando solo efectos?

¿ignoramos que pueden haber causas invisibles o no evidentes, y creemos que los efectos son nuestro verdadero problema?

 

Hoy ha enviado un email informando a todos de los cambios.

 

Es extremadamente estricto, así que hoy cuando he ido al daily... me ha echado. Le he dicho que estaria bien comentar estas decisiones con el equipo, que la comunicación del daily me parece muy positiva, y que incluso estoy realizando tareas 'semi-técnicas' y de test. Pero he terminado volviendo a mi sitio.

Ojo el piojo. Ante esa postura veo dos posibles causas raiz. Puede haber mas, pero ahora imagino 2.

El individuo esta experimentando una sensación de peligro fuerte en caso de cometer pequeños errores.

O esta expresando su ego a través de su rol identificando su persona con lo que hace. ("lo que hago tiene que estar perfecto, porque debo ser perfecto")

Cuando la reaccion es emocional, no creo que sea un malentendido... y fijate que nos seguimos enfocando en la regla "invisible guns" y en realidad el problema no es la regla, es la actitud frente a la regla.

Hay algo ahi detras no tan evidente.

 

Luego he contestado su email expresando mi disconformidad, y adjuntando algunos enlaces que  abren la puerta a la presencia del PO en dailys y retros. Además he resaltado la importancia de tomar las decisiones en equipo y de la importancia de "Individios e interacciones sobre procesos y herramientas". Se ha mantenido firme en su decisión.

Pues tanto si es por sensación de peligro, como si es por ego, mostrar links no va a disolver la situación. Hasta quizás la agrave. Si te planteas en una lucha por ver quien tiene la razon, ahi van a perder todos.

Quizás no sea el perfil adecuado, porque un perfil tecnico suele estar apegado a una necesidad de control y exactitud. Y la pérdida del control genera mucha ansiedad y reacciones de este tipo. Y aunque no sea el perfil adecuado, quizás podamos ayudarlo a que se adapte. Pero depende de el, no de ti.

Yo apostaría por la formación, en lugar de leer blogs. No es lo mismo consumir información, que recibir interacción.

Una de las cosas más valiosas de los cursos, es estar frente a los agilistas de alta gama. He tenido la fortuna de poder hacerlo. Con la interacción en persona absorbes cosas, posturas, actitudes, inquietudes, que no son información.

Porque tanto scrum como el agilismo no es algo para saber, sino para entender y comprender.

Como tampoco se puede aprender a andar en bicicleta leyendo libros.

 

No sé cómo acabará esto... pero a mi me parece un caso de gran rigidez alejado de los principios Agile.

¿Agile es ser flexible?

¿Agile es ser rigido?

:)

 

Espero no haber sido muy pesado.

Yo espero lo mismo.

Abrazo!

 

Gracias por vuestra atención!

Pdta: Si este no es el lugar para estas cosas, por favor decídmelo!

--
Heu rebut aquest missatge perquè esteu subscrit al grup "agile-spain-barcelona" de Google Groups.

Per anul·lar la subscripció a aquest grup i deixar de rebre els seus missatges, envieu un correu electrònic a agile-spain-barc...@googlegroups.com.

Si voleu publicar missatges en aquest grup, envieu un correu electrònic a agile-spai...@googlegroups.com.
Visiteu aquest grup a http://groups.google.com/group/agile-spain-barcelona.
Per veure més opcions, visiteu https://groups.google.com/d/optout.

--
Daniel Ceillan

Blog: www.agile-patterns.com

[David Albert]

Gracias Daniel, y gracias a todos los que están respondiendo. La verdad es que no esperaba ni de lejos tantas respuestas. Espectacular como se mueve esta comunidad!!

Muy interesante la idea de procurar contar con un experto SM (asesor externo o en plantilla). Mirando en perspectiva, estar 'tutorizados' en este proceso habría sido un gran acierto.

En general, hoy en día es necesario buscar asociaciones con personas/empresas que dominen lo que a nosotros nos falta, y asegurar la transición a una manera de trabajar Agile me parece un movimiento estratégico muy lógico.

Sobre el caso en concreto, el SM se está formando en estos momentos. Espero que entre esto y el diálogo con el equipo podamos no perder de vista el manifiesto ágil... aunque la idea de echarme de dailys y retros vino del curso que hace... XD

Flexibilidad!

Un abrazo!