Buscar en Gazafatonario IT

sábado, noviembre 26, 2016

User Story Mapping - Una introducción


El User Story Map es una herramienta que permite generar una representación visual del producto completo. Ofrece una vista general de todas las funcionalidades que lo componen (the big picture) de punta a punta. 

Permite identificar Historias de Usuario faltantes en el Backlog, planificar Releases (entregas) dividiéndolo en porciones (Slicing) y visualizar cómo se distribuyen las funcionalidades de acuerdo a las diferentes áreas del sistema.

Son diferentes a los backlogs típicos de historias de usuario en cuanto: 

  • Hacen visible el flujo de trabajo o la cadena de valor
  • Muestran las relaciones entre historias más grandes y sus historias hijas
  • Ayudan a confirmar la completitud del backlog
  • Proporcionan un contexto útil para la priorización
  • Permiten planear entregas (releases) en porciones valuadas y completas de funcionalidad

En esta presentación, basada en el trabajo de Jeff patton, hago una breve introducción al tema de User Story Mapping. La pueden descargar de:


martes, noviembre 08, 2016

Más de cómo ser un Scrum Master extraordinario

Créditos de la foto: Dean Potter's solo walk at Taft Point in Yosemite by Photographer Jeff Cunningham.
Entender que Scrum no es una metodología sino un marco de trabajo (framework) que propone unos pocos lineamientos ayuda. No existen reglas que apliquen a todos y cada uno de los escenarios posibles donde se usa, solo algunas prácticas que han funcionado en algunas organizaciones con anterioridad.
Como Scrum Master o Coach ágil necesitas determinar o encontrar por tu cuenta lo que funciona para la Organización con la que estás involucrado. Si lo logras, lo conviertes en un destino, no en un proceso. De eso se trata el empirismo.
Ser Scrum Master o Coach ágil es principalmente acerca de liderazgo y coaching. No es un rol de gestión. No eres un gerente de proyectos ni de personas. Además, ser Scrum Master o Coach ágil definitivamente no es acerca de reforzar los procesos.
Scrum no está diseñado para Contadores. Algunas métricas son útiles para entender la salud de un equipo Scrum pero por lo general insistir en “cumplir con distintas KPI” (como por ejemplo ‘compromisos versus velocidad’) no ayuda. Si eres un Scrum Master excepcional seguro mantendrás a tu equipo libre de esta clase de presión.
Scrum no tiene mucho que decir sobre el proceso que habilita al Dueño de Producto a llenar el Backlog con historias de usuario de valor, usables y factibles. El descubrimiento del producto basado en Lean UX, Design Thinking o Lean Startup puede ayudar a esta causa. Un Scrum Master extraordinario quiere o querrá que su equipo sea parte de esta carrera evolutiva – por ejemplo, haciéndolos partícipes de entrevistas con los usuarios o haciendo experimentos.
La comunicación del equipo con los interesados no debería ser únicamente a través de un guardián o “proxy” (por ejemplo, solo a través del Dueño de Producto). Hacerlo así hiere de gravedad la transparencia y afecta negativamente el desempeño del equipo. Las revisiones de Sprint son una buena forma de presentar el valor entregado por el equipo durante el Sprint que está finalizando pero también es una buena manera de estar en contacto cercano con los interesados.
Si quieres llegar a ser un Scrum Master extraordinario enfoca tu energía en construir un entorno grandioso para tu equipo, probablemente así no tendrás que pasarte la vida, tu fantástica vida como Scrum Master, removiendo impedimentos.
De esta manera encontrarás ese balance del que habla mi amigo Johhny Ordoñez* y que requiere la Agilidad Moderna para seguir evolucionando y seguir transformándonos en mejores personas cada día, ese balance a nivel personal, de equipo, de grupo, de organización y de sociedad.
*https://twitter.com/JohnnyOrdonez/status/788097273674788864
-------
Más sobre cómo ir de Scrum Master bueno a Scrum Master grandioso en http://www.gazafatonarioit.com/2015/05/de-scrum-master-bueno-scrum-master.html

