Entradas publicadadas a lo largo del Febrero, 2010

Cuando un cliente nos escribe en un documento las necesidades que tiene para alcanzar sus objetivos, nos esta dando una información muy amplia y normalmente poco precisa en bastantes aspectos. El cliente suele tener claro el objetivo, pero muy poco los detalles peque´ños, que al final son los garantizan poder tener éxito.

Tomemos como ejemplo un cliente que nos plantea el objetivo de tener una web de comercio electrónico para la venta de productos naturales de cultivo ecológico. Tiene muy claro el objetivo principal, y nos transmite este objetivo en un extenso documento, pero normalmente olvida traducir este documento en tareas a desarrollar.

La primera misión del Product Owner es exprimir toda la información que recibimos para convertirla en un documento donde se escriban los pequeños objetivos que tenemos que alcanzar, la pila de producto.

Como es bastante difícil poder desfragmentar en pequeñas tareas todos los objetivos intermedios del cliente, lo mejor es dividir los mismos en varios niveles de precisión. Básicamente, podemos precisar de forma mas exhaustiva las primeras tareas a realizar, sin saber como serán las que realizaremos dentro de unos meses u años, dado que no podemos adivinar al cien por cien el futuro.

La mejor manera de manejar la incertidumbre del futuro es crear distintos niveles de tareas en la pila de producto.

  • Épicas: Son todas las grandes ideas del cliente. Todas se pueden hacer, no se dice no a nada. Las estimaciones suelen ser altas, al tener un alto grado de incertidumbre.
  • Temas: Las ideas generales ya diseccionadas en áreas de trabajo distintas.
  • Historias: Detalles concretos de cada tema
  • Tareas: Si una historia dura mas de dos días de trabajo, debería dividirse en tareas, no es recomendable que se trabaje en una historia que dure mas de dos días.

Pongamos un ejemplo:

  • Épica: Meter sistema de pago On Line
  • Tema: Pago Por Tarjeta, Transferencia o PayPal
  • Historia: Conexión con un banco en concreto.
  • Tareas: Test, XML, etc.

En el ejemplo anterior no parece muy difícil disgregar las épica hasta llegar a las tareas. Esto por que es el primer objetivo del cliente que hemos analizado. Pero supongamos que el proyecto de desarrollo del portal se estima en un año. Al momento del inicio, no sabemos con que nos vamos a encontrar en un futuro, por lo que lo mejor es redactar una épica.

  • Épica: Meter sistema de pago On Line
  • Tema: Pago Por Tarjeta, Transferencia, PayPal, Iphone, Android, o algún nuevo sistema que salga, por ejemplo si lo lanza Google.
  • Historia: Conexión con un banco, no tenemos ni idea de con que banco, dado que esta negociando als condiciones.
  • Tareas: No existen tareas, dado que no hay historias concretas.

Como podemos comprobar, predecir el futuro es imposible, e incluso puede que el cliente al final no llegue a ningún acuerdo con ningún banco y solo acepte PayPal. Es por esto que para tener un rango del coste se crean dentro de la pila de producto distintos niveles de detalles, el cliente puede tener una idea aproximada, pero no se puede concretar hasta que llegue el momento de abordarla.

Perder el tiempo en querer redactar de forma detalla el futuro es una pérdida de tiempo y dinero, y casi siempre genera un gran conflicto entre el cliente y la empresa contratada. La recomendación es muy clara, emplear distintos niveles de detalles en la pila de producto.

Un equipo de Scrum es mas que la suma de sus individualidades. La foto que empleamos para ilustrar este artículo es el fiel reflejo de la relación de un equipo de Scrum.

Deben divertirse como niños, el trabajo que realizan, aún asumiendo su cuota de responsabilidad, les debe permitir divertirse, jugar en equipo. Esa es la principal cualidad que debe tener un equipo de Scrum.

Estamos acostumbrados a que las personas vean el trabajo como una carga, un mal menor. Esa es la opinión o pensamiento general que suelen tener los gerentes o directores de empresas. Que los miembros de su equipo hacen las cosas por obligación, buscando solo el beneficio económico.

Este planteamiento es un error muy común, como podemos ver en la pirámide de Maslow:

El nivel económico es una necesidad que se puede considerar que cubre los dos primeros escalones de la pirámide, pero no es la principal que hace que una persona cualificada se mantenga en su puesto de trabajo.

Hay que diferenciar, entre personas cualificadas y personas no cualificadas. Estás últimas tienen mas difícil el acceso al mercado de trabajo y un ascenso en el mismo, por lo que normalmente se conformarán con cubrir sus necesidades básicas.

Las personas cualificadas buscaran seguir escalando en la pirámide lo mas alto posible. En un equipo de Scrum se puede progresar, y seguir avanzando escalones de la pirámide.

En un equipo, si se les deja ser como niños, tener ilusiones, poder gestionar y solucionar problemas, ayudarles y estimular la participación global, por encima de una competición individual, al final se consigue que los miembros del equipo, alcances los siguientes niveles sin necesidad de hundir o desprestigiar a otros compañeros de trabajos.

Trabajando en equipos autogestionados las personas alcanzan: La afiliación, el reconocimiento y la autorealización.

El principal valor que tiene que tener un equipo es ser como un niño: Tener la mente abierta todo, poner ilusión en lo que hace, no mentir y sobre todo, disfrutar mucho de los que se está haciendo, compartir los éxitos y fracasos entre todos y ser feliz.

Es muy raro no ver a un niño feliz cuando juega a algún deporte con amigos en un equipo. En caso de no serlo, hay que educarle a pensar en el equipo por encima del egoísmo personal.

El Scrum Master tiene un rol muy importante dentro del equipo, y no solo por el “El nombre, las funciones y la  responsabilidad”, que eso viene implícito, si no por que debe de poseer alguna características personales especiales.

El Scrum Master necesita ser un referente dentro del equipo, un compañero especial, para ello debe ser y parecer un líder. Un líder que sepa dirigir al equipo, transmitir confianza, seguridad y valores de sacrificio por el equipo.

El Scrum Master debe poseer el don de la empatía, saber estar a la altura de cada uno de sus miembros, poder armonizar y canalizar la energía individual para que todos vayan al mismo compás, y se produzca un beneficio general.

El Scrum Master además debe ser sociable.

La recomendaciones sobre que personas del equipo deben asumir el papel de Scrum Mater, varían según las distintas corrientes de opinión:

a) Hay una corriente que aboga por que este rol sea rotatorio entre todos los miembros del equipo, lo que conlleva, a que cada uno vaya creciendo en las cualidades antes comentadas cuando tenga que meterse en el papel del Scrum Master.

b) Existe otra que opina que este papel debe desempeñarlo la persona que tenga estas cualidades, dado que conseguirá aumentar la productividad y felicidad del equipo. Con esto se busca el objetivo de no obligar a miembros del equipo a ejercer una rol para el cual no están capacitados.

La recomendación es que cada uno elija la opción que considere mejor para su equipo. No existe una verdadera.

Una de las mayores críticas que recibe Scrum es la carencia de una documentación exhaustiva, una documentación, que según estos mismos argumentos, ayuda a seguir el plan y a que se cumpla exactamente.

En este aspecto tienen toda la razón, Scrum no esta acompañado de una exhaustiva documentación, como dice uno de los principios del manifiesto ágil: “El software que funciona, por encima de la documentación exhaustiva”.

Scrum no adivina el futuro lejano, ni el intermedio, como mucho te ayuda a tener una visión general de como quiere llegar a ese futuro. Scrum te ayuda a ir dando pasitos hasta llegar a él, pero no sabe que ocurrirá en el futuro .

En realidad nadie sabe que ocurrirá en un futuro lejano, cualquier proyecto que tenga de tiempo de trabajo mas de un año tiene una gran incertidumbre, por lo que querer averiguar el futuro con una documentación exhaustiva, es como jugar a las cartas de tarot, por eso Scrum decide aprovechar el tiempo que se invierte en generar esta documentación en otros menesteres, como por ejemplo comenzar ya el camino, el trabajo, que ya veremos donde estaremos dentro de unos meses.

Lo que es una crítica con argumento, en verdad se convierte en una herramienta que no sirve para predecir el futuro, si no todos seríamos visionarios y sabríamos adivinar el futuro.

Los estudios demuestran que un 64% de las funcionalidades implementadas en proyectos con una documentación exhaustiva no se usan, y que solo un 16% de los proyectos se completa con éxito. Estas cifras demuestran que la disposición de una documentación grande no garantiza adivinar mejor el futuro.

La recomendación es preparar de forma sencilla una hoja de ruta con las ideas básicas que se quieren alcanzar priorizadas por importancia y comenzar a caminar. Cuando se vayan cumpliendo etapas ya se volverá a pensar sobre nuevas necesidades e incluso añadir la documentación necesaria para su buena ejecución si hace falta.