Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

"Nosotros hacemos Scrum"

En esto de Scrum y las metodologías de gestión de proyectos en general existen dos corrientes de pensamiento principales. Una es la encabezada por Jeff Sutherland, co-creador de Scrum y gurú de las metodologías Ágiles: según él, para que Scrum funcione hay que ceñirse estrictamente a las reglas, y todo lo que no pase el checklist completo no puede llamarse Scrum (y de hecho debería estar perseguido por la iglesia y garantizarte una buena temporada en los fuegos del infierno).

Otra la forman los que piensan que no hay una policía del Scrum que vaya a venir a detenerte si decides formar equipos de 14 personas cuando la norma es de entre cuatro y diez personas por equipo, o que rodeen el edificio con sirenas y megáfonos si llegáis a la conclusión de que los Sprints de duración fija no son para vosotros.

por Ángel Medinilla, 20 febrero 08

Durante mucho tiempo me he contado entre los segundos, y sin embargo conforme voy ayudando a más empresas a adoptar Scrum y progresar en la búsqueda de una mejor forma de hacer las cosas me voy dando cuenta de que, al final, resulta que los primeros tenían razón. Por lo menos una parte importante de la razón.

Me encuentro con frecuencia con empresas a las que estoy explicando lo que hacemos y me dicen “sí, bueno, nosotros ya hacemos Scrum”. Entonces utilizo el test de Nokia que el propio Sutherland ha enunciado muchas veces. Normalmente basta con preguntar “Ah, perfecto…Oye, ¿Y cuál es la velocidad de vuestros equipos?” para que se te queden mirando como si les estuvieses hablando en Sánscrito. Otras preguntas típicas incluyen “¿Puedo ver vuestro tablón de tareas?” o “¿Dónde guardáis la pila de producto con su prioridad y sus estimaciones?”. Una muy buena es “¿tenéis una persona identificada como Dueño de Producto, la única persona autorizada a incluir historias y cambiar sus prioridades?”. A la tercera o la cuarta las empresas comienzan a reconsiderar seriamente aquello de “nosotros ya hacemos Scrum” y lo cambian por “hemos tonteado un poco con las reuniones diarias y las entregas parciales”.

Lo peligroso de Scrum es que es muy atractivo leer un folleto sobre los rudimentos de Scrum en cinco minutos y a continuación decir “vamos a implantar esto” sin pararse a considerar qué es lo que hace que Scrum funcione y cuál es la mejor estrategia para implementarlo en su empresa concreta.

Porque al final implantar Scrum es un proceso de cambio, y uno además bastante serio. Scrum es sencillo, pero duro como una piedra, y encontraréis mucha resistencia. Los Jefes de Proyecto no querrán comenzar los proyectos sin tenerlo todo perfectamente identificado, acotado y planificado. Los desarrolladores no querrán la responsabilidad de estimar las historias y demostrar el producto. Los gerentes no querrán dejar tranquilo al equipo durante los Sprints. De hecho, hay en torno a un 40% de empresas que no lo consiguen en absoluto y un 20% que solo consiguen un modelo híbrido de Scrum, que les permite mejorar en su trabajo pero queda lejos del auténtico poder de Scrum desencadenado.

Por eso es importante, al menos en los comienzos, ceñirse a los principios de Scrum. Son reglas holísticas, empíricas, fruto de la experimentación en cientos de miles de equipos haciendo Scrum diarios por todo el planeta. Lo que ha funcionado para ellos bien puede funcionar para vosotros. Y luego, aplicad la regla del Shuhari: aprended la regla, experimentad con la regla y, cuando hayáis encontrado lo que realmente funciona para vosotros, disolved la regla.

Así que si estás entre las empresas que afirman “hacer Scrum”, piénsalo un par de veces y revisa tu proceso. Al fin y al cabo, de eso van las metodologías ágiles: empezar con algo aunque sea imperfecto y luego mejorarlo constantemente.

Comentarios
1 Juan Palacio
21 febrero 2008, 02:36

Hola Angel!

Al hilo de lo que planteas, por mi experiencia, sí que hay una fase de “iniciado” en la que con cuatro apuntes dices: “vale! ya hago Scrum”.
Noo! estás empezando; pero como dices: hay que empezar por algo y mejorarlo constantemente, no hay que tener complejos ni críticas paralizantes, que nadie nace enseñado.
De esta forma vas aprendiendo, y llega el momento en el que comprendes mucho más, y ves el modelo como Jeff o Ken lo vieron.
La cuestión ahora es ¿me paro?, ¿esta es la verdad?, ¿ya no se puede evolucionar, o continúo el proceso de mejora?. Claro que entonces volveremos a “no aplicas el Scrum ortodoxo como debe ser”.

Bueno!, pero entonces podríamos decir “nosostros hacemos Scrum” pero en el otro sentido.

Un saludo ;-)


2 Ángel Medinilla
21 febrero 2008, 02:59

Juán, un lujazo tenerte por aquí ;-)

Ishikawa decía que todo, hasta lo que está bien hecho, es mejorable. Y sin duda es mejor empezar por algo imperfecto y posteriormente aplicar Kaizen que pegarnos tres años intentando implementar una metodología. Yo, como digo en el artículo, soy partidario del Shuhari: comienza según las reglas, y luego haz aquello que te haga mejor, da igual si lo llamas Scrum o MyScrum.

Lamentablemente, de estos últimos aun no me he encontrado a ninguno: normalmente corresponden más al primer perfil… ;-)


3 Eduardo Cabrera
22 febrero 2008, 02:37

Desde el respeto, os comento que parece flotar en el post y los comentarios un tufillo metodológico-formalista que os encargáis de ventilar al final. Pero no del todo.

Me explico: Yo tb prefiero el Shuhari, pero es que si simplemente (y como ejemplo real) comienzo siguiendo la regla de meter al product owner en las reuniones de sprints (de duración variable incluso, venga) y con eso consigo implicarlo un mísero 0,5% más de lo previsto. Eso ya es mejora! y valor! ¿Hago Scrum? formalmente no (ni de lejos) ¿me ha ayudado Scrum? Decididamente sí ¿Resultado? He mejorado la gestión del proyecto ¿Conclusión? Scrum me ayuda aunque no lo siga formalmente.

Luego ya mejoraré el despliegue de Scrum… o no, porque lo que tengo que mejorar/aumentar es el valor generado, no otra cosa.

Saludos a ambos, artistas. Os sigo.


4 Ángel Medinilla
23 febrero 2008, 00:57

Eduardo, lo que se recomienda en el artículo es partir de un enfoque metodológico formal y LUEGO extender, particularizar y quedarnos con lo que nos funciona. ESO es ShuHari. Evidentemente eres muy libre de quedarte con el 0.5% de Scrum y conseguir una mejora del 0.5%, no hay una policía del Scrum que te multe, pero ni vas a conseguir toda la productividad y mejora que podrías si aplicases todo el método ni es cierto que “hagas Scrum”, que es de lo que me quejo (entre comillas) en el artículo.

Un Saludo y gracias por el comentario y por seguirnos.


5 Juan Palacio
23 febrero 2008, 18:10

Eduardo, no puedo estar más de acuerdo contigo. Si has interpretado mi comentario como “metodológico”, es que me he explicado muy mal. Es justo lo contrario.
Hay mucha gente que por ser metodológicos y seguir un CMMI “ortodoxo” o un XP, Scrum, DSDM… o lo que sea… se complican la vida.

Copio y pego del último párrafo de la introducción del libro que comparto en mi blog (Flexibilidad con Scrum”):

“Son los consejos que daría a un amigo, al que al mismo tiempo diría que siempre que sea posible, antes de copiar las formas de trabajar de otros, las cuestione, y si su realidad le demuestra que es mejor adaptarlas, que no lo dude. Por eso estas páginas no dan recetas para calcar, sino conocimiento que ojalá resulte útil para adaptar o diseñar las propias”

Un saludo!


6 Eduardo Cabrera
23 febrero 2008, 19:58

Creo que coincidimos en casi todo, entonces, pero no me resisto a matizar parte del comentario #4 de Ángel, donde dice: <em>ni vas a conseguir toda la productividad y mejora que podrías si aplicases todo el método ni es cierto que “hagas Scrum”</em>

Es que es ahí donde no coincidimos. Dejando claro que no soy un anti-metodologista y de hecho cuando un proceso lo tengo estudiado, diseñado, depurado e implantado me parto el alma por que se siga, tengo que decir sobre la anterior afirmación que no estoy de acuerdo. Aplicar Scrum, como cualquier otra metodología, ágil o no, no me garantiza nada. Nada. Bueno, me puede garantizar una certificación, pero estamos para mejorar el negocio, no el cumplimiento (que etimológicamente viene de “cumplo y miento” ;)

Es capacidad y virtud del gestor que la aplica escoger una aproximación ecléctica a ella, en función de las circunstancias, medios, etc, hasta el nivel de cumplimiento de la misma que genere el máximo coste/beneficio. Y esta última perspectiva es la que comentaba al principio que parecía ofuscada con el post y el debate posterior pero que amablemente habéis aclarado.


7 Crystyn
2 marzo 2008, 16:06

hola,. me ha gustado mucho este blog, he encontrado cosas muy interesantes. Me fascina navegar por la web, y encontrar blogs y más blogs como este. Por eso creo que tengo que compartir un concurso que acabo de encontrar, en donde regalan un Dominio y Hosting Profesional Gratis, para crear o mejorar los blogs,.. lo están haciendo en Bloggea2.com

http://www.bloggea2.com/2008/02/26/gana-un-dominio-y-hosting-profesional-gratis-con-bloggea2/

Yo ya me inscribí ;) , y sin ser egoísta, quería compartirlo con todos los lectores de este blog, y así ayudar a que existan más y mejores blogs..

Un Saludo..


Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.