¿Quién es la persona ideal para ser Scrum Master?

[Juanma Gómez]

¡Buenas!

Me gustaría trasladar a la comunidad una pregunta. Imaginad un equipo tradicional, con su Team Leader. Ese equipo comienza a agilizarse y adopta Scrum. El equipo quiere tener un Scrum Master, y hay que elegir entre el team leader, al que no le interesa mucho el tema de Scrum ni el rol de Scrum Master, y un desarrollador del equipo al que sí le motiva emprender esa vía.

¿Qué pros y contras le encontráis a cada caso? ¿Os habéis topado con alguna experiencia así?

[Harald Messemer]

Hola Juanma,

En mi opinión la decisión en el caso que describes es fácil, dado que el Teamleader no está interesado y tienes alguien del equipo que si está interesado. Asignar (o imponer) a alguien una responsabilidad que no le interesa, no te dará ningún resultado positivo y menos al tratarse de provocar un cambio de la manera de trabajar.

Evidentemente si tienes teamleaders que no se identifican con Scrum y equipos que les gusta Scrum y que reportan a estos teamleaders tendrás el problema que tampoco va funcionar, debido a que tu organización no está alineada a este cambio de trabajo.

Si todos los implicados, Teamleaders y Equipo, están convencidos de la necesidad de un cambio y que Scrum es el vehiculo para conseguirlo y la organización esté alineado con ello, entonces se puede pensar quien del equipo, incluyendo Teamleaders, debe ser el Scrum Master.

Mi comparativa de validez de ambos perfiles serían:

• Teamleader
  

+ sabe de gestión de personas

+ sabe de gestión de cliente

+ acostumbrado a trabajar con fechas y recursos limitados

- alejado de la tecnología

- acostumbrado a mandar

- menos detallista

• Desarrollador

+ conoce bien las necesidades de los desarrolladores

+ sabe estimar porque conoce la tecnologia

+ sabe traducir requerimientos en soluciones

- no conoce muy bien la motivación del cliente

- suele no tener experiencia con fechas y recursos limitados

- discurso tecnico opaco para cliente

Lo que dice Cohn sobre User Proxies es aplicable también a este caso.

Espero que haya sido útil.

Un saludo

Harald

2013/3/12 Juanma Gómez <juanma...@gmail.com>

¡Buenas!

Me gustaría trasladar a la comunidad una pregunta. Imaginad un equipo tradicional, con su Team Leader. Ese equipo comienza a agilizarse y adopta Scrum. El equipo quiere tener un Scrum Master, y hay que elegir entre el team leader, al que no le interesa mucho el tema de Scrum ni el rol de Scrum Master, y un desarrollador del equipo al que sí le motiva emprender esa vía.

¿Qué pros y contras le encontráis a cada caso? ¿Os habéis topado con alguna experiencia así?

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/lV8j7pMI4F0J.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Xavier Quesada Allue]

Creo que falta un poco de contexto. Porqué hay que elegir solamente entre estas dos personas? Y todo el resto de la empresa? Yo no pondría a ninguna de las dos personas de SM. El team lead ciertamente no. Y de hecho me preocupa un poco que lo propongas como opcion válida.

Quien está decidiendo hacer Scrum? Quien sponsoriza? Quien decide la asignacion de roles? Falta el contexto de la gerencia.

Saludos,

Xavier

2013/3/12 Juanma Gómez <juanma...@gmail.com>

¡Buenas!

Me gustaría trasladar a la comunidad una pregunta. Imaginad un equipo tradicional, con su Team Leader. Ese equipo comienza a agilizarse y adopta Scrum. El equipo quiere tener un Scrum Master, y hay que elegir entre el team leader, al que no le interesa mucho el tema de Scrum ni el rol de Scrum Master, y un desarrollador del equipo al que sí le motiva emprender esa vía.

