Modelo, Metodo y Gestión. ¿Puede una misma persona ejecutar el rol de ScrumMaster y Propietario a la vez?

Continuando la serie de entradas dedicada a los multiroles en Scrum, quiero hacer unas reflexiones sobre la conveniencia, o no, de que el ScrumMaster y el Product Owner sean representados por la misma persona.

Vamos al grano, os dejo con el StoryPost que a fin de cuentas es lo que has venido a leer.

Te encuentras en una situación complicada, estás intentando implantar Scrum en el proyecto y la organización no está dispuesta a poner a una nueva persona que juegue el rol de ScrumMaster, apoyan tu propuesta para mejorar el proyecto y el producto, pero se muestran escépticos, no quieren gastar dinero a priori.<br />Implantalo! - Te dicen. -Si vemos una mejora significativa podemos hacer los cambios que solicitas.
El cliente no puede, o no quiere, aportar una persona para que resuelva el rol de Product Owner. No te niegan su apoyo, pero tampoco pueden descargar esa responsabilidad en una persona de su propia organización. De modo que eres tú quien canaliza el diálogo con los distintos interesados que aportan nuevos funcionalidades al producto. Y nadie por encima de ti, en tu organización quiere/puede asumir el rol. Lo cual significa, que debes ser tú quien asuma el rol de Propietario.
Además, no tienes ningún Jefe de equipo a quién asignarle el Rol de Scrum Master y nadie del equipo de desarrollo quiere asumir esa responsabilidad, es lógico, no tienen la suficiente formación o experiencia para ejecutar el rol. Quizá todo este planteamiento pueda parecer complejo. El lector del blog podría pensar: Vaya, se tienen que alinear los astros para que todo esto suceda!!!. ¡Pues no!. Por desgracia es una situación muy habitual para alguien que quiere implantar Scrum.
Te planteas asumir tú los dos roles, es la única manera de conseguir arrancar con Scrum… Pero ¿es apropiado, conveniente, posible, un error?  Bajo mi punto de vista es absolutamente inapropiado. Vamos a analizarlo desde varios enfoques.
El Product Owner es un rol con mucho peso dentro del grupo Scrum. Es quien tiene el poder sobre el producto. Decide qué se hace, cuándo se hace y puede parar el desarrollo si lo cree oportuno. Es responsable de la validación y/o evaluación de la calidad y avance de los incrementos del producto y con ese San Benito colgado será visto por el equipo de desarrollo como un ‘auditor’ de su trabajo. Por mucho que el Scrum Master trabaje, esa imagen siempre estará ahí.  Pero ¿cómo lo va a hacer si es él mismo quien ejerce los dos roles? Directamente, no puede hacerlo.
En una reunión de Refinamiento del Backlog ¿Cómo va a ser capaz de defender su postura como cliente y como facilitador y coaching?  ¿quién te corregirá cuando, como propietario,  realices acciones inapropiadas para el propio método? ¿serás capaz de establecer un protocolo para que el equipo de desarrollo identifique qué rol juegas cuando estás hablando? Esta última cuestión es importantísima puesto que los miembros del equipo, implícitamente han otorgado unos valores y ámbitos de credibilidad  a cada rol y a cada persona, pero en este caso hay dos roles y sólo una persona…
Definitivamente,  es una mala idea que una misma persona desempeñe los dos roles, aúna demasiadas responsabilidades.  Tranquilo, no es un problema, hay otras soluciones ágiles y siempre puedes crear la tuya propia... es lo que acabamos haciendo todos., y el que diga lo contrario es que no sabe qué es Scrum. Oscar R. Onrubia @OscaRonrubia

Bueno, este es mi punto de vista… puede que no estés de acuerdo y tengas una opinión contraria o cercana, pero con matices. Me encantaría leer tu aportación en los comentarios.

Saludos a todos y muchas gracias por leer el blog.

Oscar R. Onrubia

@OscaRonrubia

Anuncios

