Tras un apabullante AOS2017, que me ha situado fuera de la zona de confort durante día y medio, vuelvo a la seguridad de mi hogar con reflexiones y aprendizajes golpeando mi cabeza.
Este post sirve como reflexión personal (y compartida) a través del cual pretendo dar orden a toda esta información.
Me llevo mucha información más de la que aquí coloco; pero escribirla toda sería imposible. Escribo aquí los highlights para acudir a ellos en un futuro. O que sirvan de inicio de futuros debates. Si estás leyendo esto, probablemente sabrás cómo localizarme :)
Same problems everywhere
En este AOS, no sé si por las cervezas o porque me he atrevido a usar la ley de los 2 pies más que en anteriores ocasiones, he interactuado con personas con las que no había hablado (profundamente) hasta este fin de semana, y he conocido muchas otras realidades diferentes a las mías. Al contrastar las realidades entre sí, me ha sorprendido la cantidad de quejas y lamentos sobre los mismos problemas de siempre, cuya solución nos parece evidente (ya que todos lo vemos igual si vamos a la AOS) y sin embargo, en la realidad empresarial se aplica de forma diferente por otros motivos que (quizás) desconocemos:
- Separación equipos de negocio vs equipos de desarrollo, alejando al desarrollador del negocio, y escuchando “quejas” de los de negocio porque el desarrollador no entiendo éste.
- Separación vertical vs. horizontal (ejemplo, frontend + backend, en vez de funcionalidades). Creación de embudos, colas de trabajo y bloqueos por interdependencias.
- Cierre de alcance — tiempo — presupuesto. El triángulo mágico de siempre, y cómo cerrar contratos que nos permitan no cerrarlo.
- Gestión de Garantías. ¿Debería existir en el desarrollo de software conceptos como “garantía”?
¿Por qué replicamos estructuras y mecánicas en todas las empresas, cuando, desde el punto de vista teórico, parece evidente que tienen los problemas que siempre nos encontramos?
Roadmap Journey
El descubrimiento de los últimos días para mí ha sido Vanesa. Vi su charla de la #lechazoconf (puedes verla aquí), y enseguida me hice superfans de sus capacidades. En el AOS aportó con una esclarecedora charla donde explicó con detenimiento su “metodología” de trabajo de Roadmap (cuando deben coordinar el roadmap de un producto entre muchos equipos y Product Owners).
Mi reflexión es que Vanesa ha hecho en lastminute algo que en nuestra empresa se está convirtiendo en un reto (y eso que nuestro equipo de producto es muy pequeño). Y lo ha hecho porque ha sabido explotar de forma única un conjunto de capacidades que se requieren para trabajar con roadmaps. A mi parecer:
- Visualización gráfica: ser capaz de dibujar un roadmap en un solo slide no lo hace cualquiera.
- Analítica y Razonamiento: ser capaz de razonar por qué priorizamos y qué soluciones buscamos, sobre las métricas y datos que hay encima de la mesa, replanteando funcionalidades e hipótesis, no lo hace cualquiera.
- Empatía: entender las necesidades y problemas del otro, y colocarlos en la balanza a la par que los datos, no lo hace cualquiera.
En futuras entrevistas para personas que requieran “liderar roadmap” serán tres capacidades a las que prestaré especial atención.
Por cierto Vanesa, yo compraría un libro que definiera esta “metodología”. The Roadmap Journey es un título precioso.
Remotamente ágiles
En INIT llevamos trabajando 9 años con equipos distribuidos, y es algo que “cuesta aprender”. Yo en concreto estoy contento porque nuestro equipo, tras un proceso enfocado en los últimos 2 años, ha sabido dotarse de unas mecánicas para trabajar con el otro equipo de San Salvador de Jujuy. Sin embargo, es necesario escuchar otras experiencias para progresar en este aprendizaje. Algunas de las que adquirí, profundicé o recordé durante este foro / debate son:
- Equipos distribuidos vs. equipos remotos: no es lo mismo. Me recordó este interesantísimo post de Martin Fowler, gracias al cual, “diagnostiqué” nuestro caso como el Multi Site teams: https://martinfowler.com/articles/remote-or-co-located.html
- Hemos tonteado otros modelos como el “Satellite workers” a la hora de colaborar con diferentes profesionales. Sin embargo, nuestro modelo aquí falló, pues fue imposible (por nuestra historia) de comportarnos todos como si estuviéramos en remoto (y así evitar que las personas satélite no se enteraran de nuestras conversaciones). Javi Rubio me hizo replantearme si deberíamos repetir la experiencia y sacar nuevas conclusiones.
- Me gustaría MUCHO probar con un equipo “remote first”. A la hora de crear un nuevo equipo en la oficina, me gustaría plantearnos si podríamos intentar que este equipo fuera totalmente remoto.
- Y algunas mecánicas muy concretas, como: (1) realizar pair programming con los chicos de Jujuy eleva la confianza (y no solo entre desarrolladores, podría el PO participar); (2) probar a hacer las reuniones de planificación de equipos cada uno en su sitio, (3) el bot slack que “acusa” de forma automática cuando alguien no ha “vertido” la daily en el slack.
- Me quedé con ganas de explicar cómo hacemos las retros. Lo dejaré para un futuro post por aquí :)
Equipos Multidisciplinares
Gracias a la inspiración del CEO de nuestra init services , salí a proponer un foro debate sobre lo complicado que tenemos a la hora de trabajar en equipos multidisciplinares. En nuestro contexto, somos equipos multiproyecto, en el que un equipo de 5 personas trabaja en varias proyectos. Sin embargo, en nuestros equipos empezamos a vender soluciones con necesidades de diseño, marketing y UX; y sin embargo, al no ser perfiles que intervienen durante el 100% del proyecto, sus dedicaciones a los equipos se fragmentan; creándose personas trasversales que empiezan a agruparse en “otros equipos” (equipo de diseño, de marketing, etc.).
Gracias al debate, y en particular a la participación de Aritz de biko2, me llevo una nueva reflexión: Si añadimos capacidades de marketing, diseño y/o UX al equipo, el error está en el origen, al seguir vendiendo los mismos proyectos que antes. Si ahora tenemos esas capacidades, entonces ahora debemos vender lo que nuestro nuevo equipo sabe hacer; y venderemos más marketing, diseño y/o UX; y nuestros proyectos deberán reflejar más las consecuencias de tener estas capacidades. Por ejemplo: la priorización de las funcionalidades a desarrollar en los proyectos (o productos de nuestros clientes) podrá venir derivada del trabajo de estas capacidades.
(¡Gracias Xabi por la “facilitación gráfica”!)
Autoexigencia en los equipos
Cuando salió la charla, no me llamó la atención; pues pensaba que era un tema que actualmente no me preocupaba en exceso, ni a mi ni al equipo. Sin embargo, ya que Aritz había participado tanto en la de Equipos Multidisciplinares, pensé en que sería buena idea quedarme en ésta.
Y lo fue; pues creo que este es el ejemplo de charla “No sé que no sé”. Y se creó un debate muy interesante, con los siguientes ingredientes:
- ¿Cómo medir la exigencia de un equipo? Me gustó la idea de medirla a través del “backlog” de aprendizaje del equipo. Si después de la retro, el backlog de aprendizaje del equipo es pequeño o de mala calidad, eso también refleja un nivel de exigencia bajo.
- ¿Podemos o debemos ser exigentes con otros equipos? Al inicio, la respuesta me parecía evidente: si yo quiero que la empresa en la que trabajo vaya bien, me parece lógico querer que el resto debe ser exigente consigo mismo. Aunque a medida que avanzó la discusión ya no me parecía todo tan evidente…
- Motivación: uno de mis ingredientes preferidos. Recapacité mucho sobre la motivación personal desde la visión de cada uno, su alineamiento de ésta con la del equipo, y el alineamiento de ésta con la de la empresa y el grupo (en nuestro caso). La necesidad de que el grupo de empresa sepa y tenga canales para comunicar esta visión y así acabar en el individuo, y por tanto, yo sabiendo cómo, cada vez que tecleo, cada una de mis líneas de código acaba impactando en la visión de empresa.
- Y me gustó mucho el debate sobre cómo enfocar el despido de las personas dentro de los equipos. Por falta de tiempo y porque el debate acabó en otros derroteros, me quedé con ganas de lanzar esta pregunta: ¿alguien en la sala tiene o conoce experiencias de empresas reales que delegan al equipo la potestad completa de decidir si se despide a una persona, sin que intervenga management? (se habló mucho al respecto de contratación, pero me quedó con ganas de saber lo mismo en despidos).
Y gracias
Gracias a Xabi y a Alicia, compañeros de trabajo y ya casi de vida, por hacer del viaje a y desde Bilbao otro momento “open space”. ¡Charlas muy intensas con comida en Milagros para satisfacer nuestra ansia de lechazo!
Gracias especiales también a Jordi Gómez, también compañero y CEO de init services, por hacer posible este viaje. Porque fue quien me inspiró y enseñó que había nuevas formas de hacer las cosas desde la primera AOS que asistió (y existió). Y porque nunca se cansa de hacer que su empresa viaje por este complicado camino que es el aprendizaje continuo.
Y gracias a la organización, por hacerlo posible. ¡Qué fácil parece todo cuando todo sale bien! Enhorabuena.
