Trabajé en una organización donde implementamos Scrum, pero eliminamos los roles "junior" y "senior". Los desarrolladores sénior todavía se consideraban a sí mismos como personas mayores (con toda la actitud que conlleva).
Ahora trabajo como Scrum Master en una organización diferente y estoy pensando en implementar la misma política. Pero esta organización tiene gerentes junior, senior, control de calidad y desarrollo. Estoy pensando en dejar todos los títulos y hacer que todos sean desarrolladores, y tener un desarrollador líder en cada equipo.
¿Es este un enfoque viable?
Un equipo de desarrollo de Scrum se organiza a sí mismo y evita los roles jerárquicos tradicionales, como el de desarrollador líder.
La idea es que los miembros del equipo lideren dando ejemplo y ganándose el respeto de los demás miembros del equipo. Por ejemplo, en el caso de que tenga un desarrollador con mucha experiencia en el equipo, a menudo puede asumir el liderazgo técnico con la plena cooperación del equipo debido al respeto que el equipo tiene por él.
El peligro de tener un rol de desarrollador líder es que puede desempoderar a otros miembros del equipo. Digamos, por ejemplo, que 3 desarrolladores en el equipo quieren usar el enfoque X, pero que el desarrollador líder quiere usar el enfoque Y. El rol del desarrollador líder les permite anular la opinión de los otros miembros del equipo. Mientras que en un equipo Scrum argumentarían el caso del enfoque Y con una buena posibilidad de ganar la discusión debido al respeto que los otros miembros del equipo les tienen.
El beneficio de este enfoque es que todos los miembros del equipo sienten que participan en el proceso de toma de decisiones. Esto ayuda a todo el equipo a tirar en la misma dirección y trabajar con entusiasmo en el enfoque técnico elegido.
Creo que Barnaby dio en el clavo con bastante solidez.
Puede tener grados de experiencia en su empresa y, de hecho, es posible que no pueda alejarse de ellos dada la forma en que Recursos humanos a menudo estratifica los títulos de trabajo. Sin embargo, lo que debe dejar en claro para todos es que es el equipo el que se mide en el éxito o fracaso colectivo del equipo. No hay estrellas de rock en el equipo, solo maestros y estudiantes que pueden ser intercambiables según la habilidad (Bob es un codificador de C++ increíble y le enseña a Sally. Sally es una diosa en Java Script y le enseña a Bob).
Si usted es un programador de estrellas de rock y su equipo tiene dificultades para desempeñarse, no obtiene un nuevo equipo. En su lugar, te preguntan: "¿Qué estás haciendo para ayudar al equipo a mejorar?" Tomaré un equipo de codificadores promedio que son realmente buenos juntos en lugar de un par de codificadores rockstar individualistas casi cualquier día.
Hay un modelo de evaluación de recursos humanos más nuevo que realmente respalda esto. En lugar de que un individuo sea evaluado por su éxito personal, el modelo se divide 50/50 entre el equipo y el desarrollo individual. El primer 50% de su revisión se basa en el éxito del equipo. Si la puntuación del equipo es del 100%, obtienes 50 puntos. Si el equipo anotó un 50%, obtienes 25 puntos.
La segunda mitad se basa únicamente en el desarrollo individual basado en metas establecidas por el empleado y el gerente. ¿Aprendiste ese nuevo idioma en el que te registraste? Entonces obtienes una alta puntuación de desarrollo.
La clave es que el individuo no se mide por el trabajo realizado, el equipo sí.
Scrum solo tiene tres roles. El uso de otros títulos o funciones dentro del equipo (incluido el de "desarrollador principal") es en gran medida un antipatrón de Scrum.
Si bien puede tener personas de varios niveles de habilidad y especializaciones en el equipo Scrum, el marco Scrum solo tiene tres roles dentro del equipo:
Eso es. No puede llamarlo Scrum si tiene roles como "Ayudante Junior Flunky a cargo de doblar clips" dentro de su Equipo Scrum. Puede ser una habilidad útil que agregue valor a su proyecto, pero no es un rol legítimo dentro de Scrum.
Definitivamente, lo más importante para trabajar es el trabajo en equipo real entre los diversos desarrolladores. Es inevitable que algunos tengan más experiencia que otros, a menudo con habilidades muy diferentes. Lo primero de lo que hay que asegurarse es que las personas que son muy buenas en una cosa en particular no simplemente "van por su cuenta y lo hacen". Debe asegurarse de que primero expliquen a los demás lo que van a hacer (y por qué), y luego les muestren lo que han hecho. Por lo tanto, todos están involucrados, todos tienen la oportunidad de aprender e, inevitablemente, alguien nota algo que la persona más experimentada pasó por alto accidentalmente.
La noción de "planificar el trabajo, trabajar el plan" está ahí por una razón. Pero muchos equipos que se llaman a sí mismos "equipos" en realidad no lo siguen.
Hace más o menos un año, me involucré con un "equipo" que en realidad era solo "lobos solitarios, en una manada". Su antiguo "gerente" se contentaba con ser simplemente un supervisor, preguntándoles una vez por semana qué estaba haciendo cada uno de ellos y terminando la reunión diciéndoles que siguieran haciéndolo. Todos pasaban el día ocupados trabajando en lo que sea que "ellos" hicieran, como si todos los demás en la sala ni siquiera estuvieran allí. Fue un poco como un choque cultural para ellos al principio, pero todos llegaron a admitir que la gestión de proyectos "real" redujo en gran medida la intensa presión personal bajo la que todos habían aprendido a vivir.
Creo que Scrum es un marco fantástico para proyectos de software. Sin embargo, dicho esto, solo tener esos tres roles deja un gran vacío en el equipo. Ya sea que elimine o no los títulos de los desarrolladores, no cambia el hecho de que, de hecho, hay desarrolladores de nivel junior, intermedio y senior en el equipo.
Lo he visto muchas veces donde el propietario del producto (PO) escribe todas las historias de los usuarios. Y, por supuesto, ese PO, aunque puede haberlo sido alguna vez en el pasado, no es una persona técnica. Las historias escritas por un PO no son técnicas como las especificaciones técnicas que solían ser en el marco de Waterfall. Pero si piensas en los días de Waterfall, ¿quién escribió las especificaciones técnicas? Los desarrolladores senior lo hicieron. El FA (analista funcional) escribió los requisitos comerciales, y los desarrolladores senior tomaron esos requisitos y crearon especificaciones técnicas para que los desarrolladores las siguieran.
Avance rápido hasta hoy, falta esa especificación técnica. Si no tiene desarrolladores senior "liderando" a los desarrolladores, terminará con una gran deuda tecnológica. Lo he visto. Yo sugeriría un pequeño ajuste...
Asegúrese de que cada equipo de desarrollo tenga un desarrollador senior y el resto sean intermedios y junior. El PO escribe las épicas y las historias de alto nivel, pero el desarrollador senior escribe las historias de bajo nivel que se asignan a los desarrolladores.
Y bajo ninguna circunstancia una OP debe tomar decisiones técnicas; estos deberían ser realizados por el desarrollador principal, o al menos deberían dar la aprobación final a las decisiones técnicas. He visto tantas veces que el PO toma decisiones técnicas y se hacen promesas en base a ellas, antes de que el equipo de desarrollo vea los requisitos.
Todd A. Jacobs