Cuantos miembros se necesitan para SCRUM???

[jagutierrezm]

Saludos, en la empresa donde trabajo tienen la idea que para
implementar SCRUM se necesita un equipo muy grande para poder
implementar SCRUM.
En su experiencia, ¿Cual es la cantidad mínima y la cantidad optima
para implementar SCRUM? Tomando en cuenta que una misma persona puede
cumplir varios roles

[David Roncancio]

Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a ponerse feo el asunto por que a pesar de que alguno de los miembros haga por varios roles no se van a ver los mismos resultados, lo que se aconseja generalmente son equipos de 7+ o - 2 personas, es decir que lo mínimo para que te buenos resultados son 5 personas

Cordialmente, 

David Roncancio
(+57) 3014311354

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

[Juanma Gómez]

Hola!

Me imagino que la pregunta abarca un poco más de amplitud, ya que no sólo cuenta el equipo de desarrollo como tal. Además, en el equipo del que formo parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda cabe que con más gente seguramente podríamos desarrollar técnicas que ahora mismo son muy costosas para nosotros.

Creo que lo mejor que puedes hacer es contratar a un Agile Coach y que valore cuánto fácil o difícil va a ser implementar métodos ágiles en tu empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, todo lo que podamos decir por aquí va a carecer de sentido...

Juanma Gómez.

[jorge baez]

un equipo entre una y dos pizzas ;)

[Antonio de la Torre]

Hola:

Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y
7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones,
scrum diario, etc.
Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros

Según mi opinión, siempre compensa :-)

Pero si Scrum como marco no se quiere asumir, siempre se pueden poner
en práctica muchas más prácticas ágiles

http://www.extremeprogramming.org/

Saludos

El día 14 de febrero de 2012 16:00, Juanma Gómez
<juanma...@gmail.com> escribió:

[Israel Alcázar]

Hola,

Nosotros hacemos Scrum con un equipo de 2 personas, un product owner y un scrum master / coach y no tenemos mayor problema por ser pocos. No entiendo muy bien que el número de personas afecte a scrum.

Saludos

Enviado desde mi dispositivo móvil

[jorge]

por poder...

ya que abres la caja de los truenos ;) mi opción con dos personas sería continuous development: comunicación diaria, sentados cerca, retrospectiva continua, planificación continua, entrega continua...

scrum con menos de 4 me parece forzadillo y sobraría pizza :)

2012/2/14 Israel Alcázar <israel...@gmail.com>

[Jose Luis Soria]

La versión "oficial" de la última guía de scrum (http://www.scrum.org/
scrumguides/) propone de 3 a 9 personas. Esto sería lo que se llama el
Equipo de Desarrollo o Development Team. Si hablamos del Scrum Team
(Equipo de Desarrollo + Scrum Master + Product Owner), serían entre 4
y 11, según el Scrum Master esté también desarrollando o no. Pero se
deja claro que el número concreto es abierto, y que hagas lo que mejor
te funcione. Como siempre, hay que experimentar un poco sobre todo al
principio, pero intentando que el equipo tenga una composición estable
y que si no hay más remedio de cambiarlo, que no se haga el cambio
durante un Sprint.

En la práctica, por supuesto que hay equipos Scrum funcionando
perfectamente por el mundo con menos de 3 personas (como comenta
Israel), o con más de 9 (aunque esto ya lo veo más difícil). Los
límites recomendados son en base a lo que más frecuentemente se ha
visto que funciona bien, por lo que en principio lo tendrás más fácil
si te mantienes en esos límites. Pero no quiere decir que otros
números no puedan funcionar.

¿Por qué los números? Por las características deseables para un equipo
de desarrollo:

Menos de 3 personas va a ser difícil que formen un equipo
multidisciplinar, que pueda afrontar casi todas las tareas que surjan
durante el proyecto. Y algunas de las prácticas como el Daily Scrum
pierden un poco su sentido. Quizá en un proyecto con un equipo tan
pequeño sería mejor optar por otra cosa que no sea Scrum, o adaptarlo.

Más de 9 personas va a dificultar mucho la comunicación, la marcha de
las distintas reuniones, la resolución de problemas, etc.

Un saludo!!!

On Feb 14, 8:53 pm, jorge <jorge.b...@gmail.com> wrote:
> por poder...
>
> ya que abres la caja de los truenos ;) mi opción con dos personas sería
> continuous development: comunicación diaria, sentados cerca, retrospectiva
> continua, planificación continua, entrega continua...
>
> scrum con menos de 4 me parece forzadillo y sobraría pizza :)
>

> 2012/2/14 Israel Alcázar <israelalca...@gmail.com>

>
>
>
>
>
>
>
> > Hola,
>
> > Nosotros hacemos Scrum con un equipo de 2 personas, un product owner y un
> > scrum master / coach y no tenemos mayor problema por ser pocos. No entiendo
> > muy bien que el número de personas afecte a scrum.
>
> > Saludos
>
> > Enviado desde mi dispositivo móvil

> > El 14/02/2012 17:23, "Antonio de la Torre" <adelatorref...@gmail.com>

> > escribió:
>
> >  Hola:
>
> >> Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y
> >> 7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones,
> >> scrum diario, etc.
> >> Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros
>
> >> Según mi opinión, siempre compensa :-)
>
> >> Pero si Scrum como marco no se quiere asumir, siempre se pueden poner
> >> en práctica muchas más prácticas ágiles
>
> >>http://www.extremeprogramming.org/
>
> >> Saludos
>
> >> El día 14 de febrero de 2012 16:00, Juanma Gómez

> >> <juanmagom...@gmail.com> escribió:

> >> > Hola!
>
> >> > Me imagino que la pregunta abarca un poco más de amplitud, ya que no
> >> sólo
> >> > cuenta el equipo de desarrollo como tal. Además, en el equipo del que
> >> formo
> >> > parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda cabe
> >> que con
> >> > más gente seguramente podríamos desarrollar técnicas que ahora mismo
> >> son muy
> >> > costosas para nosotros.
>
> >> > Creo que lo mejor que puedes hacer es contratar a un Agile Coach y que
> >> > valore cuánto fácil o difícil va a ser implementar métodos ágiles en tu
> >> > empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, todo
> >> lo
> >> > que podamos decir por aquí va a carecer de sentido...
>
> >> > Juanma Gómez.
>
> >> > El 14 de febrero de 2012 15:36, David Roncancio <

> >> david.roncan...@gmail.com>

> >> > escribió:
>
> >> >> Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a
> >> ponerse
> >> >> feo el asunto por que a pesar de que alguno de los miembros haga por
> >> varios
> >> >> roles no se van a ver los mismos resultados, lo que se aconseja
> >> generalmente
> >> >> son equipos de 7+ o - 2 personas, es decir que lo mínimo para que te
> >> buenos
> >> >> resultados son 5 personas
>
> >> >> Cordialmente,
>
> >> >> David Roncancio
> >> >> (+57) 3014311354
>

> >> >> On Tue, Feb 14, 2012 at 9:32 AM, jagutierrezm <jagutierr...@gmail.com>

[Israel Alcázar]

Buena puntualización JL. Nuestro caso es un poco mas complejo realmente ya que trabajamos en remoto y hay una persona que tiene una asignación parcial. Si contamos al PO y los 2 team members me parece mas que razonable la figura de  SM que medie y facilite y evite que el resto de personas pierdan el foco. 

A nosotros nos va bien, al ser pocos todo es mas fluido (las reuniones son mas cortas y la comunicación es mejor) lo que no implica que no haya que mejorar en cada iteración.

Saludos,

Israel Alcázar Rodríguez
israel...@gmail.com
http://www.farmerdev.com

http://www.mavencharts.com
http://www.twitter.com/ialcazar

[Harringer]

