Exprimiendo Scrum: ¿Cuál es tu definición de equipo?

Equipo ALa problemática de la gestión de proyectos en las organizaciones que desarrollan software se deriva, simplificando el asunto, de dos situaciones: gestionar proyectos muy grandes o gestionar muchos proyectos pequeños. Todos estaremos de acuerdo en que cualquiera de estas dos situaciones es más compleja que la situación, más equilibrada, en la que tenemos un número limitado de proyectos con unas dimensiones limitadas.

De estas tres posibilidades, sin duda la más compleja es muchos proyectos pequeños. Los grandes problemas siempre se pueden dividir en problemas de tamaño medio y reducir así la complejidad, llevarlos a la categoría de ‘un numero pequeños de proyectos medianos’.

El por qué la situación más compleja se da cuando tenemos muchos pequeños proyectos es simple: tendemos a tener más cambios de contexto. Los cambios de contexto se dan al ‘pasar’ de un proyecto a otro y son tiempos perdidos. Si a un número grande de proyectos pequeños, unimos que no hay concepto de equipo, los cambios de contexto son continuos y la caída de productividad acusada. Cuando un proyecto está en manos de una persona y no de un equipo, esta persona inevitablemente es un cuello de botella. No voy ha hablar hoy de los cambios de contexto, en otra ocasión volveré sobre el tema, que ya he tratado, someramente, en alguna otra ocasión.

Cuando tratamos de implantar Scrum en una organización este problema de la gestión de proyectos también nos afecta de manera decisiva. Como hemos comentado se trata de un problema de cambios del contexto y el antídoto de Scrum para los cambios de contexto es el concepto de equipo autoorganizado y autogestionado. La idea clave es que un equipo autoorganizado y autogestionado puede elegir en que momentos introducir los cambios de contexto, y por simple sentido común elegirá los momentos idóneos. Siguiendo con esta argumentación se hace patente que es precisamente en entornos que presentan muchos pequeños proyectos en los que más dificultoso es implantar Scrum y en los que más atención se debe prestar a un tema clave: definir que es un equipo en tu organización.

En empresas con ‘muchos pequeños proyectos’, como la gran mayoría de las pequeñas y medianas consultoras, la gran dificultad pasa por encontrar que es un equipo para esa organización, en primer lugar, y en segundo lugar definir cuantos product backlogs se van manejar.

Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenemos que pasar de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Esa es la gran dificultad.

El principal problema que tenemos en la situación actual es el tiempo que se os va en cambios de contexto, insisto. Probablemente estemos en la típica situación de prioridades difusas, de atender a los fuegos, al cliente que más grita… el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo, por ahí empiezo yo toda implantación de Scrum en este tipo de situaciones, definir los equipos.

Esa definición de equipos se puede hacer atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)… Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.

Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:

1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.

Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Aunque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.

Hay una manera muy simple de saber si hemos hecho esto bien: elegimos un desarrollador al azar y le preguntamos:

¿Tu a qué equipo perteneces?
¿Dónde está vuestro product backlog?
¿Quién son vuestro Producto Owner y Scrum Master?
¿Cuáles son los objetivos de tu equipo para este sprint?

Si recibimos respuestas ambiguas, es que no tenemos un modelo de equipos. Sin un modelo claro de equipos no es posible una correcta implantación de Scrum.

El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo en lugar de algunos proyectos grandes que respondan al modelo simple de Scrum.

Este post, se inspira en una interesante conversación mantenida sobre este tema en la lista de Agile Spain, quizás queráis leer los pensamientos allí expuestos.

¡Espero vuestros comentarios!