¿Qué pros y contras le encontráis a cada caso? ¿Os habéis topado con alguna experiencia así?

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/lV8j7pMI4F0J.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Xavier Quesada Allue
Certified Scrum Coach & Trainer

[Juanma Gómez]

¡Hola!

Efectivamente, falta contexto para dar una respuesta lo más fiel posible al problema. El tema es que me imaginaba a un equipo haciendo una transición hacia Scrum, y en ese sentido, podemos imaginarnos el contexto que queramos. Si queréis, podemos empezar por el más favorable desde el punto de vista de la gerencia: apoya el cambio incondicionalmente. Más adelante podemos introducir alguna restricción nueva.

El tema es que, dentro de ese escenario base, veamos cómo le definimos un contexto y cómo ayudamos al equipo a que gire. En lo que estaba pensando es en el caso de que el SM y el Team Leader sean dos roles mantenidos en el equipo y tomados por personas distintas. No se valora incorporar nuevas personas al equipo. ¿Qué riesgos corremos? ¿Qué ventajas puede tener este modelo? ¿Qué inconvenientes?

Xavier, en cuanto al Team Leader como SM, no termino de entender por qué no lo harías. ¿Qué problemática le ves a esa transición de rol?

--

Juanma Gómez.

http://about.me/juanmagomezr

[Alfredo Casado]

"hay que elegir entre el team leader, al que no le interesa mucho el tema de Scrum ni el rol de Scrum Master, y un desarrollador del equipo al que sí le motiva emprender esa vía."

Pues vista esa frase a mi no me falta ningún contexto, al que tenga motivación SIEMPRE.

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.

[Xavier Quesada Allue]

Tener team leaders no es una buena idea en equipos ágiles. Probablemente el Team Lead fue apuntado desde afuera del equipo y no designado internamente. Se está interfiriendo con la autogestión del equipo. Esto ya es malo de por si. Ponerlo de ScrumMaster es doblemente malo, primero porque hay conflicto de interes (probablemente siga considerandose miembro del equipo, duplicacion de roles) segundo porque tiene autoridad sobre el equipo (poco recomendable para un SM especialmente si no tiene mucha experiencia gerencial y una mentalidad de lider servil). Si a todo esto agregamos que la persona en cuestión no está demasiado interesada en Scrum ni motivada para ser un SM, ponerlo de SM pareciera ser una pésima idea.

Si la gerencia apoya incondicionalmente, yo pondría a una persona externa al equipo de ScrumMaster y le quitaría autoridad al Team Lead pidiendole que se enfoque exclusivamente en liderazgo técnico (senior developer del equipo), y si no hay presupuesto para una persona adicional, sacaría a alguien del equipo para equilibrar el presupuesto. Probablemente lo que recomendaría es una rotacion de personas, o sea que el miembro de equipo vaya a ser SM de otro equipo y vice versa.

Saludos,

Xavier

2013/3/12 Juanma Gómez <juanma...@gmail.com>

¡Hola!

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Marc Florit]

Comparto el principio de Alberto, la persona motivada antes que otra que no lo esté, o peor, que no crea en el cambio que se está planteando.

Además, en el caso del rol de SM tambien deberia exigirse conocimiento y experiencia trabajando con Scrum.

Os comento una alternativa que puse en práctica el otro dia con SM no experimientados, por si os sirve:

En un equipo Junior (en lo ágil, no en lo tecnológico) al que estoy guiando/acompañando propuse el Rol de SM rotativo (1 persona diferente cada Sprint). Reconozco que dicha práctica puede generar algo de ruido/waste en el sistema pero os aseguro que acelera la curva J una barbaridad y, en caso de duda o caos, yo estoy para reorientar el proceso.

Salut,

Marc Florit

cramt...@gmail.com

El 12/03/2013, a les 11:19, Alfredo Casado <casado....@gmail.com> va escriure:

[Juan Quijano]

Estoy totalmente de acuerdo con Harald, Alfredo y Cramtirolf. 

Creo que la solución es que pongas al que tenga ganas y esté motivado. Porque la propia motivación y la responsabilidad le llevará a ser mejor en cada sprint y, muy posiblemente (soy un optimista) sera mucho mejor profesional en poco tiempo.

Pero ten cuidado con los egos del Team Leader, que el Ego de los desarrolladores es tan grande como delicado. Y pudieras tener un problema en el equipo por la más que posible "cerrazon" del lider que se va a sentir menos leader. 

Otra cosa que tendraá que manejar el Scrum Master.

[Ismael Hernández]

Que hay Juanma,

Primero te recomendaría que lo hablaras personalmente con el Team Leader, le comentaras tus planes, y le dieras oportunidad de aportar, al fin y al cabo por algún motivo en su día,

le podrían como TL.

Quizas ese TL no sea un "enemigo de Scrum" y aunque lo fuera tampoco habría que excluirlo de la noche a la mañana sin digamos la oportunidad de un juicio justo,

 a lo mejor él tiene problemas particulares con la implementación de Scrum de la empresa y no con Scrum en si mismo, o cualquier otro tipo de problema.

También sería bueno demostrarle que Scrum funciona, probandolo durante algunos meses, con el involucrado.

En cualquier caso la elección del SM, debería ser a mi ver más democrática en lo que al grupo se refiere, incluso probaría SM rotativos por semanas o por sprint, para que cuando se eliga,

se eliga con conocimiento de cual es la manera de trabajar de cada uno.

También esta el caso, de que la motivación es una opinión subjetiva que tu tienes, quizás haya gente más motivada que no se da a conocer, y aun con esto, la motivación aunque es

imprescindible, son necesarias más cosas, conocimiento, compromiso, don de gentes, ser una persona justa....etc..

Esta claro que en como se trata un tema así, esta la futura o no futura salida del TL , pero no por ego, característica que tienen programadores , TL, 

y cualquier persona con un poco de amor propio, sino porque a nadie le suele gustar bajar de responsabilidad.

Apoyándote en la gerencia lo tendrías muy sencillo para hacer lo que se quiera,  pero no creo que ese sea el enfoque Scrum.

[Joserra Díaz]

