Equipos SCRUM: ¿Hay días sin Sprint activo? ¿Qué pasa entre Sprints?

[Adrian Listo Quilez]

Hola a todos,

Gestionando las tareas de mi equipo de desarrollo, se me plantean las dos cuestiones del título. Esto se podría resumir en una pregunta:

¿Se debería tratar que todas las tareas de un equipo técnico se ejecuten dentro de Sprints que vayan completamente seguidos, sin días 'sin Sprint activo'??


Yo identifico dos escenarios en los que nos ocurre esto:

1) Días entre sprints en los que planificamos el siguiente (no hay sprint activo)

Nosotros normalmente trabajamos con sprints de 2 semanas (normalmente de lunes a segundo viernes). Suele ocurrir que cuando acaba el sprint, las user stories del siguiente sprint aún no están suficientemente maduras. Como no están detalladas, no pueden estar bien estimadas, y no nos sentimos cómodos activando un sprint en esa situación. Eso nos lleva a que tengamos un día o dos sin Sprint activo, en la que definimos y estimamos las US; durante ese tiempo a veces empezamos tareas que sí tenemos claras.. Cuando está todo claro y estimado, vemos los días que quedan hasta el "próximo viernes" y la disponibilidad del equipo, y decidimos qué US haremos en el Sprint, y lo activamos.

Entiendo que una solución a esto sería incorporar un backlog-grooming durante los sprints (prever, planificar y dedicar un tiempo durante un sprint para preparar las US del siguiente), pero la verdad es que nos cuesta mucho dar este paso.


2) En algunas fases del proyecto, donde las tareas no son planificadas o de duración impredecible, trabajamos sin sprint activo

Por ejemplo, ahora mismo estoy en un proyecto de desarrollo de procesoso con una plataforma BPM.

Hace poco, estuvimos dos semanas "cerrando" el primer proceso para dejarlo listo para desplegar en producción: pasar UAT completo, corregir pequeños fallos estéticos o funcionales que se nos habían pasado; hubo un cambio introducido por Sistemas que nos obligó a reconfigurar algunas conexiones a bbdd, etc..  Esto eran tareas muy difíciles de planificar o estimar, y el objetivo era "dejar todo listo cuanto antes, salga lo que salga", y no trabajamos con Sprint.

De cara a empezar a desarrollar los siguientes procesos bpm, ahora mismo estamos a mitad del siguiente flujo:
captura de requerimientos del siguiente proceso, preparar un primer prototipo, validar con negocio que nuestro primer planteamiento es correcto {estamos aquí}, preparar User Stories de la v1 {veo claro activar sprint a partir de aquí}, desarrollar v1, presentar y validar v2, US v2, desarrollar v2, ...

Como los primeros pasos del flujo anterior no son de desarrollo, para mí son menos deterministas, y no me siento tan cómodo activando un sprint. Me pasa como en el escenario 1) : hasta que no tengo User Stories definidas y estimadas de qué quiero desarrollar (puede incluir otras tareas/entregables no estrictamente de desarrollo), no me siento activando un sprint.



>> ¿Cúal es vuestra experiencia en estos casos?

>> ¿Está 'mal'/es desaconsejable no tener un sprint activo siempre?
>>>> En caso de que siempre tengáis sprint activos: ¿cómo puedo gestionar las fases menos deterministas? (según mis ejemplos: cerrar y afinar un entregable, ejecutar la captura de reqs. y prototipado, ...)

>> ¿Tenéis "días entre sprints" ? ¿Qué hacéis en ese tiempo?


Muchas gracias por adelantado. Un saludo!

Aviso: La información contenida en este mensaje es confidencial, quedando totalmente prohibida por la ley su reproducción, publicación y divulgación total o parcial.

Mediante la remisión y/o contestación del presente correo electrónico usted consiente expresamente para que sus datos, recogidos en el mismo, sean tratados y pasen a formar parte de un fichero cuyo responsable de tratamiento es ENZYME ADVISING GROUP, S.L. siendo su finalidad cumplir correctamente con lo dispuesto en la relación contractual con ENZYME ADVISING GROUP. 

Asimismo, mediante la remisión y/o contestación del presente correo electrónico está dando su consentimiento para que, en caso de ser necesaria la cesión de sus datos a un tercero para el cumplimiento de fines directamente relacionados con nuestras funciones legítimas, estemos actuando conforme a Derecho. 

En atención a lo establecido en la Ley Orgánica de Protección de Datos de Carácter Personal 15/1999, de 13 de diciembre, el tratamiento de los datos de carácter personal se hará exclusivamente para las finalidades con las que han sido recabados. Asimismo, le informamos de que goza de un derecho de acceso, oposición, rectificación y cancelación de los mismos, que podrá hacer efectivo en cualquier momento mediante la remisión de una comunicación escrita a "ENZYME ADVISING GROUP, S.L., Rambla Catalunya, número 111, 3º-1ª, 08008 Barcelona" o contactando con nosotros en el correo electrónico lopd@enzymeadvisinggroup.com.

Si ha recibido este mensaje por error, le rogamos que, elimine el mismo y lo comunique a su remitente. Gracias por su colaboración.

[Alfredo Casado]

Yo haría una cosa, los días que no tengáis sprint activo que el equipo se los tome libres, de esta forma al menos el equipo puede aprovechar para descansar y afrontar con más energías las historias de usuario que tenga que hacer. No lo digo en broma, si no hay sprint no hay trabajo, y si hay trabajo ¿por qué no lo pones en un sprint?

Si cuando terminas un sprint no tienes en el backlog historias para el siguiente el cuello de botella esta en tu PO, que no esta haciendo su trabajo a tiempo. Otra cosa es que a lo mejor estáis pretendiendo tener definidas las historias hasta el ultimo detalle para estimar, normalmente para estimar basta con una definición minima, por ejemplo un parrafo y un par de escenarios quizá, depende del tipo de proyecto claro, pero para estimar sólo necesitas lo suficiente para hacerte una idea de la magnitud de la historia, no necesitas todos los detalles. Recuerda aquello de Card y Conversation, la definición cabe en una tarjeta y luego los detalles se resuelven con comunicación cercana.

Sobre las tareas no deterministas, quizás tengáis que trabajar más en la definición de terminado de las historias, las cosas o están terminadas o no lo están, pero no puede ser que se terminen y luego tengamos que "afinarlas", se necesita tener un criterio claro para determinar que algo esta terminado o no, esto es algo fundamental. De todos modos, es muy habitual que termines algo y cuando lo pongas en producción te des cuenta de que falta X o vendría bien Y, estupendo, de eso va el agilismo y por eso se hacen releases frecuentes, tareas para el siguente sprint.

En general yo diria que esos "días sin sprint" son un sintoma claro de que vuestro PO necesita ponerse las pilas, o quizas necesite ayuda. 

--
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/msgid/agile-spain/2f7977cb-d4a2-4c39-9793-894d92293f27%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Pepe Vazquez]

Hola. 

Por si te sirve mi opinión, al respecto de tu correo:

1) el PO tiene que garantizar que esas HU están listas para que al comenzar el Sprint, el equipo no tenga dudas. El refinado de HU puede ser una ayuda, si, pero la pinta que me da lo que cuentas es que o no hay un PO o el que haya "necesita mejorar" ;). 

2) SCRUmban. ¿Why not?. El día de a día de los equipos de desarrollo es muy complicado y las tareas no planificadas , urgentes o que emergen de golpe y cuando lo hacen son lo más importante, es la cruda realidad. Conozco pocos equipos que puedan decir que no tienen este tipo de trabajos. 

 Este enfoque también te vale para esas tareas de configuración,de prueba de toda  la aplicación por que  desde Sistemas te cambian la versión de weblogic, por ejemplo,.... O cuando tienes que hacer tareas para, como dices, ajustar algún comportamiento no deseado. Todo esto, yo suelo considerar que  forma parte del Backlog , como cualquier otra HU planificada y definida por el PO y el equipo ha de atender tanto las HU funcionales como las tareas técnicas o del mantenimiento del servicio.

Yo creo que tener un sprint activo siempre es algo bueno, porque provoca "cadencia" y compromiso. Lo difícil es, sin duda, conseguir que si el equipo ha seleccionado las HU que entregará en el Sprint, como hacer que otras tareas emergentes no afecten a esas funcionalidades. Una opción es dejar una parte de la capacidad del equipo para atender estos imprevistos dentro del Sprint, si es que eres capaz de conseguir que se entienda como algo bueno para garantizar la calidad de servicio. No es fácil :se entiende que la sobreutilización de la capacidad es una mejora de la eficiencia.... la realidad no suele ser esa. 

Dado que , por lo que puedo deducir, tu proyecto de plataforma de procesos BPM , requiere que el equipo haga labores análisis, refinado de requisitos, y el rol de PO , intuyo que no está muy definido,  y tienes que pedir validación al cliente del enfoque/requisitos de cada proceso para poder pasar a su implementación, vas a tener ciertamente huecos entre sprints , y me pregunto si en lugar de pensar en un marco Scrum, no os vendría mejor que el marco de trabajo fuera Kanban o para no romper mucho los esquemas  actuales como te decía antes... Scrumban.

En cuanto, y por último, para esa tarea que dices de refinar y ajustar el entregable, y  como hacerlo, permíteme que te niegue la mayor ,  ;) cuando sale del Sprint algo, ese algo tiene que ser potencialmente desplegable en producción y no requerir más ajustes que aquellos que se deriven de la revisión/demo que hagas con el cliente (en ausencia de PO) y seguro que te tocará "discutir" sobre si estaba o no en el alcance, es o no una incidencia que requiere retocar.... Si estás en este punto, algo puede ser que tenga que ser revisado de las tareas anteriores.....

Bueno, Adrian, no suelo prodigarme mucho en escribir en la lista, aunque la sigo desde hace ya bastante, pero tus cuestiones son una realidad en la mayoría de equipos, y muchas veces creemos que solo si hacemos Scrum somos ágiles.. y en mi opinión lo importante es usar con sentido común, mucho sentido común, lo que mejor se adapte a la realidad de tu organización y de tu proyecto , interiorizando valores y principios primero y luego viendo que modelo es que más te acomoda a este proyecto concreto. 

Espero haberte sido de un poco de ayuda con esta respuesta.

Saludos a todos.

Enviado desde mi iPad

--

[Daniel Ceillan]

Ui escriben mucho, perdón pero no he podido leerlo todo.

SCRUM es un framework con determinadas prácticas.

Esas prácticas son rígidas.

Esto tiene sentido para que hagan los problemas visibles.

Cuando se te hace imposible mantener o ejercer una práctica, eso te está indicando que algo no funciona bien y debe ser solucionado.

La intención de aplicar las reglas estrictamente tiene como fin ver cuando se nos hace imposible.

Pero ninguna idea esta por encima de la realidad, las necesidades o las urgencias.

Ninguna idea es absoluta.

Un saludo,

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/2352AD64-8F96-492A-ABAA-F598B91D9C0C%40gmail.com.

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

--
Daniel Ceillan

Blog: www.agile-patterns.com

[Adrian Listo Quilez]

Buenos días compañeros,

Muchas gracias por vuestro interés y las molestias tomadas en contestarme, todas vuestras respuestas han sido muy reveladoras.

En primer lugar, quería comentar lo de 'ahora estamos refinando', quizá no se entendió bien. Solo por compartir experiencias, os lo explico brevemente, abierto a comentarios: nosotros trabajamos con un estricto sistema de calidad, basado en UATs, y cuando damos algo por cerrado SÍ se cumple que es 'potencialmente desplegable'. En este caso, salieron algunas cosas técnicas que vinieron del departamento de sistemas, al pasar la UAT completa salió algún bug y aprovechamos para algún retoque menor en la parte más visual (no funcional) de algún formulario, es decir: darle el repaso final una vez se habían completado todas las funcionalidades; a esto le llamé 'refinar' de forma general. Estoy de acuerdo en que podríamos haber creado una tarea en el backlog para esto sin problemas..


Quería comentar un par de cosas que me habéis contestado antes:

• Decíais que, en caso de tareas imprevistas/no planificables, es recomendable dejar un margen en la estimación del sprint para este tipo de tareas. Esto ya lo tenemos solucionado bastante bien: medimos el ratio de velocidad (horas ideales estimadas/horas reales para cerrar una issue), y la media de lo anterior en los sprints ejecutados se aplica en la estimación del siguiente, lo cual recoge esos imprevistos que suelen salir en la etapa de análisis pre-programar y durante el desarrollo. Esto nos funciona muy bien, y normalmente completamos todo o casi de lo comprometido en un sprint.

• Lo que no me ha quedado claro, y os pediría vuestro consejo aquí, es cómo tratáis las tareas propias de la fase de análisis inicial, captura de requerimientos, prototipado, validación; es decir, todo lo que hay que hacer antes de que el Equipo se ponga a programar propiamente. Me interesa porque nosotros tenemos varios procesos en paralelo, cada uno en un punto diferente del ciclo de vida del proceso. ¿Creáis tareas en sprint también para esta parte más funcional y no tan técnica? Puede que a algunos os parezca ridícula o incluso 'ofensiva' esta pregunta :P , pero me gusta leer testimonios directos de otros equipos. Todos hemos leído muchos libros.

Muchas gracias de nuevo a todos.

Un cordial saludo.

[Adrian Listo Quilez]

Por cierto Daniel,

Me ha encantado:

La intención de aplicar las reglas estrictamente tiene como fin ver cuando se nos hace imposible.
Cuando se te hace imposible mantener o ejercer una práctica, eso te está indicando que algo no funciona bien y debe ser solucionado.

Me la apunto a fuego.

..es habitual que cuando empiezas a aplicar una práctica, enseguida la empieces a adaptar para minimizar el cambio y salirte de tu zona de confort y, evidentemente, es un error.

Me guardo tu frase como 'amuleto' contra los malos pensamientos..  ;-)

Saludos,

[Daniel Ceillan]

De nada... encantado de ayudar...

Y esto lo podríamos agregar como capítulo a la serie: "Y donde esta el Scrum Master?"

Tienes Scrum Master? Hacen retrospectivas? Cuales son los objetivos? Que necesitan?

No es para que me respondas, sino para que pensemos juntos.

Saludos

--

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/msgid/agile-spain/bba3d89d-7ca5-4820-82e4-735f6c316fc5%40googlegroups.com.

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

[Jeronimo Palacios]

Hola Adrián:

Me permito parar un momento para contestar a las dudas que planteas y a las que no planteas también.

Sprint Activo 