18 comentarios sobre “Exprimiendo Scrum: ¿Cuál es tu definición de equipo?”

  1. Para mi un equipo de trabajo tiene que querer llegar a cumplir sus objetivos, pero cumplirlos como equipo (esto es lo más dificil), te pongo un ejemplo nosotros pagabamos un euro si haciamos check in con errores, pues despues cuando he reflexionado sobre ello estabamos actuando erroneamente porque la motivación de un bien común(hacer check in sin errores) era el castigo individual(pagar un euro), osea que al final lo hacias bien, movido por el egoismo de no pagar.

    Los equipos que sean estancos, no sí es del todo posible porque generalmente todo nos afecta a todos, por ejemplo si un equipo se encarga de hacer un modulo de recepción de mercancia en cierta medida afecta a fabricación o a facturación.

    Creo que lo más importante es el sentimiento de pertenecer a un grupo con un fin común (Sé que es utópico).

  2. Es curioso la similitud que tiene Scrum con los sistemas LEAN, en nuestro como solo tenemos tres o cuatro proyectos por lo que no apreciamos los cambios de contexto como si de una empresa de software se tratase, pero si lo veo claramente, en la parte de fabricación, donde uno de los problemas más graves es el cambio de los troqueles en las líneas de prensa y se lucha por minimizar este cambio, ya que las series de fabricación tienden a ser cada vez más pequeñas y el tiempo de «cambio» es fundamental para lograr llegar a ser más competitivos. La mejora continua y el trabajo en equipo son los dos factores que permiten llegar a soluciones para optimizar esta fase, y es aquí donde se aprecia el verdadero valor del equipo, cuanto todo está perdido, cuando no ves una forma de mejorar, siempre hay alguien que tiene una idea de cómo hacerlo.

    Saludos.

  3. Por cierto, para mi la definición de equipo es aquel en el que todos sus miembros trabajan en la misma dirección.

    Pd. «Que bien me ha quedado la frase, eh…»

  4. @Juan: Completamente de acuerdo, excelente ejemplo, muy bien traido el comentario. Es algo que comento siempre cuando hablo de cambios de contexto. El problema del cambio de herramietna en la producción industrial. Es un problema al que se han dedicado muchas neuronas, incluso hay métodos especificos para acotar el problema como SMED (Single Minute Exchange of Die). El problema es que en el sofwtare el coste es menos evidente, aunque también es muy alto está más oculto. Es lo que en Peopleware llaman coste de reinmersión, lo que tardas en centrarte de nuevo en la tarea que estabas haciendo.

    @eobregon: Lo primero para que un equipo cumpla sus objetivos es que quiera cumplirlos, de acuerdo. Pero antes se tiene que dar la precondición de que estos sean realistas. Y esto no siempre ocurre. Por eso en Scrum, es el equipo el que establece sus objetivos, siempre en el marco de los objetivos generales y prioridades establecidos por el Product Owner. Una cosa que no entiendo es por qué piensas que el sentimiento de pertenenecia a un equipo es algo utópico.

    ¡Un saludo y gracias por los comentarios!

  5. Buen post crack! De acuerdo contigo en que lo más complicado es gestionar «muchos proyectos pequeños», y añado un plus de dificultad a la hora de alinear proyectos paralelos en escenarios como por ejemplo: algunos o todos estos proyectos deben alinearse en torno a un mismo calendario para «releases», y también, algunos de estos proyectos son clientes de otros, o su implementación depende de funcionalidades que otro proyecto deba alcanzar en un hito, o en una iteración, concretas.

    A mí como definición de equipo me encanta usar la palabra TEAM, a modo de siglas: Together Everyone Achieves More.

    Y en cuanto a la toma de decisiones en un momento concreto, soy de la opinión de que «ninguno de nosotros es tan inteligente como todos nosotros juntos» 🙂

    M.

  6. Creo que es muy complejo que lo sientan todos los miembros, te pongo un ejemplo en las negociaciones colectivas que se están dando en los últimos meses, debido a la situación actual, nadie está dispuesto a poner más por el bien común, eso sólo ocurre en situaciones extremas y eso es lo lamentable, hasta que no se ven las orejas al lobo nos olvidamos del plus necesario, entiendo que tiene que haber un cambio cultural obligatorio y se debe fomentar el sentimiento de grupo. La verdad es que este es un tema que me encanta.

  7. No tengo ni idea de lo que es el Scrum este del que hablas a mi me suena al sistema Scumm de los juegos antiguos de LucasArts.Y lo del Scrum Master al amo del calabozo.

    ¿Tu a qué equipo perteneces?
    ¿Dónde está vuestro product backlog?
    ¿Quién son vuestro Producto Owner y Scrum Master?
    ¿Cuáles son los objetivos de tu equipo para este sprint?

    Yo la verdad es que me hacen estas preguntas y se
    me queda la cara de tonto.
    No entiendo el porque de todos esos nombres en ingles.¿Es porque queda mas guay?
    ¿No existe una manera mas normal de decir las cosas para que un grupo de gente haga un trabajo?
    Ya digo que no tengo ni idea del tema este de dirigir a personas para que hagan algo.
    Pero vamos si se inventan una tecnica se llame scrum o lo que sea al menos podrian traducirla.
    Asi no tendriamos que oir cosas como que si el scrum master del universo contra skeletor ni product backlog (oiga yo por el back nada de nada)

  8. @FCL, jajajajajajajaj eres buenisimo, estoy montando un circo, cuando quieras llamame…. jjajajajajajajja..

    Pd. Un consejo busca Scrum en geeks y en Wikipedia, te puede ayudar a entender los terminos.

  9. @FCL: Yo tampoco se lo que es un by pass, un CTT, un stem, un scalp, un shock o el Lupus… puedo pensar que esto cabrones de médicos no usan más que terminos raros que se empeñan en que yo no entienda… o puedo pensar que como no soy médico y el tema no me interesa más allá de ver House, no tengo ni puñetera idea de que coño están hablando.

    ¡Un saludo!

  10. @FCL: Yo tampoco se lo que es un by pass, un CTT, un stem, un scalp, un shock o el Lupus… puedo pensar que esto cabrones de médicos no usan más que terminos raros que se empeñan en que yo no entienda… o puedo pensar que como no soy médico y el tema no me interesa más allá de ver House, no tengo ni puñetera idea de que coño están hablando.

    No si yo no te quito la razon en eso. Si uno es un profesional en una materia es logico que sepa todos los tecnicismos que se usan en esa jerga.
    A mi lo que en realidad me jode es que al final tenemos que aprender un monton de palabrejas en ingles que dificultan la comunicacion. En el sector de la informatica el ingles se usa todo el dia; documentacion, programas, paginas web, libros etc.

    Pero en el caso de las preguntas que tu ponias como ejemplo:
    ¿Dónde está vuestro product backlog?
    Los requisitos del sistema suelen especificarse en documentos formales; y el product backlog, o pila del producto toma la forma de una lista de historias de usuario.

    Conclusion: product backlog = pila del producto

    ¿Quién son vuestro Producto Owner y Scrum Master?
    Mira aqui te has colao y has puesto Producto owner en vez de product. No lo digo por joder la marrana sino como ejemplo de lo dificil que es mezclar palabros en ingles con el castellano.

    ¿Cuáles son los objetivos de tu equipo para este sprint?
    No he encontado traduccion de esto asi que para mi.
    sprint = objetivo a corto plazo.

    Yo insisto en que tanto tecnicismo acabara con volvernos locosa todos. Scrum y lo que sea en castellano ya!.:P

    PD: La foto del equipo A cojonuda.

  11. Respuesta a FCL: «¿No existe una manera mas normal de decir las cosas para que un grupo de gente haga un trabajo?» Bueno, lo de la jerga en project management puede ser complicado al principio. Un compañero nuestro escribió hace poco sobre el tema. Si quieres echarle una ojeada, es éste: http://blogs.salleurl.edu/project-management/introduciendo-la-gestion-de-proyectos-en-la-empresa/
    Desde luego se puede gestionar un proyecto ahorrándose toda la terminología pesada y traduciéndola al sentido común. No obstante a la larga está bien compartir las mismas palabrejas con los freaks de dirección de proyectos de otros países…

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *