14/9/2011 18:24 El Bruno

[ALM] Opinion: ¿Hasta donde debo seguir las reglas de una metodología de trabajo?

Buenas,

ayer entre tanta salida de Windows 8, hubo una serie de tweets entre @lfraile@javierholguera, @r_corral y el que firma el post (que tal vez no sea el que escribe), donde discuíamos el tema de seguir o no seguir las guías que nos proponen ciertas metodologías de trabajo como por ejemplo SCRUM.

Hasta donde tengo entendido el contexto, Javier se está preguntando si SCRUM es la forma de trabajo que mejor se adapta a su escenario de trabajo, ya que entiende que tiene que terminar una iteración para poder liberar el resultado de la implementacion de las users stories que se han definido para la misma. Supongo que es por eso que se está planteando probar un poco KANBAN para gestionar su trabajo, ya que de esta manera. Por ejemplo, en el siguiente tablero vemos que si el WIP del equipo es 5, las tareas que están a punto de cerrarse son las D, E, G, y H; y que las features liberadas en A y B ya se pueden probar.

image

Pues bien, eso ayuda en KANBAN tener un elemento cerrado cuando “está cerrado” y no tener que esperar a que se finalice una iteración para liberar el mismo.

Pero ¿porqué no cambiar el alcance de un Sprint? (vale ya he hablado de iteraciones, cambio a modo SCRUM) … pues porque el gran Ken Schwaber en su libro “AGILE PROJECT MANAGEMENT WITH SCRUM”, además de cerrar en 30 días el período fijo para un SPRINT, dice lo siguiente:

No one can provide advise, instructions, commentary or direction to the Team during the sprint. The Team is utterly self-managing.

(página 136)

Leyendo esto al pie de la letra y siendo muy radical en la implementación de SCRUM, si durante un sprint yo tengo estimado cerrar 3 elementos, tengo que esperar al final del sprint para poder liberar estos 3 elementos.

Pero, es muy común que surjan las siguientes preguntas:

  • ¿qué sucede si trabajo en un equipo que crea elementos comunes para otros equpos, y el primer elemento es crucial para que otro equipo pueda seguir trabajando?
  • ¿que debo hacer si mi equipo es capaz de entregar este elemento en 15 días, pero el sprint está cerrado en 30 días?
  • KenS propone sprints de 30 días, ¿puedo cambiar el tamaño de un sprint?

Vale, llegamos al punto interesante:

¿Puedo saltarme las reglas/obligaciones que trae cada metodología de trabajo?

Pues no hay respuesta correcta para esto. Desde mi experiencia siempre recomiendo conocer a fondo una forma de trabajo y de la misma, aprender a utilizar lo que realmente se necesite. 

Un ejemplo, hace un tiempo participé en un proyecto con un compañero donde nos guíamos por las recomendaciones de SCRUM (basados en TFS2010 y MSF for AGILE 5.0). Pero … ¡¡¡no hacíamos daily scrum meetings!!! si si si, ya lo sé, los gurúes de SCRUM me crujen. Soy un sacrílego, no soy digno, etc. Si fuese por KS, ambos deberíamos cerca de €100 a la hucha, deberíamos tener siempre la reunión en el mismo sitio, etc.; vamos que KS nos mata.

Pero mi pregunta era, ¿para qué vamos a hacer un Daily Scrum Meeting si ambos estamos sentados uno al lado del otro, compartimos 15 minutos de cafe donde hablamos de futbol, gadgets y el proyecto; y además compatirmos horas de cervezas donde también hablamso de lo mismo?. Vamos que no nos hace falta.

Cuando lo pienso un poco, veo que esto es parte de mi forma de ser. Como soy una persona que vivo al límite, en el proyecto anterior que compartí con este compañero tampoco hacíamos “Stand-up meetings” (ahora cambio a AGILE), después de trabajar un tiempo con una persona pues la conoces y eso puede ayudar bastante a la dinámica de trabajo de un equipo.

Aclaración: Esto no quita que la práctica de las SUM sea muy recomendable, es más existe un artículo en el site de Martin Fowler donde se describen algunas recomendaciones para llevar este tipo de reuniones.

Personalmente, yo creo que sin realizar las DSM no dejabamos de trabajar en modo SCRUM. Pero nos saltábamos las reglas basados en nuestra experiencia y porque sabíamos que esa era la mejor forma de trabajo.

Ahora es momento de preguntarse, lo que trato de hacer que todo el mundo se pregunte:

¿Puedo cambiar la forma en la que trabajo para ser más efectivo, sin perder la calidad?

Pues ahí te lo dejo.

 

Saludos @ Home

El Bruno

   

PD: el chart de Kanban es del nuevo librako en el que estoy terminando, a ver si hago un post/concurso para ver que título le pongo al book.

PD2: sé que alguno después de leer esto dejará de leer mi blog … pues más alivio para internet Open-mouthed smile

Archivado en: ,,,
Comparte este post:

# re: [ALM] Opinion: ¿Hasta donde debo seguir las reglas de una metodología de trabajo?

Wednesday, September 14, 2011 7:06 PM by Vicenç García Altés

Si quieres les puedes llamar hacer cafes o cervezas, pero estabas haciendo dailys, así que esta parte no te la saltabas :D

# re: [ALM] Opinion: ¿Hasta donde debo seguir las reglas de una metodología de trabajo?

Wednesday, September 14, 2011 7:18 PM by El Bruno

@Vicenç jeje ya lo sé, pero la idea es otra. Si tengo que respetar todo lo que dice KenS en su libro sobre los Daily Scrum Meetings pues no los cumplo nunca. La idea es que las reglas están allí, pero luego cada uno las adapta a su entorno (en mi caso está claro que el entorno es un bar irlandes :P)

Salu2

# re: [ALM] Opinion: ¿Hasta donde debo seguir las reglas de una metodología de trabajo?

Thursday, September 15, 2011 12:44 AM by Vicenç García Altés

Si, ya te entiendo, pero creo que para adaptar las normas, hay que ser un equipo maduro y saber muy bien lo que se hace.

Cuando un equipo no maduro adapta Scrum a su "realidad" normalmente acaba trabajando como antes, pero con la satisfacción ilusoria de poder llamarle Scrum.

Y por desgracia, un alto porcentage de equipos no son lo suficientemente maduros para poder adaptar demasiadas cosas...

# re: [ALM] Opinion: ¿Hasta donde debo seguir las reglas de una metodología de trabajo?

Thursday, September 15, 2011 11:16 AM by javierholguera

Pues en realidad la discusión fue un poco distinta.

El tema es que me he leído el "Kanban and Scrum" para ir familiarizándome un poco con Kanban y planteaba que, desde mi punto de vista, no usaría Kanban para un equipo de desarrollo, sólo para uno que se dedicara a mantener o dar soporte, al que seguramente le resultaría imposible, de otro modo, estar 3 semanas trabajando con algo sin tener ninguna interferencia externa. En ese escenario, que de hecho es el que plantean en el caso de estudio que viene en el libro, sí lo veo útil.

Pero para un equipo desarrollando un producto para sí mismos o para un tercero, no veía qué podía aportar Kanban.

Entonces alguien planteó, no recuerdo quien, el caso de tener que hacer releases cada menos tiempo de la duración del sprint. Yo decía que no veía claro, primero, la necesidad, y segundo si no estaríamos rompiendo un poco Scrum, dado que se supone que algo puede lanzarse una vez que ha pasado por una Sprint Review en la que tus "gallinas" te han dado el OK. Y este es el contexto de la "conversación", si se puede llamar así a intercambiar mensajitos de 140 caracteres.

Sobre lo que comentas en tu post, yo primero me preguntaría si se puede hacer Scrum entre 2 personas. Nosotros lo hacemos aquí, y para mí eso no es Scrum, porque muchas de las reglas que establece Scrum no tienen mucho sentido cuando estás con una o dos personas, mano a mano. Las necesidades que entiendo que te cubre Scrum, no las tienes cuando el equipo es tan pequeño (¿tiene sentido hablar de equipo, si quiera?).

Por eso, a partir de ahí, plantearse si es más o menos Scrum que hagas las Daily en un bar sentado en lugar de hacerlas en la oficina de pie, pierde sentido. Estas haciendo otra cosa, que a lo mejor todavía no tiene nombre, pero que seguramente sea más beneficioso que intentar hacer Scrum donde Scrum no tiene sentido.

# re: [ALM] Opinion: ¿Hasta donde debo seguir las reglas de una metodología de trabajo?

Friday, September 16, 2011 6:08 PM by El Bruno

@Vincenc, pues yo estoy seguro que cuando trabajas con un equipo maduro, pues te da un poco igual la forma de trabajo. Mi frase es "si trabajas con buenos profesionales, da igual la metodología de desarrollo, el resultado final será un producto de calidad :D" ... Aunque no niego que para saber qué se puede adaptar y cómo es la mejor forma de hacerlo, te tienes que haber pegado un par de golpes antes (yo todavía tengo las cicatrices y alguna que todavía esta cicatrizando)

Salu2