¿Cómo se logra un equipo autoorganizado?

La autoorganización no se puede planificar, es un comportamiento natural del ser humano, está en nuestros genes. A las personas les gusta trabajar con otras personas, todos tenemos las habilidades pero a veces no sabemos como usarlas y la única forma es crear las condiciones propicias para que emerja en el equipo y se refuerce con mejora continua. 

Si se juntan 4 niños de procedencias distintas, por ejemplo un español, un alemán, un japonés y un americano y solo hablan su propio idioma, acabarán jugando como los mejores amigos de toda la vida en cuestión de media hora.

Primero veamos qué significa autoorganización:

Autoorganización es cuando se hacen las cosas

y no hay necesidad de orquestación por parte de nadie

Un equipo autoorganizado es responsable tanto de dirigirse y de organizarse para alcanzar el objetivo marcado, así como de controlarse y adaptarse para corregir y mejorar su desempeño.

Tal como describe Brad Appleton en su artículo "Agile Self-Organizing Teams", un equipo ágil autoorganizado es:

• Autónomo: No existe una única autoridad central para la toma de decisiones, el control se distribuye colectivamente dentro del equipo
• Adaptable: El equipo ajusta dinámicamente sus roles, especialidades funcionales y otros limites con el fin de resolver sus propios problemas y mejorar su propio desempeño
• Responsable: El equipo comparte colectivamente la responsabilidad de los resultados

Equipo en proceso de autoorganización

Para lograr la autoorganización de un equipo hay que partir de ciertas condiciones: debe de haber metas claras y a corto plazo para poder establecer el compromiso. Debe de haber visibilidad y transparencia en la contribución y el progreso de cada miembro, así como del progreso del equipo. Se deben de establecer los límites según el contexto del negocio, el equipo ha de tener claras sus restricciones al trabajar: objetivos de negocio, presupuesto, tiempos de entrega...

Con las condiciones adecuadas la autoorganización se logra incrementado la autonomía del equipo a medida que van adquiriendo la misma. Pronto se crean la confianza y la seguridad para una retroalimentación honesta y una crítica constructiva entre los miembros de equipo, siendo esta la clave para que pueda asentarse la autoorganización. Las retrospectivas son claves para reforzar la autoorganización, mediante la mejora continua de cada retrospectiva debe de obtenerse una mejora que al implementarla contribuye a la creación de un equipo ganador.

Hay dos obstáculos principales que pueden darse. En primer lugar está la cultura jerárquica y de control existente en muchas organizaciones. Esta hace que el equipo no siempre tenga la oportunidad de tomar las suficientes decisiones, en ocasiones es necesario un cambio de cultura organizacional. Por otro lado hay que vigilar individuos negativos o escépticos con la autoorganización, estos pueden influenciar al equipo e impedir la autoorganización.

¿Cuáles son las tareas de un Propietario del Producto?

Recordemos que el Propietario del Producto (Product Owner) es quien tiene la autoridad y el poder de decisión sobre el producto que estamos construyendo para el cliente. Su responsabilidad principal reside maximizar el valor del producto; que construyamos un producto que sea una verdadera solución a los problemas del cliente, su compromiso es con los problemas de los usuarios/cliente, no con los elementos de la pila de producto aunque sea responsable de la misma. Decide en última instancia cómo será el resultado final, y el orden en el que se van construyendo los sucesivos incrementos: qué se pone y qué se quita de la pila del producto, y cuál es la prioridad de las funcionalidades. Conoce el plan del producto, sus posibilidades y plan de inversión, así como del retorno esperado a la inversión realizada, y se responsabiliza sobre fechas y funcionalidades de las diferentes versiones del mismo.

Hay una metáfora que describe muy al Propietario del Producto:

El Propietario del Producto es al producto como el CEO lo es a la compañía.

Como analogía con el post sobre las tareas del Scrum Master dejo aquí el siguiente listado de tareas de un Propietario del Producto, compilado por Bernd Schiffer en "37 Tasks for a Product Owner’s Job":

Tareas principales

El Product Owner por Erich Bühler

• Desarrollo y la adaptación de la hoja de ruta y visión del producto
• Escribir nuevas historias de usuario
• Dividir historias de usuario que son demasiado grandes
• Especificar criterios de aceptación para cada historia de usuario
• Escribir pruebas de aceptación
• Ordenar y priorizar la pila del producto (a través del ROI, modelo de Kano, costo-valor, el método MoSCoW, etc.)
• Planificación de releases
• La preparación de su cartera de productos (Aplicar INVEST y DEEP)

Puertas a fuera

• Observar, conocer y analizar el mercado
• Observar, conocer, contactar y analizar a los clientes y usuarios finales del producto
• Mantenerse en contacto regularmente con todas las partes interesadas del producto
• Informar a la dirección y las partes interesadas (por ejemplo gráfico del producto)
• Compartir conocimiento en toda la empresa con respecto al producto (micro-blogging, blogging, conferencias internas, etc.)

Liderazgo

• Decidir qué construir y lo que no
• Dar retroalimentación al equipo de desarrollo durante el sprint del trabajo realizado y sobre sus procesos e interacciones
• Practicar el principio Lean Go & See (Gemba Walk)
• Reclamar y explicar implementaciones de un solo clic para mantener bajos los costes de transacción (transporte)
• Reclamar y explicar builds de 10 minutos para preservar retroalimentación rápida
• Reclamar y explicar feature flags para preservar la flexibilidad
• Proporcionar y enseñar todo número de negocios al equipo de desarrollo para conectarlos con el producto y sus clientes, y poder tomar conjuntamente decisiones informadas

Skills del Product Owner por Alexandre Magno

Participación

• Participar en las reuniones de Scrum:
• Proporcionar el objetivo del sprint y nuevas historias de usuario para la planificación del sprint
• Dar retroalimentación en la revisión del sprint respecto del logro al objetivo del sprint
• Reflexionar y actuar como miembro del equipo en la retrospectiva del sprint
• Informar, ayudar y aprender en el scrum diario
• Ayudar continuamente al equipo a mejorar sus procesos

Aprendizaje

• Formarse de forma continuada sobre todo lo que es Agilidad (por ejemplo visitar grupos de usuarios, asistir a conferencias, leer libros, escribir blogs, etc.)
• El intercambio constante con otros Propietarios del Producto de la organización (por ejemplo a través de comunidades de práctica)
• Jugar con el producto
• Aprender y perfeccionar la cadena de valor entera del producto, como la contratación, el marketing y ventas
• Medir el progreso (por ejemplo el valor entregado a los clientes en cada sprint)

Misceláneo

• Ayudar al equipo crear irradiadores de información
• Entusiasmar a los clientes
• Encontrar una adecuada
• definición de listo (DoR)
• definición de hecho (DoD)
• Reforzar cada bucle de retroalimentación con respecto al producto (por ejemplo entrega continua, entrega temprana, hablar con los clientes, Minimal Marketable Product, etc.)
• Convertir las ideas en nuevos productos, idealmente MVPs

A menudo los Propietarios del Producto tienen una gran cantidad de compromisos que no están directamente relacionados con el producto, estos deberían de hacer todo lo posible para poner el foco en las tareas del bloque de tareas principales. En mi experiencia un equipo trabajando con Scrum requiere aproximadamente un 50% del tiempo de un Propietario del Producto.

¿Se puede aplicar Scrum en proyectos con factorías de software?

Como en la filosofía empresarial de muchas compañías, la inclusión de las factorías de software o e-labs (laboratorios externos) en los proyectos de TI nos viene heredada del taylorismo, que según dicta con su gestión de organización científica, divide las tareas en quien piensa y en quien las hace. Un profesor que tuve sostiene que la factoría de software es una aberración nacida del modelo del taylorismo, en que los gerentes gestionan los principios de planificación y ejecución del trabajo de personas que dejan de ser tales para convertirse en robots llamados recursos.

Modelo de caja negra de factoría de software

El peligro real de las factorías de software es su naturaleza de caja negra, no tanto por el hecho de que tengan que demostrar que funcionan y por tanto nos oculten su cocina y penurias, sino por la pérdida de conocimiento. Uno de los activos más valiosos de las compañías de TI es el conocimiento, y con factorías de software el conocimiento tácito se genera fuera de la compañía y se perderá definitivamente cuando se acabe el trabajo y se disuelva la factoría. Quizá en la factoría se haya aplicado Scrum y con cada sprint haya habido un aprendizaje valioso y mejora continua, pero con un modelo de caja negra no hay afianzamiento de conocimiento.

Con un modelo diferente Scrum podría ser aplicable a proyectos en factorías de software, tendría que ser un modelo colaborativo en que Scrum se aplicase desde la compañía de TI con el cliente presente en forma de Propietario de Producto. Los equipos de la factoría de software deberían estar presentes, física o virtualmente, en todas las reuniones que dicta Scrum, sobre todo en la reunión diaria, todo ello según el modelo de escalabilidad establecido. Por otro lado sería clave la labor de crear y aumentar las conexiones entre personas, las personas de la compañía, las de las factorías y las del cliente.

La aplicación de Scrum en proyectos con factorías de software es posible, pero requiere cambiar la naturaleza de caja negra de las mismas y por ende un cambio cultural en el que cliente y proveedor actúan como verdaderos partners. Quiero resaltar que la industria automovilista lo ha entendido con JIT "just-in-time", un método que requiere respeto por la red de partners y proveedores, desafiándolos y ayudándolos a mejorar, donde se tratar a las personas como parte más de la compañía cliente, de forma que busquen cumplir los objetivos marcados como si fueran de su propia empresa. Y no nos engañemos, en un modelo de caja negra tal como las he vivido hasta ahora, las preocupaciones sobre los riesgos son las propias, las de la factoría, y por tanto es necesario un verdadero cambio cultural hacia Agilidad para que pueda funcionar con éxito.

¿Es el Scrum Master un rol a tiempo completo?

Recordemos que el Scrum Master es el responsable del cumplimiento de las reglas del marco de Scrum, asegurando que se entienden en la organización, y se trabaja conforme a ellas. Proporciona la asesoría y formación necesaria al Propietario del Producto y al equipo. Realiza su trabajo con un modelo de liderazgo al servicio: al servicio y en ayuda del equipo y del Propietario del Producto.

Responsabilidades del Scrum Master,
gestión del proceso y de personas

En casi todos mis cursos hay alguien que hace la pregunta del post. Algunos formulan si puede ser una ocupación parcial, otros si un miembro del equipo puede llevarlo a cabo una vez haya sido entrenado adecuadamente e incluso otros si puede ser un rol que puede ser rotativo entre los miembros del equipo.

A la izquierda podemos ver una tarta con las principales responsabilidades del Scrum Master agrupadas en dos áreas: gestión del proceso, aproximadamente un 20% de su tiempo, y gestión de personas, aproximadamente un 80% de su tiempo.

Para los que quieran responder a esta cuestión de una forma más completa y por si mismos, pueden echar un vistazo al siguiente listado de tareas necesarias para garantizar el cumplimiento de roles y formas del modelo, tareas propias de un Scrum Master compiladas por Bernd Schiffer en "42 Tasks for a Scrum Master’s Job":

Lo que es y no es un Scrum Master

Reuniones

• Facilitar las reuniones del equipo, incluidas las retrospectivas: preparar, moderar, revisar

Equipo

• Formar y entrenar a los miembros en Scrum
• Hacer de coach para los miembros del equipo (uno a uno)
• Ayudar al equipo a mantener sus herramientas actualizadas
• Ayudar al equipo y al Propietario del Producto a consensuar una definición de hecho (DOD)
• Mediar en conflictos entre miembros del equipo
• Ayudar al equipo a tomar decisiones
• Ayudar al equipo a autoorganizarse
• Mediar en conflicto de intereses entre el equipo (alta calidad) y el Propietario del Producto (más funcionalidades)

Aprendizaje

• Aprender continuamente sobre Agilidad (participar en foros, asistir a conferencias, leer libros, escribir blogs, etc.)
• Hacer de consultor en todo lo relativo a Agilidad
• Ayudar al equipo a crear radiadores de información
• Proporcionar feedback al equipo
• Fomentar el uso de prácticas ágiles en el equipo de desarrollo
• Retar al equipo con innovaciones de gestión ágiles
• Interaccionar con otros Scrum Master en la organización
• Practicar el principio Lean Go & See (Gemba Walk)

Producto

• Familiarizarse con el trabajo del equipo, o sea, el producto
• Ayudar a escribir historias de usuario
• Ayudar a escribir o adaptar la visión del producto
• Ayudar a ordenar los ítems de la pila de producto
• Ayudar en la planificación de la release