No hay tal cosa en Scrum. Cuando se termina un sprint, empieza otro, y dentro de los sprints se desarrollan una serie de actividades (planificación, stand-ups, revisión y retrospectiva, además de los refinamientos del backlog). Pensar en Sprint activo es trasladar conceptos de waterfall a agile. La razón de que sea así es que una de las características de Scrum es la cadencia y el ritmo. 

Si unas veces usáis sprints y otras no, entonces no estáis haciendo Scrum, estáis haciendo otra cosa. No esperéis obtener los beneficios de Scrum si no lo hacéis correctamente. Obtendréis otros beneficios distintos a causa de aquello que estáis haciendo. Es una gran tradición lo de quemar gente diciendo que se hace Scrum cuando en realidad se hace otra cosa. 

User stories

Si las user stories para el siguiente Sprint no están listas, entonces el Product Owner no está haciendo su trabajo correctamente, el equipo no está haciéndolo notar de manera adecuada y el Scrum Master no se está asegurando de que el proceso funcione, con lo que no está cumpliendo su labor. Si os cuesta dar el paso de hacer refinamientos del backlog y preferís tener a un equipo parado preparando historias cuando podrían estar siendo productivos, entonces no sólo no estáis haciendo Scrum sino que además probablemente estaréis quemándolos. Despide a tu Product Owner y contrata uno nuevo. También al Scrum Master.

Flujo de trabajo

Sobre esto, pues me suena a más waterfall. El flujo de trabajo en Scrum es: Preparar Historias de usuario, trabajar en ellas un tiempo determinado, incrementar la funcionalidad del producto y entregarlo, validar con el cliente. Repetir. Más historias de usuario. Mejorar el proceso. Repetir. Así hasta acabar. Ni sprint "activos" ni, en principio, mucho de lo que comentas.

Definition of Done

Todas las actividades que comentas que tenéis que realizar para dejar un incremento listo para producción, deben ir en el definition of done acordado y consensuado por todos los miembros del equipo. Así que si hay una actividad que no esta hecha, no hay que poner una nueva historia de usuario, lo que hay que hacer es terminarla, y si no está terminado, no está terminado. No hay refinamiento que valga. :)

Horas reales/horas estimadas

[Introducir aquí un doble facepalm]. Adrián, en Scrum esto no funciona así. Las estimaciones son usadas para poder dar una previsión de lo que se puede hacer en el Sprint, pero la productividad no se mide de esta manera. Igualmente, hay que dejar que sea el equipo el que decida su compromiso, no utilizar la media de la diferencia de las horas reales vs estimadas para decidir la cantidad de trabajo a realizar en el próximo sprint. 

Tareas funcionales, etc...

Tal y como formulas la pregunta, me da que estáis haciendo puro waterfall y viendo como encaja agile dentro de esto. Todas esas tareas no se hacen en Scrum. Bueno, en realidad si se hacen, pero de manera incremental  y siempre buscando la inspección y adaptación sobre lo que ya hemos construido con el cliente. Nunca pongas una tarea que diga "toma de requisitos" o "elaboración del plan de proyecto" en un backlog de un equipo Scrum, porque Ken Schwaber se comerá un gatito vivo. 

Mi consejo personal 

Las dudas que planteas son de un nivel bastante básico, aunque por otro lado son normales en quien está haciendo una transición. Léete la guía de Scrum y el Essential Scrum por lo menos tres veces y contrata a alguien que os pueda formar en este tema y que os ayude a lanzar Scrum dentro de vuestra empresa. Mientras tanto, dile a la gente que no vais a hacer Scrum hasta que no sepáis como hacerlo para así no quemarlos y no generar posteriores resistencias al cambio, que son muy difíciles de manejar. Espero que aunque mi tono ha sido duro no te hayas sentido ofendido. 

Un saludo,

Jerónimo

2014-01-27 Adrian Listo Quilez <adrian...@enzymeadvisinggroup.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/msgid/agile-spain/a548ea70-10c6-41f6-bb5e-2184c6bdda4b%40googlegroups.com.

[Antonio de la Torre]

• Lo que no me ha quedado claro, y os pediría vuestro consejo aquí, es cómo tratáis las tareas propias de la fase de análisis inicial, captura de requerimientos, prototipado, validación; es decir, todo lo que hay que hacer antes de que el Equipo se ponga a programar propiamente. Me interesa porque nosotros tenemos varios procesos en paralelo, cada uno en un punto diferente del ciclo de vida del proceso. ¿Creáis tareas en sprint también para esta parte más funcional y no tan técnica? Puede que a algunos os parezca ridícula o incluso 'ofensiva' esta pregunta :P , pero me gusta leer testimonios directos de otros equipos. Todos hemos leído muchos libros.

Hola Adrián:

Muy interesante tu pregunta, ya ves que da para mucho.

Tu pregunta: "todo lo que hay que hacer antes de que el Equipo se ponga a programar propiamente."

Lo que durante el proyecto se recoge en el Grooming que nosotros hacemos el martes anterior al fin de sprint (de viernes) al inicio, no es suficiente.

Nosotros nos acogemos a lo que se conoce como Sprint 0. Que definimos como aquella fase inicial necesaria para que el Sprint 1 se parezca lo más posible al Sprint 8, en definición de historias y entrega de producto.

De duración no determinada, pero la justa y suficiente para conseguir el objetivo que digo arriba.

Te puedo dar más detalles, pero tareas clásicas:

- Sesiónes de Inception: personas, brainstorming, hechos, objetivos, 

- Creación de requisitos/historias

- Creación del backlog

- Estimación muy a groso de todo lo posible.

- Priorización

- Definición de las más importantes que se van a acometer al inicio.

- Estimación más detallada de las más importantes.

Es decir TODO el análisis inicial se hace en esta fase. Como complementario es el tiempo que pasa entre que sabes que vas a hacer el proyecto y te pones a programarlo.

Más en detalle.

En la implementación fina, se puede ver que podrías paralelizar ciertas tareas de infraestructura con estas sesiones de análisis, como crear la base de datos, repositorios, y lo más básico para que el Sprint 1 sea totalmente funcional.

Espero que ayude.

Antonio

[Adrian Listo Quilez]

Hola Jerónimo.

Muchas gracias por tu respuesta. No me siento ofendido, tranquilo. Es más, es una cura de humildad para darnos cuenta de que aún tenemos mucho por aprender y mejorar. Estamos 'en transición' como dices, todos estamos aprendiendo y poniendo lo mejor de nuestra parte; no parece que nadie se haya quemado por el camino..  ;-)

Comentarios/dudas acerca de tus puntos, me encantaría tirar un poco más de la manta de alguno de ellos. Agradecería tus comentarios.

Sprint Activo :: OK a todo lo que dices

No hay tal cosa en Scrum. Cuando se termina un sprint, empieza otro, y dentro de los sprints se desarrollan una serie de actividades (planificación, stand-ups, revisión y retrospectiva, además de los refinamientos del backlog). Pensar en Sprint activo es trasladar conceptos de waterfall a agile. La razón de que sea así es que una de las características de Scrum es la cadencia y el ritmo. 

Si unas veces usáis sprints y otras no, entonces no estáis haciendo Scrum, estáis haciendo otra cosa. No esperéis obtener los beneficios de Scrum si no lo hacéis correctamente. Obtendréis otros beneficios distintos a causa de aquello que estáis haciendo. Es una gran tradición lo de quemar gente diciendo que se hace Scrum cuando en realidad se hace otra cosa. 

User stories :: OK

Si las user stories para el siguiente Sprint no están listas, entonces el Product Owner no está haciendo su trabajo correctamente, el equipo no está haciéndolo notar de manera adecuada y el Scrum Master no se está asegurando de que el proceso funcione, con lo que no está cumpliendo su labor. Si os cuesta dar el paso de hacer refinamientos del backlog y preferís tener a un equipo parado preparando historias cuando podrían estar siendo productivos, entonces no sólo no estáis haciendo Scrum sino que además probablemente estaréis quemándolos. Despide a tu Product Owner y contrata uno nuevo. También al Scrum Master.  (.."jaja".. Al menos, creo que la gente no está quemada con este tema, aún.. )

Flujo de trabajo

Sobre esto, pues me suena a más waterfall. El flujo de trabajo en Scrum es: Preparar Historias de usuario, trabajar en ellas un tiempo determinado, incrementar la funcionalidad del producto y entregarlo, validar con el cliente. Repetir. Más historias de usuario. Mejorar el proceso. Repetir. Así hasta acabar. Ni sprint "activos" ni, en principio, mucho de lo que comentas.

Lo que comentas me parece correcto, pero, no mencionas ni la parte de captura de requerimientos, ni el prototipado, ni la validación de requerimientos.
Por cómo hablas, parece que sugieres "escribir user stories con lo que sepas, construirlo con la funcionalidad X en estado 'shippable', mostrar y validar con el cliente, repetir.." ¿Es así?
Estoy de acuerdo en trabajar así, pero sobre una base de funcionalidad clara y validada con el cliente. Y para eso, para nosotros, el prototipado es esencial porque 'aterriza' en el cliente la funcionalidad que hemos entendido, y les da una idea de qué les entregaremos en próximos sprints; a partir del primer prototipo, sí que entregamos funcionalidad incremental sobre el producto final.
¿Cómo lo ves?

Definition of Done :: OK

Todas las actividades que comentas que tenéis que realizar para dejar un incremento listo para producción, deben ir en el definition of done acordado y consensuado por todos los miembros del equipo. Así que si hay una actividad que no esta hecha, no hay que poner una nueva historia de usuario, lo que hay que hacer es terminarla, y si no está terminado, no está terminado. No hay refinamiento que valga. :)

Horas reales/horas estimadas :: NOK

[Introducir aquí un doble facepalm]. Adrián, en Scrum esto no funciona así. Las estimaciones son usadas para poder dar una previsión de lo que se puede hacer en el Sprint, pero la productividad no se mide de esta manera. Igualmente, hay que dejar que sea el equipo el que decida su compromiso, no utilizar la media de la diferencia de las horas reales vs estimadas para decidir la cantidad de trabajo a realizar en el próximo sprint. 

Aquí definitivamente creo que no nos hemos entendido..
Scrum plantea dos métricas para estimar US y cerrar el compromiso del Equipo en cada sprint: horas ideales y puntos de historia (Story Points). A nosotros, por nuestro nivel de madurez, nos resulta más fácil estimar en horas ideales.
Tanto las horas ideales como los puntos de historia no son 'absolutos', es decir, necesitas que el Equipo haga 1 o 2 sprints para poder medir su velocidad de quemado por sprint, tanto en una métrica como en otra.
(entiendo que estamos de acuerdo hasta aquí)

El ratio 'horas ideales/horas reales (ó disponibles)' no es un ratio de productividad, es un ratio de velocidad. Para mí esto es válido, y de hecho nos funciona bastante bien.
Ahora mismo, nuestra experiencia nos dice que, en media: cuando una User Story en el momento de estimarla (con la información y alcance en ese momento) nos parece que va a costar 4h, acaba costando desarrollarla y testarla ("cerrarla") unas 8h (en media!!); en esta desviación se incluye: acabar de recoger requisitos o dudas que surgen durante la implementación, imprevistos técnicos o funcionales que no habían sido previstos, bugs durante el testing, etc etc. (alcanzar Definition of Done)
Así pues, para que el Equipo defina su compromiso sobre el backlog priorizado: primero calculamos la capacidad real del equipo - imaginemos 200h para un sprint de 2 semanas con un equipo de 2,5 personas asignadas a este proyecto; si nuestro ratio es (4h ideal./8h reales), entonces cortaríamos el compromiso al alcanzar 100h ideales estimadas en el backlog.

¿Qué opinas? Estoy muy abierto a críticas o comentarios.

Tareas funcionales, etc...  (ver apartado - Flujo de trabajo, arriba)

Tal y como formulas la pregunta, me da que estáis haciendo puro waterfall y viendo como encaja agile dentro de esto. Todas esas tareas no se hacen en Scrum. Bueno, en realidad si se hacen, pero de manera incremental  y siempre buscando la inspección y adaptación sobre lo que ya hemos construido con el cliente. Nunca pongas una tarea que diga "toma de requisitos" o "elaboración del plan de proyecto" en un backlog de un equipo Scrum, porque Ken Schwaber se comerá un gatito vivo. 

 (porfa aclárame cómo hacéis esto en los sprints, aterrízalo)

Mi consejo personal :: OK

Las dudas que planteas son de un nivel bastante básico, aunque por otro lado son normales en quien está haciendo una transición. Léete la guía de Scrum y el Essential Scrum por lo menos tres veces y contrata a alguien que os pueda formar en este tema y que os ayude a lanzar Scrum dentro de vuestra empresa. Mientras tanto, dile a la gente que no vais a hacer Scrum hasta que no sepáis como hacerlo para así no quemarlos y no generar posteriores resistencias al cambio, que son muy difíciles de manejar. Espero que aunque mi tono ha sido duro no te hayas sentido ofendido. 

Muchas gracias Jerónimo por tu interés y comentarios, de verdad. Los tendremos muy en cuenta. Saludos.

 

Un saludo,

Jerónimo

[Adrian Listo Quilez]

Gracias Antonio a ti también.

Sí, la verdad es que tema está dando bastante de sí.. Me estáis ayudando mucho, y estoy seguro de que servirá para reflexionar y tomar buena nota a muchos otros compañeros de la comunidad.

Contestando a tus aportaciones en particular:

Me gusta tu idea de un Sprint 0 para prepararse a entrar en la 'rueda de hámster' que marca el ritmo de los sprints.

Entiendo que, a partir de ese momento, lo que fueron las tareas del Sprint 0 se deben ir introduciendo y repartiendo (para nuevas funcionalidades o profundizar en las inicialmente acotadas) a lo largo de próximos sprints para mantener siempre 'un colchón' en el backlog que te permita no pararte nunca,
¿lo he entendido bien?

De hecho, creo que esto es lo que nosotros estamos haciendo mal.. Por eso nos cuesta tener sprints siempre "activos". Y estoy muy de acuerdo en que eso tiene un alto impacto en el ritmo de desarrollo, la moral del equipo de desarrollo, etc. etc. y por supuesto, en la eficiencia y rentabilidad del proyecto..

Como decía Ceillan, si algo no se puede hacer tal y como marca la metodología, es un claro síntoma de que algo falla o no se está haciendo bien..

Saludos y gracias a todos.

[Antonio de la Torre]

Entiendo que, a partir de ese momento, lo que fueron las tareas del Sprint 0 se deben ir introduciendo y repartiendo (para nuevas funcionalidades o profundizar en las inicialmente acotadas) a lo largo de próximos sprints para mantener siempre 'un colchón' en el backlog que te permita no pararte nunca,
¿lo he entendido bien?

Hola Adrián.

