Scrum master a tiempo completo: 42 Tareas

Uno de los artículos que más referencio en mi formación en Scrum (Qué es Agile) cuando hablo de las labores del Scrum Master es: 42-tasks-for-a-scrum-masters-job. Por alguna razón, todo el mundo parece entender que el Product Owner es un trabajo a tiempo completo, o ser miembro de un equipo también, pero que probablemente el rol del Scrum Master puede ser realizado a media jornada o incluso menos.
El scrum master también tiene mucho trabajo en equipos medianos o grandes, o nuevos. Muchos de liderazgo. Y es preferible que se centre en sus tares como scrum master, compartiendo su trabajo entre dos equipos por ejemplo, que trabajar también con la gorra compartida de miembro del equipo. ¿Por qué? Por que las labores que tenderá hacer son las de desarrollador antes que las de scrum master.

He querido traducir este artículo, para que quede en castellano, con permiso de Bernd Schiffer, para que quede constancia, y pueda referenciarlo en nuestro idioma :)

Artículo original: 42 Tasks for a Scrum Master’s Job

Update: ¡Cómo va a cambiar con la Inteligencia Artificial! Impact of AI in organizational design

Las siguientes preguntas aparecen a menudo cuando realizo formaciones o consultorías en Scrum:

¿Por qué los roles de Scrum Master y Project Manager deberían ser llevados por personas diferentes? (Quora)
¿Será el Scrum Master una ocupación al 100% o puede un programador ocuparse de ello si tiene mucha experiencia en planificación ágil? (Quora) 

Tras estas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Quien hace esas preguntas conjeturan con la posibilidad de ahorrar dinero juntando dos roles en una sola persona.

Las preguntas son realizadas por novatos como Scrum Masters, por product owners, por miembros del equipo, por managers, por stakeholders de cualquier tipo. De los tres roles en Scrum, todos parecen inferir inmediatamente que ser miembro del equipo es un trabajo a tiempo completo -por que desarrollan software el día completo - y que ser un product owner es también a tiempo completo - por que desarrolla el producto todo el día-, pero parece difícil de imaginar cual es el trabajo de un Scrum Master pueda ser y el por qué diablos sería un trabajo a tiempo completo, también.

¿Quizás esos que preguntan no sepan que es lo que un scrum master hace todo el día?

Aquí presento una lista de 42 cosas que diría que son parte del trabajo de un scrum master:

Reuniones

- Facilitar reuniones para el equipo. Esto incluye:

   - Preparar

   - Moderar

   - Postprocesar

 - Realizar retrospectivas, que son especiales, por consiguiente las cuento separádamente.

Dinámicas de equipo

 - Realizar coaching a los miembros del equipo (p. ej. coaching 1a1)

 - Mediar en los conflictos

 - Ayudar al equipo en la toma de decisiones

 - Fomentar la auto-organización del equipo

 - Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el product owner (más funcionalidad)

Aprendizaje

 - Continuar aprendiendo todo lo relativo a Agile (p. ej. visitar grupos de comunidades, atender a conferencias, leer libros, escribir blogs,…)

 - Asesorar a los miembros del equipo en todo lo relacionado con Agile.

 - Ayudar al equipo a crear radiadores de información.

 - Dar feedback al equipo.

 - Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme trabajo para invertir el tiempo de un Scrum Master, incluyendo por ejemplo, publicación/releases automáticas, entrega continua, TDD, y muchos más).

 - Desafiar al equipo con nuevas ideas sobre Agile Management (p. ej. FedEx -Days).

 - Colaborar constantemente con otros Scrum Master en la organización (p. ej. a través de la comunidad de práctica).

 - Bajar al Gemba.

Producto

 - Ayudar a escribir o dividir historias de usuario.

 - Ayudar a escribir o adaptar la visión del producto.

 - Ayudar a ordenar los elementos de la pila de producto.

 - Ayudar con la planificación del sprint.

 - Estar familiarizado con el trabajo del equipo (p. ej. el producto)

[Sobre producto hemos escrito Desarrollo de Producto y facilitación]

Visión general

 - Juntar a la gente que debería hablarse entre ellos.

 - Estar en contacto con los stakeholders regularmente.

 - Ayudar al equipo a informar a management.

 - Ayudar a fortalecer la comunidad ágil dentro de la organización

 - Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, stakeholders y el resto de la organización

 - Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas,…)

 - Ser la persona de contacto para todos en el equipo y los stakeholders en todo lo concerniente a Agile. 

 - Dar oportunidades de aprendizaje a la gente en la organización (p.ej. charlas o talleres) y permitirles aprender conceptos Agile importantes como p.ej. la deuda técnica.

Cambio

 - Ayudar al equipo a eliminar impedimentos.

 - Sugerir nuevas métricas para el equipo como catalizadores del cambio

Espejo

 - Reflejar los valores ágiles y de scrum al equipo.

 - Recordar al equipo sus acuerdos (p.ej. políticas)

 - Ayudar al equipo a mejorar constantemente sus procesos.

 - Reflejar los problemas al equipo a través de la observación desde fuera.

 - Hacer preguntas abiertas.

 - Comprobar los modelos que usa el equipo (p.ej. sprint backlogs, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.

Varios

 - Ayudar al equipo a mantener el foco (p.ej. actuando como un buffer entre las distracciones externas y el equipo)

 - Ayudar al equipo a mantener sus herramientas scrum (paneles, pilas de acciones, gráficas, backlogs,…)

 - Ayudar al equip y el product owner para encontrar los adecuados:

    - Definición de terminado (DoD).

    - Definición de preparado (DoR).

¿Has hecho o considerado todo lo mencionado anteriormente? Tomate un respiro, ¡debes estar agotado!

     Creemos que el scrum master es un rol a tiempo completo para una persona en un equipo Scrum. Scrum Master Manifesto.

¿Interesado en mentoring de Scrum Master? 
Contacta -TAYARI-

The "Groundhog day" retrospective

Some months ago I was feeling bored and tired of facilitating retrospectives. I have facilitated several hundreds of retrospectives, and sometimes you start again with a new team,  you repeat a lot of techniques and for sure continuously became a better facilitator (if deliberate practice, and feedback). Of course that every team is different, and the great part is the outcome, to feel their change. But at some point I was bored.

So now I tend to mix classical exercises with more tuned approaches to create new things for the teams. Please, give me your opinion about this: the groundhog day retrospective:

- First, you can do a classical check-in. For this first time I did Appreciation round, and review previous actions.

- Then, you draw a timeline for the past sprint. i asked the team to identify (with color codes) three things: 

 1) problems identified during the sprint

 2) improvements that they thought should have done

 3) Facts, things that happened, observations.

 When they finished the identification, I made the following statement: “Remember the film "Groundhog day"? So now, suppose we come back next day for the sprint planning, and suddenly, we discover we are in the same sprint. People live in the same day of the previous planning. We remember everything, but nothing is done. And the same thing will happen again. We have the same stories in the top of the backlog, and we are back in the same sprint planning than two weeks (length of the sprint) before. Look the sprint again, with new eyes, but with the same work to do”

 And now you ask three questions, and after each you repeat the statement.

 1) Individually, write ONE postit looking at the problems on the timeline. If you could solve one of these problems, now that you know it´s going to happen, what would you have done to solve it during the sprint?

 (let them work and put the ideas on the wall, and repeat the statement again, adding that the same sprint is back again! :)

 2) Individually, write ONE postit looking at the improvements on the timeline. If you could do one action to improve the sprint, what would you have done to improve the sprint?

 (let them work and put the ideas on the wall, and repeat the statement again, adding that the same sprint is back again! :)

 3) Individually, write ONE posit looking at the observations, evaluating their impact, What would you change on the team behaviour, on the team reactions to those things to perform better during the sprint?

 (great! finally we achieved an incredible sprint, we can move to the next one!)

 Take a look at the wall, let them search for patterns and groups. What´s there?

 Decide actions, observe if there is need for dot voting to prioritise, or some informal agreement emerge.

 And close the retrospective, get some feedback, and make sure that every action has a responsible.

Notes: (I only have used this retro once)

- I found that those questions and the power to change the past generated a good analysis and powerful debates.

- If the team is young, you probably have to explain the film first. Seriously. :D

- I think that if you use it for releases, longer times than iterations, probably the divergence will be too high. But, tell me if you try it, please!

Comments are welcome! 

Retrospectiva - Comunicación no Violenta (CNV)

Una de las herramientas que más he utilizado estos dos últimos años ha sido la Comunicación No Violenta (CNV). De hecho, lo tengo como algo más que una herramienta, es una manera de relacionarte con el mundo.
Principalmente lo he usado como técnica de coaching y resolución de conflictos, pero sobre todo, como herramienta de auto-análisis y comprensión de mis interacciones con otras personas.

Así que me propuse utilizarlo para facilitar una retrospectiva, y encontré este artículo. Basándome en él, realicé la siguiente retrospectiva:

1. Check-in: Revisión de acciones anteriores. Y en este equipo: revisión del calendario Niko-Niko del equipo, y de la felicidad del mismo (mediante autopuntuación individual). 
2. Introducción a CNV: Explicación del fundamento de la comunicación no violenta, y explicación de las tarjetas que iban a tener que crear basado en el típico esquema de NVC: Observación - Sentimiento - Necesidad - Petición. Obviamente tanto para necesidades satisfechas como insatisfechas :)

