El poder de los equipos pequeños y por qué deberías usarlos para el trabajo complejo

 

Foto de Annie Spratt en Unsplash

Para lograr equipos de alto rendimiento, la comunicación es clave. Esto significa que el equipo debe poder comunicarse de manera efectiva entre sí, así como con su entorno y otros grupos dentro de la empresa. Los equipos Scrum son una excelente manera de lograr esta comunicación, ya que son pequeños y serializados. Esto permite una mejor colaboración y elimina la necesidad de paralelismo, que a menudo puede generar problemas de comunicación.

Los equipos Scrum generalmente se componen hasta de 10 personas, pero bien sabemos que equipos más pequeños se comunican mejor y son más productivos. Es decir, de unos 4 a 6 miembros por equipo es un volumen adecuado para una microentidad de este tipo. Este tamaño permite un entorno de trabajo más íntimo y centrado, lo que ayuda a crear un sentido de propiedad entre el equipo, ya que cada individuo es responsable de sus tareas particulares y puede expresar sus ideas o inquietudes durante los eventos de Scrum. Todo esto, sin llegar al extremo de que cada persona tenga metas individuales o intereses apartados de los demás.

Otra ventaja de los equipos Scrum es que permiten el trabajo serializado. Esto significa que en lugar de tratar de hacer varias cosas a la vez, el equipo puede concentrarse en una tarea a la vez para avanzar de manera eficiente. Esto puede generar menos errores y mejorar la productividad, al tiempo que brinda la oportunidad de aprender nuevas habilidades en el camino.

Además, los equipos Scrum permiten una mejor comunicación entre todos los interesados. Los eventos de Scrum son una excelente manera de garantizar que todos estén en la misma página y que cualquier problema o pregunta se aborde de manera rápida y eficiente. Esto puede ayudar a evitar confusiones, desacuerdos y conflictos dentro del equipo y garantizar que todos trabajen hacia el mismo objetivo.

Así que si eres un Scrum Master extraordinario o quieres llegar a serlo debes asegurarte de que tu pequeño equipo Scrum tenga éxito. Es tu razón de ser. Tu única razón de estar. El resto de tu trabajo es derivativo. Te voy a contar cómo hacerlo:

Primero, cerciórate de que todos los miembros del equipo estén comprometidos con Scrum. Esto significa que están dispuestos a trabajar juntos en colaboración y comunicarse abiertamente entre sí. Aquí es donde entran en juego los valores Scrum de Compromiso y Respeto, entre otros. Pero también es soporte vital que haya un espíritu del juego Scrum, es decir, al usar Scrum, la comunidad de productos de tu organización debe enfocarse en crear explícitamente una cultura donde las personas conozcan y sigan el espíritu de Scrum: empirismo y pensamiento Lean, valores y pilares. todos los que trabajan en o con un Equipo Scrum deben ayudar a desarrollar esa cultura predicando con el ejemplo.

En segundo lugar, es importante tener un objetivo claro y compartido de lo que se quiere lograr como equipo. Esto ayudará a todos a mantenerse enfocados y motivados. Tener una identidad de equipo sirve en estos casos. Y el Team Canvas es una herramienta que te puede asistir para ello. Luego vendrán el Objetivo de Producto y las metas intermedias: el objetivo de cada sprint. Como Scrum Master tienes que lograr que estos elementos sean los motivadores universales de cada miembro del equipo. Trabaja con quien sea necesario (por ejemplo, Talento Humano) para que esta identidad y estos objetivos compartidos se conviertan en el motor de ensueño para cada persona del equipo: no es lo mismo “pegar ladrillos” que estar “construyendo la catedral de Notre Dame”.

También, es importante que les brindes todo el apoyo necesario a los miembros de tu equipo. Esto puede incluir capacitación, recursos físicos y materiales o simplemente tener a alguien disponible para responder preguntas.

Ahora bien, una cosa es el tamaño del equipo y otra el alcance del proyecto o el trabajo que van a realizar. Un equipo más pequeño puede moverse más rápido y ser más ágil, pero también puede tener menos capacidad para tareas complejas. Además, a los equipos más pequeños les puede resultar más difícil establecer funciones y responsabilidades claras. Como resultado, es importante considerar cuidadosamente los desafíos que podría enfrentar un equipo pequeño de Scrum antes de emprender una iniciativa.

