Durante este semestre uno de mis sueños se volvió realidad: me dieron la oportunidad de llevar un proyecto como Product Owner. Anteriormente me había certificado como Scrum Master, pero nunca he tenido la oportunidad real de ponerlo en práctica, así que empezar como Product Owner me parecía una manera experimentar con el marco de trabajo de Scrum.
Pero es más fácil leerlo que hacerlo. Así que, sin enrollarse más…
1. No seas Product Owner y Scrum Master
Esto es algo que siempre veo, en un equipo de “Scrum” falta el Scrum Master o esa tarea está asignada al Product Owner. Es importante no convertirte en el Scrum Master del proyecto por más detallista, perfeccionista o meticuloso que seas. Aprende a confiar en tu equipo.
“Aprende a confiar en tu equipo.”
Esto es lo que me pasó a mi en mi primer proyecto, a pesar de que existía un scrum master, este no participaba ni guiaba en la reuniones, y solo tenía contacto con uno de los desarrolladores.
El punto bueno: planeábamos el sprint juntos.
2. Pon atención a todas las partes del proyecto
Esto puede parecer obvio, pero es importante que aunque no sepas de un lenguaje de programación como para sentarte a programar tu, sí es necesario que conozcas el alcance de los recursos disponibles en el negocio y en tu equipo.
Si en tu equipo está incluido el UX, entonces debes estar preparado para trabajar con “sprints desincronizados”, o sea, el equipo de UX debe trabajar un sprint antes en lo que el equipo de desarrollo vaya a trabajar en el siguiente.
“Y debes entender también su proceso. Si no lo sabes, pregunta.”
En mi caso, también formaba parte del equipo de UX, así que.. otra cosa: No seas UX Lead/UX Reseach/Product Owner/Scrum Master.
3. Piensa a futuro
¿Cómo esta decisión puede influir en los futuros sprints? O incluso, ¿cómo puede influir en nuevas características de tu producto que puedan surgir? Si bien, es responsabilidad del equipo de desarrollo trabajar siempre bajo las mejores prácticas, tú eres el que tiene la visión del negocio (o el cliente) y tienes que adelantarte al funcionamiento de la tecnología.
Realizar un desarrollo escalable, tener una lista de características que podrían volverse importantes, un roadmap, etc… pueden volverse cuestiones importantes al momento de tomar una decisión en el presente.
¿Debo hacer que esta parte sea estática desde el front-end? ¿O sea llamada desde la base de datos? Si no tienes ese conocimiento, pregunta.
4. No asumas nada y escribe bien las tareas
Quizá consideres que como tu ya conoces el producto los demás te entienden a la perfección, pero no lo asumas. Tú como product owner deberás mantener el backlog del equipo, escribir las historias de usuario (junto con el scrum master) y deberás detallarlas muy bien.
Esto incluye la descripción de la historia, el contexto del usuario, la solución y los criterios de aceptación que esa tarea debe tener para que sea aprobada. No te limites a crear historias y luego pegar el título en la descripción, comunica bien a tu equipo cuál es la historia.
En la reunión de pre-planning asegúrate que hayas explicado bien la historia y que todo el equipo sepa sobre qué va a trabajar; de esta manera es más sencillo para ellos crear las tareas necesarias y puntuar bien las historias.
5. Como product owner no olvides el objetivo del sprint
Entre tantas tareas y cosas que aprobar, es fácil que se pierda el objetivo del sprint. Quizá pienses que el objetivo solamente es llegar a cerrar todas las tareas, pero es más que eso, hay que considerar agrupar las tareas para que cumplan un objetivo: Dejar la base de una funcionalidad, poner a prueba un prototipo, arreglar bugs que hayan ido saliendo (aunque esto no debería de pasar).
Por eso, que no se te pase tener un objetivo del sprint y ver si realmente si se cumple, si le dio valor al proyecto o solo fueron una serie de tareas a las que darles “check”.
6. Pregunta, pregunta y vuelve a preguntar
Si no entiendes algo: pregunta. Es importante que entiendas porqué una cosa y otra es cómo es, porqué la base de datos funciona así, porque es necesaria una prueba de usabilidad, porque debes enviar ese correo a las tres de las mañana en miércoles pero solo cuando es luna llena.
Esto te ayudará a entender y justificar frente al cliente las decisiones que se hayan tomado en el transcurso del sprint, y además, te ayudará a distinguir cuando una petición no es cumplida porque hay problemas más atrás (suele pasar, deuda técnica) o porque a alguien no le caes bien (también, pasa).
Genera transparencia en tu equipo, pero hazlo de manera amable no con ganas de exponer a nadie, aunque creas que tienes toda la razón (no seas arrogante).
Y hasta aquí la primera parte. Todavía tengo muchas más cosas que decir, porque cometí muchos errores en ese primer proyecto, pero también aprendí de ellos.
Ahora cuéntame, ¿qué errores has cometido tú?