Hola!

 ¿cuando hablais de Team Leader os referís a un manager/jefe? ¿alguien que tiene "poder" jerárquico asignado en la organización? Si es así, presiento que la situación de ese equipo va a ser muy muy incómoda :\

 Si el jefe del equipo, no cree en la autoorganización del equipo, básicamente no les va a dejar hacerlo. Y obviamente no va a querer ser ScM, y mucha peor solución es que se convierta en P.O.!! :( Hay otra opción, y es la de que el Team Leader "desaparezca", y ofrezca/cree un espacio de confianza al equipo, lo malo es si se necesita esa persona por sus conocimientos para el equipo de desarrollo.

 Para mi la transición más natural en estos casos es que la del Team Leader se convierta en ScM. Basta con que se crea un par de premisas ágiles, la igualdad equipo=producto, y que trabaje para el equipo (y no el equipo para él) con la famosa figura del lider sirviente. Ahí es nada. ^_^

 Saludos!

2013/3/12 Juan Quijano <juancarl...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/wfQhdI-rsu8J.

[Adrian Perreau de Pinninck]

Mi granito de arena.

A medio plazo puede ser interesante meter al motivado a hacer de Scrum Master.
Al principio, mientras el equipo está aprendiendo a seguir las reglas me parece muy arriesgado.

En la empresa en que trabajo el equipo piloto ahora está en la situación que describís.
No obstante me pasé un primer sprint observándolos, después tres sprints haciendo de SM full time.
Sólo después dejé que el más motivado (que no es el dev lead ni el PO) empezara a llevar las reuniones.
Aún y así sigo estando presente en las reuniones a modo de observador.

Es demasiado peligroso tener a un inexperto motivado sin supervisión haciendo un trabajo dificil.

2013/3/12 Juan Quijano <juancarl...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/wfQhdI-rsu8J.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--

Adrián Perreau de Pinninck Bas, Ph.D

LinkedIn - Blog - Twitter

[Raul Plaza]

Buenas Juanma,

Partiendo de que es un escenario complicado, intentaría ver el por qué esta persona es TL y el por qué no quiere ser SM, probablemente con un poco de formacion y alguna indicación oportuna se le puda hacer ver que hay otras formas de hacer las cosas. Si esto no funciona, la gerencia apoya con tanta fuerza el cambio y la empresa quiere ser de verdad ágil, podrías proponer un cambio de TL entre equipos, de forma que cada uno ejerciera de SM en otro equipo, así posiblemente se sentiría fuera de su zona de confort y probablemente empezaría a valorar otra forma de trabajar.

Si nada de esto es posible, puedes intentar hacer un rol rotativo como comentaban en emails anteriores o preguntar a la persona más motivada si quiere ocupar este rol, pero ahi estoy de acuerdo en que probablemente haya problemas con el ego del TL y/o de algun desarrollador.

Como último recurso a lo mejor deberias de plantearte tú ejercer de SM temporal (siempre que puedas), para mostrar como debe de funcionar esta persona, muchas veces no se quiere ocupar este rol por el desconocimiento de las responsabilidades que implica. A lo mejor asi puedes hacer que crezca la motivacion.

Bueno espero haberte ayudado.

Un abrazo

2013/3/12 Adrian Perreau de Pinninck <aper...@gmail.com>

--
<---------------------------------------------->
<                                              >
<         Raúl Plaza Rodríguez      >
<                                              >
<---------------------------------------------->

[Harald Messemer]

Hola Juanma,

Me imagino que vuestros Teamleaders no son malvados y vuestros desarrolladores no todos se llaman Spolsky. En este sentido antes de hablar de Scrum o de otros metodos concretos, propondría una reflexión colectiva para identificar las necesidades de cada uno y los problemas que cada uno identifica. Una herramienta para hacer ello podría ser un DAFO.

Verás que habrá puntos en común. A partir de allí podriais trabajar en definir unos objetivos comunes para los cuales se podrían identificar unas acciones para conseguirlos. Seguramente saldrá algún tema que con Scrum se puede atacar.

Ten en cuenta que mucho gente ya ha visto ir y venir muchos metodos y muchas herramientas sin dejar impacto ninguno y puede estar un poco quemado de tanta "bala de plata". Ya sabemos que no hay balas de plata y si asocias acciones concretas a objetivos concretos puedes vislumbrar un camino y empezar a caminar.

Un saludo,

Harald

otro

2013/3/12 Raul Plaza <raul....@gmail.com>

[Juanma Gómez]

Hola a todos!

Me está encantando el interés que despierta esta conversación. En nuestro caso, como Raúl sabe, estamos experimentando con las distintas alternativas que se han planteado en este hilo. Cada una de las formas, efectivamente, ha presentado resultados distintos, con sus cosas muy buenas en todos los casos. 

Me interesaba mucho conocer experiencias distintas y reales de implementaciones o transformaciones que habéis vivido para que podamos, entre todos, nutrirnos de estas experiencias y no reinventar la rueda.

La verdad es que soy del clan de la motivación, pero la realidad es que en ocasiones entra en conflicto esa solución. 

Alguien más ha apostado por la persona más motivada?

Un abrazo!

--

[david]

Hay bastante escrito sobre este tema (como ya han comentado, hay un
cap�tulo buen�simo sobre este asunto en Succeding with Agile de Cohn),
porque yo creo que es un lugar com�n en las transiciones hacia el
agilismo (o suced�neos). Mi humilde opini�n es que debe hacer de SM
aquel que crea realmente en scum, el resto me parece anecd�tico. Ahora,
encontrar a alguien que crea realmente en Scrum (casi rozando el
fanatismo) no es tan f�cil.

Saludos.
David.

On 12/03/13 10:44, Juanma G�mez wrote:
> �Buenas!
>
> Me gustar�a trasladar a la comunidad una pregunta. Imaginad un equipo

> tradicional, con su Team Leader. Ese equipo comienza a agilizarse y
> adopta Scrum. El equipo quiere tener un Scrum Master, y hay que elegir
> entre el team leader, al que no le interesa mucho el tema de Scrum ni

> el rol de Scrum Master, y un desarrollador del equipo al que s� le
> motiva emprender esa v�a.
>
> �Qu� pros y contras le encontr�is a cada caso? �Os hab�is topado con
> alguna experiencia as�?
> --
> Has recibido este mensaje porque est�s suscrito al grupo "agile-spain"
> de Grupos de Google.
> Para anular la suscripci�n a este grupo y dejar de recibir sus correos
> electr�nicos, env�a un correo electr�nico a
> agile-spain...@googlegroups.com.
> Para publicar una entrada en este grupo, env�a un correo electr�nico a

> agile...@googlegroups.com.
> Para ver este debate en la Web, visita

> https://groups.google.com/d/msg/agile-spain/-/lV8j7pMI4F0J.
> Para obtener m�s opciones, visita
> https://groups.google.com/groups/opt_out.
>
>

[Juanma Gómez]

Hola David.

Lo primero, gracias por tu opinión. Lo que más me interesa, tal y como he comentado, es la experiencia de todos vosotros aplicando Scrum en los equipos. Las opiniones expresadas están geniales, la verdad, pero ando buscando otra cosa, experiencias reales. Nosotros llevamos implantando Scrum 2 años, y tenemos un buen nivel de madurez, aun sabiendo que el camino que nos queda por delante es muy largo. Desde hace tiempo tenemos SM en los equipos, pero no son SM dedicados, sino Developer/SM. Evidentemente, nadie nace sabiendo, y estamos todos en ese proceso de aprendizaje. 

Evidentemente, si nuestra única finalidad es mejorar nuestro proceso de desarrollo, contar con SM's con experiencia es esencial desde el principio, pero nuestro horizonte es más amplio, y apostamos por formar nosotros mismos a nuestra gente en ese sentido. Por ahora, lo que conseguimos es implicar, cada vez, a más personas, porque tienen la oportunidad de entender qué hay detrás de todo esto. Y, como todos sabemos, por mucho que nos digan A, hasta que no vivimos A no entendemos toda su complejidad. Y digo esto sin entrar ya en la motivación de los equipos, sabiendo que hay oportunidades así para aprender nuevas disciplinas. 

Con lo que no estoy de acuerdo es con el tópico de los egos de los desarrolladores (todos tenemos nuestro ego), pero ese es otro tema. 

¡Buen miércoles!

[Enrique Amodeo]

Seguramente ya se ha dicho en otro correo, pero merece la pena hacer énfasis en lo siguiente:

* Si el equipo está maduro, y trabaja en una organización agil desde hace tiempo, el SM puede ser cualquiera del equipo que tenga motivación para ello. Es probable que sólo necesita una dedicación parcial.

* Si el equipo está empezando en esto, o vive dentro de una organización no ágil, el SM debe ser un experto en agilismo de la ostia, dedicarse a esto al 100%, y debe tener la autoridad suficiente como para convencer al "management" o imponer sus decisiones. Normalmente suele ser un consultor externo. Adicionalmente se puede nombrar a alguien interno que tenga ganas como aprendiz de SM.

Antes de empezar, que el equipo y las personas claves en el "management", tomen al menos un curso de SCM. Yo no creo en el agilismo de guerrilla, o todo el departamento es ágil o la cosa no va a funcionar.

Salud !

2013/3/13 Juanma Gómez <juanma...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/lnj72Dw9wEUJ.

[Xavier Quesada Allue]

Gente, les puedo hacer una pregunta slightly off-topic?  Porqué todo el mundo pone el acrónimo "SCM" para referirse al CSM? En todo caso no debería ser SMC si lo traducimos?

Volviendo on-topic. Un tema que no se está mencionando mucho en este thread es que no todo el mundo entiende lo mismo del rol de ScrumMaster. Hay diferentes puntos de vista y por supuesto está la definición oficial de Scrum.org y la Scrum Alliance (que están alineadas) que no siempre se respeta en la práctica (la pueden encontrar en el Agile Atlas o en la Scrum Guide).

Justo Johanna Rothman acaba de publicar un artículo en InfoQ que habla de esto, miren que casualidad: (en ingles)

http://www.infoq.com/articles/what-scrum-master-are-you-hiring

Saludos,

Xavier

2013/3/13 Enrique Amodeo <eamode...@gmail.com>

[david]

Hola
Las experiencias en mi caso han sido variopintas y, como se dec�a
en otro hilo, depende mucho del contexto, pero sigo convencido de que
independientemente del contexto es una cuesti�n de creer o no creer, de
que le quite o no el sue�o. S�lo as�, ser� disciplinado/a con las
stand-up, querr� tener un panel sincero, vamos... la check-list que
tambi�n estaba circulando por otro hilo.

A mi me duele cuando scrum no sale, y me tiene preocupado, y busco
y leo porque creo en que scrum funciona, y sin embargo he visto a otros
que cumpl�an con las tres preguntas de las dailys como quien ficha al
entrar a la oficina. Es una cuesti�n de creer, de pasi�n, y por tanto de
echar horas leyendo, preguntando, probando cosas, d�ndole vueltas a
porqu� pasa el tiempo y no cierras historias y eso te quita el sue�o.
Que antes hayas sido una cosa un otra, te dar� unas cualidades u otras,
pero en mi opini�n Scrum Master es un rol nuevo y lo hace bien el que lo
toma con pasi�n (pero de la que duele, pero genera endorfinas cuando
sale bien), como el que empez� su carrera como programador y se lo tom�
en serio y no como un "picateclas" (como dir�a Sebastian Hermida).

Yo creo que en la transici�n eso es lo que hay que buscar. Si no
encuentras a nadie, al menos alguien en quien puedas sembrar y que veas
que se lo toma en serio.

Saludos
David

[Daniel Ceillan]

Hola!

Muy buenos todos los puntos de vista, y muy válidos. 

El 12 de marzo de 2013 19:42, Adrian Perreau de Pinninck <aper...@gmail.com> escribió:

Mi granito de arena.

A medio plazo puede ser interesante meter al motivado a hacer de Scrum Master.
Al principio, mientras el equipo está aprendiendo a seguir las reglas me parece muy arriesgado.

En la empresa en que trabajo el equipo piloto ahora está en la situación que describís.
No obstante me pasé un primer sprint observándolos, después tres sprints haciendo de SM full time.
Sólo después dejé que el más motivado (que no es el dev lead ni el PO) empezara a llevar las reuniones.
Aún y así sigo estando presente en las reuniones a modo de observador.

Pero quiero destacar este:

 

Es demasiado peligroso tener a un inexperto motivado sin supervisión haciendo un trabajo dificil.

Tenemos a un jefe excéptico o poco motivado, a un súbdito muy motivado. Y nadie sabe bien de que se trata lo que vamos a hacer. 

Me suena que el mejor plan sería:

1. Contratar un coach externo que ocupe el rol de SM y sea el líder del proceso de "educación"
2. Hacer gestión del cambio durante 3 o 6 meses. 
3. Y una vez que las arquitecturas mentales están afinadas y en sintonía, recién ahi empezar a hablar del éxito que puede traer scrum. 

Antes me parece una semilla intentando germinar en el cemento. 

Un saludo. 

--
Daniel Ceillan

Blog: www.agile-patterns.com