Panorama general

• Introducir Scrum en la cultura de la empresa
• Reunir a gente para que conversen
• Mantener contacto con cada interesado regularmente
• Ayudar al equipo a informar a gerencia
• Ayudar a crear una comunidad ágil en la organización
• Ser la persona de contacto con respecto a Agilidad
• Promover la formación sobre Agilidad en la organización, realizando charlas, talleres, etc.

Cambio

• Ayudar al equipo a deshacerse de los impedimentos
• Sugerir al equipo nuevas métricas que catalicen el cambio
• Ayudar al equipo a mantener el foco

Observación

• Recordar al equipo sus políticas
• Ayudar al equipo a mejorar continuamente su proceso
• Informar al equipo de lo observado
• Hacer preguntas abiertas
• Mostrar las diferencias entre los modelos que usa el equipo y la realidad

---

Apéndice

Durante el Global Scrum Gathering Munich 2016, donde coincidimos más de 600 profesionales de Scrum, hubo openspaces dedicados al rol del Scrum Master, y una de las conclusiones fue acerca de cuantos equipos puede acompañar un Scrum Master a la vez:

• Scrum Master -> tres equipos
• Good Scrum Master -> dos equipos
• Excellent Scrum Master -> un equipo

Openspaces en el Global Scrum Gathering Munich 2016

¿Scrum es un modelo de desarrollo?

Marco de trabajo Scrum

Si, Scrum se considera un modelo o marco de desarrollo ágil que se adapta a la era actual considerada del cliente, donde el cambio y la variación es inherente a cualquier proyecto o construcción de un producto.

Os quiero animar a leer el artículo "Nuevos modelos de desarrollo: Scrum" de mi amigo Alberto. Él, al igual que yo en este blog, va poniendo sus granitos de arena para que la Agilidad y Scrum vayan calando en nuestra cultura TI y vaya llegando a nuestras empresas y compañías.

¿Qué estrategia utilizar para que el conocimiento tácito se quede en la organización?

Lo que me sale del alma es la frase de "never change a winning team", quizá porque he tenido el placer de formar parte de equipos ganadores y sé todo lo que importa eso. Lo que quiero decir con esta frase es que si tienes un buen equipo, ¡cuídalo!, son los mecánicos de la herramienta que hace funcionar el core-business de tu negocio.

Bus factor

Luego viene la realidad y las personas rotamos, entramos y salimos de los equipos. Scrum propicia la comunicación, impulsa a los miembros del equipo a ser personas con perfil "T", personas expertos en su especialidad, la "I", y a la vez interesados por todo lo que les rodea, la"¯". Este ambiente, con personas abiertas e interesadas, donde la comunicación entre todo el equipo es informal y continua, facilita muchísimo el aprendizaje y la integración de nuevas personas en el equipo. Por tanto, con una rotación "normal" el conocimiento tácito no se pierde.

Lo que hay que vigilar es el "bus factor", una medida de la concentración de conocimiento en cada miembro del equipo. Imaginemos que el equipo sale de juerga y los atropella un autobús. Hay que preguntarse ¿cuántas personas tienen que resultar gravemente heridas para que el proyecto se tenga que cancelar? Si la respuesta es una persona, hay que actuar con urgencia. Hay que procurar mantener el bus factor muy elevado, en un equipo de cinco personas, es recomendable a partir de tres y, en un equipo de ocho, como mínimo cuatro.

¿Por qué la baraja de planning poker se basa en la serie de Fibonacci?

Leonardo de Pisa, Fibonacci

Es un hecho que para historias de usuario pequeñas la incertidumbre en la estimación es mucho menor que para las historias grandes, y mientras el tamaño de las historias crece linealmente la incertidumbre crece exponencialmente.

La serie de Fibonacci está compuesta por números que son la suma de los dos anteriores:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

La distancia entre los números de la serie refleja el hecho de que la incertidumbre inherente a la estimación crece proporcionalmente con el tamaño de la historia de usuario. Así, las diferencias entre 1, 2 y 3 puntos de historia son probablemente mejor comprendidas que las diferencias entre 13, 21 y 42.