miércoles, noviembre 02, 2016

Planear sprints en horas y no por puntos


Hace algunos días nuestro amigo Carlos Jaramillo nos preguntaba a algunos colegas si estábamos de acuerdo con el legendario Mike Cohn cuando dice que los sprints deberían planearse con horas y no con puntos. Carlos se refirió específicamente al artículo Why Sprints Should Be Planned with Hours, Not Points (Por qué los sprints deberían planearse con horas, no con puntos).

Como lo dice Cohn al inicio de su artículo, para mí y creo que para muchos de los que hemos leído su libro Agile Estimating and planning (Estimación y Planificación Ágil) fue una sorpresa cuando vimos el título ya que sabemos que él es un gran referente y promotor de los puntos de historia y de su uso. Pero pasemos a la que fue mi respuesta entonces:

¡Estoy de acuerdo!

En particular, estoy de acuerdo con Mike cuando dice que “los puntos (de historia) son demasiado imprecisos para ser útiles en el corto plazo”, es decir, en un sprint de menos de un mes. También me gustaría destacar aquello de que la velocidad, aunque ligeramente, puede variar de sprint a sprint.

Además de lo que dice Cohn en su artículo algunas otras razones me llevan a pensar así:

No hay una correlación directa entre puntos de historia y el esfuerzo de implementación de la historia de usuario. Es decir, no existe tal regla o ley que señale que si un punto de historia toma H horas implementarse, N puntos de historia tomarán N x H horas implementarse (por ejemplo: si la implementación de una historia de un (1) punto toma 25 horas, entonces la implementación de una historia de 2 puntos tomará 50 horas, no).

Es probable, eso sí, que al final, después de muchos sprints, el promedio muestre tendencia hacia esos números, pero nada evita, en el escenario propuesto, que una historia de 2 puntos le tome al equipo 15 horas y otra también de 2 puntos le tome 35 horas para implementarla o cualquier otro número, incluso podríamos tener una historia de 2 puntos cuya implementación tome 10 horas o menos. En cualquier caso, eso apenas sería la tendencia natural.

Además, aun con ritmo sostenido y con entrega de valor constante en cada sprint, no es lo mismo un equipo en el primer sprint del proyecto que en el séptimo o en el décimo noveno. No es lo mismo un equipo en abril que en septiembre o en diciembre. No es lo mismo un equipo si el proyecto va bien desde varios puntos de vista, como el valor entregado, la calidad, el consumo de presupuesto, etcétera, o si va regular o mal; y no es lo mismo si el equipo y aun la organización a la que pertenece han estado mejorando continuamente o si su crecimiento personal y profesional se ha estancado por acción del proyecto.

Todos esos factores que acabo de mencionar impactan positiva o negativamente la motivación del equipo y por consiguiente, el rendimiento de los miembros del equipo. Lo que finalmente se traduce en número de horas de esfuerzo necesarias para implementar una historia, o sea, para llevarla de ‘Propuesta’ o ‘En proceso’ a ‘Terminada’.

La misma calidad y el tamaño de las historias de usuario también afectan de una forma u otra el esfuerzo requerido para su implementación. Me refiero a la calidad con que son comunicadas al equipo por el Dueño de Producto o por quien corresponda, así también perturba de manera distinta una historia de 2 puntos que una de 5 o una de 8.

Y todo esto para concluir que en cada Planificación de Sprint se debe hacer el ejercicio de, precisamente, planear por horas de esfuerzo, de eso se trata esta ceremonia inicial de Scrum después de todo. La gran diferencia con la planificación de los métodos tradicionalistas es que no vamos a planear seis meses de trabajo o un año o dos, no, se trata solo de adelantarnos a lo que va a pasar en las próximas 2 semanas de trabajo, quizás tres.

