Agilismo en Navarra (III)

(…proviene de Agilismo en Navarra (II)…)

Continuamos el análisis de los datos obtenidos de las entrevistas con las prácticas más comunes y más empleadas entre las empresas que han implementado el agilismo, aunque esto no se cumple en todas:

  • Configuración de equipos fijos y estables a los que se les asigna uno o múltiples proyectos frente al uso de un pool de recursos. Además, todas coinciden en la importancia, en la medida del os posible, de que una persona se dedique el 100% a un proyecto.

  • Uso de las reuniones diarias.

  • Uso de ciclos cortos de desarrollo que varían entre 15 días y 1 mes.

  • Existencia de una persona cubriendo el rol de Product Owner. Lo que varía es la persona, pudiendo ser el comercial, un cliente, personal interno haciendo de proxy a apoyando al cliente, etc.

  • La priorización es llevada a cabo por este Product Owner.

  • Empleo del planning poker para las estimaciones pero no todos usan puntos de historia para esto.

  • Uso de un tablón donde se visualice el trabajo (historias de usuario). Lo que varía es el soporte del mismo, en algunos casos se trata de un panel físico, en otros virtual y en otros una combinación de ambos.

  • Todos efectúan demostraciones del producto pero, en algunos casos, la realizan al finalizar el Sprint y en otros a demanda, cuando hay funcionalidades que mostrar.

  • Como en la mayoría de los casos han realizado la implantación por su cuenta, han necesitado de la figura de un Scrum Master con una dedicación muy alta.

  • En menor medida aunque n una proporción importante se efectúan retrospectivas.

Y de igual modo, las prácticas ágiles menos extendidas que coinciden con las métricas de progreso:

  • El uso de gráficas burn down para ver la evolución del trabajo realizado en un sprint

  • El uso de puntos de historia en la estimación de historias de usuario.

Al margen del agilismo, casi todas las empresas dan especial relevancia a las horas invertidas, y consecuentemente llevan un registro de las mismas, como una medida de coste.

Por otro lado, entre los problemas más repetidos que se han encontrado, no solo los que lo han  implantado sino también los que lo han probado, son:

  • Implicación del Product Owner en el proceso, la relación con el cliente. Este, en mi opinión, será el problema más recurrente y el más crítico para el éxito del método.

  • Elección de la duración de los ciclos de desarrollo: ante este problema, mi consejo, lanzaros y experimentar. En los casos en había interdependencias entre proyectos, equipos o áreas, sincronizar los Sprints era complicado porque dependía de equipos, proyectos o clientes distintos con ritmos diferentes.

  • Otro problema muy habitual, es la creación de equipo: considerar como propios los objetivos del Sprint, colaborar con los compañeros para conseguirlos, asumir responsabilidades para poder auto-organizarse, etc. En esta situación, paciencia, dejar o favorecer que las cosas sucedan a su ritmo.

  • Realizar estimaciones fiables: en este punto recordar que son estimaciones y serán más fiables tanto en cuanto el equipo sea más maduro, el proyecto más avanzado o las casuísticas a las que os enfrentéis más similares entre si.

  • Pesadez de muchas liturgias (planificación, demostraciones, retrospectivas, etc) en términos de duración o eficacia.

  • Convivencia del método dentro de la organización o como extrapolarlo al resto de la empresa donde la forma de trabajar es otra. En particular, la presión de fechas que rompen con los ciclos de trabajo o impiden determinadas liturgias ágiles como la retrospectiva. También la relación con los comerciales a la hora de vender un proyecto donde debe dimensionarse en plazos y costes con muy poca información.

Que estos problemas no os desanimen, son habituales y tenéis mucho ganado estando ya identificados. Tan solo conviene estar preparados y responder adecuadamente a estos retos.

De todas maneras, no todo son problemas, aquellos que lo han intentado han corroborado los siguientes beneficios:

  • Una muy buena relación con el cliente, en los casos en que este se implica. Por un lado, gracias a la fluida comunicación durante todo el proceso y a la transparencia, se genera más confianza. Por otro lado, el cliente reconoce mayores beneficios al poder decidir en todo momento las prioridades y el rumbo de un producto que, además, está constantemente “palpando”.

  • Mayor visibilidad de lo que se está haciendo, no ya solo con el cliente, sino con todos los implicados, incluyendo al equipo que tiene la oportunidad de saber que hacen otros compañeros y ver el conjunto global del producto más allá de sus propias tareas.

  • Relacionado con lo anterior, se aprecia al equipo contento dado que ahora se les permite ser partícipes de las decisiones técnicas del producto.

  • Y algo que quizás sea obvio porque así lo indica la teoría pero no por ello menos importante porque la práctica lo constata: los ciclos de trabajo cortos permiten detectar de forma muy temprana de errores y por tanto, tener la posibilidad de corregirlos a tiempo, implican una enorme disciplina y permiten una gran adaptabilidad y respuesta ante cambios.

No me queda nada más que agradecer a todos los que se prestaron a mantener una entrevista con nosotros y espero que al resto le haya servido esta información y los que no se hayan animado hasta este momento al lanzarse lo hagan ahora. Para estos últimos que sepan que desde CEIN les prestamos ayuda, para lo cual pónganse en contacto con nosotros y estudiaremos su caso.

Esta entrada fue publicada en Artículo y etiquetada , , , . Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s