Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70
P9_cas2015_RachelDavies.png

Los pasados 3 y 4 de diciembre tuvo lugar la Conferencia Agile Spain 2015 (CAS 2015) en el Círculo de Bellas Artes de Madrid. Fue un evento masivo (más de 700 personas) que nos permitió a la comunidad ágil española reencontrarnos y escuchar a algunas buenas sesiones. Resumo aquí las cuatro que más me gustaron:

 

XP from the Begginning

Rachel Davies es la coach ágil de Unruly, una compañía de origen británico dedicada al video y la publidad en Internet. Rachel explicó el enfoque que le dan a la agilidad y al aprendizaje organizativo, ¡que da mucha envidia de no trabajar con ellos! Las principales ideas que anoté fueron:

  • Trabajan desde la fundación de la empresa con Extreme Programming (XP)
  • Dedican el 40% a requisitos (User Stories) y el restante 60% a otros tipos de trabajo (refactoring, infraestructura, I+D y aprendizaje, etc.). Me parece muy notable marcar como objetivo esta separación explícita del trabajo «visible para el cliente» y el otro más difícil de vender pero que les hace entregar altísima calidad e innovar.
  • Se aseguran que todos los empleados dedican un 20% del tiempo al aprendizaje (originariamente era 1 día semanal) y a compartir el conocimiento. Además fomentan que este tiempo de aprendizaje se reparta uniformemente. Incluso intercambian personas del equipo con otras empresas para que aprendan otras maneras de trabajar.
  • Utilizan la regla de Propiedad colectiva del código de XP aplicada al conocimiento. Ninguna función organizativa depende únicamente de una persona, ni siquiera la de coach. Esto les permite flexibilizar las vacaciones, minimizar el riesgo que se pierda conocimiento si alguien se va de la empresa e innovar más.
  • Tienen claras las fuentes de aprendizaje, que incluyen a los compañeros del equipo, otros roles de la empresa (operaciones, expertos…), otras empresas, tendencias del mercado y especialmente las actividades de compartimiento de conocimiento.

P9_cas2015_RachelDavies.png

 

Agile Selling

Juanjo Martínez Pagán es director de operaciones en ASP Gems, una compañía de desarrollo con sede en Madrid. Tenía muchas ganas de asistir a su sesión sobre «ventas ágiles», porque en muchos asistentes a mis cursos de agilidad me presentan la dificultad de salirse del «proyecto cerrado». La sesión resultó muy interesante, Juanjo nos explicó muy bien como adaptó su experiencia de procesos comerciales tradicionales en grandes empresas a los proyectos. La sesión no pretendía explicar cláusulas contractuales ágiles (le llovieron preguntas sobre este tema), sino como adaptar el proceso comercial, aunque mi principal aprendizaje fue que ambas cosas están relacionadas.

Los principales problemas que identificó Juanjo en las ventas de proyectos web son:

  • Esfuerzo dedicado a clientes que no compran.
  • Cambios necesarios a las ofertas durante los proyectos debidos al cliente (necesidades no descubiertas, roles que no intervienen al principio de la venta, etc.)
  • Ofertas mal definidas por haber sido creadas por una única persona (normalmente un comercial no experto técnicamente)

La «venta ágil» supone transformar el proceso de venta cambiando la manera en que se da respuesta a las peticiones del cliente. Básicamente se trata de:

  • Añadir roles técnicos a un equipo comercial virtual, con una asignación explícita a parte del «delivery», para mejorar la calidad técnica de las propuestas desde el principio.
  • Hacer iteraciones en función de la dedicación e interés del cliente. Esto supone no perseguir a los clientes ni añadir más detalle a las ofertas si el cliente no se ha involucrado activamente en validar la versión anterior de las propuestas. Si un cliente no muestra interés, la oferta muere naturalmente y se optimiza el esfuerzo del equipo comercial.

Aunque este enfoque no añade nada a la contratación ágil, favorece ganar confianza progresivamente y por ambas partes, lo cual facilita mucho la firma de contratos con alcance abierto o semi-abierto. Respecto a este tipo de contratos «ágiles», Juanjo dijo:

  • Nuestros contratos incluyen una cláusula donde el cliente puede echarnos con un sprint de margen, pero nunca lo han hecho.
  • Se esfuerzan en definir con detalle los requisitos de negocio y dejar más abiertos los requisitos del sistema. Esto les facilita ganar la confianza de los clientes y poder evolucionar posteriormente los requisitos funcionales y técnicos.
  • En los clientes grandes deben plegarse al contrato cerrado debido a su cultura. Lo asumen y reservan una contingencia para absorver los cambios inesperados.

 

Software Economics

Esta es la sesión que más me gustó, por mi interés personal en la economía y la gestión, y porque tantos «soft-skills» y «coaching» concentrados en dos días me cansan un poquito (¡es broma!). Luis y Guillermo trabajan en BuntPlanet, una consultora donostiarra dedicada a la ingeniería de SW y especializada en la gestión del agua. En la sesión Software Economics (Tradeoffs of Decoupled Software), se dedicaron a revisar varios aspectos económicos de la ingeniería de software, a saber:

  • Necesidades de negocio. Entender aspectos básicos de economía y de gestión ayudan a todos los miembros de los equipos a tomar mejores decisiones sin necesidad que alguien (p.e. un jefe de proyecto) lo haya hecho por ellos. Algunos de estos conceptos que se repasaron fueron: economías de escala, time to market, deuda técnica, valor, riesgo, opciones reales y coste. Un recordatorio que nunca está de más, vista su aplicación general, es que el «deuda técnica» es equivalente a «mala calidad porque sí» sino a decisiones conscientes para llegar a una entrega (y pagar después los intereses).
  • Valor, coste, riesgo y deuda. La clave de esta sección fue entender como las prácticas y estrategias técnicas impactan en estos conceptos de la economía de los proyectos. Cada equipo y proyecto tienen particularidades, y las «mejores prácticas» de la literatura y explicadas en Internet deberían pensarse como «buenas prácticas» que debo evaluar para mi contexto. El cuadrante «cuantificable» vs «visible» de más abajo es muy útil para explicar como se toman las decisiones técnicas y su efecto tanto a clientes, gerentes como equipo.
  • Desarrollo iterativo e incremental. Esta sección explica porqué el desarrollo iterativo e incremental minimiza el riesgo y la deuda, a la vez que aumenta el valor, principalmente por las inspecciones (entregas) frecuentes donde se pueden refinar los requisitos y el diseño, todo ello en el contexto de fases pequeñas y con con un esfuerzo comprometido viable (conceptos Timebox de Scrum y WIP de Lean). El segundo gráfico (riesgo vs ciclo de vida lo ilustra perfectamente).
  • El resto de la presentación es más técnico y se mete en los principios de diseño y arquitectura, que facilitan la reutilización pero que también tiene en cuenta otros aspectos como las dependencias y la flexibilidad.

P9_cas2015_BuntPlanet.png

Cuadrante «cuantificable» vs «visible»

P9_cas2015_BuntPlanet_2.png

Riesgo vs ciclo de vida

 

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.