Entradas publicadadas a lo largo del Noviembre, 2009

Scrumcoaching Actualmente la palabra más usada es Coaching, en todos las reuniones o congresos se emplea este término, el Coaching es la profesión de moda, todo el mundo ofrece estos servicios.
Curiosamente si buscamos por esta palabra en Goolge imágenes el resultado nos ofrece ilustraciones de una persona ayudando a otra, como mentores personales, que es más o menos el mensaje que venden los coachings.
Tomando como referencia la descripción que ofrece la Wikipedia:

El coaching trabaja directamente con los individuos, sus procesos mentales y emocionales.

El Coaching esta orientado más hacia un entrenamiento personal, su foco principal es trabajar e incentivar los talentos individuales, algo que contradice la filosofía de las metodologías ágiles, que se centran más en mejorar el talento del equipo y en la automotivación de los propios compañeros.

Los equipos de Scrum no necesitan un Coaching a priori, solo necesitan comunicación y motivación entre ellos, sin tener que destacar ni potenciar el talento individual.
Los equipos no necesitan un Coaching, si no personas que cumplan bien su rol dentro de los procesos, que están muy bien definidos.

La necesidades de emplear técnicas de Coaching pueden ser cubiertas de forma más eficaz por cursos de mejoras de procesos, impartidos por profesionales de las metologías ágiles, que comprendan las problemáticas de los equipos, sus procesos y que además, no buscan una mejora de la motivación ni del talento, si no ajustar las piezas que fallan para que el equipo funcione perfectamente, sin impedimentos, y se convierta en una unidad eficiente.
Los profesionales que ahora se denominan Coaching caerán normalmente en la tendencia de querer tratar a los miembros de los equipos de forma individual, haciendo hincapié en aumentar su talento individual pensando que esto hará aumentar también el del equipo. Sobre todo por que siguen las líneas de las metodologías tradicionales, desconociendo los nuevos conceptos ágiles.

En resumen, mejor que contratar un Coaching, los equipos de Scrum deberían de hacer de Coaching en sus reuniones de retrospectivas, donde se exponen los puntos débiles o fuertes del equipo y de las personas que lo integran. Para este fin se convocan las reuniones de retrospectiva, no se debería necesitar a agentes externos que le indiquen como mejorar, por que eso sería un síntoma de que el equipo no funciona como debería y que no se están cumpliendo los objetivos de cada sprint.
El mejor Coaching es una buena reunión de retrospectiva, por eso podemos afirmar que dentro del proceso de trabajo ya se incluye una fase donde se realizan funciones de Coaching, además estas están orientadas mas al talento del equipo que al individual.

alarm_clockUno de los factores importantes en las metodologías ágiles es la implicación directa del cliente en el proceso de trabajo.
Los clientes son una parte activa, no solo en la fase inicial de determinación de los objetivos, si no también durante todo el proceso de creación o desarrollo para cumplir esos objetivos.

Pero ocurre a veces que el cliente no quiere participar en el proceso, normalmente alegando falta de tiempo, o acostumbrados a un documento de requisitos que seguir a rajatabla, esperan que se cumplan estos y que él solo vea el resultado final.

Esta situación es muy difícil de manejar, dado que la no presencia del cliente conlleva tomar decisiones que no le corresponden al Product Owner y el equipo. Hay tener en cuenta que no existen recetas magistrales, que cada caso es distinto, pero se puede conseguir reducir las consecuencias de la falta del cliente empleando varias técnicas:

  1. Buscar una persona que tenga relación directa con el cliente, aunque sea para otros temas, que si disponga de tiempo para poder participar en las reuniones, las presentaciones o que pueda atender a las llamadas del equipo. Esta persona, aunque no esté en el proyecto le puede comunicar al cliente los avances, proyectando sobre el mismo la sensación de que se esta trabajando y avanzando.
  2. Entregas fáciles de usar. Este aspecto puede resultar novedoso, pero es muy efectivo con este tipo de clientes. En vez de terminar un sprint y hacer una presentación del producto terminado en este periodo, hay que crear una historia de “Preparar la presentación”. Esta historia puede ser grabar un vídeo sobre el avance del proyecto. El cliente con el mínimo esfuerzo y tiempo puede ver la evolución del proyecto.
  3. El último recurso, si los dos anteriores no funcionan se le llama la “Carta mensajera”. Si aún así el cliente no tiene tiempo para ver los vídeos y poder dar una opinión en una llamada de un minuto, lo mejor es remitir por email y correo normal las entregas. En el correo normal enviar el resultado en un soporte digital dentro un sobre grande, cuanto mas llamativo sea mejor. Si el cliente ve el sobre y no hace nada, cuando tenga mas de uno comenzará a darse cuenta de que tiene tarea pendiente, que tiene que revisar la documentación. En este caso extremo el propio cliente, si no colabora se verá desbordado por los sobres. Hay que acudir al elemento visual para hacerle llamar la atención.

Estos tres consejos son en verdad para activar la participación de un cliente en el proceso de desarrollo de su proyecto, pero si de verdad el cliente no tiene ningún interés por estar involucrado en el proceso, no es un cliente recomendable, sobre todo por que la comunicación es inexistente y el resultado casi seguro que no cubrirá la expectativas depositadas en el encargo del trabajo.

La tendencia actual de muchos equipos de desarrollo de software, es trabajar empleando las herramientas On Line, las cuales cumplen las mismas funciones que se reflejan en el tablón de trabajo.

tablon y burn down

Una de las ventajas que ofrecen las metodologías ágiles, es la capacidad de obtener mucha información de los proyectos y su evolución con una simple mirada al tablón. Sustituir este elemento visual por aplicaciones On Line no es aconsejable, dado que se convierte en un toten, en un símbolo visual del equipo, y representa de forma física el esfuerzo diario.

La mejor manera de introducir las aplicaciones de gestión que se ofrecen, es hacerlas complementarias, pero sin defenestrar al tablón, dado que este elemento no solo vierte información a los equipos, si no a todas las demás áreas de las empresas, consiguiendo con ello que exista un elemento visual que aumente la comunicación por el simple hecho de estar.

El tablón de Scrum reúne en muy poco espacio de tiempo mucha información, que además la ofrece de forma clara y concisa, básicamente se puede definir como un espacio:

  • Con pocos elementos y sencillos, que hacen que sea fácil entenderlos
  • Una sola gráfica donde se representa todos los contenidos
  • Fácil de manejar
  • Dispone también de un lugar de recogida de incidencias

Sustituir este elemento visual por uno virtual supone prescindir de una herramienta muy útil, convirtiendo el desarrollo de los Sprints en algo mas opaco y difícil de transmitir o mostrar a los equipos, a otros departamentos de la empresas, así como a los clientes o visitantes.

office3_256 No todo en Scrum es un mundo maravilloso, existen críticos y personas que lo han descartado. Básicamente sus quejas se centraban en los siguientes tres puntos:

- Muchas Reuniones y algunas muy largas, como la de estimación:

Curiosamente este punto es uno de los pilares fundamentales de Scrum, al realizar reuniones para que fluya la comunicación entre todos los agentes implicados. Pero existen personan que critican el hecho de tener que reunirse todos los días, aunque sean reuniones de cinco minutos, dado que creen que es innecesario muchas veces durante el desarrollo del sprint.
Existe también una crítica hacia las reuniones de estimación, que se suelen alargar a 3/4 horas  y la verdad es que puede resultar agotador, sobre todo si no se preparan bien y se dejan las historias abiertas, creando debates más largos de lo necesario.

- Tener que medir con métricas todos los procesos:
En este punto los críticos responden que la obligación de medir todos los procesos, que les lleva a crear unas gráficas muy bonitas de cara a los clientes, disminuye la creatividad, supeditando la misma a valores medibles.

- El equipo elimina cualidades del individuo:
Los equipos ejercen una presión a sus miembros que les hace anular ciertas cualidades como la inspiración, la espontaneidad, las genialidades absurdas, etc.
Justifican que en todos los proyectos se necesitan dosis de estas características para que se consiga un producto completo.

Esta lista puede continuar con otros muchos aspectos criticables de Scrum, pero siempre suelen tener argumentos basados en experiencias personales. Los puntos negros normalmente no suelen surgir de las metodologías que se integren en una empresa u organización, si no de su deficiente aplicación.

Se confunde normalmente lo sencillo con la facilidad. Que algo sea sencillo no quiere decir que sea fácil de manejar, valga como ejemplo un coche automático, cualquiera se puede sentar un él, tomar el volante y comenzar a conducir, no hace falta nada más que unos minutos para aprender a conducir. Pero este gesto sencillo, el de conducir, conlleva la complejidad de acceder a un tráfico, con otros miles de coches, de conocer unas normas de tráfico, etc.
Conducir es muy sencillo, el tráfico y sus normas son algo muy complejo.

Las personas que conocen Scrum se asombran de los sencillos que son sus principios y sus procesos, pero esto no quiere decir que sea fácil de implementar en una empresa u organización. Se confunde la sencillez con la facilidad.

El primer impedimento, nada sencillo de superar, es que la estructura de una empresa tiene que variar para adaptarse a la filosofía ágil, la de autogestión de equipos, la de entregar parte de la responsabilidad a otras personas. Partiendo de este punto, existen otros factores que hacen que Scrum no sea fácil de implementar.

Aun así, llevados por la sencillez de sus planteamientos muchos directivos de empresas deciden integrarlos, dejándose llevar por las modas y por las promesas de aumento de productividad, algo que luego les lleva a comprobar que están teniendo muchos problemas para cumplir sus compromisos de iteración, y que además están acumulando una gran cantidad de deuda técnica.
En este punto los responsables suelen echar la culpa a Scrum, y no a los fallos cometidos a la hora de implementarlo pensando que era algo muy sencillo.

Hay que tener en cuenta que en los procesos intervienen personas, hay que reconocer la importancia de las mismas en el desarrollo de los sprints, darle formación, apoyo, crear una comunicación fluida, ayudarles a reflexionar y conseguir una mejora constante, y por supuesto darle la potestad de poder variar o cambiar los procesos para una mejor adaptación a Scrum.

Integrar Scrum por su sencillez, sin asumir la dificultad que en realidad supone en la estructura organizativa, es cometer un grave error. Se cae en este error porque las empresas parecen tener una tendencia a buscar las victorias rápidas, a aumentar beneficios de forma rápida, con un enfoque de miras a corto plazo, atraídos por la falacia de la sencillez de los procesos.