3. Tarjetas: Individualmente, reflexión durante 15 minutos y escritura de las tarjetas, con una sentencia por tarjeta. Les pido que se enfoquen en las observaciones y sensaciones del último sprint. También les pido que escriban aquello que incluso no se atreverán a compartir después. Que lo escriban para su propia reflexión, y que se lo guarden para ellos mismos.
4. Trabajo en parejas:  Se trabaja en parejas, cada tarjeta de la siguiente manera: El autor la lee, y su compañero ESCUCHA, y pregunta con CURIOSIDAD para obtener más información sobre el contenido. Sugiero evitar consejos, juicios,... solo dejarse guiar por la curiosidad.
5. Compartir en equipo: Invito a cualquiera a compartir para todo el equipo sus reflexiones, si les apetece y se sienten cómodos. No feedback del resto, solo escucha de nuevo.
6. Revisión de peticiones, generación de acciones: Se vuelve a trabajar en parejas, y esta vez se analizan las peticiones finales de cada tarjeta. Se generan acciones en post-its para el equipo en base a esas peticiones personales. ¿cómo puede el equipo ayudar a satisfacer esas necesidades personas?
7. Agrupación y priorización: Compartimos las acciones en la pizarra, las agrupamos y las priorizamos. Asignamos responsables y las hacemos lo más concretas posibles. 
8. Check-out: Feedback sobre el ejercicio. Gracias al equipo.

Mis sensaciones como facilitador:

 - He realizado esta retrospectiva en hora y media. Creo que para un equipo de 10 personas es poco tiempo, hubiese necesitado más tiempo para la explicación inicial, e insistir con ejemplos de confusión de necesidades o "malas" observaciones. Si no conocen CNV, es realmente clave.

 - He observado útil repartir un pequeño inventario de necesidades y sentimientos.

 - Siempre he hecho invitaciones: a compartir, a expresarse, a contar sus sentimientos,..., dejando muy claro que cualquier persona era libre de pasar. No era un ejercicio obligatorio (obviamente, ¡como ninguna retro!).

 - Considero clave también el ofrecimiento a escribir, pero no compartir. Da la oportunidad de reflexión individual, incluso sin participación activa en la retro.

 - El feedback ha sido positivo. Las acciones que han salido, poderosas. Y sin embargo, mi sensación como facilitador ha sido que tenía perdido al grupo. Tengo que analizar más esto :)

Marco Scrum

Marco de Scrum

Curso de Scrum: Contactanos si estás interesado.

¡Aquí puedes ver el último video sobre Scrum en 9 minutos que hemos publicado!

CAS2013: Scrum y management, ni cerdos ni gallinas.

Scrum y management: ni cerdos ni gallinas. from Jose Ramón Díaz

Puedes ver el video: Joserra Díaz, scrum y management.

La metáfora de los cerdos y las gallinas es un drama. Y afortunádamente se dejó de usar en la guía de Scrum. Como chiste pase, pero diferenciar entre comprometida e involucrada en un proyecto, diferenciando su grado de compromiso es un poco anti-colaboración. Y con esos nombres... ¿algún cerdo en la sala? :\

Una de las gallinas es la capa de management, así que se supondría que no están comprometidas (sic) con los resultados de los proyectos (¿suena absurdo verdad?). 

• Henry Fayol – “Gestionar (management) es prever y planificar, organizar, mandar, coordinar y controlar”
• Control y gestión de los recursos de una organización para producir valor a los clientes
• Managers are the people who interrupt the ones working. Jason Fried (37 signals)
• Hay opiniones para todo, en general, Management es lo que hacen los managers. Así es más sencillo. Cada organización es un mundo

Ahora llegamos con una herramienta: Scrum. Que es el gran descubrimiento para el management. Lo dice Forbes nada menos, hace ya casi 3 años. ¡Ya les costó darse cuenta! ;) PERO, pero, hay algo que a veces no encaja… ¿qué tiene Scrum que no es una herramienta tan sencilla de utilizar en las organizaciones actuales?

Por alguna extraña razón la metáfora es entendida de otra manera. Y ni unos ni otros están del todo contentos con la nueva situación. El cambio de una mentalidad "command&control" a una verdadera autoorganización no es fácil, y no sabemos cómo usar esta nueva herramienta.

En general:

 - Mira la película completa, no microgestiones el equipo, sin tener en cuenta las influencias externas. El impacto en la organización completa.

 - Sal del edifico. Baja y comprueba in situ qué sucede, a la gente usando Scrum, a los equipos, a los usuarios, a los clientes,… ¡pasea por el gemba!

 - Cambia el foco: la gente sabe cómo definir procesos, planes y todo eso… eso es fácil. Cambia tu foco a las personas, mira si hay colaboración, comunicación, entendimiento,…

Así que si como manager quieres usar Scrum, ¿dónde te colocas?

- Si pasas a set product owner… o mejor no. NO lo hagas. Parece el camino más natural, pues controlas releases, planificaciones, hablas más con los usuarios, stakeholders, etc. Pero ser jefe de equipo, y product owner desequilibra la balanza PO <-> SM. Totalmente. Si no tienes tiempo para algo, será el equipo el que lo sufra. 

- Si eres un manager externo al equipo, y este cuenta con su PO y su SM, puedes tener la sensación de "y ahora, ¿qué hago?" Pero si la organización está arrancando con Scrum es fundamental su protección y ayuda al scrum master a que no se de cabezazos con el resto de la organización. Que el equipo no pierda de vista el propósito de lo que está haciendo. Ayúdales en eso.

