¿Cómo se ve la comunidad de Madriagil a sí misma?

¿Por qué venimos a los eventos de Madriagil?

 

Esta foto es el resultado de un ejercicio que hicimos buscando el por qué venimos a los eventos y por qué creemos que vienen los demás. Fue en el  Madriagil: Inicio de temporada + Dojo de CNV, celebrado el pasado 8 de octubre de 2015,

Al final sacamos esta Lista ordenada de razones por las que asistimos a los eventos de Madriagil:

1. Compartir
2. Formación gratis
3. Experiencias
4. Ver a la gente
5. Aprender
6. El tema es importante para asistir
7. Vivir mejor (aprender a)
8. Uniqueness (Ocasiones únicas, como visitas de algún miembro de otra comunidad)
9. Energía (recargar)
10. La idea feliz
11. Incluir a más gente
12. Persona (Ponente) conocida
13. Promocionar mi curso

 

¿Qué te parece? ¿La compartes?

Mi opinión

En mi opinión esta lista es bastante genérica y no refleja ni la conversación que tuvimos allí, ni la sensación que tengo de la actividad que tiene Madriagil como tal.
Lo primero no creo que cumplamos las condiciones para definirnos como Comunidad. Quizás tenemos intereses y valores comunes, pero nos falta algo más importante como la identidad o el sentido de pertenencia.

Y a continuación en modo lista los problemas que veo:

• No creo que seamos un grupo equilibrado.
• Muy pocos son los que proponen temas para hacer las reuniones.
• La acogida de cada charla y la atención que genera es muy irregular, dependiendo en gran medida de cada una de las razones expuestas más arriba.
• La asistencia final respecto a la confirmación suele ser del 50-60%.
• El nivel de los asistentes es irregular, puede haber gente con mucha experiencia y con poca.

Analizando un poco más un par de temas…

Cómo se convocan las reuniones.

Las últimas convocatorias han sido siempre fruto de una iniciativa individual. Aunque es genial, que la primera noticia de un evento llegue por un correo de la plataforma meetup,  nos resta identidad.

La asistencia es del 50-60%

JMBeas señaló el año pasado de la falta de compromiso de las personas que no iban a los eventos de meetup tras confirmar asistencia. Se habló bastante sobre el tema e incluso como respuesta, Bonilla le dedicó la Bonilista de esa semana: «Una silla vacía».
Creo que el fondo de la cuestión, es que el compromiso con el evento hay que construirlo, y es el resultado de construir una comunidad, con una identidad, formada por un conjunto de personas que se conocen. Si no tenemos esa comunidad, no nos extrañe que el nivel de compromiso de un «Me apunto» en una página de un Meetup sea bajo.

El nivel de los asistentes.

Obviamente no vamos a hacer una comunidad exclusiva para novatos o para expertos. Tiene que haber de todo. Lo que creo que está pasando es que no lo estamos gestionando adecuadamente. Uno de los signos más obvios es que de las personas que yo considero ‘experimentadas’ de la comunidad es MUY raro que coincidan más de dos en un mismo evento.
¿Por qué no vienen? Para mi está claro. La ratio beneficio/esfuerzo resultado de asistir a estas reuniones en muchas ocasiones no está clara y en otras muchas es inferior a uno. Ni siquiera sirve como networking, pues la falta de relación personal entre las personas que van últimamente no dan ni para una caña después del evento.

Y sorprendentemente…

el número de personas que asisten por primera vez a un evento de Madriagil es muy alto en cada ocasión. A ojo quizás sea del 20-25%. ¿Qué hacemos con estas personas? ¿Les damos una calurosa bienvenida a la comunidad? #nope

 

¿Qué podemos hacer?

Algunas ideas

Convocatorias

Sería bueno realizar un par de mejoras a esta manera de reunirnos. Primero fijar una frecuencia para hacer las reuniones y segundo mandar un correo a la lista previo, buscando una pequeña tormenta de ideas. Igual que hace MadridGUG.

Nivel de los asistentes

Crear eventos específicos más horizontales, donde el nivel y motivo de las sesiones sea más claro.
Aquí cabe la idea de ampliar la idea de Comunidad de Práctica que propusimos a unos cuantos Juanma y yo viniendo del AOS de Asturias. Esto se va a hacer en febrero, pendiente de fecha.

Construir más comunidad

Sinceramente, ni idea cómo hacer esto. Imagino que es un resultado de todo lo anterior.m

 

A partir de aquí igual todo es importante y no hago más que relacionarlo con el tema abierto en Agile Spain, relativo a que todavía no ha salido nadie para organizar la siguiente CAS.

O no lo es en absoluto, y solo hay que respirar, ser más indulgentes con nosotros mismos y seguir adelante preocupándonos únicamente de conectar con aquellos que realmente nos aportan energía.

Un abrazo a todos y ¡Feliz Año 2016!

Mi No-charla en la CAS 2015 : Necesidades vs Soluciones: una vista diferente al Crossing the Chasm

Este año presenté un par de charlas[1][2] para la CAS 2015.
El nivel es realmente extraordinario, así que no me extraña demasiado que al final no se aceptase ninguna. La parte buena es que podré ir mucho más relajado.

Presenté charlas más como un ejercicio de colaboración con la comunidad que por un objetivo personal. Este año me lo había tomado como de descanso, después de haber ido como ponente a un montón de sitios en el 2014.

Pero lo que me trae a escribir este post rápido es compartir con vosotros el abstract de la charla que creo es muy interesante, así que me encantaría prepararlo y contarlo en un @madriagil.

Necesidades vs Soluciones: una vista diferente al Crossing the Chasm

En mi entorno existe una gran inquietud tecnológica. Llega a ser un ansia feroz por buscar el siguiente best-framework-ever, por no conformarse con soluciones bien probadas.

El pasado agosto estuve en Sofía asistiendo a la ALE y conocí al genial Chris Matts que hizo la keynote inaugural. Hizo una aproximación al clásico Crossing the Chasm, mapeándolo por encima con otros modelos como el Cynevin, Meme Lifecycle o Real Options.

Fue realmente revelador. ¿Por qué algunos se conforman con una solución suficientemente buena y otros buscan continuamente la excelencia? ¿Por qué las buenas prácticas no son tan buenas? ¿Por qué reinventar continuamente la rueda? ¿Qué motivaciones existen en unos y otros?

En esta charla veremos las diferentes comunidades que tenemos a nuestro alrededor y trataremos de alinear todas estas motivaciones dándoles un objetivo común.

Articulos relacionados de Chris Matts Communities of Need & Community of Solutions y Agile – The Broken Learning Machine

Un pequeño sketch que hice ayer para explicarlo en una sesión que tuvimos en Kaleidos:

La idea clave que puse ayer es que las Necesidades se mantienen, mientras que las Soluciones cambian con el tiempo.

Aquí salió la pregunta «¿No hay un gran desperdicio de tiempo y esfuerzo en estos experimentos constantes?»

Mi respuesta es conseguir el equilibrio entre «Rentabilidad vs Atraer Talento» , «Aburrimiento vs Investigación», «Estrategia empresarial vs Motivaciones personales»

Más diferencias, foto de Alexis Monville

Espero que os resulte tan interesante este tema como lo es para mi.

[1] Tarjeta trello de la CAS2015 para la charla de Necesidades vs Soluciones
[2] Tarjeta trello de la CAS2015 para la charla de Discusiones y Decisiones

¿Qué es una historia épica?

La semana pasada se lanzó una pregunta dentro del equipo muy interesante:

¿Qué es una historia épica?

La pregunta venía motivada, porque es una petición muy recurrente entre los usuarios de Taiga.

Mi respuesta en un correo fue esta:

Una épica, según los que lo inventaron, es una historia grande y muy indefinida que se va a dividir.
La Epic, tiene que desaparecer, en sus historias más pequeñas.

Historias de usuario que recuerdo deben seguir el patrón: INVEST
​remarcando la I de «​Independent» y la V «Valuable»

En mi opinión la EPIC puede tener sentido y ser visible, incluso con otro color, pero más reflejando ese estado de proto-historia, de idea sin madurar, de historia ‘gorda’… que como algo que vaya a ser parte de la estructura de la aplicación.

Preguntas que pueden surgir:

«Realmente todas las pequeñas historias no subirían solas a producción, están relacionadas»
Aquí puede ser útil el concepto de Epic, como agregador de us. Es decir, tenemos el concepto de módulo. Pero cuidado, esto generalmente es muy confuso de gestionar en cualquier plataforma, incluso en papel.
Hace al cliente muy difícil prioririzar, hay muchas dependencias.
Los tags aquí harían un buen trabajo, creo.

«Los prototipos de UX son para la historia grande, la epic»:
Eso es un problema de documentación, o de que el UX hace los prototipos antes de dividir, o que las divide back, con el sesgo que tiene, o todo a la vez.
Si las historias son independientes deberían tener su prototipo clarito. No rebuscar en el prototipo 17.0.3 y ver qué botón es la us que estamos mirando ahora.

«Pero las EPICs no son formas de agrupar los grandes bloques de un proyecto, por ejemplo API, Front Web, Front Movil, …»
No, eso se podrían llamar módulos o similar, pero esos módulos no tiene valor ‘per se’.

La palabra epic, la usa Mike Cohn en su libro, así que es ‘oficial’ 🙂

Busco en google y me encuentro este precioso artículo de Mike Cohn de este año hablando de todo esto!
http://kcy.me/1cu9f

que es una copia de éste del 2011
http://kcy.me/1cu9p

Espero que ayude. 🙂

Después de este correo tuvimos una reunión para definir:

«Qué sería una historia épica en Taiga»

Una de las máximas necesidades que tiene el usuario de una épica, es servir de base para el primer análisis y puede estar acompañada de un buen hilo de conversaciones, diagramas, wireframes e incluso prototipos. Y esa información no la queremos perder.
Si dividimos la épica en historias más pequeñas, ¿dónde metemos toda esa información previa?

Por lo que el formato final en Taiga, será una historia de usuario, que se marcará como ‘épica’ en sus propiedades, y se distinguirá de las demás en el backlog por el color.
La épica y sus historias derivadas estarán relacionadas y así podremos acceder a toda la información del análisis previo si fuera necesario.

Como bonus, esa agregación de historias en la épica, nos da la posibilidad de hacer un seguimiento de ver cuántas historias están hechas, y así tenemos algo parecido a un módulo o conjunto de historias que tenemos agrupadas.

Como bonus++, esas historias que salen de la épica, puede que no estén en el mismo proyecto, puede que estén en un subproyecto.
Esto abre la posibilidad de tener un proyecto ‘base’ que se llama ‘Dirección General’ una épica que se llama ‘Campaña de Navidad’ e historias de esta épica en el subproyecto de ‘Dpto. de Marketing’ como ‘Anuncios en Televisión’. Pudiendo seguir el avance de todas estas historias desde la épica.

¿Qué os parece? 🙂

Foto gracias a Kulawat Wongsaroj de su post Visualizing the Big Picture of your Agile Project

La desaparación del Agile Coach empezó en la CAS2k13

Mi pato, en la sesión de Lego Serious Play con Ariel Ber en la CAS2k13

 

Borrador olvidado

Hace meses que empecé este post, pero no me acordaba de él y lo descubrí el otro día en borradores. Como me voy a poner a hacer el resumen del AOS 2014 y este blog es mío y tal, creo que es de lo más pertinente y encaja muy bien con lo que sigo descubriendo.

 

La disolución de las altas clases sociales extractoras

Me gustó mucho la CAS 2013, jugué al Lego Serious Play, vi cómo es un Undercover Change Agent, asistí a estupendas keynotes, me inmolé en el Olimpo de los sketchnoters, recabé más información sobre UX en el desarrollo ágil, comí muchos pinchos, compartí habitación con mis compañeros de trabajo, paseé por la Ría, hablé con mucha gente, …

Pero lo más importante es que cambié radicalmente de formar de pensar. Fui como Agile Coach y volví como empresa ágil.

Lo puedo resumir en tres tuits:

We are going to redefine the concept of Agile Coach and leave behind the idea of a Scrum Master babysitter. Everybody involved! #cas2k13

— Antonio de la Torre (@adelatorrefoss) October 17, 2013

We r gng to throw away this class-separated system of Scrum Masters,kind of Knowledge-keepers,and involve all single team member. #cas2k13

— Antonio de la Torre (@adelatorrefoss) October 17, 2013

I AM going to reset all my constraints and prejudices, and be brave and propose every idea I think could improve our lifes. #cas2k13

— Antonio de la Torre (@adelatorrefoss) October 17, 2013

«Vamos a redefinir el concepto de Agile Coach y dejar atrás la idea de un Scrum Master niñera. Todo el mundo implicado!»
«Vamos a tirar a la basura este sistema de Scrum Masters clasista, una especie de Guardianes del Conocimiento e implicar a cada uno de los miembros de los equipos «
«VOY a resetear todas mis restricciones y prejuicios y ser valiente y proponer cada idea que piense que puede mejorar nuestras vidas»

Lo que hay detrás de estos pensamientos es una gran dificultad para encontrar la manera de que los compañeros se vieran involucrados en la mejora, y más concretamente en MIS propuestas de mejora, y más concretamente, en que tampoco se me ocurrían muchas propuestas de mejora.

Gracias a Alonso y Daniel que fueron conmigo vimos que el «problema» de la mejora no podía ser solo mío, si no que tenía que ser de toda la empresa.

La primera acción fue que dejábamos de hacer la reunión de Scrum Masters mensual, para que la única mejora posible fuera la que sale de todo el mundo a la vez e hicimos una retrospectiva para analizar el estado del agile en la empresa.

 

Poco después …

Poco tiempo después se suspendió temporalmente el rol de Agile Coach, pues seguía sin saber cómo llegar a los equipos y así las responsabilidad quedaba plenamente en cada equipo por separado.

La retrospectiva como dinámica no salió muy bien, así que para compensar la labor que hacía como Agile Coach y crear más comunicación entre los equipos, creamos el Meetup interno HowWeWork: bajo la fórmula de una pequeña charla y luego discusión, y la verdad que nos funciona mucho mejor.

 

Hasta hoy

El rol de Agile Coach sigue suspendido y se mantienen exitosamente las reuniones bimensuales de HowWeWork (sin la palabra agile de manera intencionada, para no malinterpretar y sesgar).

Y durante este tiempo me di cuenta de un par de cosas que me ayudan a ver dónde está el problema:

En el curso de Management 3.0 con Angel Medinilla , vi que sin propósito no se puede hacer ninguna acción de mejora.
Y en el AOS 2014 y en la charla de Diego Rojas vimos que en un proceso de coaching la responsabilidad de dar el paso para el cambio está en la parte del coachee, el coach acompaña y apoya.

Si juntas las dos cosas ves que el trabajo de un Coach consiste en crear propósito a partir de lo que quiere el equipo. Dejar aparte lo que uno quiere y centrarse en lo que el otro necesita.

 

Así que equipo, cuando esté preparado os preguntaré a dónde queréis ir, mientras si me necesitáis aquí estaré.

 

 

ALE 2013 o Cómo ver la comunidad con tus propios ojos

(Post escrito en Noviembre, pero es hoy cuando puedo publicarlo, por si veis algunas fechas que no cuadran)

Quiero que tú, sí, sabes que me refiero a ti, te animes a ir a la siguiente ALE y quiero que sepas por qué yo voy a volver.

Lo que pude compartir en la ALE2013 hizo replantearme muchas cosas, fue el inicio de un cambio mental que a día de hoy todavía estoy digiriendo y reconstruyendo.

Fui con deberes, volví con propuestas, las intenté poner en práctica, fui a la CAS2k13 con la idea de seguir en la línea, pero me di cuenta que no era el camino y di un cambio radical. Y ahora camino de la Agile Coach Camp Barcelona, es tiempo de hacer un resumen de qué fue aquello.

Hace ya dos meses de la ALE y puede que esto ya no lo lean muchos de los que allí estuvimos, pero servirá para que te plantees seriamente ir a la siguiente.

El previo

Sirva de contexto de qué tenía en la cabeza, el correo que mandé a mis compañeros en Kaleidos el día antes:

El 26 de agosto de 2013 09:05, 
Antonio de la Torre <antonio.delatorre@kaleidos.net> escribió:

Hola majos:
Mañana me voy a la ALE 2013, Tres días, de miércoles a viernes, 
dónde me encontraré con los top de agile europeo.
Tengo muchas de ir, porque las conferencias son muy molonas, las 
tardes serán de Open Space a muerte y porque es mi primer evento 
gordo en ingles y fuera de España. 
Así que comparto con vosotros este futuro momentazo 🙂 

Mis objetivos:
- Conocer los llamados Gurús
- Mucho networking con los de casa y con los de fuera.
- Trabajar nuestros temas estrella:

* Agile en web : ux-diseño-maqueta-desarrollo

* Las islas de conocimiento y la mejora del mastering en la 
tecnología

* Estimaciones

Y un par de nuevos temas que estoy viendo:

* La figura mixta del ScrumMaster-Developer: Competencias 
poco claras.

* El CEO: ese miembro "especial" del equipo 
(de todos los equipos)

Espero cargarme de ganas de dar caña y seguir mejorando el Agile Coaching en Kaleidos.  Si queréis ver el programa: http://ale2013.alenetwork.eu/ale2013-program/

Saludos!

Toño

Temas de siempre y el runrun de que los «responsables» del agile, los Scrum Masters, tenían un trabajo muy difícil.

Qué ofrece la ALE

El resultado final fue brutal en el contenido, pero el cambio que estamos dando en este Otoño, lo cuento en otro post.

Aquí quiero contarte qué te ofrece la ALE para propiciar este cambio:

1. Fuera de España

Mi primera conferencia fuera de España, y puedo decir que fue un éxito personal total. Un poco temeroso por el inglés, pero enseguida vi que entendía y me entendían y hasta propuse un par de charlas en los Open Space. Problemas con los de UK, el acento de Londres y Manchester es ma-tar.
Pero para las conversaciones en café y pasillo, y sobre todo en la cena, más que de sobra.

2. Conferencia de la Comunidad

Esta conferencia es de la comunidad, nada de service-oriented-bullshit. Apetecía ir a cualquier charla porque la gente comparte mucho y encima controlan un huevo. Somos todos iguales, desde gurús escritores, hasta gente con dudas y que quiere sacar adelante un pequeño equipo. Pero nadie en plan «de qué va esto» o «intenta convencerme».
Me voy a enganchar a ir a esos sitios porque es dónde nacen los mitos. Y luego puedo presentaros a todos en las cenas de la CAS. 🙂

3. Mucho networking

La palabra constante fue «awesome». Los compañeros rumanos se curraron un grandísimo programa que incluyó muchos espacios para poder charlar y compartir. Los Open Space, Lightning Talks o «Dinner with a stranger», hicieron posible conocer muchísima gente que de otra manera seguramente no hubieras cruzado palabra. A la CAS le hace falta algo de esto.

4. Hablar con corto y con confianza

Tengo todo el apoyo de mis compañeros para que me siga ocupando y preocupando por el agilismo en Kaleidos, pero el cómo es lo que hay que construir cada día, probando muchas fórmulas.
En esta conferencia hablé MUY en corto con la gente que creía que me podía ayudar, confiándoles ciertos temas y dudas. Y todas las conversaciones fueron inspiradoras. Nunca estuve en una conferencia con tanta facilidad para las conversaciones de pasillo.

En definitiva…

Los temas que me llevaba y cómo los estamos solucionando son otro tema. Además ahora estamos en un momento de una nueva aproximación. Pero sobre el evento que es de lo que os queríá hablar…
Muy flower-power y tree-hugger, en definitiva, la mayor inyección de energía de mi vida. 

Pequeña reflexión sobre nuestros Scrum de Scrum Masters

En el post de Kaleidos he publicado un pequeño resumen de lo que fue la reunión de Enero de Scrum Masters que hacemos en mi empresa:

Scrum de Scrum Masters de Enero – Mini Open Space

Intentamos reunirnos cada último lunes de mes y aunque no siempre lo conseguimos, pues fiestas, puentes o entregas de proyecto hacen su trabajo, la sensación general es de continuidad.

Cuesta encontrar esas dos horas que dedicamos los 5 del grupo a la reflexión, pero una vez dentro todos estamos de acuerdo que necesitaríamos un día entero, para tratar la cantidad de temas interesantes a comentar.

¿Por qué es importante esta reunión?

Porque los equipos estables (muy estables, diría yo) hacen que haya poca fluidez en la información que circula de lo que hacemos y los cafés y comidas no son suficientes.

Respecto a otra forma de organizarse tengo pendiente de leer el famoso artículo de Henrik Kniberg sobre su trabajo en Spotify.

La verdad es que reunirme con mis compañeros en ese ambiente de tanta confianza y tranquilidad me encanta y se que a ellos también. 🙂

Pirata Roberts, el QA en Kaleidos

Ya tenía ganas de escribir este post. Hoy traigo la explicación de una práctica ágil interesante, motivadora, … ¡de lo mejor! Pelotazo en nuestros equipos y encima original… hay que leer el artículo de hoy con detalle.

La leyenda

En los equipos que tenemos en Kaleidos no hay un miembro que se dedique en exclusiva a pruebas y al aseguramiento de la calidad (QA). Entendiendo ésta como comprobar que las historias cumplen los tests de aceptación, el código que las crea, los tests unitarios, etc.
Siempre habíamos echado de menos a alguien detrás de la defensa, por si se nos escapaba algo, pero no queríamos dedicar a alguien en exclusiva. Aparte de lo aburrido que sería, va en contra de los equipos multidisciplinares.

Los intentos que hicimos con la revisión de las historias por parejas no funcionaron muy bien. No sabíamos muy bien a quién asignar la tarea y por iniciativa propia, todo el mundo pensaba que tenía mejores cosas tareas más prioritarias que hacer que probar el trabajo de otro que además se supone que funciona.

Así que con este cuadro, veíamos que llegábamos a las Revisiones de Sprint con alguna laguna y bastantes bugs.

Hasta que llegó la CAS 2011 (sí, hace más de un año) y uno de los Super-Tips que nos trajimos fue el Pirata Roberts. El detalle de la leyenda lo tenéis en el enlace, pero lo que nos atañe, es que el Pirata Roberts, siempre existió y existirá, porque cada cierto tiempo uno nuevo toma el lugar del anterior…, cada Sprint concretamente.

Update 5 de Febrero de 2013
Que sepas que si hablas con alguien de @kaleidosnet tienes que venir con la Princesa Prometida vista de casa. 🙂

Las misiones

El Pirata Roberts es un rol que rota entre todos los miembros del equipo, cambiando en cada Sprint, durante el cual tiene que realizar varias tareas, pero la más importante es que es el responsable de la calidad de lo que se está desarrollando y se va a entregar.

Cuando un miembro del equipo termina el desarrollo de una historia la pasa a «Ready for Test» y es el Pirata (como le llamamos ya de forma coloquial) el que la pasa a «Closed» antes del fin del sprint, confirmando así que cumple el comportamiento esperado. Ante cualquier error o duda se echa para atrás y se revisa.

Inmediatamente hemos aumentado la calidad del producto.

Pero el Pirata Roberts se encarga de más cosas:

• Realiza la demo de producto en el «Sprint Review».
• Gestiona la recepción de correos «monstruo» de clientes, liberando así al equipo de abrir un powerpoint con capturas de pantalla o dar de alta 50 bugs que iban dentro de un único correo.
• Realiza el «Backlog Grooming«, comprobando que las historias de lo más alto de la pila no tienen carencias graves, preparando la reunión de planificación.
• Comprueba la calidad del código y sus tests, jenkins, cobertura, etc.
• Despliega la versión en el servidor de integración, pre, o producción.
• … y cualquier tarea de gestión pesada.

Son muchas tareas posibles, pero cada equipo las adapta según su necesidad.

Los beneficios

El gran beneficiado es el producto, que llega al final del sprint mucho más probado y con menos incertidumbre.

Pero no lo es menos el propio miembro del equipo al que le toque ser Pirata. Es un gran trabajo y una gran responsabilidad, pero se compensa con el conocimiento que se obtiene de toda la aplicación al tener que probar todas las historias de un sprint, preparar la demo, responder correos, etc.
El equipo es más multidisciplinar y se disminuye el peligro del Bus Factor.

¿Cómo garantizas el QA?

¿Te parece interesante esta propuesta? Creemos que es singular en el modo rotatorio, pues esta tarea suele estar asignada a alguien. ¿Cómo lo resuelves en tu equipo?

Aprovecharé para explicar en detalle esta práctica en el Open Space QA y Agile que se realizará el próximo 16 de Febrero, ¡así que nos vemos allí!