viernes, 14 de julio de 2017

¿Hay nombres para la disfunciones de los roles de Scrum?

Good Scrum Master
Cortesía de Pixabay
A lo largo de mi experiencia en diferentes compañías, charlas con compañeros coaches ágiles y trainers y recorriendo algunos blogs la web, he recopilado unos pocos términos disfuncionales para el Scrum Master y el Propietario del Producto que me han hecho mucha gracia. En especial el post "The Scrum Master as the Change Leader" de Barry Overeem menciona algunas disfunciones de Scrum Master que me han hecho reír mucho. :-D

Good Scrum Master: el Buen Scrum Master que solo se dedica a ser Scrum Master. Se dedica de forma efectiva a ser el facilitador de todo el proceso, cuida que se cumplan las reglas de Scrum, se responsabiliza de que haya mejora continua, facilita las reuniones, forma y acompaña al equipo de desarrollo y al Propietario del Producto en el aprendizaje del marco, gestiona la resolución de impedimentos, motiva la colaboración desde los valores ágiles y participa e impulsa el cambio cultural de forma gradual en la organización.

Ugly Scrum Master: Un Scrum Master Feo es el que es a la vez miembro del equipo de desarrollo y Scrum Master. Usualmente se habla de disfunción porque el foco de ambos roles es otro, tecnología y coaching son cosas muy distintas, es difícil entrenar bien a un Scrum Master y no debemos menosvalorar la importancia del rol ni los desafíos a los que se enfrenta. La persona que hiciera ambos roles puede entrar en conflicto cuando producto/proyecto y proceso choquen, debiéndose inclinar por uno o por otro. Un desarrollador va a dar prioridad al producto ya que en primera instancia es constructor de producto.

Bad Scrum Master: Un Mal Scrum Master es a la vez Propietario del Producto y Scrum Master; un Scroduct Ownster como lo bautiza Atlassian en su serie de "The wrong way to do Agile". La Scrum Guide prohíbe explicitamente esta combinación, el Propietario del Producto busca el mejor producto posible, el Scrum Master el mejor equipo posible y si combinamos ambos puede convertir a la persona en un jefe de proyecto despótico.

Executive Scrum Master: Un Scrum Master Ejecutivo es un ex jefe de proyecto que aprendió a planificar en cascada y a ejecutar los planes por fases, entiende Scrum pero intenta llenar las supuestas carencias que detecta desde su perspectiva con sus técnicas de planificación. Tiene el foco fuertemente anclado en el cumplimiento de del sprint, en ver como el proceso toma forma y se asienta, y no es consciente de la parte esencial referente a los aspectos humanos, en desarrollar a los miembros del equipo y proporcionarles un entorno en el que aprendan de forma continua.

Scrum Police Officer: El Oficial de Policía Scrum es un Scrum Master que probablemente forme parte de una oficina de proyectos y que sigue rigurosamente las reglas de Scrum o las reglas de la metodología adaptada por la organización. Lo hace con cero empatia por la situación y contexto del equipo, simplemente si este no actúa de acuerdo con las reglas está mal hecho, independientemente de si aplican o aportan al equipo. Las acciones de mejora de las retrospectivas que no "encajan" simplemente son ignoradas con la afirmación que no admite duda: "somos así y eso no va a cambiar, ¡somos profesionales!"

Scrum Mother or Father: Scrum Master maternalista o paternalista que cuida de su equipo como si fuera una madre o un padre. Aplica las normas de autoridad o protección tradicionalmente asignadas a la madre o al padre de familia al ámbito laboral, en este caso al equipo de desarrollo. La consecuencia conlleva una reducción de la libertad y autonomía del equipo, siempre dependerán de este tipo de Scrum Master. A veces un Scrum Master ha de apartarse para que los equipos cometan sus propios errores y aprendan de ello.

Scribe Scrum Master: El Scrum Master Escribano que toma notas de todos las reuniones de Scrum, documenta exhaustivamente las planificaciones de sprint, las reuniones diarias, los refinamientos, las revisiones de sprint y las retrospectivas. Probablemente sus superiores miden su "eficacia" por el número de palabras de sus informes.

Team Boss Scrum Master: El Scrum Master/Jefe de Equipo, o como se suele llamar a si mismo "líder al servicio". Es el jefe, quien ficha y despide, el que decide quien merece un aumento de sueldo y quien no, el que premia y penaliza, el que se encarga de mantener las buenas costumbres en el equipo como por ejemplo hacer dos horas extra al día como buenos profesionales, el que decide quién está más capacitado para cada una de las tareas del sprint...

Secretary Scrum Master: El Scrum Master Secretario que planifica todas las reuniones de Scrum y las agendas en los calendarios de todos los miembros del equipo, Propietario del Producto e interesados... y otros jefecillos, gerentes y hierbas varias. También es responsable de mantener los calendarios de los equipos actualizados con días festivos y vacaciones.

Chairman Scrum Master: El Scrum Master Presidente de la reunión diaria, al que todas las mañanas el equipo proporciona una actualización de la situación actual. Así el Scrum Master obtiene la información necesaria para escribir el informe de situación diaria a sus superiores, informe estratégico para el buenhacer de la compañía. :-P

The Admin Scrum Master: El Scrum Master Administrador, si el equipo necesita un cambio en JIRA, Redmine, CCM, iceScrum o cualquier otra herramienta el Scrum Master es tu amigo, él conoce todos los flujos de trabajo de memoria y haciendo honor a su rol es el experto en herramientas.

Scrum Mártir: Aquel Scrum Master que es ferviente defensor de la Agilidad, impulsa mejoras en los equipos pero nadie se percata. Suelen darse cuenta de su valía una vez que han prescindido de él.

Good Product Owner
Cortesía de Pixabay
Good Product Owner: un Buen Propietario del Producto es aquél que toma toda la responsabilidad sobre el producto a la vez que tiene toda la autoridad sobre el mismo. Es alguien con una fuerte conocimiento del mercado, que siente pasión por el producto y es un verdadero líder al servicio que se integra en el equipo, está disponible, lo apoya y asiste a todas las reuniones. Tiene una visión de lo que desea construir, gestiona su propio presupuesto para decidir qué construir y es capaz de transmitir la visión al equipo de desarrollo, al inicio a través de la visión del producto, y a lo largo de los sprints a través de la pila de producto. Un buen Propietario del Producto motiva al equipo con una meta clara y elevada.

Phoenix Product Owner: un Propietario del Producto Fénix es aquél que desaparece al finalizar la planificación de sprint y no reaparece hasta dos semanas después en el inicio de la revisión de sprint. Puede tener una pila de producto bien preparada, con elementos bien trabajados y lo puede estar haciendo de sprint en sprint, su carencia reside en que no está disponible para el equipo durante el sprint y por tanto no resuelve dudas ni da feedback en caliente, minimizando de esta manera las posibilidades del marco de Scrum.

Scribe Product Owner: El Propietario del Producto Escriba suele ser un Business Analyst o un ingeniero de requerimientos de una empresa que está empezando con Scrum y que usualmente todavía no ha desarrollado su cultura ágil. La empresa describe las funciones del rol como alguien que recoge deseos y necesidades de los interesados y los escribe de un lenguaje entendible por el equipo de desarrollo a través de historias de usuario. También se le considera gestor de la pila de producto con mínima o nula autoridad sobre las historias, esta suele residir en una PMO o un SteerCO.

Proxy Product Owner: El Propietario del Producto Proxy es un corre-ve-y-dile que no tiene conocimiento profundo del negocio ni poder de decisión. Algunas compañías distribuyen el rol en dos, un gerente del producto, o product manager, y un "Propietario del Producto" Proxy. El gerente del producto se encarga de los aspectos de comercialización y gestión del producto, posee la visión, se relaciona hacia negocio y por tanto se mantiene en contacto con el mercado. El proxy tiene funciones de gestor de proyecto para con la pila de producto y la de interfasar con el equipo de desarrollo, por tanto se difumina la responsabilidad. La autoridad de este tipo de Propietario del Producto es muy limitada, tiene que pedir aprobación para introducir cambio, para cambiar prioridades, para cambiar la hoja de ruta... con lo se producen retrasos y otros desperdicios como cuellos de botella en la toma de decisiones y una disminución de la productividad y la moral.

Business Representative Product Owner: El Propietario del Producto Representativo de Negocio suele ser un senior o experto de negocio de la empresa que conoce el contexto de negocio, el mercado y a las necesidades y deseos de clientes y usuarios. También puede ser alguien del departamento de IT, un Manager de IT o un arquitecto con un alto conocimiento técnico del producto. Este tipo de Propietario del Producto suele ser responsable de parte del producto y tiene toda autoridad sobre la pila de producto y sobre lo que construye el equipo de desarrollo, pero no tiene un presupuesto propio, los cambios que gestiona en su pila están limitados al presupuesto que la PMO o el SteerCO le han asignado en forma de proyectos a ejecutar u objetivos a cumplir.

Sponsor Product Owner: El Propietario del Producto Espónsor es muy similar al representativo de negocio, la diferencia principal está en que este tiene su propio presupuesto, sobre el que dispone y decide libremente, así como la autoridad sobre sus propios objetivos. Por ejemplo, si el producto tuviera un gran éxito, este tipo de Propietario del Producto podría decidir escalar contratando nuevos equipos para acelerar el desarrollo, de la misma manera que podría desacelerar, siempre con el fin de maximizar el ROI del producto.

Pobre Owner: Aquél Propietario del Producto responsable de una pila de producto sobre la que no tiene ninguna autoridad; ni sobre el contenido ni la prioridad. Suele ser fruto del maquillado Agile de una empresa, quizá incluso dependa de un jefe de proyecto o un Team Leader... puro Cascágil o Wateragile en acción, jajajaja.  

Mis agradecimientos a Alexandre y a Marcos que han aportado algunas disfunciones resultantes de sus experiencias :-)

No hay comentarios:

Publicar un comentario