Scrum en la practica

El equipo de desarrollo se auto-organiza

Hace unos días asistí a una reunión para tratar temas sobre como el equipo de desarrollo se comunica internamente en Optiopay, uno de mis clientes en Berlín. Oficialmente, soy el Scrum Master del equipo, a pesar de que sólo estoy unos días al mes en la oficina.

Las organizaciones que comienzan a implementar Scrum comenten frecuentemente el error de intentar estandarizar a todos los equipos ScrumDurante la reunión, mi participación ha sido mínima, por no decir nula. Ellos mismos han probado un framework para mejorar la comunicación y estaban analizando los resultados. Mi única intervención ha sido para preguntar: ¿Es útil para vosotros?.

Frecuentemente, los Scrum Masters y Product Owners quieren saltar a la conversación y dirigir la vida de los equipos de desarrollo. Los programadores, acostumbrados a que les digan lo que hay que hacer, no defienden su espacio de auto-organización y con ello no fomentamos una práctica fundamental: la responsabilidad.

Un concepto clave para el éxito de Scrum es la auto-organización de los equipos de desarrollo, donde son ellos los que deciden sobre todas las características de su trabajo y como realizarlo. Estar en un nivel u otro de auto-organización dará unos beneficios u otros a la organización.

Un equipo de desarrollo que use Scrum, pero se limite a las prácticas mecánicas (Eventos, Roles, Artefactos) producirá beneficios, pero no podemos esperar grandes resultados, ya que la organización todavía tiene que madurar alrededor de la nueva forma de trabajar. Esto es uno de los problemas y olvidos más grandes de las organizaciones, especialmente las más grandes, que tienden a imponer un sistema estandarizado de trabajo.

El reto del Scrum master

El reto del Scrum Master es ser capaz de influenciar a la organización sin autoridad y sin intervención directa.El Scrum Master está ahí para demostrar que sabe de Scrum e intervenir a la más mínima oportunidad para demostrar su conocimiento, lo que limita aún más los beneficios de la auto-organización. Para mí, es clave. Si el equipo de desarrollo tiene problemas de comunicación, tienen que buscar la forma de solucionarlo por sus propios medios. Mi labor como facilitador de Scrum es que puedan hacerlo sin intervenciones externas, incluida la mía.

Los equipos de desarrollo pasan por épocas de conflictos que tienen que resolver ellos mismos, sin intervención externa y la labor del Scrum Master es facilitar ese proceso sin intervenir directamente en el resultado. Ese es el dilema del Scrum Master: cómo influenciar a la organización sin autoridad.

Promulgar la auto-organización de los equipos de desarrollo es fundamental para el buen funcionamiento y la entrega de producto. Sin embargo, si no permitimos que se desarrolle la auto-organización, nunca llegaremos a obtener el máximo beneficio, en el que un equipo de desarrollo puede ocuparse de la calidad del producto y sentirse dueño de su trabajo sin injerencias por parte de otros.

Esta semana, cada vez que sientas la necesidad de intervenir en temas del equipo de desarrollo, repita hondo y observa como, independientemente de lo que hagas, llegarán a una solución. No, como Scrum Master, no necesitan de tu intervención para solucionar sus problemas porque son adultos.

Scrum es un circo y el Scrum Master un payaso

Scrum requiere coraje. Es uno de sus valores fundamentales. Sin coraje, Scrum es una pérdida de tiempo.

Viernes. 16:41. Retrospectiva del dream team

– Bueno, vamos a empezar la retrospectiva. Es tarde y todos tenemos ganas de irnos a casa. Para romper el hielo vamos a empezar con el siguiente ejercicio: ¿Si fueras un coche en esta retrospectiva, que marca y modelo serias?

Le gente pone cara de póker. La mayoría de ellos han llegado a las 9 de la mañana y saben que a pesar de lo que diga la Scrum Master, se quedarán después de la retrospectiva para terminar el despliegue de la aplicación porque el Product Manager esta mañana le ha dicho al comité de dirección que el Lunes por la mañana los últimos cambios estarían implementados.

– Un Lamborghini – responde Manolo -, el coche que nunca tendré.
– Un camión de bomberos, porque siempre estoy apagando fuegos.
– Una carreta tirada por bueyes…

