featured

Los equipos auto-organizados, cross-funcionales, componentes y full-stack

Últimamente veo cada vez más confusión en torno al concepto de equipo ágil. Ahora que muchas organizaciones han decidido subirse al carro de la agilidad y los Agile Coaches que nunca han tenido ninguna experiencia real en Scrum, Kanban, Nexus, SAFe o LeSS -muchos de ellos dicen que lo que son es seguidores del Agile Manifesto– están recomendando a sus clientes estructuras de equipo que no tienen mucho sentido, es necesario clarificar cuales son los significados de cada uno de los términos y cuando tienen sentido aplicarlos.

La alineación entre Producto, Equipo y Arquitectura

Lo primero es tener en cuenta como está organizado nuestro producto. Esta es la primera limitante. Si tenemos un backlog organizado por componente, difícilmente podremos tener equipos de feature. Aunque esto se puede cambiar, si tenemos un Producto organizado por features y un equipo alineado, si trabajamos con una arquitectura monolítica, tendremos que lidiar con muchos retos adicionales.

¿Que quiere decir esto? Que producto, equipo y tecnología no están separados, sino precisamente lo contrario. Las decisiones en cuanto a la arquitectura de nuestras aplicaciones afecta a la composición de los equipos y a la manera de organizar nuestro producto.

Los equipos cross-funcionales

La guía de Scrum introduce el concepto de equipo cross-funcional. Este es un equipo que es capaz de transformar un Product Backlog Item (PBI) en un incremento terminado al final del Sprint. La definición no va más allá de eso.

El equipo de desarrollo tiene que ser un equipo cross-funcional. Si nuestro backlog está organizado en torno a componentes, entonces un equipo especializado en una tecnología en concreto puede ser un equipo cross-funcional.

Si está organizado en torno a características end-to-end de la aplicación, entonces tendrá que tener más generalistas que especialistas, o al menos lo suficiente para poder entregar al menos un incremento terminado durante el Sprint.

Un equipo cross-funcional puede ser un equipo de feature, uno de componente o un full-stack, pero no necesariamente todos esos tienen que ser un equipo cross-funcional. De nuevo, depende de la organización de la arquitectura de nuestro producto y de la organización del Producto en sí mismo.

Equipos de componente

Los equipos de componente son aquellos que están organizados en torno a capas de la aplicación. Normalmente serán dos o más equipos cada uno especializado en distintas partes de la tecnología. Por ejemplo, un equipo de front-end y un equipo de back-end, como podemos ver en la imagen.

La principal ventaja de los equipos de componentes es que economizan la utilización de personas, es decir, permiten que los equipos avancen a distintas velocidades asegurándonos que nadie está parado en ningún momento. El equipo 3 puede estar desarrollando cosas que se harán en unos meses mientras que el equipo 2 está preparando la próxima release. Son baratos.

La mayor pega es que las cosas no suelen funcionar como lo esperábamos y cuando necesitamos disponer del equipo 1 de nuevo, ya están ocupados haciendo otras cosas, lo que implica empezar a crear colas que tienden a infinito. A pesar de ser baratos, una estructura de equipos de componente siempre será más lenta en órdenes de magnitud que cualquier otra organización.

Este es el motivo por el que organizaciones que se estructuran de esta manera tienen ciclos de desarrollo de software que en ocasiones llegan a llevar años de principio a fin.

Equipos de feature

Los equipos de feature buscan arreglar esto. Estos equipos se organizan teniendo distintos especialistas-generalistas que pueden cubrir el desarrollo de una nueva feature orientada al usuario final. No necesariamente tienen que cubrir todas las capas de una aplicación, sino que pueden estar más especializados en un área (Pagos) que en otra (Cuenta de usuario).

La principal ventaja de estos equipos es que son mucho más ágiles que las estructuras de componente, lo que hace que sean mucho más aptos para Scrum, que requiere un incremento terminado en 30 días o menos. Algunas de las pegas más comunes de los equipos de feature son:

Hay que crear una cultura de equipo orientado a un sólo objetivo
El uso de Sprint Goals es necesario para conseguir este objetivo
No todo el mundo está completamente ocupado todo el tiempo
Pueden dar lugar a frustración de algunos miembros del equipo de desarrollo
Requieren de habilidades transversales en lugar de especialización.
En grandes organizaciones donde muchos equipos intervienen en el software, puede ser imposible mantener esta estructura.

