Este documento describe cómo las metodologías ágiles enfatizan la colaboración con los clientes y usuarios, pero en la práctica a veces es difícil lograr su involucramiento completo. Sugiere que es importante hablar el mismo idioma, compartir la estrategia del proyecto, y promover la conversación continua para que el equipo de desarrollo y los stakeholders se vean como un solo equipo trabajando hacia el mismo objetivo. También propone que los proyectos ágiles pueden usarse como una herramienta para promover un cambio de mentalidad

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

2. 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?

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

4. 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

5. ¿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

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

7. Revisemos un poco...
Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software
Development,9(8), 28-35.
● Individuos e interacciones > Procesos y herramientas
○ Interacciones entre individuos
○ Interacciones entre equipos
● Software en funcionamiento > documentación extensiva
○ Entrega de documentación útil: Suficiente y necesaria
● Colaboración con el cliente > negociación contractual
○ Interactuar como miembros del mismo equipo
● Respuesta ante el cambio > seguir un plan
○ Entender los cambios para responder de la mejor manera
○ Entregar valor
○ Negociar
7

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

9. ¡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 ágiles
● Queremos 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 veloz
● No contemplamos los casos “raros”
● “Ellos” no saben lo que quieren y
“nosotros” no entendemos por qué lo
quieren
Expectativa Realidad

10. ¡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

11. ¡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

12. “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

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

14. 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ácticos
○ Taller, mesa de trabajo sobre las particularidades de nuestra
metodología para los stakeholders
○ Taller, 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

15. 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ácticos
○ Puntualidad, ¡Por favor!
○ Reuniones periódicas sobre el avance del proyecto
○ Priorización conjunta
○ Gamification?

16. 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ón
● Sesiones de priorización
● Feedback periódico y constructivo
16
● Consejos prácticos
○ Seamos flexibles, pero asertivos
○ No subestimar las conversaciones informales
○ Las discusiones deben llegar a acuerdos.
○ Evitemos frases generalizadoras de estilo “Como todos
sabemos...”

17. 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ácticos
○ En las reuniones, procurar que el equipo se mezcle
○ Reconocer y recompensar los logros del equipo
○ Mostrar las ventajas de tener un equipo heterogéneo y
multidisciplinario
○ Compartir las sesiones de estimación
○ Fomentar la participación del equipo de desarrollo en sesiones de
feedback, retrospectivas, mesas de trabajo

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

19. 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ón
○ Ofrece al cliente una perspectiva
diferente de sus propias necesidades
● Cambio gradual
○ Es más fácil de manejar y digerir
○ Genera menos resistencia

20. Canales de comunicación
Formal Informal
Relación
Negativa Positiva
Disponibilidad
Irregular Continua
Participación
Reactiva Proactiva
Interacción
Facilitada Activa
Ambler, Scott. Active Stakeholder Participation: An Agile Best Practice. http:
//agilemodeling.com/essays/activeStakeholderParticipation.htm
El legado de nuestros proyectos

21. 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

22. ¡GRACIAS!
María José Ormaza
mjormaza@thoughtworks.com
@mjormy