Para superar estos desafíos, asegúrate de que todos los miembros del equipo entiendan su función y sean conscientes de las habilidades y destrezas de los demás miembros. Esto se puede hacer a través de comunicaciones y reuniones periódicas. También, establece con ellos expectativas claras para cada miembro del equipo. Y recuérdales constantemente que un equipo pequeño aún puede tener éxito si todos trabajan juntos hacia un objetivo común. Dale a cada persona la oportunidad de contribuir y expresar su opinión. Sé flexible con el proceso del equipo y “pon el empirismo a trabajar”, es decir, abre espacio a la prueba y el error a medida que el equipo encuentra lo que funciona mejor para ellos. Finalmente, mantén una comunicación abierta con el equipo e inspíralos a que este tipo de comunicación sea el modus vivendi y su pasión entre ellos mismos y con su entorno.

¿Te suenan algunas de estas ideas? ¿Algunas otras? Por favor, déjamelo saber en el foro.

El Planning Poker me arruinó por completo

Si llegaste hasta aquí pensando que voy a estigmatizar esta práctica de estimación ágil, aún estás a tiempo de hacer clic en algún otro lugar de tu navegador. Quizás aquí, mi artículo sobre “Estimaciones en los tiempos de la agilidad”, en cuya sección final decía que si sigues estimando como hace algún tiempo seguramente no estás en el camino ágil o te alejaste de este, es más, quizás ni estés haciendo estimaciones propiamente dichas. A lo que seguí con una serie de recomendaciones que terminaban con una enfática pero respetuosa propuesta de simplemente no estimes del todo, enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.

Se trata precisamente de evolucionar, de seguir experimentando y aprendiendo de los resultados de nuestros experimentos. Ya dimos el primer paso y fue dejar de usar técnicas tradicionales que requerían de tener mucha información y de hacer mucho trabajo que, a la postre, se convertía en desperdicio para la organización o que, en general, no era de valor para nadie. El nivel de predictibilidad era muy bajo, tuve la oportunidad de comprobarlo una y otra vez hasta la desesperación durante dos décadas. Luego empezamos a usar técnicas de estimación relativa y juegos como Planning Poker nos enseñaron a hacer mejores predicciones acerca del trabajo sin generar tanto desperdicio de tiempo.

A veces es posible hacer algo sin hacerlo. Una de las formas de estimar es no estimar. Sé que para llegar a eso el camino es cuesta arriba, pero eso muchas veces es bueno, porque cuando lo logras, ves que valió la pena porque la vista es fantástica.*

Así que avancemos un poco por ese camino…

Enfócate en generar Valor, no estimes

Imagen de Nattanan Kanchanaprat en Pixabay

Motiva al Dueño de Producto o a quien sea tu “cliente” a Ordenar por Valor todo lo que quiere. Acompáñalo en el proceso. Haz que se enamore profundamente de esta forma de pensar y de hacer basada en el valor, pero sin que llegue a odiar las formas anteriores. Hay muchas técnicas para ordenar el backlog:

• En función de lo que quieran tus clientes o consumidores
• Lo que los interesados internos quieren
• Lo que creas que impactará más
• La antiquísima MoSCoW
• Por Costo-Beneficio
• RoI (Retorno de la Inversión)
• VIP (el método del servicio preferencial)
• El costo de la demora
• Puedes elaborar una matriz Valor – Complejidad  

Puedes usar una combinación de estos, por ejemplo, entre dos elementos Requeridos (MoSCoW), implementa primero el que menor costo de implementación tenga y mayor beneficio te genere (Costo-Beneficio) o el que mayor retorno de la inversión te genere (RoI); entre dos elementos que te generen el mismo RoI, construye primero el de mayor costo de la demora (CoD) o el que te haya solicitado la persona más importante para tu organización de entre tus interesados. Aunque, ojo, esta persona no siempre es la de mayor rango jerárquico.