Los equipos de feature son una alternativa intermedia entre los equipo de componente y los full-stack, que veremos a continuación.

Full-stack feature teams

Por último, los full-stack feature teams son los anteriores llevados al extremo. En esta estructura, todos los equipos de desarrollo son capaces de llevar a termino un PBI y convertirlo en un incremento terminado, porque entre todos sus miembros controlan el stack completo de la aplicación.

Estos equipos son agilidad llevada a la máxima potencia. Al tener esta independencia y capacidad de ejecución, la organización puede estar trabajando en varias features a la vez y entregarlas todas en un sólo Sprint. LeSS (Large Scale Scrum) recomienda tener al menos un 51% de equipos full-stack, recomendando llegar al 90%.

El problema es que son realmente caros, porque muchos miembros del equipo de desarrollo no tendrán nada que aportar durante el Sprint. La solución a esto es tener profesionales que tengan más conocimiento generalista que especialista, lo cual es imposible en la mayoría de las ocasiones. ¿Que organizaciones se pueden permitir tener un administrador de base de datos (DBA) en cada equipo?

En resumen, la estructura del equipo depende de varias variables: Economía, Producto y Arquitectura. Debe ser una organización estratégica para el contexto y el entorno donde desarrollamos nuestro producto. ¿Que sentido tiene ser capaz de entregar feature nuevas cada semana si el coste de absorción por parte del usuario es muy alto? ¿Como podemos tener equipos de componente en un entorno de alta volatilidad y competencia?

Scrum y la planificación por lotes

Esta mañana estaba preparando una megamaleta para viajar durante las próximas semanas a Japón, México, Portugal y Alemania cuando me he encontrado el tuit que puedes leer más arriba. Desde el aprecio y el cariño que le tengo a José Manuel Beas, al que en muchas ocasiones he referenciado desde mi blog y esta newsletter, me he preguntado: ¿Qué lleva a una persona que tiene muchos años de experiencia en Agile a pensar que en Scrum se hace planificación por lotes?

El cuchillo la mató, señor juez

Tenemos una tendencia terrible a usar herramientas sin entender muy bien para que funcionan o qué beneficios nos aportan. Cuando le hemos arreado en la cabeza a todo el mundo con ellas y hemos generado daño, entonces le echamos la culpa a la herramienta.

Da igual que sea Scrum, Kanban, Docker o Kubernetes. La culpa nunca es de la herramienta, sino de aquellos que la usan.

En este caso, si tenemos una organización que está acostumbrada a organizar por lotes por una cuestión de economía de costes (eficiencia de los recursos) y les damos Scrum como una nueva herramienta., la usarán de la misma forma que venían trabajando hasta ahora. O lo que es lo mismo, si tenemos un mono furioso y para reducir su estrés le damos un martillo para que haga carpintería, ¿Que hará el mono? Utilizar el martillo para golpear en la cabeza a todos sus congéneres, y si no somos cuidadosos, a nosotros también.

Los cuchillos no matan personas, las matan otras personas empuñando cuchillos. Scrum no es planificación por lotes, son las personas las que utilizan Scrum para planificar por lotes.

¿Y como usan los Sprints para trabajar por lotes?

De manera resumida, cuando alguien que está acostumbrado a trabajar por fases o lotes durante toda su carrera profesional ve Scrum, piensa que los Sprints son fases de 30 días o menos en los que se utilizan el Sprint Planning y Sprint reviewrespectivamente para gestionar el proyecto y hacer seguimiento.

¿Que hay de la retrospectiva? Pues en estas organizaciones se ve como el momento en el que el Scrum Master entretiene un poquito al equipo para que no se aburran o se vayan.

El flujo continuo en Scrum

En Noviembre se actualizó la guía de Scrum para hacer explícito lo que ya se sabía desde hace mucho tiempo: En Scrum hay que entregar al menos una vez por Sprint, pero no está limitado a una sola entrega. De hecho, somos muchos los que trabajamos con equipos que despliegan 50, 100 o 500 veces por Sprint. Los defensores de DevOps dicen que en Scrum no se puede hacer Continuous Delivery, cuando es precisamente al revés.

