#142.1.1 Scrum – Espíritu, Legislación y Jurisprudencia

Un amigo, Alan Cyment, gran instructor y conocedor de Scrum, explica Scrum con una analogía con las leyes:

– Espíritu: la razón que tenían, o el bien que buscaban, los legisladores. Los legisladores pueden o no haber logrado representarlo en la ley.

– Legislación: la letra, la descripción y reglas acordadas, que implementan el espiritu.

– Jurisprudencia: al aplicar la ley, aparecen situaciones no contempladas por los legisladores, o ambigüedades en la escritura de la ley, que llevan a tomar decisiones para casos particulares, estas decisiones son base para aplicación futura de la ley en casos particulares.

En Scrum, la ley es actualmente la reflejada en el Agile Atlas

En la primer clase intentamos cubrir la legislación.

La actividad es que compares lo que vimos en clase con lo indicado en el Agile Atlas e indiques en un comentario lo que faltó incorporar, y por que es ese punto importante. O si incluimos en la clase algo que no es parte de la «legislación», quizas alguna buena práctica o «jurisprudencia» usada por muchos equipos pero que no es parte de la definición base (core) de Scrum. 

Publicado en Sin categoría
15 comments on “#142.1.1 Scrum – Espíritu, Legislación y Jurisprudencia
  1. Creo que una de las cosas que falto incorporar a la clase, es cuando un producto puede ser entregado, ya que hay que acordar con el cliente los términos de entrega, o como dice en el Agile Atlas «Definition of Done».

    Saludos!

  2. Francisco Memoli dice:

    Durante la ejercitación se utilizó jurisprudencia para los ajustes pequeños (llamados Kaizen) , como por ejemplo un cambio en la forma en la que se pasaba la pelota dado que la vez anterior uno notó que a su compañero se le cayó.

    Un detalle tal vez no mencionado en las clases es que en Agreement: Definition of Done se debe incluir la idea de que el producto en el final de cada iteración debe estar completamente terminado, testeado y cerrado incluyendo todas las iteraciones previas, como para ser publicado inmediatamente.

  3. Facundo Rodriguez dice:

    Si bien se hablo que luego de la reunion de planing, se obtienen las tareas a realizar durante el sprint, no se explico que se lo llama sprint backlog y es uno de los artefactos esenciales de scrum, por lo que es importante conocerlo, y ademas de la lista de los items que se van a desarrollar durante el sprint, tambien incluye al plan del equipo para poder realizar el trabajo.

  4. En cuanto a «legislación» de Scrum, en la misma está bien definida la duración de cada actividad en función de la duración total del Sprint. Tuvimos en cuenta en clase que la duración del Daily Scrum es de aproximadamente 15 minutos (independientemente de la duración del Sprint), pero no hablamos de distintas consideraciones en otras reuniones. El
    Agile Atlas dice que la duración recomendada del Sprint Planning es de hasta 2 horas por semana de Sprint. Asímismo, la duración recomendada del Sprint Review y Sprint Retrospective es de una hora por semana de Sprint.
    Esto es importante porque es usual que las reuniones se dilaten y superen estos tiempos (a veces ampliamente), lo cual es una clara señal de que se está perdiendo el foco que deben mantener.
    En cuanto a «jurisprudencia», o mejores prácticas, hablamos en clase de la participación del Scrum Master dependiendo del nivel de madurez del equipo de trabajo. Si el equipo tiene la suficiente experiencia y mecanismos de Scrum aceitados, la presencia del Scrum Master puede no ser necesaria en algunas reuniones.
    Recordar que «el Scrum Master trabaja para que el equipo no lo necesite».

  5. Gonzalo Rodriguez dice:

    Para mi falto hablar de los Additional Indicators of Visible Progress, en donde dado que el Product Increment es el modo más importante de crear transparencia, y Scrum requiere transparencia tanto dentro como fuera del equipo, el mismo tiene que crear cualquier artefacto adicional que necesite para asegurase de que el estado del proyecto sea entendido por todos, siendo estos artefactos adicionales comúnmente burn charts y task boards.

  6. Constanza Catania dice:

    Creo que falto hablar mas sobre los Scrum’s Values. Si bien surgieron en la actividad, creo que no se hablo en detalle sobre ellos y me parece que es importante conocerlos ya que son la base de los procesos y principios del equipo como menciona el Agile Atlas.

  7. David Marcos dice:

    Un tema que para mí falto remarcar, es la retrospectiva del sprint como menciona Agile Atlas, en el cual al final de cada sprint se revisa que es lo que se hizo bien y lo que se hizo mal. Esto es muy importante para corregir errores y mejorarlos para el sprint siguiente, y así cada vez ir haciendo mejor las cosas sin dejar de pasar por alto ciertos temas por mucho tiempo y corregirlos lo más rápido posible para un mayor beneficio.

  8. Javier Choque dice:

    Creo que mencionamos la mayoría de los temas descritos en el Agile Atlas, salvo Sprint backlog y otras herramientas como el famoso tablero de tareas «Para hacer – Haciendo – Hecho». Si me parece que faltó ver un poco más la participación del Product Owner en la actividad grupal de las pelotitas.

  9. Elián Ricardo Pinzás dice:

    Algo mencionado en clase y que forma parte de la “jurisprudencia” es la posible presencia en la retrospectiva del sprint de una parte externa al equipo mencionado como “facilitador externo”. Un facilitador externo es alguien por fuera del proyecto que se introduce para aportar una visión objetiva (inherente por su condición de externo) acerca de algún tópico en discusión.

  10. Martín Gorgazzi dice:

    Siguiendo en la tónica de Alan Cyment con la que se abre esta actividad, para entender la legislación es bueno conocer el espíritu que la inspira. Por eso me parece que hubiese sido una excelente introducción a Scrum dar a conocer los valores que lo inspiran, y que aparecen al comienzo del texto del Agile Atlas. Estos valores provienen tanto del Manifiesto Ágil como también de la propia filosofía de Scrum. A la hora de aplicar una metodología, es bueno tener en cuenta el bien que busca (sus objetivos) para aplicarla mejor y no quedarse sólo con «lo que dice el librito». («La letra mata, el espíritu da vida.»)

    Con respecto a la jurisprudencia, en clase se comentó que la reunión de Scrum Diaria se realiza de «a pie». Sin embargo esto no lo veo mencionado en el «Agile Atlas». Deduzco entonces que es una de las mejores prácticas guiadas por la experiencia, y que llevan a seguir el espíritu de la metodología, y no sólo con lo que está escrito en «su legislación».

  11. Matías Alvarez dice:

    Una buena práctica que se suele utilizar es que en las Daily, las personas que están siendo parte de esta reunión, se encuentren paradas. Esto se utiliza para evitar que la reunión se extienda demasiado.

  12. En el ejercicio de «fabricar pelotitas» no pude apreciar bien la diferencia entre el Product Owner y el Scrum Master, mejor dicho, no termine de comprender como el Scrum Master facilita el trabajo del equipo. En el Agile Atlas se hace mucho hincapié en la diferencia entre ambos roles. Podría ser de ayuda contar con otra persona (alumno o profesor) que despliegue uno de los 2 roles nombrados, de manera que cada rol quede emparejado con una persona física, y de esa forma dar un ejemplo reconocible (y recordable) de la tarea que desempeña cada rol y sus diferencias.

  13. Lo que más se notó en el ejercicio de las pelotitas fue el value: «Responding to change over following a plan», en este sentido si vimos la aplicación del value en la práctica.

    Quizás faltó un poco hacer hincapié en «Costumer Collaboration over contract negociation» ya que no recuerdo que se haya detallado en clase.

  14. Rodrigo Sanzone dice:

    De lo visto en clase, me parece que hubiera sido importante explicar con más detalle el rol del Product Owner y qué estrategias utilizada para llevar a cabo su rol. Me parece importante porque se trata de un rol muy delicado, debido a que trata con los clientes, que son quienes traen los proyectos (y la plata).
    En cuanto a la idea de jurisprudencia, me parece importante señalar como ejemplo que si bien scrum hace hincapié en las reuniones diarias, en la práctica no siempre se llevan a cabo (especialmente en proyectos muy chicos) y eso no quita que se esté aplicando el espíritu de la metodología.

  15. Alfredo Scoppa dice:

    Como bien mencionaron arriba, hubiese sido interesante conocer los valores que scrum toma del manifiesto agil.

    Si bien se menciono muy por arriba, no quedo claro como se llega a formar el Product Backlog.

    El «Product Backlog Refinement» en clase se ubico al final pero en Atlas no se especifica en que momento ocurre.

    Según Atlas, Como parte del Sprint Planning se puede definir un «Sprint Goal» esto me parece que no se menciono en clase.

    Tampoco recuerdo que hablemos sobre la definición de completado.

Replica a Facundo Rodriguez Cancelar la respuesta