Diria que con equipo superior a 9 personas tienes el problema que la ventaja de tener comunicaciones punto-punto con consenso en un equipo mas grande se convierte en una fuente de overhead dado una especie de 2-phase-commit (http://en.m.wikipedia.org/wiki/Two-phase_commit_protocol).

En resumen, resulta en inmanejable por lento y por complicado por los conflictos. Me parece que un Scrum if Scrums dara mejores resultados para equipos mas grandes que 8.

Un saludo,

Harald

[Adrian Perreau de Pinninck]

Hmmm, buena analogía lo del two-phase commit. Yo ahora te voy a poner pegas, cuando el equipo crece quizás sería más interesante una estrategia tipo NoSQL en la que la consistencia cede puestos en el ranking de prioridades y le sobrepasa la velocidad y escalabilidad.

Para poder llegar a equipos de más de 9 tendremos que romper con ciertas presunciones. Aunque no tengo claro cuáles.

2012/2/14 Harringer <harr...@gmail.com>

--

Adrián Perreau de Pinninck Bas, Ph.D

LinkedIn: http://es.linkedin.com/in/eidrien 

Blog: eidrienontech.blogspot.com

Twitter: @eidrien

[Harringer]

Probablemente se puede aflojar el criterio de consenso absoluto y asi reducir la complejidad, pero seguimos siendo personas o entes bastante complejos y probablemente tendras el mismo problema u otro parecido.

Aqui algo de chica de la wiki sobre teams:

http://en.m.wikipedia.org/wiki/Team

Buscaba algo sobre equipos de deporte en grupo, pero no lo encontre. Por el momento, el mas grande que se me ocurrio fue el futbol. 

Alguien sabe que deporte se lleva la palma?

En resumen, creo que partir el equipo en subequipos funciona mejor.

Un saludo,

Harald

[Daniel Ceillan]

Me parece que el requisito irrenunciable para poder aplicar Scrum, es tener la cabeza abierta.

Esto implica entender que el Scrum Master no es un Developer, que el PO no es un PM, que contratar un Agile Coach no es un desperdicio y entender que uno no lo sabe todo y que puede haber gente que tenga una opinion diferente a la propia, y que dicha opinion, puede cambiar radicalmente el crecimiento de nuestra empresa.

Partiendo de esa base... creo que hay una variable que no se ha comentado aqui, y es la complejidad del proyecto.

Un equipo de 3 para hacer paginas web es un golazo, pero para desarrollar algo innovador y desafiante... puede ser complicado. La magia que tiene tener un equipo de 8 o 9 es que la productividad general se multiplica, y los impedimentos se destraban mas facil. Por ende cuando tienes un proyecto de alto riesgo, no puedes encararlo con 3. Imagínate que uno de ellos tiene al hijo enfermo y debera estar en el hospital 3 dias... por 3 dias tendras un "equipo" de 2... y que a alguno no se le enferme el canario... chau equipo...

Me diras... "ah no! yo le obligo al equipo comprometerse con el proyecto, y en ese caso les obligaria a estar en la empresa"...

Te dire... todavia no has entendido que es el agilismo y si lees el manifiesto, dice claramente "valoramos mas a los individuos, las personas, por sobre los procesos y las herramientas"

Cada proyecto, cliente, equipo, persona... es un mundo aparte. Y por eso es una muy buena idea, tener algun profesional que te ayude a "tunear" tu agilismo, al lado tuyo y viendo tus procesos.

Scrum en particular requiere mucha disciplina, es bueno ir de a poco. Implementado poco a poco aquellas prácticas que nos ayudan a ser mejores... requiere paciencia y alguien con experiencia puede ayudar mucho.

No intentes ser perfecto siempre y desde cero, el camino a la perfeccion es una asintota irrenunciable, seductora y esencial.

Saludos!

--
Daniel Ceillan

Blog: www.agile-patterns.com

[Marc Florit]

Hola Daniel,

Comparto tu visión al 200%, aunque me preocupa que alguien se pueda quedar con la idea de que es preferible tener equipos de tamaño medio/grande para minimizar el impacto de las bajas laborales... para ello es preferible tener una ferrea Gestión del Conocimiento que logre incrementar el Track Factor por encima de la unidad, ya que de lo contraria se evidenciará un enorme riesgo para el proyecto.

Como tu dices, el camino a la perfección sólo es viable abordándolo en equipo y ese equipo deberá mejorar y reflexionar continuamente, a la vez que el ecosistema donde actua ese Equipo deberá potenciar el talento por encima de muchos otros parámetros.

Para no enrollarme, y ligando con el paralelismo que alguien hacía en este hilo entre Agile/Scrum y un grupo de Jazz, sólo quiero añadir un link que vi hace poco y que da una idea clara de lo que puede entenderse por Equipo de Alto Rendimiento (cohesionado, implicado y comprometido), ese Equipo llega al estado de perfección después de muchas aproximaciones sucesivas con entrenamiento y disciplina... entendedlo sólo como una metáfora, ok?
http://www.videobash.com/video_embed/234317

Aunque cierto es que siempre habrá Lone Riders que nos dejarán boquiabiertos ;)
Sobretodo si es un chaval de 19 años que en una cultura corporativa tradicional empezaría como simple becario...
http://www.videobash.com/video_embed/228797