Nuestros equipos deben o deberían tener el conocimiento y la experiencia para decirle al Dueño de Producto y al mismo Scrum Master, al final de la Planificación, cómo intentarán hacer su trabajo en el sprint que comienza y eso incluye contarnos el número de horas de esfuerzo que tomará implementar una historia de usuario en particular. Se trata es de dilucidar cuando nos tomará el diseño, la programación, las pruebas, la integración, la documentación y cualquier otra actividad concerniente a la construcción de la historia. Después de todo, para eso fue que precisamente se conformó el equipo.

¡Pero hay más!

Usamos Puntos de Historia para estimar el backlog y el esfuerzo a mediano y largo plazo porque son o representan un valor abstracto. También sabemos que es posible usar otros métodos abstractos de estimación como 'tallas de camisetas', días ideales, colores, tamaño de los planetas o, incluso como dice mi amigo Jorge Abad en sus Lecciones Aprendidas, podemos usar la técnica del ‘ojo de buen cubero’, estimar con Garrapatandamandapispuntos o con cualquier otra medida cuyas convenciones sean bien conocidas por todo el equipo.

El precepto fundamental aquí es que todos estos métodos producen estimados y los estimados, sobre todo en software, están condenados al error. Casi 50 años de experiencias después de aquella remota conferencia de la OTAN en Garmisch en la que de alguna manera se dio vida a la Ingeniería de Software nos han demostrado eso.

En cualquier caso para estos escenarios de mediano/largo plazo, si un usuario o cliente está exigiendo estimar en horas un proyecto Ágil, todavía no ha entendido el enfoque y necesita guía en ese sentido. Las horas son algo concreto sí, pero solo para lo que he explicado arriba, estimar un sprint corto o muy corto, de muy pocos días a dos semanas.

Pero igual que con los puntos, estimar con horas no nos eximirá del error inherente a las estimaciones. Así que en vez de salir corriendo detrás de las horas, deberíamos enfocarnos en habilitar y empoderar nuestros equipos para que hagan un mejor trabajo.
----------
¿Ustedes qué creen? ¿Cómo estiman los sprints? Déjenmelo saber en el foro - la sección de comentarios más abajo.


----------
Más sobre Planificación en:



El artículo de referencia de Mike Cohn lo pueden encontrar en:

miércoles, octubre 26, 2016

Ecce homo o el Ágil es algo que eres

Ecce Homo restaurado de Cecilia Giménez
En el mundo moderno, las personas profesionales tienen una preocupación, con visos de ansiedad, vinculada a su ADN, sobre todo quienes trabajan en o alrededor de compañías de TI: ser competitivas, exhibir un alto desempeño y lograr metas en plazos cortos. Las actividades que realizan y los resultados, productos o servicios generados, deben ostentar estándares elevados de calidad. Este escenario sube el nivel de estrés de quienes lo intentan día a día, aunque también acentúa el grado de satisfacción cuando se alcanzan esos objetivos.
Es precisamente bajo esta atmósfera donde el enfoque ágil presume de sus incontables beneficios. El movimiento Ágil, que no es una metodología, nos permite encontrar y poner en práctica alternativas a la gestión tradicional de personas, proyectos y organizaciones. Esta perspectiva Ágil ayuda a los equipos a responder de manera oportuna a la poca o incierta predictibilidad a través de cadencias de trabajo incremental e iterativo y de la retroalimentación empírica.
Este modelo de desarrollo repetitivo o de ciclos de trabajo abreviados, también nos habilita a las personas y a los equipos para ser cada vez más expertos en cada uno de los aspectos de la construcción de productos. En el caso de la Ingeniería de  Software, hablamos de los requisitos, diseño, programación, pruebas, integración, etcétera. Pero este enfoque puede aplicarse en muchos otros entornos de producción y operación, una oportunidad que no teníamos con el modelo tradicionalista en Cascada, donde solo había una única  ocurrencia para hacer las cosas.
Esta evolución de la eficacia en el trabajo relacionada con proyectos de desarrollo sistémico es notoria y nos permite, a su vez, ofrecer una mayor garantía de calidad y de cumplimiento con las fechas límite, aunque surgen algunos efectos colaterales de la aplicación del modelo: nos volvemos menos predictivos (¡bueno, tampoco es que antes fuéramos altamente predictivos!), se acaba eso de culpar a alguien más si las cosas no salen bien y el hecho de que Ágil requiere mucho más compromiso y esfuerzo (¡aun a ritmo sostenido!) de todos los involucrados.

Ágil es algo que eres, las prácticas y los frameworks son algo que usas

Dentro de esos innumerables beneficios de la estrategia Ágil encontramos que las características más importantes del producto reciben la más alta prioridad y que incrementos funcionales del producto se entregan desde temprano y frecuentemente; además, las prácticas y marcos de trabajo livianos que acompañan el enfoque simplifican en grande el flujo de trabajo a la vez que solo se produce la documentación necesaria y suficiente para facilitar el control del producto por parte del usuario o cliente; por último, mi beneficio favorito de este conjunto, todo esto conduce a esa eficiencia y eficacia que mencionaba al principio, lo que a su vez confluye en equipos con personas altamente motivadas y felices que exhiben un alto desempeño, sin la carga de estrés impuesta por los métodos antiguos.
Cómo se logra esto es otro asunto pero son esenciales para ello la comunicación y la colaboración no solo entre los miembros del equipo sino con las personas del entorno, los interesados. También es importante que apliquemos la filosofía Ágil donde y cuando genere valor, aunque no se me ocurre en este momento un escenario donde esto no sea posible. No se trata solo de usar Scrum, Kanban o Lean, SAFe o Nexus, o de hacer retrospectivas por hacerlas, que apenas son artefactos y comportamientos visibles, esa porción de la cultura que nos permite hacer Ágil.
Se trata es de entender y practicar las formas de racionalizar y las estructuras cognitivas de elementos como la comunicación cara a cara, la simplicidad, el compromiso, las entregas incrementales de producto funcionando con valor, la calidad y la satisfacción del cliente, entre muchos otros; pero más en el fondo o en la base, este enfoque es acerca de cultivar y experimentar continuamente valores y creencias relacionados con las personas y sus interacciones, el coraje, el respeto, la inspección y la adaptación  permanentes, la transparencia, la respuesta a los cambios constantes y tantos otros elementos que constituyen eso que conocemos como Manifiesto Ágil, es esa otra porción de fondo de la cultura que nos permite Ser Ágil.

Ágil significa reemplazar la predictibilidad falsa por la eficiencia

Las organizaciones que han incorporado estos paradigmas ágiles, por su parte, entienden que las personas experimentadas, con amplias habilidades en la resolución de problemas y en el mejoramiento de procesos, son extremadamente valiosas para hacer realidad la visión organizacional. Estas compañías reconocen que el costo de desarrollar personas con estas habilidades es grande, especialmente si quieren involucrarlas y comprometerlas en la mejora continua de procesos. Por eso no solo les proporcionan las herramientas y los recursos necesarios para entrenarse continuamente sino que también disponen de agentes de cambio que los ayudan a potenciar sus destrezas.
De esta manera es que hemos abierto nuestras mentes para enfocarnos en las personas y nuestras interacciones con ellas y cómo colaboramos con nuestros clientes y en cómo pensamos acerca de nuestro trabajo y en tácticas que nos descubran el camino hacia la superación perpetua. Nos concierne y nos motiva enfrentar los cambios, nos interesa ser la estrategia, no simplemente apoyarla, somos líderes por naturaleza, pero líderes con el poder de influenciar a otros, no de gobernarlos, nos gusta animar a los demás a que compartan nuestra visión y compartimos la de ellos, no miramos al pasado sino para aprender  y nos hacemos cargo del futuro.
Las reglas del juego cambiaron, ¿te diste cuenta? Déjamelo saber en el foro.
---
Más sobre Filosofía Ágil en:

miércoles, octubre 12, 2016

Dueño de Producto, usted ha sido invitado a la Retrospectiva

El Dueño de Producto, ¡ese ilustre olvidado!
Me preguntan por interno si este personaje debe asistir a la ceremonia de inspección y adaptación. Es una buena pregunta, teniendo en cuenta que hay quienes recomiendan que no sea así o que la participación del Dueño de Producto es opcional en la Retrospectiva.
No hay ninguna buena razón por la cual el Dueño de Producto no deba estar en la retrospectiva. Desde la misma guía de Scrum ya sus autores sugieren que debería participar:
"La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint".
Y ya sabemos que el Equipo Scrum se compone de Scrum Master + Desarrolladores + Dueño de Producto.
Pero más allá de esto, no concibo cómo, sin la participación del Dueño de Producto en esta reunión, sea posible que el equipo en pleno se inspeccione a sí mismo para luego crear un plan de mejoras que nunca estará completo sin la intervención de este actor. Por ejemplo, ¿cómo mejorar la comunicación con el entorno del negocio? El resto del equipo no podría definir la mejor estrategia para lograrlo en ausencia del Dueño de Producto.
Algunos dirán que se define la estrategia en la reunión y luego se la comunican al Dueño de Producto, eso simplemente extendería la retrospectiva, con el riesgo de que él "tumbe" las acciones a realizar por cualquier motivo válido.
  • ¿Y qué pasa si hay problemas con la salud del backlog? 
  • Problemas con la definición de los criterios de aceptación de las historias de usuario.
  • ¿El equipo conoce cómo los usuarios realmente usan el producto?
  • Problemas con la aceptación del incremento sprint tras sprint.
  • ¿El equipo conoce la visión completa del producto, la estrategia de implementación y cómo lo quieren los usuarios?
  • ¿Y qué ocurre si el Dueño de Producto no está el tiempo suficiente con el equipo para responder sus preguntas y clarificar las características del producto? O para proporcionar retroalimentación efectiva.
En fin, muchas son las razones para que el Dueño de Producto sí esté en la reunión. Estas que mencioné son solo algunas. En breve, el Dueño de Producto es protagonista principal en esta ceremonia.
Ahora bien, se me ocurren algunas malas razones por las cuales no debería asistir. Las mencionaré brevemente y estableceré alguna razón sólida para no tenerlas en cuenta:
Lo aburrimos con minucias técnicas. Una retrospectiva no es para profundizar en los detalles de lo puramente técnico.
El equipo de desarrollo y el Scrum Master son de un proveedor y el Dueño de Producto es del Cliente. Entonces dónde queda la confianza y, por consiguiente, la transparencia. Si estamos pensando así, todavía nos hace falta mucho de la Cultura Ágil y de liderazgo. En cualquier caso, esta práctica reduciría mucho la transparencia, necesaria a todas luces en un entorno ágil.
No tiene tiempo. ¡Este es, precisamente, un tema a abordar con él en la retrospectiva!
Así lo hemos hecho aquí y nos funciona. Esta es interesante. ¿Y qué tal si lo hacemos de la otra forma (que si asista) y vemos la diferencia? ¿Mejoramos o empeoramos? Seguramente será lo primero.
Esta última es la típica cuestión que se enmarca en el empirismo, es decir, aprendemos de la experiencia, como todo en Scrum. Algo que se resume también en eso de "usar o hacer lo que te funciona". Sin embargo, las razones que expuse al principio y muchas otras precisamente nos han enseñado los beneficios de la presencia del Dueño de Producto en la ceremonia.
Entre otras, pero todas absolutamente son "malas" razones.
En definitiva, el Dueño de Producto debería (sí debe) asistir a las retrospectivas, así que adelante. Si como Scrum Master te sugieren que el Dueño de Producto no debe estar en la reunión, te enfrentas a una sintomatología que te indica que falta algo de la base, los valores y principios ágiles, la forma cómo racionalizamos, el fondo de la cultura ágil, más que del mismo Scrum y otras prácticas.
---
¿Y tú, invitas al Dueño de Producto a tus retrospectivas? Déjamelo saber en la sección de comentarios más abajo.

martes, agosto 23, 2016

Inceptions, con Jorge Abad



¿Cómo nacen los productos grandiosos? De esos cuyos componentes hacen resonancia entre sí e impactan el 'modus vivendi' de quienes los usan o consumen.

¿Cómo defines su alcance?

¿Cómo estableces el Producto Mínimo Viable - MVP?

¿Cuáles son las distintas técnicas y prácticas ágiles para hacer Inceptions de gran calidad y que motiven al equipo a empezar un trabajo fabuloso?

¿Qué es eso del Elevator Pitch?

¿Y el Product Box?

Además:

El User Story Mapping

+ El plan de entregas

+ El plan de iteraciones

+ Otras técnicas y herramientas que nos ayudan no solo a entender lo que queremos construir (lo que quieren nuestros usuarios o clientes), sino también a lograr consenso entre los miembros del equipo y los interesados en el proyecto y producto o servicio que queremos diseñar y construir.

Estas y algunas otras cuestiones son las que compartí con mi gran amigo Jorge Abad, con ejemplos concretos y prácticos, durante el Webinar del mismo nombre. El video lo pueden encontrar en:



Pueden descargar la presentación de:



Nota:
Este post lo podrás encontrar también en el blog de mi estimado amigo Jorge Abad @Jorge_Abad (Inceptions, con Lucho Salazar)



sábado, julio 30, 2016

Un vistazo a la guía de Scrum

¿Hace cuánto leíste por última vez la guía de Scrum? Es bien sabido que a medida que tu experiencia y conocimientos crecen, tu forma de ver (leer) algo cambia respecto a la vez anterior. Quizás aprendas algo más, quizás seas capaz de visualizar o entender algo que antes no habías percibido o entendido.

Aprovechando la revisión de la que fue objeto la guía por parte de sus autores y de que había que traducir esa actualización, realicé una revisión exhaustiva tanto de la versión en inglés como de la versión en español en la que tuve la oportunidad de trabajar por primera vez en 2013. (Para conocer los cambios introducidos a la guía, ve a: http://www.gazafatonarioit.com/2016/07/revision-la-guia-de-scrum.html)

Con tres años más de experiencia y conocimiento en Scrum y temas relacionados, me tomé la libertad de actualizar la Gramática y redacción del documento y también algunos asuntos de fondo que me hacían ruido desde hacía mucho tiempo respecto a la versión original de la guía en inglés.

Con todo esto, aproveché también para “repasar” lo que dice la guía, para mirarla más a fondo y decidí traer aquí una lista, arbitraria por demás, pero de todo mi gusto, de algunos puntos que quiero resaltar. Son los siguientes:
“Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas”.
Es impresionante la cantidad de personas, equipos y organizaciones que solo “aprenden” o quieren aprender Scrum, como si con eso fuera suficiente para hacer todo el trabajado que se les viene por delante. La lista de proceso, técnicas, marcos de trabajo y prácticas que podemos y deberíamos usar con Scrum es extensísima, no voy a elaborarla aquí, pero lo que sí es cierto, lamentándolo mucho por quienes no lo han visto, es que Scrum solo no es suficiente.
“Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar”.
Scrum se basa en la teoría empírica  de control de procesos. Esto quiere decir básicamente que aprendemos de la experiencia. Scrum nos permite visualizar la eficacia las prácticas que usamos las personas, los equipos y las organizaciones y nos permite inspeccionarlas continuamente y adaptarlas y adaptarnos de acuerdo con los distintos escenarios circundantes.
“El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto”.
Todavía me encuentro con muchos equipos y organizaciones que no terminan de integrar al negocio, vía el Dueño de Producto, en sus equipos. Y muchos menos son los Dueños de Producto que realmente actúan como tal. El muy comentado pero pocas veces entendido “backlog” de producto sigue siendo gestionado por el equipo y muchas veces solo por el Scrum Master o por alguien más que no es ninguno de los roles propuestos en la guía.
“El Scrum Master es el responsable de asegurar que Scrum se entienda y se adopte. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum”.
Usar Scrum no nos hace ágiles, eso lo tenemos claro muchos. Pero muchos no tienen claro que si vamos a usar Scrum como marco de trabajo ágil, debemos ajustarnos a las reglas enumeradas en la guía. Estas reglas condensan la experiencia de muchos años de trabajo, sobre todo en proyectos de software, de los autores y de muchos otros en la industria. Conjuguemos esta observación con la del primer punto más arriba.
“La Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un mes. Para Sprints más cortos el evento es usualmente más corto”.
En las versiones anteriores es español aquí decía que el tiempo de las reuniones era proporcional a estas ocho horas para sprints más cortos. En ninguna parte de la guía original en inglés dice así, de tal forma que la actualicé en este sentido.
“Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”.
¿Cuántos de los equipos en los que has trabajado, en los que eres Scrum Master, miembro del Equipo o Dueño de Producto, hacen esto? De hecho, muchos quieren terminar lo más rápido posible la planificación para ponerse a trabajar pero nadie es capaz de explicar cómo van a trabajar para lograr la meta trazada del Sprint.
“El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas”.
Es más, muchas veces los equipos no establecen un objetivo más allá de aquel que indica el número de historias de usuario a construir en el sprint. La meta del Sprint debería ser algo más de Valor para el Dueño de Producto y, por ende, para el negocio. Dejaré este asunto de la meta del sprint para otro artículo pero además de pensar en las características o funcionalidades a implementar siempre es bueno pensar en las razones para llevar a cabo la iteración. Bien sabemos que metas efectivas nos sirven para probar o demostrar que nuestras ideas funcionan, para fomentar el trabajo en equipo, para reducir o eliminar un riesgo específico o para proporcionar mayor valor entregado al negocio.
 “El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o replanificar el resto del trabajo del Sprint”.
La expresión clave aquí es “a menudo”. Hacer otras cosas después de la reunión diaria puede hacernos perder foco y, por consiguiente, productividad y puede alejarnos de la consecución del objetivo del sprint. Por ejemplo, en la reunión diaria no hablamos de las soluciones a los impedimentos, entonces es buena idea tener reuniones específicas sobre estos asuntos justo después de aquella.
“El Scrum Master se asegura de que se cumpla la regla de que solo los miembros del Equipo de Desarrollo participan en el Scrum Diario”.
Sigo viendo mucho de comando y control en la reunión diaria. ¡El seguimiento diario, dicen algunos! Esta es una reunión de coordinación, de planificación, es precisamente “una reunión clave de inspección y adaptación”. Cualquier otra cosa que se requiera hacer con el equipo, debe ser en otra reunión especial, no en esta.
“Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor”.
La Revisión de Sprint no es solo para hacer la demostración del incremento de producto terminado. Y puesto que a esta reunión asisten o pueden asistir interesados clave en el producto, es una oportunidad única para discutir lo que viene a continuación en el proyecto.
“Una Lista de Producto nunca está completa. Mientras el producto exista, su Lista de Producto también existe”.
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. ¿Hace falta decir algo más?
“Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor”.
El valor para el negocio. Noten además que hablamos de “los elementos de la lista”, no son solo historias de usuario, como muchos erróneamente creen y manifiestan.
“Scrum no reconoce subequipos en los equipos de desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla”.
No existe tal cosa como “ellos y nosotros”, somos un único equipo indivisible, somos una unidad morfológica (orgánica) y funcional y actuamos como tal. Valoramos las habilidades y fortalezas de cada uno de los miembros de esta unidad, pero hacia el mundo exterior somos El Equipo.


Y bueno, como dice mi amigo y colega Jorge Abad, hasta aquí estas reflexiones, viscerales por demás, sobre la guía de Scrum. Los invito a que la descarguen y vuelvan a leerla y a que nos cuenten en el foro cuáles son sus puntos favoritos de la guía, con cuál no están de acuerdo, cuál cambiarían, etcétera.

También pueden descargar la guía de:

Guía de Scrum en español