Welcome to the Home of Scrum! ™

¿Qué es el autodiseño de equipos? La autoorganización es un proceso en el que alguna forma de coordinación surge de las interacciones entre los componentes de un sistema inicialmente desordenado. En las empresas de organización jerárquica, el diseño de la organización y su coordinación la realiza el management, por lo tanto no existe la autoorganización, aunque habitualmente sí existe en aquellas actividades que son delegadas por el management. Durante la investigación para la creación de este artículo, lancé una encuesta para conocer el grado de popularidad del autodiseño. Aunque la muestra es limitada, me pareció positivo que casi 2/3 de las respuestas afirmaran haber realizado el autodiseño para muchos o todos los equipos de una autoorganización, cifra que excede la de mi experiencia. Las respuestas de colegas como Michael Küsters, Martin Hinshelwood o Willem-Jan Agelling, me aportaron visiones más potentes que las que yo he podido ver en cliente. Podéis revisar de nuevo el enlace de la encuesta para ver los datos actualizados. Según el diagrama anterior, inspirada en el modelo de autoorganización de Gunther Verheyen [1], la autoorganización presenta varios niveles: Autogestión: las personas deciden como hacer el trabajo, pero no el diseño organizativo, p.e. el de los equipos. Autodiseño: las personas deciden como agruparse para realizar el trabajo, según su criterio. Autodirección: las personas deciden aspectos como los objetivos organizativos y las condiciones del trabajo. El nivel más habitual de autoorganización en las organizaciones ágiles es el de autogestión. La dirección dota de unos objetivos y de unos recursos a los managers, y éstos diseñan sus equipos. El autodiseño comienza cuando las personas deciden en que equipos trabajar, ya sean equipos estables o «equipos líquidos», con capacidad para cambiar de miembros según la evolución del trabajo. ¿Cómo planificar un proceso de autodiseño? ¿Estamos preparados para el autodiseño? En primer lugar se debería evaluar si el autodiseño es posible en esta organización y en este momento. Es imprescindible un soporte nítido de la Dirección y que la organización esté preparada, en aspectos como p.e.: Haber trabajado con equipos ágiles durante algunos años. Haber acompañado al management en la delegación y empoderamiento de los equipos. Tener equipos que estén a favor del autodiseño. A veces la Dirección no confía en que el proceso no vaya a funcionar por algunos rasgos de conducta que observa en los equipos, como baja colaboración entre equipos, poca proactividad o visión de conjunto. Según Michael Küsters [7], esto suelen ser razones sólidas para no iniciar un proceso aumplio de autodiseño. Como en muchos cambios organizativos, un paso para ganar el apoyo de Dirección y limitar el riesgo es hacer un piloto para formar un nuevo equipo. Otra opción es que la Dirección pueda experimentar el autodiseño en eventos como las hackhatons, y mejor si se realizan en la propia organización. ¿Qué enfoque seguir para organizar el autodiseño? Una vez que existe el apoyo de Dirección, se puede comenzar a planificar en serio el proceso de autodiseño. El primer paso es definir qué equipos pueden optar a ser autodiseñados. Tres opciones para hacerlo son: Dejar los equipos como están, y permitir a las personas cambiar de equipo. Esta opción plantea el menor riesgo y puede ayudar a la organización a conocer la implicación con los equipos, así como las necesidades de cambio de las personas. Diseñar los nuevos equipos según la estrategia de la organización, p.e. equipos para nuevos productos, o para cubrir una parte del «customer journey». Esta opción tiene más riesgo, pero va en la dirección de mayor crecimiento para la organización. Dejar a las personas proponer los equipos. Esta opción favorece la confianza en las personas que será necesaria para seguir en el proceso de autodiseño. Finalmente es la Dirección que habrá de escoger la combinación de estas opciones que considere viable, y en caso de percibir riesgo se puede comenzar por unos pocos equipos e ir creciendo según la experiencia. El proceso más habitual de autodiseño es el conocido como el «Mercado» (marketplace en inglés) que aparece en las referencias [2], [3], [4] y [5]. El Mercado consiste en que una vez definidos los equipos que se autodiseñaran, se organiza un evento presencial en en cual algunos roles preasignados (normalmente el Product Owner y el Scrum Master) explican (en modo «venta») las metas de sus productos e iniciativas, y los developers deciden a equipos quieren ir, considerando unas reglas y límites establecidos previamente. Se realizan varias rondas hasta que se considera que se ha alcanzado un autodiseño que cumple los objetivos. En mi experiencia directa, solo he podido participar en eventos parecidos al Mercado con uno o dos equipos. La dinámica del evento es parecida a la que explican los autores referenciados más abajo, pero con menos riesgo y mucho más sencilla de planificar y realizar por ser con muy pocos equipos. Otro proceso que uso Microsoft con hasta 600 desarrolladores fue un híbrido entre selección del management y autodiseño, que me contó Brian Harry (Technical Fellow), fue el siguiente: Los líderes presentaron sus planes y estructura de los equipos que proponían en un evento largo de varias horas. Los miembros de los equipos tenían varios días para pensarlo, hablando entre ellos y haciendo preguntas a dichos líderes. A continuación, dichos miembros hacían su petición con un orden de tres posibles equipos a los que querían ir. Finalmente los managers trataban de acomodar las peticiones de las personas en equipos equilibrados. La mayoría lograron su primera petición, una parte significativa la segunda y solo unos pocos la tercera. Aunque este proceso no es tan potente como el «marketplace» que veremos a continuación, fue muy apreciado por los trabajadores. ¿Cómo preparar el evento «marketplace»? Todos los autores coinciden en la importancia de la comunicación previa al evento. Para evitar al máximo los malentedidos, las conductas indeseadas, las dudas o la desconfianza en el proceso de autodiseño, es vital explicar bien aspectos como: Los objetivos del proceso. Los principios para tomar decisiones Las reglas y límites. El criterio de éxito del proceso. Cómo se procederá despues del evento. Definir las reglas, los límites y los principios del evento es fundamental para éste fluya adecuadamente, p.e.: Los equipos tienen que ser preferentemente autónomos y tener entre 3 y 7 miembros. Se tiene que cubrir unas capacidades mínimas (p.e. 2 front-end, 2 back-end, 1 tester y un especialist de sistemas) No pueden quedar equipos infradotados ni equipos sobreasignados. En caso de duda, el bien del equipo o empresa prima a mi interés propio. Tanto en mi experiencia como en la de otros que han desarrollado estos procesos [2], [3] y [7], es importante que las reglas sean tan pocas como claras. Muchas reglas frenan la potencia del proceso y la autoconfianza de los miembros de los equipos. Las reglas confusas pueden causar que los managers necesiten corregir el proceso posteriormente, restándole igualmente credibilidad y confianza. Un plan de facilitación puede ser muy útil para que los facilitadores trabajen de manera común, y un simple poster con las reglas colgado en la pared puede ser suficiente para los participantes en el evento de «Mercado». Ejemplos de paneles de mercado de autoselección de Dandy People y Flowdays. ¿Cuál es la estructura y dinámica del evento? La estructura habitual de los eventos tipo Mercado de autodiseño, según [2], [3], [4] y [5] es sencilla: Presentar los objetivos, estructura y reglas del evento. Los Product Owner presentan las iniciativas para las que buscan developers. Se repiten ciclos de autodiseño, evaluación de resultado y búsqueda de mejoras. Se finaliza el evento, presentando los resultados y explicando los siguientes pasos. Para no extenderme demasiado en el artícul me centraré en los puntos menos evidentes: Los ciclos de autodiseño La principal herramienta de los evento tipo Mercado son los paneles con las características y miembros de los equipos que hemos visto un poco más arriba que contienen p.e. tanto el nombre y objetivos del equipo, como sus necesidades de perfiles. Las actividades de estos ciclos son: El un tiempo breve (p.e. entre 5 y 10 minutos) las personas escogen a que equipo quieren ir. Se revisa si se han cumplido los objetivos, típicamente conseguir definir todos los equipos cumpliendo las reglas, principios y límites. Habitualmente los Product Owners revisan el estado de cada equipo, y cualquier miembro del evento puede hacer observaciones. Finalmente, se hace una mini-retrospectiva: cualquier miembro del evento puede proponer mejoras. La finalización del evento Como en todo proceso ágil, buscamos: Transparencia en el proceso y aprendizaje, como pasa en las Retrospectivas de los Sprints. Por ello se recomienda reservar una parte final de la sesión para que todos los participantes busquen puntos fuertes y débiles sobre el funcionamiento de la sesión, así como propustas de mejoras, respecto aspectos como: Claridad del proceso y la información. Facilidad para tomar las decisiones. Comodidad con el resultado final. Y además es importante dejar claros los siguientes pasos, como pasa en las Revisiones de los Sprints, en este caso: Dejar claro cuando se van a desplegar los equipos, y que pasos previos se darán. Como se va a coordinar el proceso y como se realizará la comunicación. ¿Cómo desplegar los resultados del evento? Una vez concluido el taller de autodiseño, tenemos una propuesta de equipos que debe respetarse al máximo posible. Es conveniente que un grupo centralizado siga dando soporte a los equipos que se van formar y centralicen la relación con la Dirección y la comunicación. Durante el periodo de despliegue de los nuevos equipos, que se recomienta que no pase de 2 o 3 meses [2], las actividades de soporte a estos equipos son: Seguimiento de los impedimentos para lanzar los equipos, p.e. la dedicación a otros equipos que no se puede liberar. Reuniones o contactos asíncronos y periódicos entre los equipos ya creados para compartir experiencias. Actividades de creación de los equipos, como definición del manifiesto de equipo, formaciones iniciales comunes, observaciones entre equipos para aprender entre ellos, etc. Conclusiones En este artículo he revisado los procesos de autodiseño de equipos, desde la exploración inicial con dirección hasta la preparación, realización y seguimiento del taller de autoselección. Para ello me he basado en mis experiencias (varias, pero centradas en la creación de nuevos equpos) y en las de algunos coaches conocidos (que han incluido la creación de múltiples equipos en paralelo). Algunas conclusiones de lo explorado son: El autodiseño es un síntoma de una cultura ágil madura. El autodiseño es coherente con una cultura de equipos autogestionados. El autodiseño tiene efectos más allá de la creación de los equipos, como el rol del management para con los equipos, o la información de la que dispone RR.HH. Recursos para saber más Niveles de autoorganización, según Gunther Verheyen. Creating Great Teams, por Sandy Mamoli & David Mole Self-organising a new organisation — the Marketplace, de Willem-Jan Ageling Team Selection: Manager Selection or Self-Selection? de Sunil Gulia Self-organization Chefs, de Ziryan Salayi Self-selecting teams on a small scale, de Magnus Dahlgren Encuesta en Linkedin sobre Autodiseño Lessons Learned from Self-Selection Reteaming at Redgate

A roadmap is a complementary practice that a Scrum Team might use to forecast upcoming deliveries or to translate Product Backlog items into a visual representation. This article includes a few Roadmap templates for Product Owners to use to communicate their forecast to customers and stakeholders. Give them a try and let me know what you think in the comments section!

Aiming towards Sustainable Pace “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." - The Agile Manifesto Principle “programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime.” - Extreme Programming An unsustainable pace is unhealthy. It contributes to burnout, quality issues, and unpredictable results. If you are an agile leader - do you know whether your teams are currently operating at a sustainable pace? Do you care? Would you rather not know because you’re afraid of the answer? Measuring Sustainable Pace Beyond having a general idea of the sustainability of pace, perhaps it would help to have a concrete KPI related to it? If we use the language of OKRs, maybe something along these lines: Objective Achieve a healthy sustainable pace KR1 - People working reasonable hours AMB (as measured by) hours per week KR2 - People happy about their pace AMB continuous survey KR3 - Plans don’t assume unsustainable pace AMB ability to achieve forecasts without resorting to unsustainable pace measures Forecasting towards Sustainable Pace by inspecting sustainability of past pace The last KR relates to the planning/forecasting approaches we use in agile. Agile approaches leverage empirical planning approaches. They look at the past (Yesterday’s weather) to try and forecast the future. Whether it is Sprint/Iteration planning or forecasting single item completion times using SLEs. Whether by looking at Velocity, Throughput, or Cycle/Flow Times - most approaches tend to ignore how these past results were achieved when using them to predict future capacity. For example, if our velocity in previous Sprints was 15-20 points, we will probably take on about 15-20 points. But what if these 15-20 points required a herculean effort that wasn’t sustainable? If our cycle/flow times are 7-10 days 85% of the time we will be tempted to set that as an SLE (Service Level Expectation) to ourselves. But does that make sense if this was achieved while working 60 hour weeks? Planning/Forecasting using a Sustainability Factor What I’m advising teams/organizations I’m working with is to consider the “sustainability factor” when considering any past results for the purpose of forecasting the future and adjusting accordingly. This isn’t trivial. It requires making sustainable pace an explicit “citizen” of the measurement dashboard and conversation. We have learned that speed and quality are related. We now understand that inappropriate speed might be at the expense of quality, so we look at a balanced scorecard of speed and quality. Moving forward, we need to add pace sustainability to this scorecard and to the conversation around how much work does it make sense to forecast. A metric I've been toying with is Weighted Predictability/Sustainability: As you can see here, achieving reasonable predictability scores is weighted down by the unsustainable pace required to achieve them. so a score of 80% is actually weighted down to 53%. This 53% is what should be used for future planning purposes. For example during Sprint Planning. Similarly if the team is able to meet an SLE of 8 days or less 80% of the time but do it with an unsustainable pace of around 150% - it means that actually they are able to meet their SLE when working sustainably around 50% of the time. A couple of caveats though - we know its not all about effort, and there are a lot of delays in the work, and it might actually be that if we work at a more sustainable pace we will achieve better predictability with the current SLE or amount of work we take on. We don't really know, and that's ok. The only thing I'm trying to stress here is that we shouldn't ignore HOW we are achieving the results we are. Moving Forward - Treating Pace Sustainability as a first-class citizen So what's a good name for this metric / KPI. Flow Sustainability? Pace Sustainability? Work Sustainability? Burnout Risk? Does it make sense to use some sort of weighted factor combining predictability and sustainability? Is it enough to look at sustainability from a qualitative perspective? would it help to make it more quantitative? Are you explicitly measuring anything related to Sustainable Pace? Do you have goals around it? Do you take it into consideration when planning? Please share in the comments!

El Scrum Master es un líder servicial que se enfoca en el crecimiento de las personas, trabajo en equipo, la adopción del empirismo y la autogestión para ayudar a maximizar la entrega de valor. Ser exitoso como líder servicial se evidencia cuando las personas a las cuales se sirven son exitosas. Esto puede verse reflejado como el logro de resultados grandiosos, la capacidad para trabajar en equipo, el crecimiento continuo de las personas, la mejora continua y al aprendizaje, el coraje para buscar soluciones o acciones para lograr el objetivo del equipo. Este liderazgo servicial promueve un entorno de confianza, una cultura basada en la confianza y la transparencia de las personas así como el foco en la entrega de producto con valor a los clientes entre otras cosas.