Mariola es Scrum Master desde hace un año, cuando Queremos tu dinero Banco S.A. decidió que había que ser ágil porque el CTO se leyó un libro que hablaba del tema en sus vacaciones de Navidad en San Tropez. Cuando volvió de las vacaciones, convocó al comité de dirección para comunicarles la decisión del cambio de rumbo y como Agile les llevaría al cielo de las-corporaciones-gordas-que-se-comportan-como-startups-para-parecerse-a-apple.

Así que de Jefa de Proyecto se convirtió en Scrum Master. En realidad el trabajo es más o menos el mismo, pero se hace más divertido. El banco contrató a Más Agilidad S.L., una empresa creada por dos Agile Coaches que dan charlas sobre transformaciones que nadie ha visto en las conferencias más importantes de su sector. Lo que aprendió Mariola es que hay que mantener a la gente motivada y para ello las retrospectivas son muy importantes, por eso cargó al presupuesto de su proyecto comprar un montón de cajas de Legos.

– Para recoger datos, quiero que construyáis un modelo con Lego® de cómo ha sido el Sprint.

El equipo construye modelos. Jugar con bloques es divertido y al menos uno se distrae de la semana. Ninguno de ellos trabaja para el banco, todos están subcontratados por distintas consultoras. Algunos se plantean si realmente le facturan al banco las horas que se pasan jugando. En cualquier caso, seguro que se compensa con el Overtime.

Uno a uno muestran sus modelos. Laura enseña su modelo, donde todos los miembros del equipo mira a un espacio vacío. – ¿Y eso? – El hueco vacío es el del Product Owner.

Mariola hace una carantoña. Han discutido esto muchas veces. El Product Manager está muy ocupado y sólo acude a algunas retrospectivas. Es por eso que ella hace de Proxy Product Owner para facilitar el trabajo del Product Manager. Se encargar de priorizar las tareas del backlog y escribir las tareas que el equipo tiene que hacer. Ella hace su trabajo lo mejor que puede. Un día ella será la Product Manager y también estará ocupada en cosas más importantes.

– El último Sprint el equipo se había comprometido a entregar 56 Story Points y sólo ha entregado el 70%, estamos reduciendo la eficiencia del equipo. ¿Qué está pasando?

Más Agilidad S.L. les ha mandado un Agile Coach muy joven. Está con el equipo una vez por semana y a veces cuando habla parece que estuviera desconectado de la realidad. Ha insistido en que las retrospectivas son muy importantes. El jefe de Mariola le ha dicho en secreto que el Scrum Master es un puesto de recursos humanos y que su trabajo es motivar a la gente.

– Mira, este modelo representa una mierdecita con ojos del wahtsapp – dice Manolo.

Manolo es muy problemático. El Agile Coach le ha dicho a Mariola que tiene un problema de motivación y Mariola intentó el modelo de los cinco pasos de la manipulación para hacerle entrar en razón, pero no quiere. Es una persona muy difícil.

Ya han pasado 40 minutos. El equipo escribe las cosas que hay que mejorar. Entre las mismas cosas de siempre, alguien ha escrito: Contratar una cabra de Product Owner. Mariola elimina discretamente el Post-it®. Todos son muy difíciles y no están comprometidos con la empresa. Después de un año, las cosas no parecen ir a mejor y el coach de Más Agilidad S.L. les ha dicho que su problema es de flujo y que necesitan hacer Kanban.

Manolo habla de nuevo. Hace un chiste sobre payasos y circos. Mariola cierra los ojos y se imagina conduciendo una excavadora. Terminan, se levantan del bar, pagan y vuelven al trabajo. El camarero les mira raro pero no dice nada, lo de hacer las retrospectivas en un bar no está funcionando cómo esperaba, pero eso no importa, porque ella va a dar una charla sobre el tema en la próxima conferencia ágil. Sus retrospectivas son las mejores.

Introducción a Scrum en Agile in Africa 2015 [ENG]

Los 7 pecados capitales del Product Owner

1. Pensar que su responsabilidad es gestionar el Product Backlog

