miércoles, 31 de julio de 2019

¿Qué hacer con los especialistas en una transformación ágil?

El especialista hace crecer a los demás
Cortesía de Pixabay
La Agilidad literalmente no tiene tiempo para héroes ni para divas. Por un lado los héroes y las divas no suelen ser colaborativas, y por otro, todo el concepto de construcción iterativa a través de ciclos cortos de feedback y aprendizaje continuo no son compatibles con las nociones de heroísmo, héroes y divas no admiten el fracaso. Como equipo ágil, y como empresa ágil, debemos de esperar que muchas de las ideas fallarán y que incluso las historias de usuario no siempre acaben siendo buenas soluciones a la primera.

No importa lo inteligente que sea cada individuo en un equipo o tribu, desbloqueadas las motivaciones intrínsecas lo que importa es que todos los individuos en un entorno ágil sean apasionados, proactivos, creativos y pensadores activos, ante eso un héroe o diva no tiene ninguna posibilidad.

Como especialistas entendemos a personas que tiene un conocimiento profundo en una disciplina en particular. La cuestión es si los especialistas en una empresa a transformar son divas o si entienden que todo expertise, especialmente en TI, caduca a los pocos años. Vivimos en un mundo en el que los analfabetos son aquellos que no desaprenden y aprenden continuamente. Especialistas que vivan y persistan en su torre de marfil no tienen cabida en una empresa ágil.

Especialista como mentor - Cortesía de Pixabay
Los especialistas en una compañía ágil se convierten en mentores, en líderes técnicos, en Chapter Leads por ejemplo, que desarrollan a los demás en su disciplina de expertise. Lo hacen a través de la asesoría, de la transferencia de conocimientoSe convierten en líderes al servicio que se centran en entrenar y ayudar a los miembros del los equipos a crecer en su función, desarrollando así la competencia de estos.

Para generar equipos ágiles de excelencia o hiperproductivos hemos de pivotar cuidadosamente a los especialistas entre diferentes equipos para así difundir el conocimientoEntrenamiento cruzado, pair programming, establecer comunidades de práctica nos permiten mitigar los cuellos de botella que puedan significar los especialistas y crear habilidades tipo T, tanto en los especialistas como en los miembros de los equipos.

jueves, 25 de julio de 2019

¿El Manifiesto Ágil debería de actualizarse?

Tablero con el borrador del Manifiesto Ágil en 2001
cortesía de los autores firmantes del mismo
El Manifiesto Ágil marcó en 2001 un punto de inflexión en la ingeniería de software poniendo el foco en cosas como el valor, las personas, la comunicación efectiva, los ciclos cortos de entrega, los ciclos cortos de feedback y el aprendizaje.

El mundo ha evolucionado desde entonces, muchas compañías han incorporado la Agilidad y han madurado en un mundo que conocemos como VUCA; un mundo digital con sus transformaciones digitales, un mundo distribuido e hiperconectado, con una alta pervasividad del software, en el que es necesario la innovación a todos los niveles, el microaprendizaje continuo y la entrega continua bajo demanda con dependencias crecientes y diseños emergentes.

La evolución del mundo y las compañías requiere una revisión del Manifiesto Ágil. Por ejemplo en 2001 la capacidad de ordenadores y servidores era limitada y por ello el tercer principio dimensiona los sprints entre 2 semanas y 2 meses, cuando hoy en día con los sistemas actuales, hay compañías que en un solo día son capaces de identificar una nueva funcionalidad, construirla y llevarla a producción y hasta medir el uso que hacen de ella los usuarios finales.

En 2011, Kent Beck propuso que incluso un gran manifiesto debería de evolucionar y propuso Beyond Agile Manifestoel que muestro a continuación y podría ser el siguiente paso:
  • Visión y disciplina de equipo, por encima de individuos y su interacción, (por encima de los procesos y las herramientas)
  • Aprendizaje validado, por encima de software que funciona (por encima de la documentación exhaustiva)
  • Descubrimiento con el cliente, por encima de la colaboración con el cliente (por encima de la negociación contractual)
  • Iniciar el cambio, por encima la respuesta al cambio (por encima del seguimiento de un plan)
Visión y disciplina de equipo: efectivamente hoy en día el foco está en la formación de equipos de excelencia u hiperproductivos, equipos que tratamos como una sola unidad y que con una misión clara y un mínimo de restricciones construyen sistemas de forma autoorganizada.

Aprendizaje validado: hemos aprendido que cualquier requisito, funcionalidad, historia de usuario no deja de ser una hipótesis, pensamos que nos van a dar beneficios, pero no lo sabemos hasta que las validemos. Para ello utilizamos el ciclo Lean UX que se basa en el ciclo de feedback construir-medir-aprender. A través del mismo generamos conocimiento validado sobre un producto, extrayendo conclusiones valiosas de los usuarios que ya usan o vayan a utilizar ese producto.

Descubrimiento con el cliente: cada vez más lo que tiene futuro son los partnerships y alejarnos del concepto de cliente-proveedor. Colaboramos comos dos partners, el de negocio (ex-cliente) y el tecnológico (ex-proveedor), con un objetivo de crecimiento mutuo poniendo el foco en maximizar la competitividad de cliente (negocio).

Iniciar el cambio: hoy en día un buen Propietario de Producto interactúa continuamente con sus interesados y usuarios para entender sus necesidades y problemas, y levantar nuevas necesidades para mantener el producto en constante evolución y a la empresa competitiva en ese mundo VUCA. Probablemente si no hay cambios en un producto es que ha llegado a la obsolescencia.

Suscribo la actualización, creo que para el mundo de hoy es lo que lo haría que sea un gran manifiesto. ¡Gracias Kent!

jueves, 11 de julio de 2019

¿Cómo gestionar a los diferentes tipos de interesados?

Una de las responsabilidades de un Propietario del Producto es la relación con los diferentes interesados del proyecto/producto:
  • identificar a los interesados y su nivel de apoyo
  • comunicarse con ellos para entender sus necesidades
  • balancear las diferentes necesidades de los mismos
  • influenciarlos
Para identificar el nivel de apoyo una herramienta muy útil es el siguiente cuadrante de tipos de interesados que clasifica según potencial de cooperación y amenaza:
Cuadrante de tipos de interesados - Savage et al. 1991
Según el tipo de interesado podemos aplicar las siguientes estrategias:

Interesado Marginal (Bajo potencial de amenaza, bajo potencial de cooperación)

Estrategia: monitorearlos
  • Al reconocer que sus intereses son limitados y específicos limitándonos a monitorearlos se evita el desperdicio de esfuerzos
  • Se debe de intentar aumentar su apoyo o rechazar su oposición en las cuestiones en las que sus decisiones sean importantes para ellos
Interesado No Apoyador (Alto potencial de amenaza, bajo potencial de cooperación)

Estrategias:
  • Defensa: reducir las dependencias con los intereses del interesado en el producto
  • Comprometerse: mantenerlo informado y satisfecho de forma continua
Interesado Apoyador (Bajo potencial de amenaza, alto potencial de cooperación)

Estrategia: envolverlos en decisiones relevantes para fomentar el potencial de cooperación
  • Atención constante informándolos e invitándolos a los diferentes eventos
  • Aumentar su participación en el proceso de toma de decisiones sobre el producto
Interesado Ventajas y Desventajas (Alto potencial de amenaza, alto potencial de cooperación)

Estrategia: involucrarlos
  • Colaborar buscando maximizar su cooperación, haciéndoles partícipes en los eventos volviendo más difíciles las posibles oposiciones

viernes, 5 de julio de 2019

¿Qué es más barato, construir una funcionalidad con Scrum o en un proyecto en cascada?

¿Qué es más barato? ¿Cascada? ¿Agile?
cortesía de PixaBay
Es una pregunta habitual en mis acompañamientos y mis cursos. La cuestión en primer lugar es ¿cómo nos miden? Si nos miden por alcance de proyecto cumplido probablemente la forma más barata de desarrollar producto es hacerlo con un proyecto cerrado en cascada... pero si nos miden por el valor de negocio entregado las cosas pueden ser muy distintas.

Sin duda un project manager o jefe de proyecto busca la forma de ejecutar el proyecto "cerrado" de la forma más óptima posible, lo que no es tan evidente es si el resultado de un proyecto cerrado es un buen incremento de valor sobre el producto, me refiero a si el software construido a lo largo de un proyecto es una buena solución a las necesidades de nuestro cliente. En todo caso un jefe de proyecto al optimizar minimiza los costes.

Desarrollar con Scrum significa descubrir de forma iterativa un solución óptima para las necesidades de nuestro cliente. Descubrir significa que para construir una funcionalidad le hemos de dar varias vueltas antes de acertar, y eso sin duda tiene un sobrecoste respecto a si construyeramos la funcionalidad correcta a la primera. Pero claro, una funcionalidad no deja de ser una hipótesis de solución a un problema, no podemos no descubrir, ya que en tal caso probablemente construyamos algo que no sea una buena solución a la necesidad.

Dando respuesta a la pregunta del post, cascada es más barato por funcionalidad, pero para construir la funcionalidad equivocada y construir funcionalidades que no resuelvan necesidades, y por tanto que probablemente nadie vaya a utilizar. Scrum es una forma más cara de construcción de funcionalidades, pero bajo ese marco construimos las funcionalidades correctas, las que dan solución a las necesidades del usuario.

Visto esto, ¿qué es más barato? Dependerá de los objetivos: si el objetivo es incrementar la competitividad de nuestro cliente sin duda lo es Scrum, si el objetivo es cumplir con alcances iniciales de proyectos cerrados, sin duda lo son los proyectos en cascada.