Domingo, 14 Enero 2018 21:11

La demo en equipos que no desarrollan un producto

Escrito por
Valora este artículo
(1 Voto)

Las metodologías ágiles están de moda... sobre esto no hay duda. De hecho, distintas empresas están buscando transformar su modo de trabajar usando estas metodologías, a veces por motivos que las mismas desconocen.

En estos casos, Scrum suele ser la solución elegida ya que combina la posibilidad de cambiar la visión del equipo desde el producto hacia la necesidad del negocio, al mismo tiempo que otorga al nivel ejecutivo esa sensación de previsión -generalmente falsa- a la que estaban acostumbrados con los procesos anteriores.

En mi experiencia, cuando se trabaja con la provisión de un servicio y no con el desarrollo de un producto, el ritual que presenta más desafíos es el de la demo; probablemente porque se tiene la percepción de que se está realizando un ritual vacío... y esta sensación puede sabotear la transformación a agile de equipos o incluso de organizaciones enteras.

Esto representa un desafío: ¿Cómo hacemos para que el equipo vea el sentido de realizar la demo en aquellos ambientes donde no están trabajando sobre un producto sino sobre un servicio?

En este artículo intentaré aportar elementos para una respuesta...

 

Ante todo, para que cualquier demo tenga sentido, es necesario que exista la percepción de producto. Sin esta percepción, una demostración del avance no tiene sentido.

Probablemente el mejor modo de transmitir esta percepción de desarrollo de producto, es mediante un plan de releases. Por supuesto, para poder realizar ésto, es necesario que el product owner sea realmente un "dueño del producto". En un artículo anterior ya mencioné el riesgo que comporta tener un dueño del producto que no sea realmente el "dueño" (o sea que no tenga poder de decisión sobre el mismo).

En este artículo, en cambio, hablo de los equipos que tienen un dueño del producto con poder de decisión... pero "sin un producto" del cual ser dueño.

Definición de nuestro producto

Antes que nada, aclaremos que incluso si nuestro equipo está focalizado en proveer un servicio, podemos siempre hablar de un producto... solo que quizás no lo sabemos, porque el producto que proveemos es intangible.

En este caso, el producto que estamos proveyendo es "la provisión del servicio" en sí misma.

Y como todo producto, podemos especificar las características que el mismo tendrá en los distintos releases, del mismo modo como lo haríamos en el caso de un producto tangible.

Un ejemplo de funcionalidades incluidas en un release puede ser la implementación de integración continua... o de deploy continuo... o de documentación..

Por el contrario, la implementación de standares en la provisión del servicio (como por ejemplo ITIL) no serían historias desde este punto de vista ya que si bien es obvio que muchas de las funcionalidades de nuestro producto sean elegidas porque queremos adecuar el servicio a esos standares, también es cierto que las historias del tipo "adecuar el servicio al standard X" no ayudan a que el equipo obtenga la visión de producto que se busca.

Historias de producto e historias de servicio

De este modo, durante el sprint, probablemente el equipo tenga por lo menos dos tipos de historia:

  • de construcción de producto
  • de provisión de servicio

Hay que tener en cuenta también que la construcción de este "producto" ocupará solo un porcentaje del tiempo y esfuerzo del equipo, ya que el resto del tiempo (generalmente el mayor porcentaje del tiempo) estará dedicado a proveer el servicio... y debido a esta situación, probablemente durante la demo se demuestren más historias de provisión de servicio que de construcción del producto.

Pero también es cierto que las historias de construcción del producto serán las que darán más sentido a la demo, y por lo tanto es importante que el scrum master se asegure que dos condiciones sean cumplidas:

  • Que todos los miembros del equipo participen en al menos una de las historias de construcción del producto
  • Que estas historias tengan más peso relativo en la ceremonia de demostración

¿Y la retrospectiva?

Este cambio de enfoque puede provocar que temas que en otros equipos generalmente se tratarían en la retrospectiva sean tratados en cambio en la demo... entonces surge la pregunta lógica: ¿qué temas se tratarían en la retrospectiva?.

La solución que me ha dado más resultados en estos casos, fue tratar en la retrospectiva aquellas situaciones que afectaban sobre todo a las historias de provisión de servicio.

Esto tenía la ventaja de que, al ser las historias que requerán la mayor cantidad de recursos del equipo, eran donde surgían las oportunidades de mejora principales. Y por otro lado, las disfuncionalidades de los equipos suelen surgir en todas las historias, sin importar el modo como las clasifiquemos.

Probablemente este enfoque no sea la solución ideal, pero es la que más resultados me ha dado en este tipo de situaciones hasta el momento.

 

Leer 70 veces Modificado por última vez en Martes, 16 Enero 2018 07:00
elScrumMaster

Soy el creador y autor de este sitio, donde comparto mis intuiciones, conocimientos y descubrimientos a lo largo de mi vida.

Principalmente orientado a mis experiencias laborales.

Soy siempre yo, tres en uno: elCoach, elScrumamaster y elDba... y por supuesto, aunque no tenga perfil en el sitio, soy también:

  • elTrainer
  • elDesarrollador
  • elConferencista
  • .... y próximamente elAutor

PD: Si te interesa el idioma italiano, acá podés encontrar mis lecciones: https://tinycards.duolingo.com/profile

https://www.linkedin.com/in/pabloagil/
Volver arriba