- Si eres un manager de varios niveles superiores, pasea por el gemba, baja a ver qué sucede, atento a lo que suceda en los equipos scrum, las personas alrededor de los equipos en otras áreas de la organización, identifica a tu equipo de trabajo y trabajad para mejorar el sistema, y apoyar aquello bueno que emerja.

 - Si eres jefe de equipo, el paso lógico es ser scrum master. Recuerda, equipo = producto. Trabaja en el equipo. Cambia de chip, prueba la autoorganización, ayúdales… y dales espacio.

 En definitiva, una  organización que empieza a hacer Scrum requerirá que el management se centre en las personas y el sistema completo, y no luche contra la organización si no que colabore, haga amigos, y la transforme.

* Nota, hablo de Scrum como una herramientas… y en realidad NO lo es. Es mucho más, incluye valores, principios, cambio de mentalidad… ¡¡por eso es difícil!!

Estimación ágil de proyectos (y 2): Equipo multiproyecto.

Hablábamos el "otro día" sobre la planificación ágil, y explicábamos el proceso para estimar un proyecto, y ver su evolución. Trabajábamos con la hipótesis de que era un proyecto para un equipo, un entorno que no siempre se da en las empresas.
El mecanismo que aplicamos en un entorno multiproyecto es básicamente el mismo, pero contamos con una nueva incógnita: la dedicación del equipo a cada proyecto.

Sabemos lo perjudicial que es para nuestra cabeza la multitarea, lo negativo que es para un equipo el multiproyecto y lo fatal para una organización la pérdida de foco y capacidad de ejecución. Sin embargo, en muchos entornos, se sigue empezando cualquier proyecto que se nos pase por la cabeza, antes que priorizarlos claramente y dedicar energías a aquello que nos aporta más valor. Este es un tema muy importante, y que influye poderosamente en la capacidad de trabajo de una organización.

Así que, si trabajas en un equipo multiproyecto, las posibilidades de tener un buen lío son abundantes. Y la estimación va a depender tanto o más de gerencia como del equipo. ¿por qué? Simplemente por que si la dedicación no es conocida, o no es sostenida, no puedes estimar. Así que añadimos una nueva hipótesis a la hora de dar fechas. Y es arriesgada, probablemente no cae en la responsabilidad del equipo.

Si decides trabajar en multiproyecto (recuerda, es una decisión, quizás no es tuya, pero es de alguien) a la hora de estimar, deberás asignar un porcentaje de dedicación a cada proyecto. Si tienes datos históricos de porcentajes de puntos historia por proyecto, te podrán ayudar a trabajar con una hipótesis lo más cercana a la realidad posible.

Próximos talleres en Pamplona: Lean/kanban y Retrospectivas

ACTUALIZACIÓN FEB. 2013: Cursos de Lean/Kanban en San Sebastian y Madrid.

En Noviembre hemos organizado junto con CEIN dos diferentes talleres, de una mañana de duración, sobre temáticas ágiles.

Taller Lean/Kanban
El primer taller se realizará el 9 de Noviembre, sobre Kanban. Veremos cuales son los conceptos que podemos aplicar de esta metodología de manera práctica. Hablaremos sobre los principios ágiles y Lean, realizaremos una simulación, dibujaremos nuestro panel kanban... todo en 6 intensas horas de aprendizaje y experiencia.
Puedes encontrar más información e inscripciones en la web de CEIN.

Taller de retrospectivas eficientes
El segundo taller es el día 28 de Noviembre y girará alrededor de las retrospectivas y la mejora continua de los equipos. Veremos técnicas y tácticas para esta reunión tan importante en los equipos ágiles. Se tratará de aprender nuevas maneras de realizar retros, mejorar la efectividad de las mismas, y comprender la importancia de generar aprendizaje de manera constante en los equipos.
Puedes encontrar más información e inscripciones en la web de CEIN.

Formaciones y eventos en Abril: AON y CSM en Donosti

Este abril se promete intenso, y estamos organizando un curso de certificación en Scrum Master nada menos que con Xavier Quesada, en San Sebastian. Colaboro con él en la organización e intentaré aportar al curso con mi experiencia. Queda muy poquito tiempo, pues es el 26 y 27 de Abril, así que reserva pronto tu plaza. Oportunidades así tenemos pocas por estos lares.

En este curso aprenderás:

- Los principios y valores fundamentales del pensamiento Lean y del Agilismo que hacen que Scrum funcione.

- Como arrancar un proyecto Scrum, desde la visión hasta la pila de producto (Product Backlog).

- Los roles y responsabilidades en Scrum y como mapearlos a los existentes en tu organización.

- Las reuniones y ceremonias en Scrum, y como facilitarlas existosamente.

- Estimación y Planificación Ágil: como planear y monitorear el avance de un proyecto Scrum.

- Visual Management (gestión visual): como crear equipos autogestionados y generar confianza y transparencia.

- Prácticas técnicas: Que necesitás saber sobre cómo desarrollar software en forma ágil, y porqué es importante.

- Temas avanzados: como escalar Scrum, como hacer Scrum distribuído y offshore, como hacer Scrum con múltiples proyectos y equipos, como combinar Scrum con otras metodologías.

- Mas allá del CSM: como seguir creciendo profesionalmente luego de este curso

El curso prevee un espacio abierto para tratar situaciones de la vida real traídas por los participantes.

Certificación

Luego de terminar el curso exitosamente y de completar exitosamente el examen online, los participantes reciben la certificación oficial "Certified ScrumMaster" de la Scrum Alliance, más un año de membresía paga. 

Además, el 21 de Abril tenemos con la majísima gente de CEIN ;) un eventazo, repetimos el fantástico lugar del AOS2011 (Pamplona) para hacer otro Open Space, esta vez monotemático: 

OpenSpace, "Negocio y Clientes (Llevando Agile fuera de la empresa)"

Numerosas empresas se están moviendo hacia metodologías ágiles de manera interna, como mejora de sus procesos y potenciación del valor de sus personas. Sin embargo, nos falta una "x" en la ecuación, y son la parte contratante: los clientes.

Queremos que el Open Space sea un lugar donde la gente se encuentre. Un espacio de colaboración donde podamos compartir problemáticas y posibles soluciones. Un punto de encuentro en el que busquemos argumentos para poder entendernos.

Por tanto, si te apetece hablar de:

• Gestionar de manera ágil los proyectos con proveedores
• Vender "agilismo" a mis clientes
• Gestionar portfolios de proyectos
• Crear espacios de colaboración con mis clientes/proveedores
• Gestionar alcances de proyectos
• Contratos ágiles
• El Retorno de la Inversión en metodologías ágiles
• ...

Así que apúntate también, que quedan pocas plazas, en https://agilespain.stagehq.com/events/1348/

Nos vemos en abril!!

Metodologías Agiles y coaching

Este post tiene como raíz las conversaciones con Visi Serrano, otra emprendedora como profesional independiente, psicologa y facilitadora de procesos participativos, colaborativos y autogestionados y muchas cosas más que me sorprenden desde mi visión de ingeniero.

En las metodologías ágiles se habla mucho de la figura del Agile Coach, casi como el nirvana de la figura de un Scrum Master. El coaching aporta un valor inmenso a los que los que ayudamos en la implantación de metodologías ágiles, por su caracter enfoque de conseguir metas o habilidades personales.
En las metodologías ágiles, no es suficiente con hablar de procesos a seguir. Hay que hablar de principios y valores. Y es ahí donde el coaching más nos ayuda.
De todas maneras, siempre que me preguntan por al Agile Coaching, suelo indicar que no es realmente coaching. No el coaching que la mayor parte de las personas piensan cuando oyen esa palabra. El otro día, Tobias Mayer comentaba en Twitter:

for those who asked, Agile Mentor, Agile Guide or even Agile Sherpa are more accurate descriptors than Agile Coach, in almost all cases. https://twitter.com/#!/tobiasmayer/status/173280854108409856

   Y en general estoy de acuerdo con él. Lo que muchas veces llamamos coaching en el mundo de las metodologías ágiles, es realmente un mentoring, una guía, o simplemente una formación. Las diferencias fundamentales, 

• que el coaching trabaja con que la solución sale del coachee. Como Agile Coaches, muchas veces debemos forzar las soluciones, enseñar un camino claro.
• que el coaching no dirige, va donde el cliente quiere. Sin embargo, en el caso de un agile coach, obviamente, no se puede ir donde quieras. Si te dicen que quieren hacer waterfall, ¿les dejas? :D ¡No! 

   Y aún así, me he ido a recibir formación en coaching -un curso sobre coaching co-activo, por cierto, muy interesante. Me parece una de las herramientas más potentes para provocar el cambio en las personas. El conocimiento y las técnicas que aporta me resultan útiles para entender a los clientes, para entender a los equipos y para entender a las personas (no quiero decir que los clientes no sean personas! ;) ). El cambio cultural para una implantación de metodologías ágiles es un cambio imprescindible, y desde la perspectiva que nos proporciona el coaching, más facil de atacar y conseguir.
   A raíz de unos mensajes cruzados en Twitter, por intereses comunes -si no recuerdo mal fueron a partir de charlar sobre "Open Space Technology"- Visi Serrano y yo llevamos unas semanas preparando unos temas, donde podremos aunar la experiencia en metodologías ágiles de uno, y la experiencia en coaching y cambio organizacional de otra. Hemos visto claro que los dos campos son muy complementarios. Así que para centrarnos en la primera linea del manifiesto, una de las primeras cuestiones que deberíamos entender es como trabajar con personas, y eso es precisamente donde observo que el coaching más nos ayuda. Nos ayuda a ver las cosas desde la perspectiva de otras personas, a entenderlas y escucharlas. La creación de equipos auto-organizados siempre ha sido una especie de mito, y no es nada fácil de conseguir. El trabajo con un coach especialista en estas tareas, puede facilitar la labor de manera importante.
   Como autodenominados Agile Coach, sabemos hacia donde debemos dirigir a las personas y los equipos. Sabemos qué valores creemos, y debemos transmitirlos. Sabemos el por qué de estas metodologías y debemos cambiar nuestra parcelita del mundo. El coaching nos ayuda a que otras personas descubran y transiten ese camino más fácilmente, y nos da mejores herramientas para acompañarles.

   A raíz de las conversaciones con Visi, he visto que el coaching ontológico, y con su experiencia en trabajo de cambio en organizaciones,  podemos ofrecer las dos caras de la moneda que se complementan perfectamente. Pronto, más en sus pantallas y sus organizaciones ;)


