¿Está bien tener personas con múltiples roles en un equipo Scrum?

Estoy evaluando algunas metodologías de estilo ágil para una posible introducción a mi equipo. Con Scrum, ¿está permitido que la misma persona realice múltiples roles? Tenemos un pequeño equipo de cuatro desarrolladores y un diseñador web; en realidad no tenemos un liderazgo (cumplo con este rol), probadores de control de calidad o analistas de negocios, y todas nuestras tareas de desarrollo provienen del CIO. Las pruebas automatizadas se consideran una pérdida total de tiempo, y todo se centra en la velocidad y no en la calidad.

Lo que sucederá es que el CIO presentará una tarea de desarrollo (ya sea una característica o un error) y se la entregará a un desarrollador (no a todo el equipo, a un individuo, a menudo en privado o de la nada) que entonces es Se espera que se complete. El CIO no reúne requisitos más allá de la idea inicial (y esto nos ha mordido antes, ya que implementaremos algo solo para descubrir que ninguno de los usuarios finales puede usar la función, porque no fueron consultados ni informados al respecto antes de que lo desarrollemos, y en pánico se nos pedirá que revertamos el cambio), pero requiere decir / aprobar todo lo que hacemos.

Lo primero es lo primero, ¿es un estilo Scrum algo a considerar para introducir algunos estándares y prácticas? Tras la lectura, Scrum parece confiar un poco más en la confianza y la comunicación y se centra más en la gestión de proyectos que en el desarrollo, que es algo de lo que estamos completamente desprovistos, ya que actualmente no tenemos ninguna apariencia de gestión de proyectos.

En segundo lugar, si puede funcionar, ¿no es razonable que alguien, digamos yo mismo, actúe como ScrumMaster y como desarrollador? ¿O que un desarrollador también sea el Propietario del producto (aunque es probable que sea el CIO, que no es un desarrollador)? Me doy cuenta de que el Scrum Master y el Propietario del producto deberían ser personas diferentes, pero al mismo tiempo no creo que tengamos a nadie que tenga las cualidades de un Propietario del producto (es probable que se convierta en un "Necesito todas estas historias, yo no me importa cómo hacerlo pero "tipo de trato y / o cualquier congelación se descongelaría por un capricho).

Me parece que podría necesitar elegir y elegir piezas de Scrum / XP / Lean para compensar cómo se hacen las cosas actualmente, ya que es muy poco probable que se pueda cambiar la mentalidad; por ejemplo, la programación de pares nunca volaría (visto como un desperdicio, se realiza la mitad de las tareas si necesita dos personas para todo), TDD sería una venta difícil, pero los ciclos cortos serían bienvenidos.

Scrum, Kanban o cualquier otra metodología Agile es principalmente una metodología enfocada en proyectos de desarrollo de software . En otras palabras, es una práctica de gestión de proyectos por su propia naturaleza.

Por mucho que desee desesperadamente que usted y su equipo realicen trabajos de proyectos, descubrirán que Agile simplemente no trabajará en su organización debido al hecho de que realmente no están haciendo trabajos de "proyectos" o dedicándose como equipo a un "compromiso de proyecto".

Puede organizar un mini proyecto en torno a una característica compleja, pero en realidad no tiene conexión con analistas de negocios o usuarios finales, entonces, ¿cómo puede verificar que está entregando Historias de usuarios cuando no tiene forma de saber realmente qué es el usuario? ¿quiere?

Su única parte interesada es su jefe, y básicamente se asegura de que su equipo no exista para servir a las otras partes interesadas del proyecto, usted existe como un equipo para atenderlo a él y a sus necesidades, independientemente de cómo esto afecte a las otras partes interesadas.

Además de todo eso, está asignando tareas individuales a individuos y probablemente priorizando las cosas de inmediato cuando decide que deberían irse. No puede funcionar en una metodología de proyecto Agile si los recursos individuales del proyecto se priorizarán en un momento dado, o si el sprint se pondrá en espera.

No se supone que funcione así

Un sprint es un compromiso de todo el equipo para entregar un subconjunto de historias de usuarios en una fecha específica. Una vez iniciado, se debe completar un sprint antes de que se produzca una nueva priorización o cambios. ¿Cómo se supone que se debe gestionar un proyecto cuando se ejecuta en un entorno ad hoc tan caótico?

No trabaja en un entorno propicio para las metodologías de gestión de proyectos ágiles. Ni siquiera trabaja en un entorno propicio para las metodologías de Cascada. Trabajas en una monarquía y no eres más que los peones de los reyes que hacen su voluntad y apagan incendios.

Esta no es la creación de un equipo de proyecto de desarrollo de software.

Entonces, de una manera muy oscura, estoy respondiendo su pregunta al decir que, en su situación, realmente no importa si las personas desempeñan múltiples roles. Tienes problemas mucho mayores en tus manos. Usted pregunta cómo quitar las manchas de agua de la alfombra en una casa sin techo.

Como señalé aquí , si el Scrum Master o el Product Owner tienen tareas accionables, también son miembros del Equipo.

Dicho esto, vas a tener serios problemas para ser ágil a menos que tengas una verdadera aceptación tanto de tu CIO como de tus clientes. ¿Está su CIO dispuesto a cumplir con el hecho de que no puede agregar un elemento de trabajo a mitad del sprint, sino que tendrá que esperar hasta el siguiente? ¿Está dispuesto a priorizar los elementos a desarrollar? Por lo que has escrito, parece que él es el dueño de lo que haces y, por lo tanto, debería ser el propietario del producto. Si él no está dispuesto, no vas a tener éxito más de lo que lo haces actualmente.

Scrum podría ser una buena solución para su problema de que el CIO asigne trabajo a un desarrollador ad hoc, pero solo si el CIO aceptará el proceso. Sospecho que a su CIO no le va a gustar que le saquen una asignación directa. Pero si puede lograr que el CIO acepte la idea de que él escriba historias de usuarios y luego las priorice, podría encontrar una forma muy efectiva de administrar. Pero comenzará por convencer a su CIO de que se adhiera al proceso.

Scrum es algo a considerar, seguro. Sin embargo, hay algo que decir para involucrar a todos los involucrados en la misma página y aceptar algunos cambios en la estructura junto con al menos algunos sprints para resolver varios problemas iniciales al usar esta metodología.

El propietario del producto debe estar fuera del equipo de desarrollo, ya que de lo contrario se presentaría un conflicto de intereses grave aquí. Sin embargo, el Scrum Master puede ser un desarrollador, ya que no hay un conflicto tan grave en este caso.