• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Scrum en la practica

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.

  • Simula un flujo de Kanban con esta herramienta
  • Scrum y Kanban, lo peor de los dos
  • 4 maneras de beneficiarte de Scrum y Kanban juntos

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.

  • Kanban Metric Layout (I)
  • Kanban Metric Layout (II)

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?

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:

En Scrum se entrega solamente una vez cada Sprint

La aceptación de los PBIs en Scrum es algo que suscita dudas en los equipos. En realidad es muy fácil.

En Scrum tenemos cuatro eventos y un metaevento. Los eventos son el Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva. El metaevento es el Sprint, que es un contenedor para todos los demás.

Durante el Sprint Planning, seleccionamos los PBIs que queremos completar durante ese Sprint y trazamos un Sprint Goal que marcará la dirección de lo que queremos conseguir en ese Sprint. Una vez que vayamos trabajando en ellos, colaboramos con el Product Owner para que los validarlos. Los entregámos de acuerdo con nuestra Definition of Done tan pronto como estén validados.

En algunas organizaciones es más difícil, porque dependen de un proceso manual auditado de subida a producción, pero en aquellas que utilizan DevOps, tan pronto como se cumplen los criterios que tengamos establecidos, será un sistema automatizado el que se encarga de subir a producción. Una vez que esté hecho, los PBIs son aceptados.

Lo que no hay que hacer nunca es esperar hasta el Sprint Review para entregar los PBIs. Esto provoca una espera innecesaria. En cuanto el Product Owner los valida, deberían entrar en el pipeline de puesta en producción.

Poner en Producción y hacer una release

¿Que ocurre si los PBIs que hemos seleccionado en el Sprint no queremos ponerlos en producción? Esta es una cuestión de configuración. En Scrum, el concepto de “En Producción” y “Released” son distintos. El uso de herramientas que permitan hacer toggling feature permite tener software en producción y configurarlo a gusto del Product Owner.

Puede ser que hoy estemos haciendo elementos para la próxima campaña de Navidad. Este Software puede estar terminado y subido a producción pero no activado a ojos del usuario, lo cual nos permite también ver como se comporta y hacer cuantas modificaciones necesitemos sin correr tanto riesgo como en un sistema de despliegue tradicional.

Además, esta estrategia nos permite tener una Definition of Done más completa que incluya “puesta en producción” aunque sigamos trabajando en los elementos durante más tiempo, haciendo el desarrollo iterativo e incremental. Ante la duda, no, esperar a tener toda una nueva funcionalidad para ponerla en producción no es iterativo e incremental. Es más Waterfall.

En Scrum los PBIs se entregan tan pronto están finalizados, independientemente de si hemos llegado al Sprint Review o no. Nos permite desacoplar la entrega de los eventos. Así éstos se centren más en la estrategia de nuestro producto en lugar de en el funcionamiento técnico. O una demo.

Para validar el valor del Software realizado, esta vez sí, el Product Owner debería de buscar hacer una release cuanto antes.

Puedes leer más sobre como conseguir un buen Sprint Review en este artículo del blog.

  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Páginas intermedias omitidas …
  • Ir a la página 8
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad