Scrum en la practica

Cinco señales de un Daily Scrum disfuncional

Cuando se trata de analizar por qué un evento en Scrum no funciona, frecuentemente hay que mirar más allá del formato o de la actitud de los participantes y centrarse en los motivos profundos que hay detrás del funcionamiento del evento.

Anteriormente ya hemos hablado de la efectividad de los Scrum Masters, de cómo mantener vivas las iniciativas ágiles en tu organización y de cómo trabajar activamente para destruirlas. Hoy lo haremos desde el punto de vista del Daily Scrum.

A pesar de la importancia de este evento para favorecer la transparencia, la inspección y la adaptación, son muchos equipos los que perciben este evento diario como una carga en lugar de un espacio productivo para inspeccionar y adaptar el trabajo para conseguir metas.

Veamos los cinco signos más importantes de que el Daily Scrum no funciona.

Signos de que el Daily Scrum no funciona

Es un reporte

Los miembros del equipo Scrum van, uno por uno, explicando en qué estaban trabajando ayer y en qué van a trabajar a lo largo del día de hoy.

En aquellos equipos más inmaduros, a lo largo del tiempo se reduce a: “Voy a seguir trabajando en lo que hice ayer y seguiré haciendo mañana”. En muchas organizaciones esta es la oportunidad diaria para que Product Owners, Scrum Masters, Jefes de Proyecto y otras especies de la organización realicen su control diario para comprobar que todo el mundo está trabajando.

Por otro lado, este método es cómodo para los miembros del equipo Scrum que simplemente quieren marcar la casilla de “Hacemos Scrum” y seguir trabajando en lo suyo durante el resto del Sprint.

Responder a las tres preguntas

“¿Qué hice ayer para contribuir al Sprint Goal?” “¿Qué voy a hacer hoy para contribuir al Sprint Goal?” “¿Qué impedimentos tengo para conseguir el Sprint Goal?”

Esta es una variante del anterior. Normalmente indica que existe un Scrum Master que se leyó la guía de Scrum y quiere que se haga Scrum como-lo-dice-la-guía. En realidad no deberíamos esperar mucho más que en la versión anterior, ya que cuando alguien no quiere explicar que en esta organización no hay Sprint Goals ni planificación de producto porque trabajamos en proyectos de alcance, tiempo y coste cerrado, lo que hace es marear la perdiz un poco para responder lo mismo que hemos visto anteriormente.

De hecho, en la actualización de la guía de 2020 el uso de las tres preguntas se ha eliminado porque sus efectos eran más perniciosos que beneficiosos.

Falta gente

El Daily Scrum normalmente tiene dos o tres faltas de personas todos los días. Hay miembros del equipo que reportan por otros. Hay personas que comentan por Slack lo que iban a decir en el Daily Scrum y -en su versión más visual management– otras dicen que han actualizado los Post-its en el tablero.

La sensación es que la mayoría de los miembros del equipo Scrum no están involucrados con la forma de trabajar y ven el Daily Scrum como una carga en lugar de algo que pueda ser útil para ellos.

No ocurre sin el Scrum Master

El Scrum Master motivado se asegura de que haya un Daily Scrum todos los días a la misma hora y en el mismo lugar. Sin embargo, cuando se va de vacaciones o dejar la empresa, los que quedan corren a eliminar una reunión más que no les aporta valor, lo sustituyen por un Daily Stand-up asíncrono -🤦‍♂️- o directamente la van moviendo de un lugar para otro hasta que no se hace más.

Nunca hay follow-ups

Para mi sorpresa, todavía hay Scrum Masters que, con la excusa de seguir lo-que-dice-la-guía, limitan el Daily Scrum a 15 minutos y nunca permiten seguimiento a temas importantes que han salido durante el evento.

Sin embargo, estos eventos Kaizen espontáneos son tanto o más importantes que el propio Daily Scrum, ya que permiten la adaptación necesaria para poder alinearnos en torno a un objetivo común -el Sprint Goal-.

La importancia del Daily Scrum

Scrum está basado en tres pilares: Transparencia -todos sabemos lo que está ocurriendo-, inspección -podemos comprobar el trabajo conforme se hace- y adaptación -podemos cambiar la dirección táctica.

El Daily Scrum juega un papel fundamental en asegurar que durante el Sprint este proceso se sigue y nos permite adaptarnos a los problemas y necesidades que vamos encontrando.

Cuando el Daily Scrum se estanca es difícil que podamos realizar ningún tipo de adaptación porque no hay transparencia sobre donde estamos ni hacia donde vamos.

Y es en este tipo de situaciones donde se dan las marchas de la muerte al final del Sprint o directamente las cosas se van desbordando hacia el siguiente Sprint, eliminando la sensación de avance.

En un próximo post hablaré de cuales son los motivos por los que se dan estas -y otras- situaciones y donde aplicar esfuerzo para que poco a poco dejen de producirse.

Cómo trabajar como Scrum Master externo y tener éxito

Es común encontrarnos con organizaciones que deciden adoptar una estrategia de contratar externos para ayudar a introducir Agilidad.

También es frecuente encontrar profesionales que han sufrido malas experiencias realizando esta labor.

En este artículo vamos a analizar qué problemas podemos encontrarnos al intentar adoptar una estrategia de Professional Scrum y cuales son los pushbacks más comunes.

Professional Scrum ¿Qué es?

Ken Schwaber fundó Scrum.org hace 15 años tras su paso por la Scrum Alliance.

Hay diferentes teorías y versiones sobre los motivos de su salida de ésta organización, creada tras la Agile Alliance y que compartía varios miembros fundadores.

Lamentablemente el artículo inicial con las motivaciones que le animaron a crear una nueva organización ya no se encuentra online; sin embargo, algo que ha mencionado muchas veces a lo largo de los años es que quería formar parte de una organización que se esforzara por hacer Scrum de manera profesional.

En realidad, Professional Scrum no es distinto, a nivel mecánico, del Scrum descrito en la guía oficial.

Professional Scrum es, más bien, una manera de entender y de usar Scrum. A grandes rasgos sus características pueden ser resumidas de la siguiente manera:

Unos valores sólidos en los que apoyarse a la hora de introducir Scrum y utilizarlo como el marco de referencia para construir productos.
Un enfoque en la generación de valor, a través de la construcción de productos que sean usables.
Una alta ética profesional, fomentando y mimando organizaciones que se miden a sí mismas bajo altos estándares éticos.
Un entorno de profesionalidad, donde todos los miembros de los equipos Scrum y de la organización buscan la excelencia y llegar más lejos.
Por último, una entrega constante de valor, a través de la puesta en manos de los usuarios de Incrementos de alto valor.

Como podemos intuir, Scrum en organizaciones que se limitan a aplicarlo de manera mecánica tiende a ofrecer beneficios reducidos. Es solamente cuando vamos más allá cuando podemos desatar todo el potencial de la organización.

Motivaciones para perseguir Agilidad

Cada organización tiene distintas motivaciones para poner en marcha iniciativas de Agilidad de negocio. Sin embargo, solemos encontrar dos problemas principales:

Los sponsors que deciden adoptar Agilidad lo hacen como una herramienta que solucione todos (o parte) de sus problemas
No hay una comunicación explícita de los motivos subyacentes a lo largo y ancho de la organización, lo que impide entender pero también medir como de efectiva está siendo nuestra iniciativa.

Estos dos problemas, que en mi experiencia afectan a todas las organizaciones con las que he trabajado en cierta medida, chocan de manera frontal con la manera de hacer Scrum profesional que he mencionado anteriormente.

¿A todas? A todas.

En otro artículo hablaba de la disciplina para evitar que las iniciativas de adopción de Agilidad murieran o fueran engullidas por la cultura organizacional. Hacía una analogía con el entrenamiento deportivo que es muy válida en este contexto.

No importa cuánto gastemos en implantar herramientas que si somos incapaces de entender las nuevas maneras de hacer de las mismas, toda nuestra inversión será inútil.

No hablo exclusivamente de herramientas tecnológicas. En este saco entra también Scrum.

Conflicto de agendas

Aparentemente esto es un problema de la propia organización que no tiene por qué afectar al desarrollo del trabajo de un Scrum Master externo. Es más, precisamente por ser externo probablemente tenga una capacidad de abstraerse y poner distancia con los problemas y cultura existente y plantear otro tipo de soluciones.

Terrible error.

Precisamente las empresas más afectadas por los problemas que mencionábamos anteriormente son aquellas que contratan Scrum Masters externos. ¿Para qué?

Para culparlos si las cosas salen mal.

Es muy sencillo. Cuando empezamos a trabajar en una organización nueva, es muy posible que nuestro sponsor esté motivado y nos proporcione todo el apoyo necesario para desarrollar los cambios que necesitamos para crear un entorno de Scrum profesional.

E incluso aunque esto sea así al comienzo, las personas cambian y lo que era cierto en un momento puede no serlo en otro. Incluso puede que terminemos siendo minions al servicio de la política interna.

Cómo lidiar con éstas situaciones

Para mi la única forma de lidiar con estas situaciones es siendo brutalmente transparente tanto acerca de nuestras intenciones -el tipo de enfoque que queremos darle a nuestro trabajo-, como del trabajo que estamos realizando -siendo muy organizados y comunicando qué y cómo estamos haciendo en cada momento- tanto como con los objetivos que queremos conseguir con el primer y el segundo punto.

Si no hay alineamiento es el momento de cambiar o dejar de empujar hasta que se facilite el alineamiento.

Para ello, y especialmente al comienzo, nuestra labor va a ser casi totalmente pedagógica. Hemos de mostrar el estado futuro y asegurar que quienes tienen que facilitar ese camino entienden no a donde tenemos que llegar, sino como remar todos juntos en esa dirección.

Esto, a corto plazo, puede parecer incluso dañino para vuestra carrera como Scrum Masters; sin embargo, a la larga os facilitará acceso a mejores oportunidades profesionales y os mantendrá alejados de aquellas que directamente evitarán vuestro enfoque.

Cinco indicadores para saber si un Scrum Master es efectivo

A pesar de la inmensa popularidad de Scrum, después de muchos años observo que muchas organizaciones están ciegas o directamente son incapaces de medir la efectividad de los Scrum Masters.

Cuando ejercemos como Scrum Masters por primera vez, asumimos como nuestros los eventos y el funcionamiento del framework. Los más atrevidos puede que incluso se vean como unos líderes del equipo Scrum -más bien aspirantes a managers sin título- pero muy pocos son capaces de enumerar alguna medida que les permita saber si están siendo efectivos en su trabajo.

Si pertenecemos a una organización con unos mínimos sistemas de control lo más seguro es que la pregunta ¿Cómo medimos lo que hacen estos Scrum Masters? ha surgido en más de una ocasión.

Recuerdo un documento interno de una gran empresa española que establecía tres métricas para medir la efectividad del Scrum Master: el número de equipos a los que servía, el número de eventos que facilitaba y si el equipo cumplía o no con los compromisos que estimaba.

El problema de los incentivos

Si sabes que te van a medir de acuerdo a la descripción anterior, ¿Que harías para aumentar tu rendimiento?

En primer lugar, probablemente trabajarías para más equipos, aunque diluyeras tu capacidad de abarcar problemas y no estarías disponible.

En segundo lugar, te centrarías en hacer facilitación a través de formulas aunque no fuera lo que el equipo necesita (o desea).

En tercer lugar, te centrarías mucho en técnicas de estimación y procurarías asegurarte de que la velocidad es lo más importante (tenga valor o no).

O dicho de otra manera: El objetivo sería cumplir, no transformar ni mejorar.

Los incentivos dirigen nuestra vida. Trabajamos para cobrar un sueldo. Participamos en deportes de equipo para sentir pertenencia. Mejoramos nuestro coche para mostrar status. Incluso reciclamos más si tenemos un sistema que te da palmaditas en la espalda cada vez que lo hacemos.

¿Y cuando los incentivos se vuelven perversos? Es decir, provocar el efecto contrario al que realmente se espera. Wikipedia tiene una buena lista de éstos.

Cinco opciones para medir la efectividad

En lugar de utilizar métricas personalísimas, yo apuesto por hacer uso de métricas dependientes de objetivos, véanse:

Tenemos una entrega fiable de incrementos de producto de manera regular, que llegan a los usuarios y generan valor para la organización.
Las personas que forman parte de los equipos Scrum asumen más responsabilidad, se sienten dueños de su carrera profesional y de los productos que desarrollan.
El entendimiento de Scrum dentro del equipo y la organización es sólido. Las personas comprenden y se adhieren a los principios y valores de Scrum
La moral es alta. Los miembros del equipo Scrum sienten que están haciendo una contribución y esto se ve reflejado en la calidad de los productos en los que trabajan.
Hay una ambición de mejorar continuamente y de seguir aprendiendo por parte de la organización.

Obviamente, medir estos puntos es difícil -si no imposible- mediante métricas objetivas. Pero si pensamos al contrario, es fácil identificar cuando estos puntos no se están cumpliendo.

¿Por qué? Porque el efecto de un buen Scrum Master es indirecto.

Medir lo indirecto

Cuando un Scrum Master observa los valores de Scrum, se centra en eliminar los distintos tipos de impedimentos y hace que Scrum cale dentro de la organización, se dan ciertas paradojas:

El Scrum Master tiene tiempo libre, lo que va en contra de la cultura de la productividad impostada que tenemos en las organizaciones.
Está disponible en tiempo real, lo que puede dar la sensación de que no está aprovechando su tiempo
Se prepara para su trabajo aprendiendo, leyendo y mejorando sus herramientas, lo que puede generar desconfianza.

Sin embargo y al mismo tiempo podemos observar que los indicadores del punto anterior se cumplen: Se entregan incrementos de manera fiable, la gente asume responsabilidad por su trabajo, la organización entiende Scrum, la moral es alta y ambición de seguir mejorando.

¿Que significa esta utopía?

Pues que el Scrum Master está siendo efectivo. Si tomamos cada uno de los puntos por separado puede que el Scrum Master sea efectivo -o al menos lo parezca-, pero cuando se dan todos podemos afirmar con rotúndidad que lo está siendo.

Si te interesa seguir leyendo, aquí tienes las tres estrategias que más me han ayudado a ser un Scrum Master efectivo.

¿Y cuando podemos afirmar que el Scrum Master está fallando?

Pues mirando estos indicadores en el sentido contrario: Falta de entrega fiable de incrementos de valor, Scrum mecánico e inconsistente, degradación de los equipos y baja moral.

Pero hay una que es la más importante:

Dependencia del Scrum Master

Si Scrum funciona solamente porque el Scrum Master está encima puedo asegurar que está fracasando en su trabajo. De manera estrepitosa.

Este es el principal indicador de que nuestro esfuerzo en que Scrum funcione lo más probable es que esté siendo inútil.

Entendiendo la guía de Kanban para equipos Scrum: ¿Por qué este fregao?

[fusion_builder_container hundred_percent=”no” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” overlay_color=”” video_preview_image=”” border_size=”” border_color=”” border_style=”solid” padding_top=”” padding_bottom=”” padding_left=”” padding_right=””][fusion_builder_row][fusion_builder_column type=”1_1″ type=”1_1″ layout=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” border_position=”all” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” center_content=”no” last=”true” min_height=”” hover_type=”none” link=”” first=”true”][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=””]

Hace unas semanas actualizamos en Scrum.org la guía de Kanban para equipos Scrum a una nueva versión.

El objetivo de esta revisión ha sido incorporar el feedback recogido por las miles de personas que están utilizando Kanban con sus equipos Scrum y clarificar algunos de los principios. Como casi todo, la primera versión de algo no es perfecta y en Scrum.org somos muy críticos con nuestro propio trabajo.

La guía de Kanban para equipos Scrum ha ayudado a entender como trabajar conjuntamente con los dos métodos, evitando algunas de las falacias más comunes. En el blog encontrarás varios artículos que te dejo al final del texto.

Los cambios incluyen:

Una reestructuración de la sección de teoría para conectar mejor entre flow, empirismo, introducir las métricas y la Ley de Little.
Limpieza de la sección de definición de workflow para que los ejemplos estuvieran en un sitio separado.
Políticas más generales para reducir el nivel de prescripción y permitir que el foco esté en los principios y no en las prácticas.
El alcance de visualización y accountability sobre la definición de Workflow se han modificado.
Una nueva sección sobre como el incremento en Scrum se ve afectado por el Flow.
Los Service Level Expectations (SLE) ahora son parte de la sección de workflow.

¿Por qué Scrum.org se mete en el mundo de Kanban?

Cuando se publicó la guía de Kanban para equipos Scrum y el curso Professional Scrum with Kanban (PSK) hubo revuelo en ámbas comunidades. Por un lado, miembros de la comunidad de Kanban, dividida entre los que trabajan pro Kanban University y los que tomaron la decisión de escindirse de la organización, pusieron el grito en el cielo.

La pugna entre Scrum y Kanban ha beneficiado ampliamente a ámbas comunidades, por un lado porque el debate genera nuevo conocimiento y por otro -el malo- debido a que los acalorados enfrentamientos normalmente provocan beneficio económico para aquellos que viven de prescribir métodos.

Hubo fervientes creyentes de Scrum pensaron que esto era una perversión que haría caer Scrum en pro de otras cosas y veían amenazada sus creencias más profundas.

Y luego, existía una gran mayoría, más silenciosa y centrada en los resultados que siempre ha creído en la construcción de puentes entre comunidades cuya misión es la misma, mejorar los entornos de trabajo a través de la mejora de resultados.

La elaboración y difusión de la guía fue una iniciativa personal de Steve Porter, quien creía que la comunidad de Scrum tenía mucho que aprender de Kanban.

Un año y medio después, tras formar a cientos de alumnos en decenas de clases, no puedo más que darle la razón. La publicación de la guía y el trabajo que Scrum.org y los trainers hemos hecho en torno a la difusión de la misma ha resultado en mejores resultados en los equipos que aplican Kanban como parte de su trabajo con Scrum.

A lo largo de este año hemos compartido muchos artículos sobre Kanban, Scrum y las métricas que se pueden utilizar al combinar ámbos.

En especial, estos dos artículos escritos por mi compañero Nacho Navarro describen muy bien la potencia que se puede alcanzar a través del uso de las métricas utilizando Scrum y Kanban conjuntamente.

El futuro de Scrum y Kanban

Como todo futuro, siempre es incierto. La incoporación de Kanban al mundo de Scrum.org ha traido beneficios tangibles y apenas desventajas. Aunque hay quien piensa que los conceptos que se enseñan en la guía de Kanban para equipos Scrum ya formaban parte implicimante de Scrum. Otros pensamos que desarrollar principios que amplifiquen y publicarlos ayuda a generar más debate.

¿Y tu? ¿Que opinas? Déjanos un comentario para abrir el debate.

Si quieres saber más scrum como utilizar Kanban con tus equipos Scrum, aquí tienes nuestra próxima clase de Professional Scrum with Kanban.

[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container][fusion_builder_container hundred_percent=”no” hundred_percent_height=”no” hundred_percent_height_scroll=”no” hundred_percent_height_center_content=”yes” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” status=”published” publish_date=”” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” enable_mobile=”no” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” video_preview_image=”” border_size=”” border_color=”” border_style=”solid” margin_top=”” margin_bottom=”” padding_top=”” padding_right=”” padding_bottom=”” padding_left=””][fusion_builder_row][fusion_builder_column type=”1_1″ type=”1_1″ layout=”1_1″ spacing=”” center_content=”no” link=”” target=”_self” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_image_id=”” background_position=”left top” background_repeat=”no-repeat” hover_type=”none” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” box_shadow=”no” box_shadow_blur=”0″ box_shadow_spread=”0″ box_shadow_color=”” box_shadow_style=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” first=”true” last=”true”][fusion_events cat_slug=”professional-scrum-with-kanban” past_events=”no” number_posts=”1″ columns=”1″ column_spacing=”43″ picture_size=”auto” content_length=”excerpt” excerpt_length=”” strip_html=”” pagination=”no” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” padding_right=”” padding_left=”” /][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

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?