Salu2,

[Daniel Ceillan]

El 15 de febrero de 2012 10:16, Marc Florit <cramt...@gmail.com> escribió:

Hola Daniel,

Comparto tu visión al 200%, aunque me preocupa que alguien se pueda quedar con la idea de que es preferible tener equipos de tamaño medio/grande para minimizar el impacto de las bajas laborales... para ello es preferible tener una ferrea Gestión del Conocimiento que logre incrementar el Track Factor por encima de la unidad, ya que de lo contraria se evidenciará un enorme riesgo para el proyecto.

Gracias! pero lo del ausentismo era solo un ejemplo.
 

Como tu dices, el camino a la perfección sólo es viable abordándolo en equipo y ese equipo deberá mejorar y reflexionar continuamente, a la vez que el ecosistema donde actua ese Equipo deberá potenciar el talento por encima de muchos otros parámetros.

Para no enrollarme, y ligando con el paralelismo que alguien hacía en este hilo entre Agile/Scrum y un grupo de Jazz, sólo quiero añadir un link que vi hace poco y que da una idea clara de lo que puede entenderse por Equipo de Alto Rendimiento (cohesionado, implicado y comprometido), ese Equipo llega al estado de perfección después de muchas aproximaciones sucesivas con entrenamiento y disciplina... entendedlo sólo como una metáfora, ok?
http://www.videobash.com/video_embed/234317

Excelente video... :)

Se me ocurren varias conclusiones del mismo. Si bien es perfecto lo que dices, es solo una metafora y no hay que buscarle el pelo al huevo.

He visto muchas comparaciones, aunque a veces son peligrosas, bien aplicadas suelen ser muy graficas. Bueno en fin. a este ejemplo...

En el caso de comparar al equipo con una orquesta (archiusado) podriamos decir que el director de orquesta (PM o lider) solo esta alli para ir recordando las instancias y la coordinacion o tempo del equipo, pero cada parte esta enfocada en su rol y no es interrumpido por el director. Existe un delicado equilibrio entre la atencion al director, y el enfoque en la tarea actual...

Tomando tu video, podemos decir que el producto es deslumbrante, independientemente de que alguno de sus miembros olvide una nota, seria imperceptible. En ese caso un "director" que interrumpa todo el play por un error que solo el lo ve, seria un gran desperdicio.

Por ultimo la maestria. Es importante tener gente con vocacion de maestro, asi ejercera una automejora constante, y su salario espiritual sera su propio progreso y avance hacia convertirse en maestro.

Tampoco veo egos y en consecuencia un profundo respeto por el delicado equilibrio que hace posible una obra deslumbrante.

Tambien creo que hay que añadir, que en la busqueda de la maestria, no sirve solamente "ejecutar obras", sino tambien tener tiempos de ensayo, practica, entrenamiento... (CodingDojos, CodeRetreat, sprints, cursos, lab days)
 

Aunque cierto es que siempre habrá Lone Riders que nos dejarán boquiabiertos ;)
Sobretodo si es un chaval de 19 años que en una cultura corporativa tradicional empezaría como simple becario...
http://www.videobash.com/video_embed/228797

Ya hubo un debate sobre talentos. Son peligrosos, aunque a veces necesarios en proyectos muy desafiantes. Siempre sera mucho mas preferible un team player. Los talentos son difíciles de motivar, de integrar... suelen ser un factor de desequilibrio.

Gracias por compartir. Saludetes!

[Marc Florit]

Lo dicho, comparto tu enfoque al 200%
ha sido un placer leer tus reflexiones y el jugo q le has sacado al link ;)