¿Conversamos Agil?

Agile Mammut
Jul 27, 2017 · 3 min read

Un aspecto importante en que los proyectos (agile o waterfall) no salgan adelante, es el poco cuidado y implicación que se les tiene a los requisitos del producto; cuando estamos en pleno desarrollo del producto, el equipo más o menos tiene la idea de lo que el producto tiene que hacer, o no; pero lo que está en la cabeza de un desarrollador, puede diferir a lo que el cliente quiere, o el Product Owner, o el General manager, o el tech leader etc etc … como veis lo que entendemos de una funcionalidad a otra cambia según la cabeza que lo piense; por eso cobra una importante relevancia las 3 C. “Card, Conversation, Confirmation”, estas 3 Cs están muy bien, y todos los que bebemos del mundo ágil, nos conocemos al dedillo lo que significa estas 3Cs; pero ¿Realmente en la práctica esta Conversación tiene lugar?. Me encuentro muchos equipos agiles los cuales hacen “Scrum de pega”, quiero decir, se pone el dashboard, se hace los sprints, ponemos al jefe de proyecto como Scrum Master??? O Product Owner???; en fin este tema lo tratare en otro post; uno de los pitfalls que veo en estos equipos es la Conversation con las user stories, es inexistente.

Y es inexistente, por varios motivos.

· Palabra de Product Owner…Amen: Es cierto que el Product Owner, es quien tiene la última palabra acerca de la user stories; en algunas organizaciones el Product Owner es una transformación del rol del Project Manager, con seniority; dejando que su ego cohíba cualquier tipo de conversación acerca de la historia de usuario.

· Zona de confort del equipo: En la gestión que imperaba con el waterfall, (command & control); el equipo de desarrollo “solo” se preocupaba con cumplir o codificar lo impuesto en los especificaciones, muchas veces dadas escritas por el ser mitológico que es el analista con todas sus variantes (analista funcional, analista “orgánico” WTF, analista-programador…); dejando sin derecho de réplica a los desarrolladores. Al implantar Agile en las organizaciones, no se cambia el mindset del equipo de desarrollo, en el que el equipo espera que la User story contenga toda la información para implementar la funcionalidad; sin tener esa conversación en las user stories. En muchas equipos que han implentado mal llamado Agile, el equipo de desarrollo, no quiere tomar parte de la conversación o no la incita. Puede ser por comodidad, o que la organización no allá realizado la transformación ágil a todos los niveles por lo que no hay Psychological safety.

· Nula existencia del espacio de debate: La transformación ágil con lleva a crear los espacios para debatir ideas, y que cada miembro del equipo se sienta responsable del producto que tiene que sacar, es por eso que el término acuñado “seguridad psicológica o Psychological safety “para tener completamente libertad de expresar ideas en el entorno laboral, este debate o promover este debate en el equipo, poco a poco lleva a adoptar el producto como suyo.

Tal como Gokjo en innumerables post nos relata, la user story, solo nos debe dar pie a empezar a dialogar/conversar acerca de la funcionalidad descrita en la user story, tanto el product owner como los miembros del equipo tienen que ser parte activas de esta conversación, las user stories es un documento vivo y de ahí su potencia, el Scrum Master tiene que forzar (desde su perspectiva de Servant Leader) a que se de esta conversación.

Agile Mammut
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade