Una situación que veo recurrentemente en las empresas de desarrollo software para terceros es que conforman sus equipos poniendo una persona en el rol de Scrum Master y asignandole también algunas otras tareas. Esto genera que en términos generales que la persona en el rol de Scrum Master termine concentrando 3 grupos de tareas:
- a) tareas de facilitación propias del Scrum Master que podemos resumir como ayudar a que el equipo siga la propuesta de proceso de Scrum, removiendo potenciales impedimentos, etc
- b) tareas típicas de la gestión del proyecto desde la perspectiva de la software factory como ser: seguimiento del presupuesto, planificación del equipo a mediano/largo plazo, seguimiento de la facturación, gestión de riesgos, etc. Aclaro aquí una cuestión importante: la gestión de presupuesto y del plan son responsabilidades del Producto Owner cuando vemos el proyecto desde la perspectiva de la organización que es dueña del producto, pero estas cuestiones también están presentes desde la perspectiva del proyecto de la software factory.
- c) tareas de gestión internas requeridas por la organización(software factory) respecto de los miembros del equipo como ser evaluaciones de desempeño, coordinación de licencias, etc.
Lo que me resulta sospecho es la concentración de estos tres grupos de tareas en un misma persona porque me parece que puede haber cierto conflicto. Un caso puntual a modo de ejemplo: se supone que el Scrum Master debería generar un contexto de seguridad para que el equipo y sus miembros puedan hablar en confianza sobre sus dificultades, equivocaciones, etc, pero al mismo tiempo esa persona Scrum Master tiene que evaluar el desempeño de los miembros del equipo ¿cuan seguro puede sentirse un miembro de equipo para hablar de sus equivocaciones cuando ese Scrum Master es también la persona que evalúa su desempeño?
Lo que yo recomendaría en estos escenarios es tener dos personas distintas: una con el rol de Scrum Master (que estaría presente en el día a día del proyecto ) y otra con el rol de gestor de proyecto (con una presencia mucho más esporádica).
Blog de NicoPaez 
Nico,
Mas allá de la bondad de separación de roles, me preocupa que el equipo no pueda desarrollar la confianza de hablar con franqueza. Porque no podría un miembro hablar de sus equivocaciones a quien va a evaluarlos?
En mi caso no me preocupa que se equivoquen, sino cómo actúan frente a la equivocación, y claramente me es importante que sean honestos.
Hola Carlos, gracias por tu comentario. Entiendo tu punto pero a mi parecer estamos en una sociedad donde no es tan común admitir los errores. Más aún hay instituciones/organizaciones donde el error es penado. Eso hace que alguna gente (me animaría a decir mucha gente) no se sienta cómoda compartiendo sus errores con quienes los evalúan y sabiendo que esas opiniones pueden influir en su remuneración. De todas formas el hecho de la evaluación es solo un ítem. Mi punto es que he visto en varias organizaciones poner en una misma persona el rol de Scrum Master junto con otros roles/tareas/responsabilidades que pueden resultar conflictivas y/o inconvenientes.
Como explica Ron Jeffries en https://ronjeffries.com/articles/019-01ff/management/, hay cosas que están fuera del scope de scrum (how you budget, how you decide compensation, how you assess performance, and so on), pero él entiende que la interface para esas cuestiones desde fuera con el equipo es la sprint review.
Ahora, me interesa el punto de las evaluaciones (tal vez es un tema para un post), pero ¿como un «gestor de proyecto» con una «presencia mucho más esporádica» va a poder hacer un buen trabajo evaluando a los individuos que componen el equipo?
Asumiendo que se generó (o se quiere generar) un «jelled team», donde cada uno entiende las fortalezas y debilidades de los demás y logran una muy buena productividad, ¿como se puede evaluar a los individuos desde fuera del equipo sin desinsentivar las prácticas que los hacen eficientes?
Gracias Andrés por el aporte. Coincido en que muchas cuestiones de management quedan fuera de la propuesta de Scrum. La cuestión de mi planteo es que en muchas empresas que desarrollaron software que he visto se le agregan esas cuestiones a la lista de tareas de la misma persona que ocupa el rol de Scrum Master y es eso lo que me parece insano/riesgo. El tema de evaluación de desempeño es una de esas cuestiones y en particular me parece que en muchos casos no está bien resuelta independientemente de Scrum, por eso creo que es un tema al cual le voy a post aparte.
Hola Nico, lo que mencionas se está tornando muy común en las empresas. Pero te comento, hay un feedback que siempre podemos dar a los miembros del equipo. Como Scrum Master lo he dado. Si me piden evaluar a una persona, sería ese mismo feedback que entregaría y se lo comentaría al equipo. Considero que ser trasparente con el equipo es lo mejor que puedes hacer para fomentar su confianza.
Hola Nico, buen punto en principio, también noto eso en las organizaciones y equipos, pero en mi opinión hoy en día hablamos mucho del rol Scrum para hacerlo parecido a lo que propone el Framework, creo que es mejor asimilar las buena prácticas del rol y potenciar a los líderes de equipo con las habilidades de desarrollar personas y para eso sumar prácticas de Scrum Master es positivo. El líder no sólo debe evaluar sino preocuparse por el desempeño y evolución del equipo!