PD: Este es el post cruzado de Visi: Psicología y Scrum: desarrollo ágil de equipos.

   

Visión del desarrollo ágil de software

Me liaron para dar una charla en The Mêlée (yo encantado, claro), y me propusieron hablar desde mi experiencia con metodologías ágiles. Así que lo que intenté finalmente es exponer mis razones para considerar las metodologías ágiles, y cuales son las partes que más valoro actualmente.
Os escribo un pequeño resumen, y podeis encontrar alguna explicación más en la documentación adjunta en slideshare (desarrollo ágil de software). Mis tres razones básicas por las que he llegado al convencimiento de que las metodologías ágiles son las más adecuadas para desarrollar software son las siguientes:

1. El axioma Equipo = Producto
2. El software es un juego coaborativo, de comunicación y finito
3. El desarrollo de software se realiza sobre un sistema complejo

El primer punto fue el que empezó realmente a hacerme plantearme mi manera de pensar en este mundo del software. Yo debía hacer equipos capaces y sobresalientes, más que proyectos y productos. Ese cambio de responsabilidad, me implicaba centrarme más en las personas con las que trabajaba.

En ese momento, el manifiesto ágil encajó perfectamente en mi cabeza. Mi conclusión es que el objetivo principal es entregar valor al cliente, obviamente bajo la perspectiva de paso sostenible. Y los valores que he ido adquiriendo son:

• Colaboración: búsqueda de la visión compartida
• Mejora continua, sin descanso, y adaptándonos al cambio.
• Autoorganización de los equipos, obtener lo mejor cada persona.
• La Calidad es incuestionable.
• Las buenas prácticas son indispensables, pero cuidado que a veces nos hacen perder el objetivo.
• El camino de la mejora de gestión y técnico deben ir unidos.

Desarrollo ágil de software

View more documents from Jose Ramón Díaz

Retrospectivas: Busca necesidades y no problemas

Cuando planteamos problemas en una retrospectiva, generalmente tenemos una idea ya prefijada de las causas que los pueden estar produciendo. Esto nos lleva a plantear muchas veces la lo que creemos que es la solución como el propio problema o impedimento a solucionar que tenemos.

Sin embargo, creo que hay que llevar a las retrospectivas la verdadera necesidad que tenemos, aquello que si lo conseguimos, podremos hacer mejor nuestro trabajo. Esa necesidad es la que debe ser compartida con el equipo, para entre todos, buscar sus causas posibles de que no suceda.

En un sistema complejo como un desarrollo de software (Management 3.0), la causa-efecto no es linear. Las cosas que suceden pueden tener más de una causa, y por tanto no siempre las mismas causas desencadenan los mismos efectos. Esta complejidad añade más valor a analizar los problemas por el equipo, con más visión que sólo la de una persona. Si planteas tu necesidad al equipo que no puedes conseguir, es más facil averiguar las causas de manera colaborativa.

En resumen, podrías plantear situaciones ideales en vez de problemas. Y averiguar cómo llegar a esa situación, eliminando las causas que te lo impiden. ¿no favorecería esto el aprendizaje y la visión compartida, al establecer la meta antes que el camino?

Me gustaría compartir además algunas ideas que he ido obteniendo a lo largo de unas cuantas retrospectivas (algo más de dos años, al menos una cada 15 días,...):

• Piensa siempre lo primero que el problema es sistémico, no de las personas. Soluciona primero el sistema, generalmente éste limita a las personas.
• No evites los conflictos, genera un ambiente donde sea sano que florezcan.
• Plantea las necesidades a resolver, no lo que pensamos que son las causas. Esto también ayuda a la eliminación de la figura del "culpable"
• Aprende técnicas de retrospectivas y conoce cuando se debe aplicar cada una. Ayudan, y mucho.
• El brainstorming es la técnica más conocida y peor implementada. Pon reglas claras desde el principio para hacerlo bien: elimina las críticas que impiden una verdadera libertad de ideas.
• Siempre obtén acciones de las retrospectivas, o no serán retrospectivas, solo "reunión de desahogo". Que no vienen mal de vez en cuando, pero esas, con una cerveza en la mano mucho mejor.

Scrum vs. Kanban: Más libros en castellano

Vuelvo a hablar de libros, esta vez para presentar la traducción de un libro Henrik Kniberg y Mattias Skarin al castellano. Se trata del libro Kanban vs. Scrum publicado inicialmente a través de InfoQ. Ahora, gracias a Agile-Spain podemos disponer de este pequeño gran libro en castellano.