9 comentarios sobre “¿Puede una persona ejecutar el rol de Propietario y Scrum Master?

  1. sí. Lo veo igual que tú, Oscar, pero puede haber excepciones que confirmen la regla. Lo apunto, porque yo me veo como una de ellas en el equipo del proyecto Safe Creative.
    Posiblemente no sea frecuente, pero me refiero al caso del equipo de una start-up en el que el emprendedor, es conocedor de scrum.
    Como emprendedor (qué poco me gusta esta palabra) o como fundador, conoce bien la visión y las decisiones de producto, y si es veterano o conocedor de scrum en un equipo de start-up es también una buena opción para estar al tanto de los impedimentos y hacer que scrum funcione (que no es otra la función del scrum master).
    Desde luego, en una empresa con equipos de desarrollo y clientes externos, es mejor lo que tu dices y no hacer prubas de este tipo 😉

    Un saludo!

    1. Hola Juan:
      En primer lugar, gracias por tu aportación.
      Cuando escribía esta entrada estuve valorando la posibilidad de la situación que planteas. Creo que aunque soy novato en estas ágiles lides, me estoy significando como un defensor extremo del método y por ese motivo llego a la conclusión de que no se debe romper esa ‘Triada de responsabilidades’ (mi próxima entrada del blog) que equilibra el método y el proyecto. Las responsabilidades de los roles de Scrum me recuerdan a la división de poderes de Montesquieu, en la que (cito de wikipedia):

      “Para prevenir que una rama del poder se convirtiera en suprema, y para inducirlas a cooperar, los sistemas de gobierno que emplean la separación de poderes se crean típicamente con un sistema de “checks and balances”
      http://es.wikipedia.org/wiki/Separaci%C3%B3n_de_poderes

      Lo que tú propones es viable en grupos con mucha experiencia en Scrum y además funciona. Entonces, si funciona y es viable ¿por qué creo que es inapropiado?…
      La clave está en la última imagen de la entrada, en la que digo “Pero tranquilo, hay otras solucione ágiles que se adaptarán a tus necesidades”. La solución metodológica que se elija, no tiene que ser una validada por la comunidad agilista de nuevo cuño, puede ser una creada ‘Ad hoc’ para dar solución a las necesidades del proyecto y del equipo de trabajo.
      ¿Y cómo es eso? ¿Me puedo crear yo mismo una metodología ágil? Por supuesto, siempre y cuando se ajuste al “Manifiesto por el Desarrollo Ágil de Software”
      http://agilemanifesto.org/iso/es/

      Creo que lo que ocurre cuando alguien hace lo que expones es que está aplicando su propia metodología, en este caso ligeramente variada de la propuesta por Scrum, pero no es Scrum lo que está aplicando, sino más bien una ‘síntesis’ entendida dentro del ‘patrón dialéctico de tesis, antítesis y síntesis’
      http://www.scrummanager.net/bok/index.php?title=Espiral_de_conocimiento

      Saludos y reitero las gracias por tus comentarios.

  2. Hola Oscar.
    Sí así es. conforme se van alcanzando niveles de fluidez altos se pueden ir dejando la pauta académica del marco de Scrum,
    Pero eso no es dejar scrum, sino ir realmente al scrum original. El definido por Nonaka y Takeuchi, que no tiene componentes, artefactos y roles definidos sino principios. El scrum original basado en principios y el conocimiento de quien los aplica es para mi gestión experta, y el scrum basado en la implementación definida y cerrada de los componentes artefactos y roles es más gestión técnica.

    Una aplicación fija y pautada es apropiada para ingeniería concurrente o para aprendizaje de agilidad, pero una aplicación basada en los principios de campos de scrum de Nonaka y Takeuchi es una aplicación de scrum para gestión basada en el conocimiento de las personas más que en las prácticas y procesos. Es en definitiva llevar el primer principio de la agilidad a la gestión, o mejor aún a la auto-gestión del modelo.

    Por supuesto es mi opinión.
    Gracias a ti por el post.
    Un saludo.

    1. Hola Juan:
      Qué gran puntualización… el conocimiento extremo te permite saltarte las reglas…
      El principio básico de todos los de alguna forma han aportado nuevas formas, en cualquier área, que han cambiado su industria o han generado generado un movimiento cultural.
      Además Juan, entre tú y yo, yo también asumo dos roles en el proyecto.
      Saludos y gracias por tus comentarios.

  3. Que gran post!! Bastante esclarecedor la diferenciación de roles dentro de un equipo que aplique este tipo de tecnologías. No siempre se tiene tan claro o no interesa a una de las partes o a ambas… 😉
    Un saludo.

    1. Gracias por el comentario lolasoylola.
      En las primeras entradas del blog estoy dedicando el espacio al análisis de situaciones extremas en los equipos que quieren hacer Scrum y tienen dificultades para implementarlo, dificultades originadas en la asignación de roles.
      No trato de resolverlas (¿o sí?) más bien trato de explicar el motivo por el cuál la división de roles en Scrum tiene que ser tal como se ha definido y cualquier variación tiene un impacto elevado en el método.
      Una aclaración importante. Scrum no es una tecnología, es una metodología… o mejor dicho un framework que permite implementar, dentro de un marco estandarizado, tu solución personalizada.
      Para lo que necesites, aquí estamos.
      Saludos.
      Óscar R. Onrubia

  4. Desde mi punto de vista, el problema del planteamiento que nos presentas aparece ya en la primera viñeta: si la organización apoya la iniciativa de implantar Scrum tiene que aportar los mínimos recursos para poder hacerlo. Si no puede aportarlos, quizá no sea el momento de aplicar Scum. Si no quiere aportarlos es que no han entendido la filosofía de Scrum.

    Aprovecho para darte la enhorabuena por tu blog tanto por contenido como por estética: me parece brillante el uso de las viñetas para el desarrollo de los post.

    Un saludo.

    1. Hola Diego:
      Muchas gracias por el comentario, y la enhorabuena.
      Vamos con lo primero, el comentario. Estoy totalmente de acuerdo contigo. Si no hay implicación por parte de la organización es que la filosofía no es compartida y únicamente se buscan mejoras a coste cero. Quizá la empresa debería revisar sus propias directrices y hacer lo que dice y no lo que hace: proactividad vs reactividad.
      Ahora sobre el blog. Agradezco tu enhorabuena, estoy comenzando con el blog y es muy agradable ver que a otros les gusta mi trabajo. El formato, la estética, es fundamental, y el contenido… Uf!!!, eso sí que es dificil…
      Saludos.
      Óscar R. Onrubia

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s