Efectivamente, las tareas del Sprint 0, luego las tienes que repetir a su escala en cada Sprint, en lo que se llama Grooming del Backlog.

Un 10% al sprint, una tarde en un sprint de dos semanas, debería ser de sobra para tener el backlog perfecto para entrar en el siguiente sprint sin parones para definir.

Ahora bien, si ves que una tarde cada dos semanas no es suficiente, hay que plantearse, o hacer sesiones específicas para aclarar historias con muchísimas dudas, o es que estáis profundizando mucho más en el alcance que lo que váis a hacer en las siguientes dos semanas.

Esto último es un problema, porque se pierde el foco y distrae muchísimo del objetivo principal, que es cerrar el sprint con éxito.

Animo :)

Antonio

[Jeronimo Palacios]

Hola Adrián:

Sigo contestando a lo que planteas.

Flujo de trabajo 

La toma de contacto con el cliente, validación y petición de prototipos la pide el Product Owner y el equipo se queda al margen de estas cosas. Es decir, el Product Owner se reúne con el cliente, le explica la forma de trabajar, cierra con él las historias de usuario, si necesita un prototipo prioriza una historia de usuario en el backlog del equipo para que entre en el siguiente sprint y, una vez que lo tiene, lo muestra al cliente y lo valida. 

Esa tarea es exclusiva del Product Owner. También maximizar el valor obtenido de las sesiones de refinamiento del backlog y la gestión con los stakeholders (internos o externos). ¿El acercamiento "escribir historias con lo que sepas [...]" puede funcionar? Puede. Para mi ese acercamiento muestra que el Product Owner no está haciendo su trabajo en condiciones y tiene que interrumpir la cadencia y el ritmo del equipo para que le "ayuden" a hacerlo. Pero esas no son responsabilidades del equipo de desarrollo. Si existen dudas técnicas se les puede preguntar, pero el responsable es el PO.

Horas reales/estimadas

Entendí lo que preguntabas, pero efectivamente pensé que lo utilizabais como ratio de productividad. Si es velocidad, entonces tenéis vuestra previsión, -por cierto, da igual que esté estimado en story points, horas o gnomos de jardín- y luego lo comparáis con vuestra velocidad real. 

Sobre la manera de medir la "capacidad", mi experiencia es que es una manera tan buena como cualquier otra para empezar a hacer estimaciones, pero que la aspiración del equipo siempre debe ser ir a mejor, no calcular en ratios de horas ideales o reales. Conforme pase el tiempo el equipo irá mejorando las estimaciones. 

Tareas funcionales

Aquellas que tienen que ver con el desarrollo puro y duro van al DoD del equipo y éste es responsable; aquellas que tienen que ver con el producto (validación, requisitos, etc..) son responsabilidad del product owner. 

Sobre la Iteración 0 que proponía Antonio, creo que no es lo más adecuado para vosotros. Scrum os dice que tenéis un problema en la parte de planificación y producto, sobre todo con relación a la figura del Product Owner. La solución es clara: tener una persona que haga ese trabajo y lo haga muy bien. Si queréis taparlo con sprints "activos", iteraciones "0" y otras cosas es como darse un golpe en la cabeza para olvidarse de que te duele un pie: No importa cuan fuerte lo hagas que el problema seguirá existiendo. 

Espero haber resuelto las dudas que tenías :)

Jerónimo

2014-01-28 Adrian Listo Quilez <adrian...@enzymeadvisinggroup.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/msgid/agile-spain/35e4bfdf-462d-4e4a-9580-6c09dd3736eb%40googlegroups.com.

[Jose Luis Soria]

Jerónimo, quizá estoy malinterpretándote, pero según leo tus comentarios, contienen un par de detalles acerca del rol de Product Owner que son erróneos desde el punto de vista de Scrum.

En primer lugar está el hecho de que el equipo se quede al margen de ciertas interacciones con el cliente. Lo peor que puede hacer un Product Owner es actuar como proxy entre el equipo y el cliente; la colaboración con el cliente, la comunicación cara a cara y el trabajo diario con la gente de negocio están claramente identificados en el manifiesto ágil y en sus principios. Siempre es mejor que el cliente te cuente algo directamente, a que el Product Owner te cuente su versión de lo mismo, o lo que él haya entendido. Esto incluye cierre de historias de usuario, prototipos y cualquier otro elemento en el que el cliente tenga criterio para opinar. Por supuesto que el PO idealmente estará presente en estas conversaciones, y en todo caso (si no puede estar) deberá ser informado y preocuparse de estar al tanto para ver las posibles repercusiones sobre el backlog. Llevado al extremo, recuerdo por ejemplo el caso de un equipo que estaban sentados en la misma habitación que el cliente y que sin embargo intentaban esperar a su PO (que normalmente no estaba presente) cada vez que tenían alguna duda sobre alguna funcionalidad, para que él hablase con el cliente. Es un ejemplo claro de la diferencia entre "hacer Agile" y "ser Ágil".

El otro problema que veo es que según lo planteas, da la impresión de que el PO es el responsable de escribir el contenido del backlog, y que el equipo de desarrollo no es responsable de ayudarle en esta labor. Conozco casos de excelentes POs que rara vez escriben una sola historia de usuario, y en su lugar se apoyan en el equipo para ello. Por ejemplo, la típica figura de analista funcional, convenientemente reciclado an algunos aspectos, tendría cabida perfectamente en un equipo Scrum en el que el PO necesite apoyo para completar los elementos del backlog. El PO es responsable de que exista un backlog claramente expresado, ordenado y que refleje la entrega de valor, pero esto no quiere decir que se tenga que ocupar de escribirlo, tal y como nos recuerda la propia guía de Scrum en el apartado en el que se describe el rol. De hecho, si evitamos que el equipo participe en la elaboración del backlog, vamos a tener un backlog mucho más pobre y que provocará mucho trabajo extra. Por ejemplo, un buen tester es una ayuda inestimable a la hora de escribir los criterios de aceptación de cada historia de usuario. O un programador puede detectar dependencias entre historias que provoquen su reescritura. Y en general, todos entenderán mucho mejor el producto a construir si están involucrados en su definición.

Repito que es posible que esté entendiendo mal tus comentarios, mis disculpas en ese caso.

Por otra parte, coincido plenamente en considerar la práctica del "Sprint 0" como una mala idea. El problema es que nada te impide añadir un Sprint 0+, o un Sprint 0.5, o como queráis llamarlos, y podemos estar posponiendo la entrega de valor indefinidamente, lo cual es waterfall puro y duro. Lo mejor es empezar un Sprint 1 en el que haya mucho trabajo preparatorio (definición, arquitectura, planificación o lo que haga falta), si es necesario, pero con una mínima entrega de funcionalidad que valide ese trabajo. El Sprint 2 tendrá un poco menos de preparación y un poco más de entrega de valor, y así sucesivamente hasta tener Sprints plenamente dedicados a la entrega de valor. De hecho si pese a todo se opta por hacer ese Sprint 0, yo prefiero dejarlo fuera de Scrum, no llamarlo Sprint, y empezar a esprintar cuando realmente empecemos a entregar valor.

Un saludo!!!

En atención a lo establecido en la Ley Orgánica de Protección de Datos de Carácter Personal 15/1999, de 13 de diciembre, el tratamiento de los datos de carácter personal se hará exclusivamente para las finalidades con las que han sido recabados. Asimismo, le informamos de que goza de un derecho de acceso, oposición, rectificación y cancelación de los mismos, que podrá hacer efectivo en cualquier momento mediante la remisión de una comunicación escrita a "ENZYME ADVISING GROUP, S.L., Rambla Catalunya, número 111, 3º-1ª, 08008 Barcelona" o contactando con nosotros en el correo electrónico lo...@enzymeadvisinggroup.com.

Si ha recibido este mensaje por error, le rogamos que, elimine el mismo y lo comunique a su remitente. Gracias por su colaboración.

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

[Jeronimo Palacios]

Hola José Luis, gracias por puntualizar mis comentarios. Efectivamente no me has malinterpretado en la esencia, aunque probablemente debido a que yo no he puntualizado lo suficiente, creo por tu comentario que has asumido algo que yo no quería expresar. 

Si no te importa, te contesto entre líneas. 

En primer lugar está el hecho de que el equipo se quede al margen de ciertas interacciones con el cliente.

No quería decir que el equipo deba quedarse al margen de las interacciones con el cliente. Que existan interacciones con el cliente es responsabilidad exclusiva del Product Owner (es decir, que el promotor de que existan esas interacciones es el PO) y a partir de ahí todas las interacciones que añadan valor son bienvenidas, pero siempre desde la base que el responsable de que existan esas interacciones es el PO.

 

Lo peor que puede hacer un Product Owner es actuar como proxy entre el equipo y el cliente; la colaboración con el cliente, la comunicación cara a cara y el trabajo diario con la gente de negocio están claramente identificados en el manifiesto ágil y en sus principios. Siempre es mejor que el cliente te cuente algo directamente, a que el Product Owner te cuente su versión de lo mismo, o lo que él haya entendido.

Totalmente de acuerdo. Personas e interacciones sobre procesos y herramientas.

 

Esto incluye cierre de historias de usuario, prototipos y cualquier otro elemento en el que el cliente tenga criterio para opinar. Por supuesto que el PO idealmente estará presente en estas conversaciones, y en todo caso (si no puede estar) deberá ser informado y preocuparse de estar al tanto para ver las posibles repercusiones sobre el backlog.

Desde el punto de vista de Scrum no es idealmente, es que es una de sus responsabilidades. Puede darse la situación de que no pueda estar, pero yo como Scrum Master o miembro del equipo nunca tomaría la iniciativa de la responsabilidad a no ser que tenga una buena razón para no estar. Lo de que deberá ser informado tampoco lo comparto. Si el PO no está en la reunión ¿Por qué debería de informarlo el equipo?. 

Por supuesto, estoy llevando todo hacia el extremo, al igual que en el correo anterior. Las relaciones día a día deben ser de cooperación y colaboración y no deberían de  aferrarse a lo que dice Scrum.

 

Llevado al extremo, recuerdo por ejemplo el caso de un equipo que estaban sentados en la misma habitación que el cliente y que sin embargo intentaban esperar a su PO (que normalmente no estaba presente) cada vez que tenían alguna duda sobre alguna funcionalidad, para que él hablase con el cliente. Es un ejemplo claro de la diferencia entre "hacer Agile" y "ser Ágil".

Es curioso porque he vivido esta situación hace poco. La realidad de la situación que yo viví es que el PO había abdicado de muchas de sus funciones en el equipo, hasta que el equipo se negó en redondo a seguir comunicándose con el cliente, dado que el PO luego llegaba a culpar al equipo de determinadas cosas que ahora el cliente quería o no, así que comenzó a pedir minutas de las reuniones por escrito. Son dos visiones de la misma moneda.

 

El otro problema que veo es que según lo planteas, da la impresión de que el PO es el responsable de escribir el contenido del backlog, y que el equipo de desarrollo no es responsable de ayudarle en esta labor.

El PO es responsable de que exista un backlog que maximice el valor y por ello debe de colaborar con el equipo y buscar su cooperación para realizar esa labor. El equipo no es responsable de ayudarle en esa labor. El equipo, siguiendo los principios y valores ágiles colaborará y cooperará en lo necesario para que el backlog refleje eso.

 

Conozco casos de excelentes POs que rara vez escriben una sola historia de usuario, y en su lugar se apoyan en el equipo para ello.

Mi experiencia me dice al contrario... conozco literalmente cientos de equipos cuyos PO abdican de su responsabilidad y es el equipo al final el que tiene que guisarse y comerse el backlog. Mi experiencia me dice que un product owner que no escribe de usuarios o es un facilitador excelente o un PO pésimo. Ojo, creo que es muy probable que tu experiencia te haya llevado a conocer a ese facilitador excelente y la mía a los pésimos y por eso miramos a través de distinto cristal.

 

Por ejemplo, la típica figura de analista funcional, convenientemente reciclado an algunos aspectos, tendría cabida perfectamente en un equipo Scrum en el que el PO necesite apoyo para completar los elementos del backlog. El PO es responsable de que exista un backlog claramente expresado, ordenado y que refleje la entrega de valor, pero esto no quiere decir que se tenga que ocupar de escribirlo, tal y como nos recuerda la propia guía de Scrum en el apartado en el que se describe el rol.

Totalmente de acuerdo. Dicho esto, mi experiencia es que en una gran cantidad de casos el PO abdica de sus funciones y deja toda la esa parte al equipo (y otros) y el se encarga de priorizar. Eso genera unos cuellos de botella increíbles y encuentro equipos técnicamente excelente que pierden literalmente horas de trabajo intentando refinar un backlog que el PO no se ha molestado en trabajar.

 

De hecho, si evitamos que el equipo participe en la elaboración del backlog, vamos a tener un backlog mucho más pobre y que provocará mucho trabajo extra. Por ejemplo, un buen tester es una ayuda inestimable a la hora de escribir los criterios de aceptación de cada historia de usuario. O un programador puede detectar dependencias entre historias que provoquen su reescritura. Y en general, todos entenderán mucho mejor el producto a construir si están involucrados en su definición.

Aquí difiero ligeramente en cuando en la parte de criterios de satisfacción. Creo que el PO puede pedir cooperación y colaboración del equipo pero debe ser él y sólo él quien decida cuales son los más adecuados para cada historia de usuario. Estando en el resto de acuerdo, otros casos que añadiría es cuando el equipo decide incorporar una feature o incluso un requerimiento en el product backlog.

 

Repito que es posible que esté entendiendo mal tus comentarios, mis disculpas en ese caso.

En absoluto, en el anterior correo estaba intentando explicar algo en cuatro frases que, obviamente, es mucho más complejo que eso. De hecho, yo intento educar al PO en que él es el responsable y que debe involucrar al resto, pero primero tiene que ser capaz el de llevar la responsabilidad. El trabajo de PO es uno de los más difíciles, desde mi punto de vista, en cualquier organización ágil y creo que hay mucho por hacer en ese sentido.

Veo que has interpretado mi correo según tu experiencia, lo cual es lo más lógico... espero haber aclarado esos puntos un poco más.

 

Por otra parte, coincido plenamente en considerar la práctica del "Sprint 0" como una mala idea. El problema es que nada te impide añadir un Sprint 0+, o un Sprint 0.5, o como queráis llamarlos, y podemos estar posponiendo la entrega de valor indefinidamente, lo cual es waterfall puro y duro. Lo mejor es empezar un Sprint 1 en el que haya mucho trabajo preparatorio (definición, arquitectura, planificación o lo que haga falta), si es necesario, pero con una mínima entrega de funcionalidad que valide ese trabajo. El Sprint 2 tendrá un poco menos de preparación y un poco más de entrega de valor, y así sucesivamente hasta tener Sprints plenamente dedicados a la entrega de valor. De hecho si pese a todo se opta por hacer ese Sprint 0, yo prefiero dejarlo fuera de Scrum, no llamarlo Sprint, y empezar a esprintar cuando realmente empecemos a entregar valor.

De acuerdo de nuevo. Solamente puntualizar que es "Iteración 0" no "Sprint 0", porque no hay nada de eso en Scrum. Es una práctica importada que, en otro contexto, tiene su sentido.

 

Un saludo!!!

¡Otro para ti! :)

 

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/183558e5-c0f4-4d81-a4fc-42e4ed620c65%40googlegroups.com.

[Daniel Ceillan]

Ping! nota al margen...

Yo no alimentaría el debate desde la cosmovisión de "tal cosa es cierta" y "tal otra esta errada" sino más bien alimentaría las opciones o las diferentes formas de ver el método como "matices" de una misma verdad.

Por supuesto que existe una definición bien específica de lo que es SCRUM y como funciona. Y tambien de lo que es AGILE y como debería funcionar. Pero veo un riesgo en el debate de que se convierta en un Barza-Madrid.

Hay que aceptar que cada casa es un mundo, cada equipo es un mundo, cada cliente, cada persona, etc...

Y sería un error incluso estandarizar lo bueno. Todos sabemos que estandarizar es una buena practica, pero se puede estandarizar el amor? la amistad? la confianza?

Si se puede, pero obviamente sería un error. El Arte demanda Talento, el Talento Creatividad y la Creatividad soltura.

Hecho el disclaimer aporto mi matiz, a una misma verdad que compartimos y nos une.

El 30 de enero de 2014, 2:00, Jeronimo Palacios <giro...@gmail.com> escribió:

Hola José Luis, gracias por puntualizar mis comentarios. Efectivamente no me has malinterpretado en la esencia, aunque probablemente debido a que yo no he puntualizado lo suficiente, creo por tu comentario que has asumido algo que yo no quería expresar. 

Si no te importa, te contesto entre líneas. 

En primer lugar está el hecho de que el equipo se quede al margen de ciertas interacciones con el cliente.

No quería decir que el equipo deba quedarse al margen de las interacciones con el cliente. Que existan interacciones con el cliente es responsabilidad exclusiva del Product Owner (es decir, que el promotor de que existan esas interacciones es el PO) y a partir de ahí todas las interacciones que añadan valor son bienvenidas, pero siempre desde la base que el responsable de que existan esas interacciones es el PO.

Aqui agrego mi matiz. Yo veo más encargado de las "cuestiones humanas" al Scrum Master. He visto por ahi definido al PO como el "agente del cambio" y demas cosas... yo apuesto más por que los desafíos y cuestiones humanas recaigan más de lleno en el Scrum Master. Al PO lo veo como alguien que demanda tener la vista clavada en el horizonte, en el mapa, y tener bien claro en que parte del agua hay más pique para el producto.

Todo lo demás solo estaría quitándole energía, concentración, capacidad a alguien que tiene una misión clara: dar dirección. Responder la pregunta ¿a donde vamos?

 

 

Lo peor que puede hacer un Product Owner es actuar como proxy entre el equipo y el cliente; la colaboración con el cliente, la comunicación cara a cara y el trabajo diario con la gente de negocio están claramente identificados en el manifiesto ágil y en sus principios. Siempre es mejor que el cliente te cuente algo directamente, a que el Product Owner te cuente su versión de lo mismo, o lo que él haya entendido.

Totalmente de acuerdo. Personas e interacciones sobre procesos y herramientas.

 

Si respetamos Scrum, el método, no importa quien hable con quien. O que hayan dicho. Los cambios en el backlog los gestiona el PO. Y cualquier cristiano que quiera cambiar algo en la ruta del proyecto, debe ir a persuadir al PO.

Un matiz adicional que suele escaparse a la vista de cualquiera de nosotros. El manifiesto dice "individuos e interacciones", no dice "developers e interacciones". Solemos asumir que lo más importante son los developers, que deben ser auto-organizados, que deben realizar un esfuerzo sustentable. Pues lo de auto-organizado y sustentable se debe expandir a todos los INDIVIDUOS que participan del proceso.

 

Esto incluye cierre de historias de usuario, prototipos y cualquier otro elemento en el que el cliente tenga criterio para opinar. Por supuesto que el PO idealmente estará presente en estas conversaciones, y en todo caso (si no puede estar) deberá ser informado y preocuparse de estar al tanto para ver las posibles repercusiones sobre el backlog.

Desde el punto de vista de Scrum no es idealmente, es que es una de sus responsabilidades. Puede darse la situación de que no pueda estar, pero yo como Scrum Master o miembro del equipo nunca tomaría la iniciativa de la responsabilidad a no ser que tenga una buena razón para no estar. Lo de que deberá ser informado tampoco lo comparto. Si el PO no está en la reunión ¿Por qué debería de informarlo el equipo?. 

Por supuesto, estoy llevando todo hacia el extremo, al igual que en el correo anterior. Las relaciones día a día deben ser de cooperación y colaboración y no deberían de  aferrarse a lo que dice Scrum.

 

Llevado al extremo, recuerdo por ejemplo el caso de un equipo que estaban sentados en la misma habitación que el cliente y que sin embargo intentaban esperar a su PO (que normalmente no estaba presente) cada vez que tenían alguna duda sobre alguna funcionalidad, para que él hablase con el cliente. Es un ejemplo claro de la diferencia entre "hacer Agile" y "ser Ágil".

Es curioso porque he vivido esta situación hace poco. La realidad de la situación que yo viví es que el PO había abdicado de muchas de sus funciones en el equipo, hasta que el equipo se negó en redondo a seguir comunicándose con el cliente, dado que el PO luego llegaba a culpar al equipo de determinadas cosas que ahora el cliente quería o no, así que comenzó a pedir minutas de las reuniones por escrito. Son dos visiones de la misma moneda.

Pues en esas situaciones el catalizador es el Scrum Master. O mas bien debe serlo. 

 

 

El otro problema que veo es que según lo planteas, da la impresión de que el PO es el responsable de escribir el contenido del backlog, y que el equipo de desarrollo no es responsable de ayudarle en esta labor.

El PO es responsable de que exista un backlog que maximice el valor y por ello debe de colaborar con el equipo y buscar su cooperación para realizar esa labor. El equipo no es responsable de ayudarle en esa labor. El equipo, siguiendo los principios y valores ágiles colaborará y cooperará en lo necesario para que el backlog refleje eso.

El backlog debe ser como una fogata que nos invita a cantar alrededor. Una invitación a la visibilidad y la colaboración.

 

 

Conozco casos de excelentes POs que rara vez escriben una sola historia de usuario, y en su lugar se apoyan en el equipo para ello.

Mi experiencia me dice al contrario... conozco literalmente cientos de equipos cuyos PO abdican de su responsabilidad y es el equipo al final el que tiene que guisarse y comerse el backlog. Mi experiencia me dice que un product owner que no escribe de usuarios o es un facilitador excelente o un PO pésimo. Ojo, creo que es muy probable que tu experiencia te haya llevado a conocer a ese facilitador excelente y la mía a los pésimos y por eso miramos a través de distinto cristal.

 

Aqui yo regaría o alimentaría (dependiendo de si es un animal o vegetal) el paradigma de "todo esta conectado". Mientras sigamos viendo a los individuos como piezas, creo que seguimos razonando fuera del territoria de agilandia. O somos mecanicistas, o tayloristas, o algo similar.

Es importante descubrir que todo esta conectado con todo. Es como cuando decimos que si se falla, falla el equipo entero. Es que es verdad! No existe tal cosa como el "rendimiento individual". La misma persona, en diferentes contexto cambia su rendimiento. Un 100% Y al final lo que importa es el rendimiento de todo el equipo. No sirve de nada que 1 miembro sea excelente, y en lo global perdamos.

A veces nos quedamos mirando el aspecto de las cosas, y no vemos lo que hay detrás. Creo fundamental para todo agilista, ver el trasfondo de las cosas. Porque es lo que nos permite encontrar las causas raiz de los desafíos.

Nos quedamos con el "tal cosa falla", y no nos preguntamos porque?

O nos tentamos con la simpleza de señalar culpables, y no vemos que toda persona tiene necesidades. Que por encima de todo somos HUMANOS. Y eso significa muchas cosas. Entre ellas que somos frágiles, vulnerables, inseguros y emocionales. Pero nunca pésimos. Y por supuesto nunca perfectos.

Espero que mi matiz aporte algo, tiene la intención de repotenciar a todo aquel que lea el hilo. Intento que se vea otro angulo de la misma cosa.

Les envio un abrazo muy cordial y de admiración por su pasion y talento. Y me siento afortunado de poder participar en una lista tan prodigiosa de gente tan generosa.

Saludos!

[Adrian Listo Quilez]

jaja.. Genial Jerónimo.

Muchas gracias por contestarme, supongo que habrás necesitado 10 minutos de meditación antes y después de contestarme, y quizá habrás tenido que sustituir un nuevo teclado..  :P  Gracias por tu paciencia.

Tus explicaciones son muy buenas, te lo agradezco de veras; además siempre dejas caer alguna perlita sarcástica genial.. En particular, me quedo con lo claro que ves el distinguir las tareas propiamente de desarrollo y el Equipo, con lo que es más funcional y diseño de Producto, que es tarea del PO y queda fuera del sprint. Ha sido muy revelador.

Has diagnosticado un mal que en mi empresa estamos empezando a comprender: tradicionalmente hemos incluido muchas tareas del proyecto de definición funcional una vez arrancado el proyecto, entregables, etc.. en la definición del backlog; las funciones del PO  (como muy bien apuntabas) son reforzadas -impulsadas en realidad- desde el equipo técnico, de ahí el cacao.. Has dibujado muy bien el rol de PO, me lo apunto. Ahora mismo es el Team Leader el que está cubriendo al PO (Jefe de Proyecto), y no debería ser así.

Tomo muy buena nota y voy a tratar de aprender. De hecho inicio estos días un nuevo proyecto en el que tendré el rol de PO. Voy a trabajar en asegurar las funciones del PO.

El resto de puntos está claro.

Muchas gracias, me quito el sombrero.

El martes, 28 de enero de 2014 12:43:54 UTC+1, Jerónimo Palacios escribió:

En atención a lo establecido en la Ley Orgánica de Protección de Datos de Carácter Personal 15/1999, de 13 de diciembre, el tratamiento de los datos de carácter personal se hará exclusivamente para las finalidades con las que han sido recabados. Asimismo, le informamos de que goza de un derecho de acceso, oposición, rectificación y cancelación de los mismos, que podrá hacer efectivo en cualquier momento mediante la remisión de una comunicación escrita a "ENZYME ADVISING GROUP, S.L., Rambla Catalunya, número 111, 3º-1ª, 08008 Barcelona" o contactando con nosotros en el correo electrónico lo...@enzymeadvisinggroup.com.

Si ha recibido este mensaje por error, le rogamos que, elimine el mismo y lo comunique a su remitente. Gracias por su colaboración.

--
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/msgid/agile-spain/35e4bfdf-462d-4e4a-9580-6c09dd3736eb%40googlegroups.com.

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

[Adrian Listo Quilez]

jojojo.. EXCELENTE

Disculpadme, he contestado sin darme cuenta de que había un mail adicional de Jerónimo contestando a Jose Luis.

El "diálogo" que representa ese post es de un valor incalculable. Yo lo he marcado y creo que es de lo mejor que he leído por este foro.  ..supongo que condicionado por el hecho de que es un tema que me atañe particularmente..  ;-)

Un saludo a todos, y gracias por participar con tanto entusiasmo.

Aviso: La información contenida en este mensaje es confidencial, quedando totalmente prohibida por la ley su reproducción, publicación y divulgación total o parcial.

Mediante la remisión y/o contestación del presente correo electrónico usted consiente expresamente para que sus datos, recogidos en el mismo, sean tratados y pasen a formar parte de un fichero cuyo responsable de tratamiento es ENZYME ADVISING GROUP, S.L. siendo su finalidad cumplir correctamente con lo dispuesto en la relación contractual con ENZYME ADVISING GROUP. 

Asimismo, mediante la remisión y/o contestación del presente correo electrónico está dando su consentimiento para que, en caso de ser necesaria la cesión de sus datos a un tercero para el cumplimiento de fines directamente relacionados con nuestras funciones legítimas, estemos actuando conforme a Derecho. 

En atención a lo establecido en la Ley Orgánica de Protección de Datos de Carácter Personal 15/1999, de 13 de diciembre, el tratamiento de los datos de carácter personal se hará exclusivamente para las finalidades con las que han sido recabados. Asimismo, le informamos de que goza de un derecho de acceso, oposición, rectificación y cancelación de los mismos, que podrá hacer efectivo en cualquier momento mediante la remisión de una comunicación escrita a "ENZYME ADVISING GROUP, S.L., Rambla Catalunya, número 111, 3º-1ª, 08008 Barcelona" o contactando con nosotros en el correo electrónico lopd@enzymeadvisinggroup.com.

[Antonio de la Torre]

Hola:

Por alusiones :-)

Seré breve, para que no me leais en diagonal :)

@Jose Luis, por nuestra experiencia, empezar con un Sprint 1 (dos semanas), con un backlog vacío, es llenar un sprint de reuniones (Inception, taller de historias, infraestructura, etc.) que harán que la demo sea totalmente vacía de valor, además de confundir las expectativas del cliente de lo que deber ser la revisión del sprint.

Efectivamente Sprint 0 es un nombre. Xavier Quesada le cambió el nombre a Fase  "Inception", para evitar confusiones, pero en nuestra opinión hace falta distinguir fase de reuniones de conceptualización y definición, de fases de desarrollo, ritmo y entrega de valor, porque el enfoque de la entrega de "valor" cambia.

Dices:

> El problema es que nada te impide añadir un Sprint 0+, o un Sprint 0.5, o como queráis llamarlos, y podemos estar posponiendo la entrega de valor indefinidamente, lo cual es waterfall puro y duro.

El acuerdo al que todos tenemos que llegar es que la fase 0 tiene que durar lo justo lo necesario y suficiente y no más. "Nada te impide", entraría en el terreno de la mala práctica. (Hay una tira de XKCD muy buena sobre eso :-) )

 

El hilo del Sprint 0, para vuestro interés.

https://groups.google.com/d/msg/agile-spain/GuM7SqovaoE/ReeqJj4MdcgJ

Saludos!

Antonio

--
Twitter: @adelatorrefoss