La responsabilidad del Product Owner es maximizar el valor del Producto del que es responsable. Eso incluye, entre otras tareas, gestionar el Product Backlog, pero no está limitado a ella. El Product Owner realiza muchas otras tareas que están enfocadas a desarrollar el producto que el cliente quiere. Esa es su labor principal.

2. No estar disponible para el equipo

La colaboración entre el equipo de desarrollo y el Product Owner no solo es necesaria sino que es fundamental. Si el Product Owner es responsable de construir el Producto correcto, el equipo de desarrollo lo es de hacerlo correctamente. Esto requiere de una comunicación fluida y continua, no sólo en los distintos eventos de Scrum, sino también manteniendo Transparencia, Inspección y Adaptación, que son los pilares del empirismo, en el que está basado Scrum.

3. No gestionar presupuestos

Cómo parte de las responsabilidades del Product Owner, se incluyen todas las responsabilidades clásicas de negocio, y esto incluye gestionar los presupuestos. Es labor del Product Owner decidir si habrá un próximo sprint, que features serán incluidas en la próxima release, así como el esfuerzo económico destinado al desarrollo. Por ejemplo, si el equipo quiere incorporar a otro ingeniero, es responsabilidad del Product Owner decidir que porcentaje del presupuesto le asignará al mismo.

4. No conocer a los stakeholders

Muchos Product Owners no han visto a un cliente en toda su vida profesional. Se limitan a hacer lo que les dicen los jefes. Bien, si esto es así, entonces probablemente la compañía esté haciendo Scrum aficionado. El Product Owner es responsable de la comunicación con los Stakeholders, de entender cuales son sus necesidades, y de tomar decisiones en consecuencia.

5. Creer que es el jefe

Algunos Product Owners ven su responsabilidad sobre el producto como la vía para ser el jefe. Muchos incluso son jefes funcionales, siendo esto una malísima decisión. El Product Owner tiene completa responsabilidad y es dueño del producto. Punto. Tiene que saber encontrar puntos de colaboración con el Equipo de Desarrollo y el Scrum Master para conseguir hacer un producto excelente.

6. No reportar

Contrariamente a lo que la gente cree, en Scrum la labor de reportar no es del Scrum Master, ni del Equipo de Desarrollo. Es labor del Product Owner reportar adecuadamente a los Stakeholders, asegurarse de que estos tienen un conocimiento de lo que se está haciendo. Hay distintas maneras de hacerlo, y todas requerirán grandes dosis de liderazgo por su parte.

7. No acudir a los eventos de Scrum

Curiosamente, hay Product Owners que nunca van a un Sprint Review, o a una Retrospectiva. Piensan que eso es cosa del Equipo de Desarrollo y del Scrum Master. Nada más lejos de la realidad. El PO es el primer interesado en estar en los eventos para asegurarse de que el Producto que se está desarrollando lo hace conforme a lo que ellos esperan. No hacerlo así es irresponsable.

Creando espacios físicos de trabajo para equipos ágiles

A pesar de todo lo que escuchamos sobre agilidad y auto-organización de equipos de trabajo ágiles, estamos todavía muy lejos de construir entornos que realmente reflejen esa realidad. Scrum está basado en el empirismo: Transparencia, Inspección, Adaptación y vuelta a empezar. Incluso en grandes empresas que invierten en crear buenos espacios de trabajo, parece que la idea no ha calado lo suficiente. Hay que dar a los equipos la oportunidad de ser autónomos y tomar decisiones -a pesar de que haya voces que digan que la auto-organización es un mito- sobre como crear sus propios espacios de trabajo.

El secreto está en manejar restricciones, no en hacer planes

Muchas organizaciones, cuando se trata de remodelar espacios de trabajo, contratan a una empresa externa que les diga como hacerlos. Esta empresa elabora un plan y hace lo que cree que es mejor. En la mayoría de los casos, lo que es mejor es buscar lo que hacen las grandes del sector tecnológico y copiarlo sin el más mínimo atisbo de vergüenza.

Cuando los equipos empiezan a trabajar en los nuevos espacios, es cuando se descubre que hay pocas -o muchas- salas de reuniones. Que no hay espacios que permitan la comunicación abierta y el trabajo de 20 o 30 personas en un LiftingOff o que algún lumbreras pensó que lo mejor era optimizar el espacio y sentar a los distintos miembros de un equipo a 300 metros unos de otros.