Las barajas se basan en la serie de Fibonacci pero tienen ciertas variaciones. Se incluye el 0 para historias que requieren un esfuerzo casi nulo, 1/2 para historias muy pequeñas. Algunas barajas sustituyen el 21 por un 20, ya que decir que una historia tiene un tamaño de 21 da una falsa sensación de precisión. A partir del 21 las barajas suelen pasar al infinito (∞) y, si siguen, incluyen valores redondos como 40 y 100.

Distintas barajas de planning poker

También hay razones que derivan de la naturaleza humana para utilizar esta serie. Para las personas nos es fácil estimar de forma relativa, nos es fácil determinar cuánto menor o mayor es algo respecto a otra cosa. Pero tenemos la tendencia de pensar en múltiplos de dos, por ejemplo, una historia de usuario la comparamos con una de 2 puntos, vemos que es mayor y automáticamente pensamos en 4, 8 o 16. La serie de Fibonacci nos obliga a romper con ello y a buscar la estimación más adecuada.

Además resulta que somos buenos utilizando la serie de Fibonacci, no distinguimos bien entre 5 y 6 y 7 pero si entre 5 y 8. Esto ocurre porque la serie de Fibonacci está en todas partes en la naturaleza, como en la mayoría de las plantas, los cristales y nuestras falanges por ejemplo que tienen tiene tamaños relativos 2, 3 y 5. También nuestra cultura está impregnada de la serie, como en la música, la arquitectura y la pintura.

Vivimos inmersos en proporciones de la serie de Fibonacci, hasta el punto de que todo aquello cuyas proporciones cumplan con el cociente de dos números de la serie, el número áureo, lo consideramos bello. 

---

Quiero invitaros a leer el post "Estimaciones de un proyecto" de Personas y Proyectos donde Paz nos invita a estimar proyectos nuevos con la serie de Fibonnaci con cartas de planning poker.

¿Qué ocurre con la velocidad del equipo cuando las horas estimadas de una historia de usuario son inferiores a la suma de las horas estimadas en las tareas correspondientes de la pila de sprint?

Este es un tema alrededor del cual suele producirse confusión. Aunque lo que estimamos es esfuerzo y no tiempo, la unidad "horas ideales" la asociamos inconscientemente al tiempo.

Para ilustrarlo veamos el siguiente ejemplo: Un historia de usuario estimada en 20 horas se ha descompuesto en la reunión de planificación del sprint en una tarea de 8, otra de 10 y otra de 4 horas. Sumando las tareas vemos que necesitaremos 22 horas, y suponiendo que solo realizamos esa historia de usuario en ese sprint, nos preguntamos si la velocidad del equipo es 20 o 22.

Fijaros que la estimación de la historia de usuario probablemente la hayamos realizado en unos pocos minutos, seguramente con estimación de póquer, mientras que las estimaciones de las tareas las hemos trabajado y pensado en profundidad. Simplemente no podemos comparar unas horas con las otras, sería como comparar manzanas con peras.

Por tanto la velocidad del ejemplo anterior es 20h/sprint, aunque se estimen 22 horas ideales para desarrollar las tareas.

Ahora cambiamos de escenario, en vez de la estimación de 20 horas, estimamos la historia de usuario en 5 puntos de historia. ¿A que ahora no hay duda de que la velocidad es de 5 puntos de historia/sprint? Recordad que las tareas de la pila de sprint siempre se estiman en horas, por tanto aquí tenemos una buena razón para medir el esfuerzo de la pila de producto en una unidad diferente a horas.

Las consecuencias de confusión en este tema pueden ser nefastas para un proyecto. Nuestra historia tiene un tamaño en esfuerzo de 20 horas, como hay cierta confusión pensamos que nuestra velocidad es de 22 horas/sprint, y por tanto cuando hagamos la siguiente reunión de planificación de sprint seleccionaremos historias por esas 22 horas... cuando realmente nuestra velocidad en horas de pila de producto es de 20. Tomaríamos la decisión equivocada de incluir la historia 3 del ejemplo anterior en el segundo sprint. La buena noticia es que al cabo de 2/3 sprints cualquier equipo se daría cuenta de ello y tomaría las medidas adecuadas.

Recordad, la velocidad siempre se ha de basar en, y solo en, las estimaciones de la pila de producto.