23
CLIENTES Y USUARIOS: DE ENEMIGOS A ALIADOS Poniendo el manifiesto Ágil en práctica María José Ormaza ABRIL 2015

Clientes y usuarios: de enemigos a aliados

Embed Size (px)

Citation preview

CLIENTES Y USUARIOS:DE ENEMIGOS A ALIADOS

Poniendo el manifiesto Ágil en práctica

María José Ormaza

ABRIL 2015

AGENDA

INTRO ¿Qué dice el manifiesto

Ágil?

¿Qué dice la teoría y qué pasa en la práctica?

¿Cómo lograr el involucramiento

?

¿Por qué es importante hablar de algo tan obvio?

El agilismo como

herramienta de cambio

Revisemos el manifiesto Ágil y entendamos su enfoque en el elemento humano.

En el hermoso mundo de la teoría, todo marcha sobre ruedas. No siempre en la práctica sucede lo mismo.

La relación con los clientes / usuarios se construye día a día. ¿Cómo podemos hacerlo mejor?

¿Cómo usar las metodologías ágiles para promover el cambio?

Introducción¿Por qué hablar de “ellos”?

La necesidad de tener stakeholders comprometidos

Cockburn, A., & Highsmith, J. (2001). Agile software development: The people factor. Computer, 34(11), 131-133.

Es imposible entender un problema ajeno si no te lo cuentan

Escenarios imprevistos: Si lo puedes imaginar, puede pasar.

Cuanto más entendamos las necesidades (y los cambios), mejor podremos solucionarlas

Cuando el equipo se integra, la colaboración fluye naturalmente

El objetivo no es construir un “sistema”, sino construir una SOLUCIÓN

4

¿Por qué no siempre sucede?

Cohn, M. and Ford, D., 2003. Introducing an agile process to an organization. Computer 36 (6), 74–78.Nerur, S., Mahapatra, R.K., Mangalaraj, G., 2005. Challenges of migrating to agile methodologies. Communications of the ACM 48 (5), 72–78.

Las metodologías tradicionales no fomentan la colaboración a lo largo de los proyectos

La documentación abruma a los stakeholders

Los equipos de desarrollo intentan que el cliente entienda su idioma en lugar de entender al cliente

Los clientes pierden el interés cuando los proyectos son largos y no se ve ningún resultado

5

¿Qué dice el manifiesto Ágil?Y qué significa eso en términos de la relación con los clientes y usuarios.

Revisemos un poco...

Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development,9(8), 28-35.

Individuos e interacciones > Procesos y herramientasInteracciones entre individuosInteracciones entre equipos

Software en funcionamiento > documentación extensivaEntrega de documentación útil: Suficiente y necesaria

Colaboración con el cliente > negociación contractualInteractuar como miembros del mismo equipo

Respuesta ante el cambio > seguir un planEntender los cambios para responder de la mejor maneraEntregar valorNegociar

7

¿Qué dice la teoría... Y qué pasa en la práctica?

¡No nos entendemos!

Racheva, Z., Daneva, M., Sikkel, K., Herrmann, A., & Wieringa, R. (2010, September). Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study. In RE (pp. 147-156).

Queremos hablar en los mismos términos

El proyecto se terminará rápido, muy rápido

Queremos stakeholders ágilesQueremos mejorar sus procesos y

hacerlos más eficientes

9

Los stakeholders no entienden nuestra metodología y el equipo de desarrollo no entiende el negocio

Ágil no implica velozNo contemplamos los casos “raros”“Ellos” no saben lo que quieren y “nosotros” no entendemos por qué lo quieren

Expectativa Realidad

¡Involucremos a todos! ¿Quiénes son todos?

Racheva, Z., Daneva, M., Sikkel, K., Herrmann, A., & Wieringa, R. (2010, September). Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study. In RE (pp. 147-156).

10

Todos los stakeholders estarán involucrados

Tendremos que cubrir las aristas necesarias para construir las funcionalidades necesarias

Visión global, involucramiento incremental

Hay stakeholders importantes que no están interesados

Los interesados en cada arista de negocio tienen diferentes prioridades

Todos quieren que su parte se construya primero, a más detalle, más rápido, con más recursos...

Expectativa Realidad

¡No hay tiempo!

Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. Software, ieee, 22(5), 30-39.

11

Los stakeholders estarán prestos a asistir a las sesiones de priorización, análisis, firma de historias

Se encontrará el tiempo estratégico en que el equipo de desarrollo se involucre en el negocio

Los stakeholders suelen tener un tiempo limitado. Muy limitado.

Cuando las personas idóneas no pueden asistir, otras personas menos adecuadas las reemplazan

El tiempo del equipo de desarrollo se puede ver segmentado para ajustarse al tiempo del negocio

Expectativa Realidad

“Siempre hemos trabajado así”

12

Los stakeholders aprenderán de nosotros y nosotros de ellos

Será fácil para ellos entender nuestros términos porque son menos técnicos que en las metodologías tradicionales

¿MVP? ¿Puntos? ¿Sprints? ¿Iteraciones? ¿Velocidad?¿Burn.. what?¿Cómo que no sabemos cuántos días y horas tomará terminar el proyecto?

Expectativa Realidad

¿Cómo lograr el involucramiento?Logremos este objetivo en el día a día.

Hablemos el mismo idioma

Racheva, Z., Daneva, M., Sikkel, K., Herrmann, A., & Wieringa, R. (2010, September). Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study. In RE (pp. 147-156).

Es VITAL introducir la metodología en las fases más tempranas del proyecto

El equipo de desarrollo debe tener una visión holística de los problemas a resolver

14

Consejos prácticosTaller, mesa de trabajo sobre las particularidades de

nuestra metodología para los stakeholdersTaller, mesa de trabajo sobre las particularidades del

negocio para el equipo de desarrollo¿Aún así no nos entendemos? Cambiemos la estrategia e

intentémoslo nuevamente

Compartamos la estrategia

Dorairaj, S., Noble, J., & Malik, P. (2010). Understanding the importance of trust in distributed Agile projects: A practical perspective. In Agile Processes in Software Engineering and Extreme Programming (pp. 172-177). Springer Berlin Heidelberg.

No dejemos de hablar nuestro idioma, pero entendamos también el suyo

Ambas partes del equipo deben conocer qué y por qué se hace

15

Consejos prácticosPuntualidad, ¡Por favor!Reuniones periódicas sobre el avance del proyectoPriorización conjuntaGamification?

Promovamos la conversación

Ambler, Scott. Active Stakeholder Participation: An Agile Best Practice. http://agilemodeling.com/essays/activeStakeholderParticipation.htm

Saquemos el mayor provecho de la incepciónSesiones de priorizaciónFeedback periódico y constructivo

16

Consejos prácticosSeamos flexibles, pero asertivosNo subestimar las conversaciones informalesLas discusiones deben llegar a acuerdos.Evitemos frases generalizadoras de estilo “Como todos

sabemos...”

No somos Nosotros VS. Ellos, somos Nosotros Y Ellos

El equipo debe verse como un todo que persigue el mismo objetivo

Motivar la participación conjunta del equipo de desarrollo con el cliente

17

Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. Software, ieee, 22(5), 30-39.

Consejos prácticosEn las reuniones, procurar que el equipo se mezcleReconocer y recompensar los logros del equipoMostrar las ventajas de tener un equipo heterogéneo y

multidisciplinarioCompartir las sesiones de estimaciónFomentar la participación del equipo de desarrollo en sesiones de

feedback, retrospectivas, mesas de trabajo

El Agilismo como herramienta de cambio“Hacer la misma cosa una y otra vez; y esperar resultados distintos es locura.”

A. Einstein

El legado de nuestros proyectos

Adler, P. S., & Shenhar, A. (1990). Adapting your technological base: The organizational challenge. Sloan Management Review, (32)1, 25–37.Boehm, B., Turner, R., 2005. Management challenges to implement agile processes in traditional development organizations. IEEE Software 22 (5), 30–39. 19

Cambio de mentalidad sobre el uso de la tecnología

PriorizaciónOfrece al cliente una perspectiva diferente de sus propias necesidades

Cambio gradual Es más fácil de manejar y digerirGenera menos resistencia

Canales de comunicaciónFormal Informal

RelaciónNegativa Positiva

DisponibilidadIrregular Continua

ParticipaciónReactiva Proactiva

InteracciónFacilitada Activa

Ambler, Scott. Active Stakeholder Participation: An Agile Best Practice. http://agilemodeling.com/essays/activeStakeholderParticipation.htm

El legado de nuestros proyectos

Momentos claves

Cada contacto con el cliente es una oportunidad para fomentar su participación (en el contexto adecuado)

Aprovechar iteraciones productivas para estrechar relaciones con los clientes

La mejor forma de involucrar a los clientes y usuarios dependerá de la naturaleza del proyecto, el equipo humano, las restricciones temporales, ...

No construyamos para los clientes. Construyamos juntos.

21

¡GRACIAS!

María José [email protected]

@mjormy