El papel del Sprint Planning no es el de planificar todo lo que se va a hacer en el Sprint, sino que sirve para marcar un objetivo y aportar foco a ese Sprint, centrando el trabajo que vamos a hacer en torno a ese objetivo. Eso permite flexibilidad a la hora de conseguir el objetivo de negocio y estabilidad para stakeholders, que saben que existe una cadencia mínima de entrega.

En la práctica, esto supone que un equipo que usa Scrum, se centra en un Sprint Goal que es un objetivo de negocio y deja más o menos libre el alcance para conseguir ese Sprint Goal. Una vez que tienen una hipótesis y un mínimo de trabajo para comenzar el Sprint, utilizan el Daily Scrum para inspeccionar y revisar su acercamiento o alejamiento del Sprint Goal y planifican de manera diaria para alcanzarlo de acuerdo a la Definition of Done, que aporta la transparencia necesaria.

Mientras tanto, el Product Owner puede seguir trabajando en el Product Backlog durante la duración del Sprint, identificando cuales son los temas más valiosos para trabajar a continuación. En el Sprint Review el Product Owner muestra el incremento del Sprint (que no es más que la suma de todo el producto desarrollado este Sprint integrado con todo lo que se hubiera hecho anteriormente) a los stakeholders y como ha resultado en la consecución del Sprint Goal. Todos juntos analizan la situación y con ello vuelven a decidir que será lo más importante a realizar el siguiente Sprint.

El incremento suele estar ya en producción y también se muestran las métricas de negocio asociadas.

En la retrospectiva, el equipo Scrum analiza como ha sido su trabajo y sus herramientas y deciden mejoras para implementar el siguiente Sprint.

A diferencia de Scrum, en la planificación por lotes se traza un plan en el que se decide todo lo que se va a realizar, se parte en trozos que se van entregando independientemente. Cuando están todos los trozos se unen y se acaba el proyecto.

¿Creéis ahora que Scrum se haga planificación por lotes?

Especializaciones y caminos para agilistas

Me gustaría empezar con un disclaimer: Todo esto puede sonar muy endogámico, pero la realidad es que sólo puedo hablar de lo que conozco. Desafortunadamente no conozco todo lo que las personas que están en esta industria hacen o preparan. Si crees que me falta algo, déjame un comentario para intentar mejorarlo.

Vamos allá.

Agile o no Agile

Una consideración inicial. Siempre que un compañero me dice que no sigue ningún método, que en realidad es Agile, me recorre algo entre una carcajada y un escalofrío.

Normalmente tras esa afirmación viene una explicación acerca de por qué los frameworks y métodos no son suficientes y que lo importante es hacer Agile. Mira, esto es simple, Agile, el manifiesto ágil es sólamente una declaración de intenciones, elaborada por unos locos que se reunieron en una estación de esquí para intentar cambiar la industria del desarrollo de software.

Esa declaración de intenciones está muy bien, pero si no eres capaz de explicarme qué haces para implementar Agile, mi conclusión es que te has inventado una nueva religión a tu medida porque no te convencen las existentes -o porque es más fácil que aprender las existentes-. Ésto está bien como decisión personal pero mal como decisión que tomas por tu organización o cliente. Hacer Agile es como decir soy buena persona. Como declaración de intenciones está bien, pero existe un sistema social -con un montón de normas- que es el que tiene que juzgar esa afirmación.

Detrás de cada método, framework o librería, hay cientos de miles de horas de profesionales con mucho conocimiento para destilar lo mejor de su experiencia. Si alguien piensa que es capaz de superar eso, es que quizás delire un poco.

Así que si no tienes mucha idea de Scrum o Kanban o XP, te recomiendo que no digas que haces Agile para compensar. Igual en tu imaginación queda bien, pero a los demás nos da un poco de vergüenza ajena.

En su lugar, se honesto y plantéate qué puedes hacer para mejorar tu conocimiento.

Aprender los básicos

El movimiento ágil viene -y se ha popularizado- desde el mundo del desarrollo de Software. Probablemente la gestión de proyectos de Software ha sido la industria más abusada y maleada de toda la historia de las profesiones de conocimiento en los últimos 50 años. éstos locos que se reunieron para elaborar un manifiesto que les permitiera cambiar la industria terminaron con esta declaración de intenciones. El problema es: Ahora que tenemos las intenciones ¿Cómo las ponemos en marcha?

Hay algo que no he contado. En lugar de reunirse y ver como cambiar la industria, el panorama era distinto. Lo que ocurría es que muchas de las personas alli presentes habían creado métodos para hacer Software de manera distinta: Scrum, XP, Crystal, DSDM… Lo que hicieron en realidad fue ponerse de acuerdo en lo que sus métodos tenían en común. Y de ahí salió el manifiesto ágil.

Scrum: Scrum es el método ágil más popular y más usado a nivel mundial. Si te consideras agilista, tienes que saber Scrum y es un buen comienzo. La guía de Scrum es el documento que sienta las bases sobre el marco de trabajo y las certificaciones más comunes son el Professional Scrum Master de Scrum.org y el Certified Scrum Master de la Scrum Alliance. Puedes ver sus diferencias aquí
XP: XP ha sido la referencia de muchos desarrolladores desde mucho antes que Scrum. Creado por Kent Beck, sigue siendo una referencia para la excelencia técnica. Muchas de sus técnicas, como las historias de usuario, han despegado y hoy son incluso más conocidas que el propio método. XP es una colección de técnicas más que un método compacto. La principal referencia monumental es el libro eXtreme Programming. Ahora mismo no conozco ningún buen curso en España para aprender XP.
Kanban: Kanban es más que conocido en el mundo Lean y TPS (Toyota Production System). El método aplicado al desarrollo de Software se popularizó a raíz del trabajo de David J. Anderson y Daniel Vacanti en AT&T. Posteriormente han evolucionado por caminos distintos, dando lugar el trabajo de Anderson a la Lean Kanban University y el de Vacanti a una colaboración con Scrum.org. El texto de referencia es el Blue Book de Anderson y la Essential Kanban Condensed. Un buen punto de partida para aprender es el Team Kanban Practitioner de la LKU o el Professional Scrum with Kanban de Scrum.org (PSK).
DevOps: DevOps no es ni un método ni un marco de trabajo. Es un movimiento que ha tomado fuerza desde 2011 en adelante y promueve una serie de prácticas para integrar las operaciones y el desarrollo de Software, rompiendo los silos existentes en grandes organizaciones haciendolas más ágiles. Aunque DevOps está muy orientado a la parte técnica, es necesario sponsorship del liderazgo de la organización para poder lanzar una iniciativa de este tipo. Un texto de referencia es el DevOps Handbook y un buen curso de iniciación es el DevOps Leader del DevOps Institute.

La parte de producto

Ningún método ágil va a funcionar si no somos capaces de cerrar el gap existente entre IT y Negocio. Y ese gap se llama producto. Algo que en muchas organizaciones directamente no existe y es lo que aúna esas dos patas y permite establecer métricas más ágiles en la organización. Los técnicos deben de dejar de mirar a negocio como si fueran vendehumos y los de negocio tienen que dejar de mirar a los técnicos como extraterrestres.

Product Ownership: Utilices el método que utilices en tu organización, es necesario conocer técnicas para desarrollar un producto. En general, cuando hablamos de proyectos hablamos de cómo gastar dinero y cuando hablamos de producto, de como ganarlo. Eso lleva a un cambio de mentalidad en el que pasamos de pensar en Alcance, tiempo y coste para empezar a pensar en Usuarios, retención o ingresos. El libro Product Ownership de Robert Galen es un buen punto de partida. También el Professional Scrum Product Owner de Scrum.org.
¿Como ampliar? User Story Mapping, Impact Mapping, Business Model Canvas, Value Proposition Canvas, Lean Canvas, Innovation Games o Lean Startup. Portfolio Management es un plus necesario cuando trabajamos con varios productos a la vez.

En general veo a la gente de producto muy verde a la hora de manejar técnicas que permitan sacar el máximo partido de su inversión (habitualmente dinero en forma de tiempo de desarrolladores). Lo que me suelo encontrar es con visionarios que pretenden que otros ejecuten, con una capacidad bastante limitada para transmitir su visión. Todas estas técnicas ayudan a poder entender al usuario y transmitir esa visión para poder crear productos del máximo valro posible.

Escalando el desarrollo de producto

Una vez que tenemos un producto claro, un Product Manager competente y una manera de gestionar al equipo de desarrollo, es normal que queramos escalar nuestro esfuerzo para construir productos más grandes. Hay que entender que cuanto más escalamos, más lenta será nuestra velocidad por cada magnitud de escalado, debido a la complejidad añadida de tener a más personas en el mismo producto.

Nexus: Nexus es la propuesta de Scrum.org para escalar de 3 a 9 equipos de 3 a 9 personas a su vez. Equipos Scrum. La guía de Nexus se puede descargar gratuitamente de [la página de scrum.org] y su formación correspondiente es el Scaled Professional Scrum.
LeSS: Large Scale-Scrum es la propuesta de Craig Larman y Bas Vodde para escalar Scrum dentro de un entrono de desarrollo de producto. Mezcla cultura, gobierno y desarrollo de producto en un sólo método que es más prescriptivo que Nexus
SAFe: Scaled Agile Framework es una propuesta que no sólo escala el desarrollo de producto sino también el gobierno de la organización de desarrollo, integrando el gobierno de programa y portfolio. Su creador lo define como una librería, más que un método, pero en su última versión incorpora uan versión essential que describe el mínimo para ponerlo en marcha.
¿Como ampliar? El uso de Evidence Based-Management como marco de trabajo sobre métricas de valor es muy interesante, así como la introducción de Upstream Kanban para gestionar la demanda.

De estos tres métodos, puedes ver una comparativa en este artículo del blog.

Escalando la organización

El problema del escalado es que se produce en varias direcciones. Si escalar el desarrollo de producto es escalar verticalmente, escalar la organización que soporta ese desarrollo de producto es escalar horizontalmente. Se trata de crear la organización ágil, que de soporte a iniciativas que proporcionen respuestas rápidas a las necesidades del mercado.

SAFe: En su versión de programa y portfolio, SAFe pretende dar respuesta a las necesidades de gobierno de las organizaciones, escalando las iniciativas desde el budgeting hasta los equipos de desarrollo. La información sobre SAFe está contenida en la Big Picture de SAFe y el curso de referencia es el Leading SAFe 4.5.
El método Kanban: El método Kanban ha evolucionado durante los últimos años para proporcionar una solución más flexible a organizaciones que desean ser más ágiles sin sacrificar las estructuras, roles y títulos existentes, sino kanbanizándolos e introduciendo una cultura de la mejora continua (kaizen) a través de cadencias regulares. Además acaba de incorporar el Kanban Maturity Model (KMM) como herramienta para diagnosticar y mejorar la situación actual. Para aprender más sobre Kanban tienes la acreditación Kanban Management Professional que comprende los cursos Kanban Systems Design y Kanban Management Professional.
Scrum Studio: Esta propuesta apunta a la creación de iniciativas ágiles a través de la creación de estudios de innovación, para vencer las resistencias tradicionales y crear algo que, junto a la organización, no se rige por las reglas habituales de la misma. Puedes ver mi charla sobre Scrum Studio en la última CAS en Youtube. Ahora mismo, además de un whitepaper que estamos preparando

Entendiendo la complejidad

Systems Thinking: El efoque sistémico y sus herramientas son necesarias en entornos de alta incertidumbre como son los de desarrollo de producto. Aunque no tengo una referencia clara para recomendar, es algo a tener en cuenta a la hora de especializarse.
Cynefin: La propuesta de Dave Snowden es un marco de trabajo para la toma de decisiones en entornos complejos. Mediante el análisis de patrones, Snowden recomienda la toma de decisiones basada en el dominio del problema, lo que nos permite atacar problemas concretos con herramientas adecuadas.
Lean Product Development Flow: Don Reinertsen lleva 30 años estudiando y enseñando los principios económicos que subyacen a métodos como Lean y aplican al desarrollo de productos. Mediante el análisis y el uso de herramientas lógico-matemáticas, proporciona una visión del desarrollo de software desde una perspectiva muchas veces olvidada: la de la economía.

La parte de personas

A pesar de haberla dejado para el final, la parte de personas es una de las más importantes de todo esto. El cambio cultural que supone la agilidad en una organización es un reto que no muchos están capacitados para afrontar. En este sentido, nada de lo que hay en el sector realmente me gusta y me iría al mundo del coaching tradicional.

Inteligencia emocional: Para poder lidiar con las emociones de los demás, tenemos que estar preparados nosotros emocionalmente. Asistir a una formación en inteligencia emocional es clave para entender los procesos internos que nos gobiernan y ponernos a prueba. Estas formaciones suelen ser muy vivienciales e intensas, y no las recomendaría a todo el mundo
Coaching personal y ejecutivo: Aunque el coaching es una de esas herramientas denostadas, los programas certificados de coaching de AECOP o ICF suponen un buen punto de partida para el aprendizaje de herramientas soft que nos permitan realizar mejor nuestro trabajo.
Agile Coaching: El Agile Coaching institute tiene programas para el desarrollo de distintas áreas de Agile Coaches. No los conozco personalmente y no tengo suficientes referencias como para opinar.
¿Como ampliar? Un programa de coaching completo, la facilitación gráfica, training from the back of the room o mindfulness pueden ser buenos complementos a esa parte de soft skills.

Yo tengo un sesgo claro. En el año 2011, cuando ya llevaba tres o cuatro años introduciendo Scrum en organizaciones, me di cuenta de la oferta tan pobre que había en torno a todo esto. Después de hacer un programa de coaching personal y ejecutivo de dos años (soy coach certificado por AECOP y el European Council of Mentoring and Coaching), decidí cursar el grado de Psicología por la UNED. Hoy me quedan un par de asignaturas y el TFG, que espero presentar en 2019.

Probablemente me he dejado mucho en este intento de aunar un montón de ideas que en ocasiones están inconexas, pero en general estoy contento con el resultado. Si te ayuda a entender mejor los pasos a seguir en este mundillo, entonces habrá cumplido su cometido. Por útlimo, mucho cuidado con las ensaladas de cosas, o podemos acabar como Deloitte:

Principios de SAFe®

Como dijo John Ratzenberger

encuentra gente que comparta tus valores, y conquistareis el mundo juntos.

Como todo “buen” marco de trabajo ágil, SAFe® está guiado por unos valores fundamentales que dictan las acciones y el comportamiento, y ayudan a la gente a distinguir entre lo correcto o lo incorrecto. Estos valores fundamentales son los que deben guiar la organización en el proceso de toma de decisiones sobre los distintos aspectos que vayan surgiendo en el proceso de adopción de SAFe®.

Hay cuatro valores fundamentales que SAFe honra, apoya y ayuda a ofrecer: Alineación, Calidad incorporada, Transparencia y Ejecución del programa.

Alineación

La alineación también se escala. Es una condición necesaria para poder abordar la realidad empresarial de un cambio acelerado, turbulencias creadas por la competencia y equipos geográficamente distribuidos.

Si no se mantiene el alineamiento entre los equipos, al escalar disfrutaremos de un entorno de trabajo donde reinaran la anarquía y el descontrol.

Todos los ART (Agile Release Train) son equipos de equipos alineados hacia un objetivo común. A su vez, todos estos ART están a su vez alineados según unos presupuestos que vienen dictados por los aspectos estratégicos de la empresa.
¿y cómo conseguimos que todos los equipos de un ART estén alineados? Sincronizando los sprints de todos los equipos implicados en el tren, todos ellos empiezan el mismo día y tienen la misma duración. Esto va en contra de la flexibilidad total, pero los beneficios son mayores que las pérdidas, pues incluso el acto de fijar fechas fomenta la comunicación entre equipos.

Calidad

La calidad debe estar asegurada en cada incremento de solución entregada al cliente, la calidad no se “añade más tarde”.

Si la calidad es importante a nivel de equipo, ésta cobra más importancia a nivel de programa puesto que inyectar código de mala calidad en la solución provocará más costes en la interacción con los otros componentes o funcionalidades del sistema. “If you produce crappy code and you scale it, you will get crappy solution”.

Sin ella, la organización operará con grandes entregables que no han sido verificados ni validados, esto provocaría una repetición del trabajo y por consiguiente una disminución de velocidad en la entrega.

La calidad debe estar presente a nivel de software mediante una atención continua a la excelencia técnica y el buen diseño de la solución (arquitectura) que faciliten la agilidad. También a nivel de hardware y en la integración de los distintos componentes del sistema.

Transparencia

El desarrollo de grandes soluciones es complejo. Las cosas salen mal o no funcionan como estaba planeado. La falta de transparencia da lugar a decisiones basadas en supuestos especulativos y la falta de datos. Nadie puede arreglar un secreto.

Los equipos de alto rendimiento están basados en la confianza, y su construcción lleva tiempo. La transparencia es el mejor facilitador de la confianza.

En SAFe® hay numerosos mecanismos o eventos que ayudan a la empresa a conseguir esta transparencia. El uso de herramientas visuales, así como herramientas virtuales, permite fácilmente irradiar información. También de manera regular se hacen sincronizaciones a distintos niveles (Scrum of Scrums, PO sync, Release Management, etc) que ayudan a fomentar la transparencia organizacional.

Ejecución del programa

Ninguno de los valores anteriores importa si los equipos no son capaces de ejecutar y entregar valor de manera continua e incremental (principio básico del agilismo).

La historia nos muestra que mientras muchas empresas empiezan la transformación con los Equipos Ágiles, a menudo se sienten frustradas, ya que incluso estos equipos luchan para entregar grandes cantidades de valor de la solución de manera fiable y eficiente.

Pero con la alineación, la transparencia y sin olvidar la calidad, los equipos tienen un poco de “viento a favor”. Eso permite enfocar la ejecución. Y si luchan -y lo harán, porque el desarrollo de soluciones complejas es difícil- tienen la piedra angular de los “Inspect and Adapt Workshops”. De esta manera, cierran el ciclo de ejecución y planificaran acciones para mejorar la siguiente iteración, también llamadas Incremento de Programa.

La ejecución del programa no puede ser solo cosa del equipo, no puede ser algo que suceda de abajo hacia arriba. Para el éxito en la adopción de SAFe® es necesario el apoyo activo de sus líderes (Lean-Agile leaders).

Estos valores son muy “bonitos”, todas las empresas quieren la entrega satisfactoria y con valor de las soluciones que construyen, ¿pero hasta qué punto están todos sus departamentos o incluso equipos alineados? Y sobre la transparencia, ¿creéis que acabar con las agendas ocultas es algo que se consigue en unos días? ¿o en unos meses? ¿o como líderes / managers no se presiona en un momento dado al equipo para que reduzca la calidad de la solución debido a una fecha de entrega? ¿se hace demasiado a menudo?

Empieza por hacer visible lo invisible mediante radiadores, ha hacer que fluya la información de manera constructiva a través de eventos de sincronización y sobretodo, periódicamente Inspecciona y Adapta a nivel de equipo de equipos.

Los valores fundamentales de SAFe® son una herramienta muy potente para la transformación digital de una empresa hacía una metodología de trabajo ágil mediante la adopción del mismo, pero es realmente muy difícil que dichos valores estén presentes en el día a día de la empresa y en las decisiones que se tomen y este va ser uno de nuestros mayores cometidos como “Lean-Agile Leaders”.

6 errores evitables que cometen los equipos Scrum

El otro día alguien me preguntó cuales eran los errores típicos que veía en equipos Scrum que empezaban.
Mi respuesta fue sorprendente: ¿Los que empiezan? Los que más problemas tienen son aquellos que ya llevan mucho tiempo funcionando.

Error 1: Mucho Work in Progress

Acaba la primera parte del Sprint Planning y el equipo empieza a desgranar los PBIs en tareas, los estiman y cada uno de los miembros del equipo empieza a trabajar en un ítem distinto.

Eso provoca que luego haya problemas de integración y silos en los cuales el equipo no tiene ni idea de que está pasando. Los equipos maduros empiezan algo y no empiezan lo siguiente hasta que no lo terminan, manteniendo una o dos tareas en paralelo al mismo tiempo.

Cuando llega el final del Sprint, la mayoría de las cosas están a medio acabar y no da tiempo a integrar. Sin embargo el Product Owner aprieta para mostrar cuanto más mejor en el Sprint Review y el equipo de desarrollo añade la “deuda técnica” al backlog, para re visitarla… nunca.

Error 2: Falta de Sprint Goal

El Sprint Backlog se convierte en un cajón de sastre en el que entran decenas de cosas que no tienen nada que ver las unas con las otras, lo que hace que no haya coherencia y se pierda el desarrollo iterativo e incremental y la transparencia.

El Sprint Goal es una dirección general que ayuda al equipo a mantener el foco en cual es el objetivo de este incremento. El Sprint Backlog puede cambiar, el Sprint Goal no. Eso permite flexibilidad para lidiar con cosas que no estaban planeadas y un mejor enfoque en las necesidades de negocio.

Cuando no tenemos un Sprint Goal que de dirección, perdemos una herramienta muy potente que promueve dos de los valores de Scrum: Coraje y Compromiso. Entonces Scrum se convierte en un proceso más dentro de la compañía, además de perder foco en el valor de negocio entregado en cada incremento.

Error 3: Asignación individual de tareas

Los miembros del equipo de desarrollo trabajan individualmente en tareas hasta que las completan y luego pasan a trabajar en otra cosa. Eso provoca, de nuevo, falta de integración y posibles problemas de dependencias.

Algunos equipos tienen normas para lidiar con esto. Por ejemplo, tiene que haber un code review por al menos dos miembros del equipo. Trabajar en pares. Muchas veces con poca efectividad, sobre todo si la carga de trabajo es alta.

La única manera de lidiar con esta situación es, lamentablemente, reducir la carga de trabajo. Paradójicamente, el ahorro de entregar más rápido se traduce en cuatro veces más para reparar la deuda técnica y de conocimiento que supone ese ahorro.

Además, cuando se maximiza la utilización, se tiende a perder valor. ¿Cómo? Aumentando el tiempo de entrega. Cuando el equipo se enfoca en entregar unas cuantas cosas bien hechas, quizás esté perdiendo eficiencia, pero se asegura de entregar, lo cual ya supone una gran diferencia con muchos equipos, que trabajan en cosas durante meses sin llegar a entregarlas… nunca.

Error 4: Falta de responsabilidad

En Scrum, el rol responsable de dar cuentas sobre el incremento es el equipo de desarrollo. Que el nombre no nos lleve a engaño. Todos los miembros del equipo de desarrollo dan cuentas sobre todo el incremento.

No existe la individualidad del desarrollador en Scrum. Desafortunadamente, eso lleva a muchos miembros del equipo de desarrollo a quejarse porque ellos sí hacen su trabajo.

La manera de actuar es la de dejar que el equipo se autoorganice y lidia con esos problemas. Y la del Scrum Master no es actuar sobre los miembros que consideramos destacados o vagos, sino mantener esa discusión dentro del equipo, sin que escale en la organización.

En el caso del Product Owner, él es el responsable de dar cuentas de la inversión que hace en el equipo de desarrollo cada Sprint. Y tiene que hacerlo con datos. Si la calidad técnica del producto falla, de rebote el Product Owner se convierte en responsable.

Error 5: Maximización de utilización o eficiencia

Este es, sin duda, uno de los peores que puede tener una organización. Enfocarse en que la gente trabaje muchas horas en lugar de generar valor.

No nos equivoquemos. Estos dos objetivos son totalmente incompatibles. El desarrollo de software, por su propia naturaleza, incurre en una variabilidad muy grande y no es posible estandarizar tareas, duraciones, problemas o buenas prácticas.

La realidad es que cada vez que hacemos algo en software, por muchas veces que creamos haberlo hecho antes, nos enfrentamos a algo totalmente nuevo, en un entorno nuevo, un sistema nuevo, que nunca habíamos hecho antes. Es ineficiente porque aprendemos sobre la marcha.

Las ineficiencias aparecen en forma de miembros que no tienen suficiente trabajo, otros que están sobrecargados y otros problemas intermedios. El temor a que la gente esté parada lleva a introducir trabajo no necesario para generar valor y que la gente esté ocupada.

El resultado es que cuando el trabajo que tienen que hacer esos miembros es necesario, están ocupados haciendo otra cosa. Están siendo eficientes. Y haciendo perder dinero a la compañía.

Error 6: El equipo de desarrollo es el equipo de desarrolladores

El último es, quizás, el más desconocido. Debido a su nombre, los profesionales en Scrum piensan que un equipo de desarrollo tiene que estar formado por gente técnica: programadores, ingenieros de operaciones o calidad.

Nada más lejos de la realidad. El equipo de desarrollo tiene todos los perfiles necesarios para poder entregar un incremento de producto. Si eso supone que tienen que incorporar a un Business Analyst, un especialista en SEO o un diseñador, también son miembros del equipo de desarrollo.

Si ves que tu equipo se está acercando a alguno de estos errores o que el proceso de Scrum no está desarrollando adecuadamente, te recomiendo el artículo Cuatro señales de que Agile no funciona en tu organización.