La presente ponencia busca mostrar la importancia del trabajo conjunto de equipos clientes y equipo de desarrollo para la construcción de software, fomentar el involucramiento de los equipos y mostrar técnicas para obtener el mayor provecho de las prácticas ágiles que involucran a clientes y usuarios como parte del proceso de desarrollo.

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