Para realizar una reestructuración del espacio en organizaciones ágiles, se atiende a varias restricciones: Número de equipos (no de personas), Número de espacios de los que los equipos son dueños y número de espacios adicionales que necesitamos, prevención de riesgos, etc. En muchas ocasiones me encuentro con que la respuesta es: Es que así organizamos la empresa alrededor de la Informática. Bien, precisamente esa es la idea. Si tu empresa depende de la tecnología para funcionar, entonces asegúrate de que la tecnología está bien cuidada.

Los equipos son dueños de su espacio

Cuando se plantea una reorganización física, lo mejor es darles a los equipos un espacio y dejarles que ellos decidan como organizarlo, contando con el apoyo necesario. La primera imagen que puede venir a la cabeza es la de un equipo que decide poner sofás en lugar de mesas o llenarlo todo de neveras de Red Bull. Ahí va un secreto: Los equipos no están formados por retrasados mentales y, además de tener las mismas ideas sobre un espacio que tu tienes, conocen mucho mejor su trabajo para entender que: Puede que necesiten espacios para colocar radiadores de información adicionales, un espacio físico para trabajar con hardware o un espacio abierto para poder reunirse sin tener que depender de un planner en Outlook.

Los equipos son responsables de su espacio

La mejor manera de reorganizar espacios es dar la posibilidad de tener un set de elementos para poder utilizar: Mobiliario, Pizarras, Televisores, Suelo, Pintura, etc.. y que el equipo haga un trabajo de adaptación a sus necesidades. Porque DevOps no va a tener las mismas necesidades que tu producto A o tu producto B.

Ser responsable del espacio significa tener la oportunidad de readaptarlo cada vez que sea necesario, de nuevo, atendiendo a las restricciones, por ejemplo, de presupuesto. Un espacio organizado así puede responder a los pilares de Transparencia, Inspección y Adaptación mucho mejor que un equipo que cada vez que tiene que cambiar una silla, tiene que rellenar un formulario pidiéndolo a mantenimiento.

Los espacios sirven propósitos, no estética

Los escandinavos lo tienen claro. El diseño sirve un propósito, no a sí mismo. Los equipos de un cliente con el que trabajé en 2012 tenían a sus miembros distribuidos por toda la empresa con arreglo a áreas funcionales. No podían hacer los Daily Scrum en el mismo sitio todos los días, ni siquiera a la misma hora, porque había tal problema con las salas de reuniones que, en un momento dado, todo estaba reservado y había una especia de mercado “negro” interno para negociar con las horas de las mismas.

El resultado era un equipo que no podía hacer lo más básico de Scrum: Tener un Daily Scrum en el que todos los miembros pudieran inspeccionar y adaptar el Sprint Backlog. La solución fue trasladar el Daily a la cafetería más cercana, hasta que el manager funcional empezó a quejarse porque estaban mucho tiempo fuera. Cuando empecé a trabajar con este cliente, le pedí a dos Senior Managers que me acompañaran durante dos días a observar Daily Scrums. Fue un caos.

El Verano siguiente, esta multinacional reformó sus oficinas para crear espacios abiertos donde cada departamento tuviera al menos 5 o 6 espacios donde poder trabajar sin necesidad de pasar por el planning. Esto supuso una reducción de salas de reuniones y ocasionó quejas de los expertos en reunirse. Durante el proceso se descubrió que había una persona que reservaba distintas salas de reuniones a lo largo del día para trabajar en ellas. Se había creado una especia de despacho móvil. Lo había hecho porque sentado en su mesa, las interrupciones no dejaban de llegar.

Una pequeña conclusión

La reorganización de espacios refleja la cultura real de una empresa. Si ésta es impuesta, sin consultar y sin tener en cuenta las necesidades reales, no se puede esperar mucho de los productos que crean. En el anterior ejemplo, el cliente me contrató bajo la premisa de que “Scrum no funcionaba”. No hizo falta más de una semana para demostrar que el problema no era Scrum, sino que Scrum hacía visibles problemas que antes estaban enquistados. Y este es precisamente su poder.