Ha sido un trabajo colaborativo, coordinado por Ángel Medinilla, donde han participado personas del grupo de Agile-Spain, que con ganas de contribuir a la comunidad hispano-parlante han realizado un gran trabajo. Desde aquí gracias a Angel, Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano
Ángel os dará más detalles del libro en su blog, y podeis descargarlo desde este enlace.

Charla sobre desarrollo de software ágil (2)

Aquí os dejo la charla que di el otro día en la Navarparty, junto con una breve descripción de lo que conté, sin entrar en detalles. Teneis el video disponible en la web de la Navarparty.

Desarrollo Agil

View more presentations from jrramon.

[2] Generalmente se presentan los típicos problemas en el desarrollo de software, en los que caemos una y otra vez, como razones para cambiar a lo ágil: clientes insatisfechos, equipos quemados, calidad insuficiente, fechas nunca alcanzadas,...
[3] pero aquí prefiero dar dos razones por las que creo que las metodologías ágiles se adaptan mejor.
[4] Por que creo que primero, el producto es equivalente al equipo que lo ha creado, y que el producto de un gestor de proyectos es crear un equipo, y que
[5] el software es un juego colaborativo. [6] Estos dos libros inciden en estas ideas.
[7] Así que ahora debemos elegir el nuevo camino, tomar la pastilla azul que ofrecieron a Neo (jope, ¿o era la roja?).
[8] Las metodologías ágiles más comunes fueron creadas en los 90,
[9] pero el manifiesto ágil les dio el espaldarazo definitivo.
[10-15] El manifiesto ágil condensan en cuatro frases los conocimientos y experiencias en gestión de proyectos de software de algunos de los mayores expertos en este mundo.
[16-22] Y los principios que se desprenden de ellos son las bases de estas metodologías.
[23] ¿cómo podemos llevar al terreno práctico estas ideas?
[24] Aplicando por ejemplo este esquema metodológico (como ejemplo, no olvidemos que hay muchas metodologías ágiles), que actua a nivel técnico, sobre el ecosistema software (prácticas de XP) , a nivel de gestión de proyecto (Scrum), y a nivel organizativo (aplicando los principios de Lean).
[25-35] XP nos da herramientas para garantizar una buena calidad e integridad de los desarrollos (TDD, Integración continua, Pair programming) , pero no debemos olvidar que puede ser tomada como una metodología de gestión completa. Lean nos da unos principios que buscan mejorar la organización en todos sus niveles. Y Scrum, la metodología "de moda", nos da el framework para gestionar los proyectos centrándonos en la entrega de valor al cliente y la mejora continua.
[37] Dos palabras básicas para ser ágiles: confianza y colaboración.
[38] ¡No olvides visitar agile-spain!

http://najaraba.blogspot.com/2008/02/el-producto-es-el-equipo.html
http://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566
http://alistair.cockburn.us/Software+development+as+a+cooperative+game
http://agilemanifesto.org/
http://www.extremeprogramming.org/
http://www.proyectosagiles.org/que-es-scrum
http://poppendieck.com/
http://www.agile-spain.com

Equipos vs. personas

Si algo me gusta de Scrum como metodología ágil es que intenta sacar el máximo potencial a los equipos. Entendiendo equipo no como un grupo de personas que trabajan juntas, si no como un grupo de personas que comparten una visión y una motivación que les une con lazos especiales.
La medición de métricas en Scrum está muy orientada al equipo: La velocidad y el burn-down son elementos a nivel de esta agrupación. Las personas son controladas por el mismo equipo de manera secundaria. Si en cada daily-scrum, se ve una persona que no avanza, hay motivos y datos para que el resto de personas le ayuden o le den un toque, pero el foco está puesto en el equipo.
Ya decía Alistair Cockburn que construir software es un juego cooperativo, que sin equipo no hay juego, o al menos no hay juego satisfactorio. Lean nos habla de la calidad en integridad conceptual, que se note que la calidad del producto por que aflora la integridad del equipo que lo realiza.
Ahora me pregunto yo cómo realizar métricas para evaluar el desempeño de las personas... por qué, ¿es necesario en un ambiente ágil? Las personas que no "funcionen" serán rápidamente detectadas por los equipos y no las querrán con ellos. ¿hay mejor métrica que esa?
Si las métricas personales dependen de las estimaciones, ratios de cumplimiento de sus tareas,... ¿es posible formar así un equipo con una motivación común? ¿no lo estaremos tensando demasiado? Supongo que debe haber un equilibrio, pero yo desde luego pondría má peso en el equipo. Nadie construye software solo.
En fin, más preguntas para Agile-Spain ;)

Desarrollo software Lean

Uno de los temas en los que estoy más interesado ultimamente en este mundo del desarrollo de software es el "Lean Development". Es un conceto que surgio de la adaptación del modelo de Toyota de fabricación al software. Orginariamente parece que fueron "los Poppendieck" los inventores del término, en un par de libros que no te puedes perder:

• Implementing Lean Software Development: From Concept to Cash.
  
• Lean Software Development: An Agile Toolkit. Este lo tengo hace unos meses y me parece muy bueno. Enfoques diferentes para problemas tradicionales.

Lo importante de Lean, es que se basa en unos principios, adaptados del TPS. Y esto es una de las claves para su futuro éxito, que no son herramientas, no son pasos a dar o procesos a seguir. Son principios cuyo valor reside en su aplicabilidad independientemente del "estado del arte" en el que te encuentres. Las medidas las decides tú, los cambios guiados por principios son efectivos si los principios son adecuados. Así que llegamos a la cuestión, ¿son los principios Lean acertados para lograr un mejor desarrollo de software? (Ahí es nada, definimos mejor como de mejor calidad, mejor satisfacción del cliente, mejor ganancias para el proveedor,... mejor lo que quieras!)
¿Cuales son estos principios? (el orden no importa)

• Eliminar la basura
  
• Crear conocimiento
• Construir calidad inherente en el producto
• Retrasar el compromiso
• Entregar rápidamente
• Respetar a las personas
• Mejorar el sistema global

Iremos viendo cada uno, intentando adivinar si son beneficiosos para el desarrollo de software. (!me acabo de obligar a escribir al menos 7 posts!).
Otra pregunta que te sueles hacer cuando empiezas a conocer Lean es su relación con las metodologías ágiles. Básicamente creo que hablan de lo mismo, pero Lean está un paso por encima a nivel organizativo. Las metodologías ágiles (XP y Scrum al menos, que son las que más conozco, no olvidemos que existen otras) se focalizan en el equipo que desarrolla un proyecto. Lean complemente esa visión con principios aplicables a la organización que soporta los equipos, y que debe gestionar un portfolio de proyectos y equipos. Hay cuatro cuestiones que se deben lograr:

• Seleccionar las cosas adecuadas en las que currar (Lean Management). ¿te interesan todos los proyectos?
  
• Ajustar la carga de trabajo a la capacidad. Muchas veces ni siquiera conoces tu capacidad.
  
• Mejorar la productividad de la "tubería-desarrollo" (Lean-Scrum). Aumentar la capacidad del sistema.
  
• Mejorar las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en mejorar el sistema global.
  

Recapitularemos tras ver los principios, y volveremos sobre estas cuatro cuestiones. Si quieres ir adelantando las ideas, aquí tienes una pequeña recapitulación de los principios.

P.1 Eliminación de la basura.
P.2 Creando conocimiento
P.3 Construir con Calidad

El declive y caida de lo ágil

Un reflexión de tic-tac (sobre una frase: "El hombre que actúa con métodos, ignorando los principios, es seguro que tendrá problemas.") me hace pensar en la carga de profundidad que tiene este otro artículo de James Shore: The Decline and Fall of Agile.
Habla sobre los problemas que está dando la proliferación de implantaciones que se están haciendo del método Scrum, pero haciendolo sin preocuparse de los principios que lo sustentan.

"These teams say they're Agile, but they're just planning (and replanning) frequently.. ""Agile is hard, and you can't master it by sitting through a two-day course."

Ciertamente hay una serie de cuestiones que escapan al "método Scrum", que deben ser parte fundamental de una metodología ágil. En el mismo artículo comenta algunas:

• shared workspaces: La comunicación en espacios compartidos fluye mejor, es más fácil compartir una visión y el trabajo.
  

• high-bandwidth communication: El equipo debe mantener en todo momento un canal de comunicación de alta capacidad. No hay excusas para guardarse información, no preguntar, o no compartir.

• on-site customers: Es muy importante la disponbilidad del cliente cuando sabemos que los requerimientos van a evolucionar, y el equipo necesita aclaraciones en cualquier momento.

• work in cross-functional teams: Los equipos multidisciplinares deben estar intrgrados en la solución del proyecto, deben ser un equipo al completo, no una serie de grupos de personas que resuelven cada uno su papel. Así se pierde enseguida la visión compartida.

• let alone deliver releasable software: El avance de los proyectos se mide por producto terminado.

• use good engineering practices: El concepto de deuda técnica aclara muy bien este punto. Si te hipotecas tecnicamente, el futuro del software no será sostenible.
  

Pero, ¿realmente son necesarias todas estas prácticas anteriores para ser ágil? Pues... ¡quizás no! Hay que conocer los principios, y aplicarlos para cada problema, que necesita una respuesta adaptada. En un comentario del grupo de Yahoo de lean-agile-scrum, la genial Mary Poppendieck lo dice en una respuesta muy interesante:

It sounds to me like you are taking the Scrum recipe much too seriously. If you want to be successful, you have to spend some time thinking creatively about what will work in your world. Lifting recipes from others and expecting them to work in your environment doesn't have a good track record of success.

Creo que por aquí estamos bastante lejos de pensar en el declive de Scrum, cuando no me parece que esté demasiado implantado por estas tierras. Pero si podemos llegar a la lección antes de qué nos peguemos con los problemas, eso que habremos ganado.