Hazlo gradualmente, de manera orgánica. Experimenta.

Imagen tomada de https://pixabay.com/images/id-512503/

Pasa de puntos de historias a tallas de camiseta. Pero no hagas un equivalente entre una talla y un número de puntos. Sería como tratar de saltar en paracaídas con una soga atada al avión, ¡no lo vas a lograr! Si lo que quieres es “medir” la velocidad del equipo, entonces cambia la escala también: ya no serán 30 o 47 puntos, sino seis elementos Talla M u ocho talla S, por ejemplo. Más adelante, busca una forma cada vez menos cuantitativa y más cualitativa de realizar la estimación, que tienda o evolucione siempre hacia el valor del incremento de producto a entregar y se aleje de una vez por todas y para siempre del esfuerzo necesario para hacer el trabajo o de la complejidad inherente a cada elemento del producto.

Evidentemente necesitarás kilometraje ágil. Tú, tu equipo y muy probablemente tu organización ya habrán llegado, al menos, a la cima de la curva de la innovación, en este caso, de cambio de forma de pensar y de hacer las cosas “a lo ágil”. Es decir, una gran mayoría temprana y un sector de la mayoría tardía, ya han entendido de qué se trata, ya han interiorizado, practican y promueven el pensamiento ágil, los valores y principios del Manifiesto Ágil, los pilares de Colabora, Entrega, Reflexiona y Mejora del Corazón de la Agilidad; y ya hay un sistema de valores de poca o ninguna variabilidad y consistente con las prácticas empresariales como base que guía el accionar de todos o de casi todos en la empresa y en su entorno.

Algunos patrones Scrum para estimar

Imagen de Achim Scholty en Pixabay

Usa patrones Scrum como el Gradiente de granularidad. ^(II)

Hemos experimentado y sabemos que los elementos pequeños son más fáciles de estimar, pero desglosar los elementos de trabajo es mucho trabajo en sí mismo. Las estimaciones de trabajo para pequeños incrementos de producto y tareas tienen menos errores que para los más grandes por tres razones:

·    La magnitud del trabajo (y, por lo tanto, del posible error) es menor que para un incremento o tarea más grande.

·    El equipo puede comprender mejor las entregas y tareas más pequeñas que las más grandes.

·    El porcentaje de error en las entregas y tareas más pequeñas es menor que en las grandes porque hay menos elementos de adivinanzas (y el tamaño máximo de cualquier error se mitiga implícitamente).

Por lo tanto:

Divide los primeros PBI en elementos pequeños de medio Sprint o menos de trabajo para una persona (aproximadamente el 10 % del trabajo total del Sprint) cada uno. El equipo debe desglosar los PBI posteriores para que su tamaño sea proporcional a su profundidad en el backlog Producto.

Otro patrón es el del Trabajo fijo. ^(III)

Scrum divide el tiempo en dos. Hay un cronograma continuo para el análisis y el negocio, y un cronograma cíclico de Sprint para la producción. El tiempo para el análisis y la innovación es imposible de estimar y puede desarrollarse durante largos intervalos, porque surge de manera impredecible en un proceso que Steve Johnson llama "la corazonada lenta" en su libro “Where Good Ideas Come From: The Natural History of Innovation”, Capítulo III, “The Slow Hunch”.

Todo el trabajo debe tenerse en cuenta si el Dueño del producto va a utilizar la velocidad del equipo para la planificación del lanzamiento del producto, pero no todo el trabajo de desarrollo puede tener un límite de tiempo.

Así que:

Divide todo el trabajo del Equipo de Desarrollo en aquel cuya duración estiman (es decir, trabajan en el producto) y lo que no pueden estimar (como el trabajo para entender los requisitos a medida que el equipo mueve los PBI a Preparado). En cada Sprint, reserva tiempos periódicos para el trabajo no estimable, fuera del presupuesto del Sprint, y completa la mayor parte de cada tipo de trabajo que permita el bloque de tiempo.

O este otro patrón del Alto valor primero.^(IV)

Que hace alarde del antiguo y conocido refrán “más vale pájaro en mano que un ciento volando”, y hoy por hoy los desarrollos a corto plazo deberían ofrecer valor lo antes posible.

Las cosas así:

Haz que tu equipo desarrolle primero los elementos del Producto de alto valor más esenciales.

Imagen basada en “A Scrum book”. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

También usa patrones como El Clima de Ayer, Equipos que terminan más temprano aceleran más rápido e Illegitimus Non Interruptus no solo para hacer mejores predicciones de lo que planeas entregar sino también para llevar a tu equipo a niveles de desempeño grandiosos y entregar más valor en menos tiempo, quizás el doble del valor en la mitad del tiempo. Para saber más de estos y otros patrones puedes ir a:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

Donde encontrarás sendas presentaciones para descargar y videos para ver sobre el tema.

Para finalizar

Como siempre, permite que las personas comprometidas con el trabajo decidan qué hacer respecto a la estimación. Guíalos. Muéstrales beneficios de uno u otro enfoque, de una u otra práctica. Y también perjuicios. Contrasta con el camino ágil recorrido. No es lo mismo un equipo u organización que apenas están saliendo de los enfoques tradicionales a uno que ya lleva ciertos kilómetros transitados.

Si este último es tu escenario, la próxima vez que quieras estimar algo, estima el valor de lo que vas a entregar, no el esfuerzo que te lleva realizarlo o la complejidad de lo que vas a hacer.

Y aunque no hablé de #NoEstimates, este es un movimiento, una filosofía, una visión de pensar acerca de cómo hacer algo, no es una técnica o metodología. Bueno, quizás estas ideas y propuestas constituyan un aporte a esa tendencia.

Referencias

* Basado en una frase de la película Hannah Montana (2009) que viera con mi hija Pamela, de 12 años entonces: “la vida es cuesta arriba, pero la vista es genial”.

(II) ¶59 Granularity Gradient. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(III) ¶23 Fixed Work. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(IV) ¶51 High Value First. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

Imagen de la portada basada en:

• Imagen de Natalia Ovcharenko en Pixabay
• Imagen de Mike Cohn en www.mountaingoatsoftware.com
• Imagen de Agile Poker Estimation Planning Cards by Clearly Agile, Inc.

Las historias de usuario como instrumentos de negociación

Hablemos un poco de ese continuum que significa diseñar y construir soluciones de valor para una organización. Las organizaciones hoy día están hechas de software, el software está en todas partes y si de construir software se trata, los equipos ágiles tenemos algo que decir.

De los incontables utensilios que contamos en nuestra mesa de trabajo las historias de usuario están siempre a la vista de quienes transitamos por los senderos de los problemas complejos y las soluciones para ellos. Para nosotros, trabajar en soluciones mejora la comprensión de los problemas. Esta es posiblemente la razón principal por la cual los enfoques iterativo e incremental son mejores que cualquier otro en la actualidad. Y si los combinamos, mucho mejor. Los Agilistas fantásticos:

1.     Construimos de manera iterativa para minimizar el riesgo

2.    Construimos de manera incremental para maximizar el retorno de la inversión (ROI)

3.    ¡Repetimos  1 y 2 hasta la saciedad! O hasta que se esté generando el suficiente valor como para detener nuestro esfuerzo de desarrollo.

En ese camino hemos aprendido que los problemas no son subjetivos. Lo subjetivo es la percepción que tengamos de esos problemas. En general estos se basan en la realidad. Además, los enfoques de pensamiento, nuestro mindset, pueden llegar a redefinir esos problemas por completo.

Ya sabemos que una historia de usuario no es un contrato firmado en piedra, más bien es una carta de intención de algo que el sistema debe hacer y cuyos detalles se abordan durante la conversación entre el usuario (Dueño del Producto) y el equipo de desarrollo. También son cartas de negociación entre unos y otros, pero solo habrá una negociación fluida si el usuario está realmente interesado en el éxito del esfuerzo de desarrollo, si está dispuesto a comunicarse de manera efectiva y a trabajar con y como parte del equipo.

Los ingredientes clave de una historia de usuario son: quién es el usuario, qué quiere hacer el usuario y por qué lo necesita. Contrario a lo que mucha gente cree, las personas (usuarios o consumidores finales, expertos con el conocimiento, interesados, patrocinadores y otras personas impactadas por la historia), constituyen lo más importante de una historia de usuario. Esto permite o posibilita la comunicación para que hagamos las cosas correctas y nos ayuda a identificar el valor para priorizar lo que haremos primero y lo que haremos más adelante.

La parte “conversación” de una historia de usuario idealmente es una colaboración entre el usuario y el equipo que construye la solución, es una asociación para entender el problema y trabajar precisamente en una solución que resuelva ese problema y también permite confirmar más adelante que esa solución de hecho sí resuelve el problema adecuadamente.

Las historias de usuario proporcionan un entorno, un medio para adaptarnos, para buscar oportunidades. Si encontramos un obstáculo que no es posible sortear, siempre podemos buscar otra historia relacionada que nos permita avanzar. Es posible que, al hacerlo, encontremos la solución a la historia que no nos permitía progresar en principio y podemos volver a ella.

Ahora bien, si esa carta de intención, esa necesidad que tiene el usuario, es muy específica, la tarea del equipo es preguntar “¿por qué?” ¿Por qué y para qué se necesita esa historia?; en cambio, si es muy abstracta, preguntaremos “¿cómo?” ¿Cómo lo hace? ¿Cómo quiere o quisiera la solución? Las historias de usuario siempre son sobre “negociación” si queremos un buen balance entre costo y valor.

En general, las historias de usuario nos permiten a los Agilistas fantásticos:

1.     Lograr este balance en pequeños alcances,

2.    Construir la solución, o los incrementos de esta, de tal manera que podamos obtener una efectiva retroalimentación anticipada.

3.    Trabajar en los aspectos de más valor primero para que sean entregados y empiecen a generar ROI lo más pronto posible.

Finalmente, ninguna discusión o exposición sobre historias de usuario estaría completa si no incluimos la palabra “confianza”. Si la confianza es poca en un equipo Scrum, las historias de usuario se convertirán muy pronto en piezas muy concretas de descripciones de problemas que el Dueño de Producto le entregará al equipo de desarrollo y que quizás nadie querrá resolver. Si esto ocurre, seguramente el equipo de desarrollo también va a solicitar, con grado de exigencia, unos criterios de aceptación muy concretos. El resultado: el muy pesado, extenso y falto de humanidad documento de especificación de requisitos funcionales y no funcionales del pasado, el mismo que cargaba consigo el sinsabor de la frustración y la derrota.

Entonces, para que positivamente las historias de usuario sean una herramienta auténtica de negociación entre las áreas de TI y las del negocio y para que sean una representación de los problemas de este último y de las soluciones que puedan proporcionar los primeros, es necesario que en el ambiente haya un alto grado de confianza. El Equipo Scrum en pleno, e incluso los interesados del entorno, tienen que conformar un equipo propiamente dicho, donde el trabajo colaborativo, la adaptación, el mejoramiento continuo y la entrega continua de valor sirvan de pilares y de integradores entre sus miembros para que todo lo anterior sea posible.

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

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

bit.ly/guiascrumes

Principios para Frameworks de Procesos de Software Efectivos

Septiembre 28 de 2015, por Scott Ambler

El framework de decisión de procesos de Disciplined Agile se guía por los siguientes principios:

1. Elegir es bueno y tomar decisiones informadas es mejor. Cada equipo es una colección única de individuos que enfrentan situaciones únicas dentro del contexto de una organización particular. Un único proceso no sirve para todo. Para facilitar la elección, el framework DA soporta varios ciclos de vida de entrega y es un proceso dirigido por metas. Y más importante, el framework DA describe las compensaciones involucradas con una gran variedad de prácticas ágiles y no ágiles que permiten a las personas a tomar decisiones inteligentes relacionadas con prácticas para adoptar la situación actual que enfrentan.
2. Optimizar el todo. El framework DA cubre todo el ciclo de TI, mostrando como encajan todos sus elementos. Si los equipos no entienden el entorno de los procesos, corren el riesgo de optimizar localmente sus propios procesos causando detrimento en el todo. Por ejemplo, el equipo de manejo de datos puede tener su propio proceso basado en estrategias DAMA (Gestión de Datos, por sus siglas en inglés) tradicionales, mientras que el equipo de entrega puede tener el proceso basado en los principios del Manifiesto Ágil y el equipo de operaciones puede tener su proceso basado en ITIL. Las cosas así, el proceso general se vuelve inefectivo porque estas tres estrategias individuales se contradicen y se degradan unas con otras cuando se combinan.
3. Cada equipo es dueño de su proceso. Los equipos y las personas miembros de esos equipos deben ser libres de mejorar la forma en que trabajan basados en su aprendizaje en el tiempo. En el parloteo ágil decimos que estos equipos “son dueños de sus procesos”.
4. Mejorar continuamente. Personas, equipos y organizaciones deben esforzarse por aprender y mejorar continuamente la forma en que trabajan. El framework DA incluye la meta de proceso Mejorar el Proceso y el Entorno del Equipo, la cual describe opciones para hacer exactamente lo que esto implica. También tiene un apartado explícito para el Mejoramiento Continuo de procesos que describe las estrategias para compartir mejoras entre equipos, incrementando de esta forma la velocidad de los esfuerzos de mejora de procesos de su organización.
5. Promover y apoyar el cambio en el proceso. Los departamentos de TI son sistemas adaptativos complejos. Una implicación de esto es que cualquier mejora que un equipo haga puede cambiar la forma en que trabajan con otros equipos, motivando mejoras de proceso dentro de esos equipos. Estos cambios a su vez pueden motivar mejoras dentro de otros equipos y así sucesivamente. Los equipos ágiles disciplinados son conscientes de su estatus corporativo y entienden que necesitan trabajar con otros equipos para ayudarlos a entender y a adoptar nuevas innovaciones y a prepararse para que otros los ayuden a hacer lo mismo.
6. Resultados repetibles son mucho más importantes que los procesos repetibles. Los equipos efectivos se enfocan en producir resultados repetibles, tales como entregar software de alta calidad que cubra las necesidades de los interesados de manera efectiva en tiempo y en costo. Debido a que cada equipo se encuentra así mismo en una situación única, para ser más eficientes necesitan seguir un único proceso personalizado que refleje esa situación. Ese “único proceso” puede constar de un ciclo de vida relativamente estándar y de prácticas comunes tales como la ideación de la arquitectura, pruebas de regresión de la base de datos y muchas otras (asumiendo que estas prácticas también se personalicen para reflejar esa la situación). A cada equipo en su organización se le debe permitir seguir su versión del proceso, idealmente compartiendo componentes similares del proceso, definidos por un framework común de proceso, para lograr los resultados requeridos.
7. El empirismo es mucho más importante que la teoría. Observar qué tan bien funciona una técnica en la práctica y, más importante aun, observar el contexto de las situaciones en las que (no) funciona, es de mayor valor para los practicantes que las teorías o la prognosis sobre lo que debería funcionar. La teoría tiene su lugar, pero es una prima pobre del empirismo. El framework DA se desarrolló originalmente basado en observaciones de docenas de organizaciones en todo el mundo y ha evolucionado desde entonces basado en el aprendizaje de muchas otras. Además está siendo respaldado por investigaciones en curso de nuestra industria.

Los departamentos de TI son sistemas adaptativos complejos únicos. Cualquier persona que trabaje en un ambiente así necesita un framework de proceso que sea lo suficientemente flexible como para que aborde el amplio rango de situaciones que enfrentan sus equipos. El framework de decisión de procesos DA es liviano a la vez que lo suficientemente flexible para soportar el escalamiento tanto a nivel táctico como estratégico.

-----

Nota del traductor, o sea yo:

Este artículo se publicó originalmente en inglés por Scott Ambler, bajo el título de “Principles for Effective Software Process Frameworks” que pueden encontrar en: http://www.disciplinedagiledelivery.com/software-process-framework-principles/

Publicado con permiso del autor.