Luego de pasar mucho tiempo desarrollando software de la llamada "manera tradicional", me doy cuenta que muchas cosas se pudieron hacer mejor si se hubiera utilizado metodologías ágiles como scrum.

En ocasiones recuerdo cuando teníamos reuniones con algún cliente, nos solicitaba un software que hiciera aquella función u otra , pero no daba mas detalle, no acompañaba el desarrollo, solo esperaba que para el tiempo que el tenia estipulado, se concretara un proyecto y que funcionara a las mil maravillas.

Con que ilusión asentábamos con la cabeza sin reprochar, sin confrontar, sin siquiera recabar por mas información. Pero bueno, como dicen por ahí siempre hay una luz al final del camino y esta me parece hasta hora es SCRUM.

No quiero entrar en definiciones exhaustivas  pero les daré la definición que le doy a la gente cuando me pregunta que es scrum: "SCRUM es un marco de trabajo flexible en el que las personas, las interacciones, la confianza, el software funcionando y respuesta ante el cambio son los principios que rigen el desarrollo de un proyecto".

Luego resulta la pregunta de que ventajas tiene esto respecto a los otros métodos de trabajo, y por donde empezar: 
Bueno pues el equipo de desarrollo se pone las metas para el sprint
Hay re-alimentación  temprana de parte del cliente
El equipo se siente valorado
El cliente se integra al desarrollo del proyecto
Si hay algún problema se busca una solución , se prueba , si funciona esta bien, sino, se busca otra y listo.
No hay sobreesfuerso.

y muchas otras más.

Bueno pero como esto se trata de contar la experiencia con scrum, puedo decir que me gusta, facilita la realización de los proyectos, no se carga una persona con el conocimiento de un negocio, sino que un equipo esta en capacidad de hacerlo por si solos. 

Para poder ser conscientes del cambio que hay que dar, se debe empezar por dejar "el ego atrás"  pues siempre es el primer impedimento silencioso que nos hace reacios al cambio.

Y este punto es muy importante pues si veníamos trabajando de otra forma, algunas veces somos héroes que conocen código que nadie mas a tocado o quiere tocar, algunas veces conocemos negocios que son complejos, y explicarlos son una tarea difícil , otras veces  dejar a cargo a alguien cuando uno se va de vacaciones es una pesadilla, siempre lo van a llamar a uno.

Estas y muchas más situaciones me habrán pasado con los años y que probablemente se me olvido mencionar. Debo aclarar que esta es mi muy humilde y sincera manera de contarles mis experiencias usando SCRUM para el desarrollo de software.

Echa un vistazo al Tweet de @svalencian: https://twitter.com/svalencian/status/381974286690295809
Por qué insistimos en que todos los equipos hagan retrospectivas 

Lo más importante de las retrospectivas es asegurarse de que tienen lugar. Aun así, todo el mundo coincide en que las retrospectivas son extremadamente  útiles. De hecho, yo diría que la retrospectiva es el segundo evento más importante de Scrum (siendo el primero la reunión de planificación de Sprint) ya que ¡es tu mejor oportunidad para mejorar! 

Difundiendo las lecciones entre los equipos
Reglas importantes para la persona que actúa como “puente de conocimiento”:

• Debería ser bueno escuchando. 
• Si la retrospectiva es poco activa, debería estar listo para realizar preguntas simples pero bien apuntadas para estimular la discusión dentro del grupo. Por ejemplo, “si pudierais rebobinar y hacer este Sprint otra vez desde el día 1, ¿qué haríais de forma diferente?” 
• Debe estar dispuesto a pasar tiempo visitando todas las retrospectivas de todos los equipos. 
• Debería tener algún tipo de autoridad, de forma que pueda actuar sobre las sugerencias que estén fuera del control del propio equipo.

Descansos entre Sprints 
Como mínimo, intentamos que la retrospectiva y la subsiguiente reunión de planificación de Sprint no ocurran el mismo día. Todo el mundo debería tener al menos una buena noche de sueño sin Sprint antes de comenzar el siguiente Sprint.

Scrum se enfoca en las prácticas de organización y gestión, mientras que XP se centra más en las prácticas de programación. Esa es la razón de que funcionen tan bien juntas: tratan de áreas diferentes y se complementan entre ellas. 

Ritmo sostenible / trabajo enérgico
Hace cosa de un año uno de nuestros equipos (el más grande) estaba trabajando un número insalubre de horas extra. La calidad de la base de código era pésima y habían pasado la mayor parte del tiempo apagando fuegos. El equipo de pruebas (que también estaba haciendo horas extra) no tenía ninguna 
posibilidad de hacer aseguramiento de la calidad en condiciones. Nuestros usuarios estaban enfadados y la prensa nos estaba devorando vivos. Después de unos meses conseguimos disminuir las horas de trabajo a un nivel decente. La gente comenzó a trabajar en horarios normales (excepto durante 
algunas crisis de proyecto, a veces). Y, oh sorpresa, la productividad y la calidad mejoraron notablemente. Por supuesto, reducir las horas de trabajo no fue en absoluto el único aspecto que condujo a la mejora, pero todos estamos convencidos de que tuvo mucho que ver.

Cómo hacemos pruebas 
Nuestra experiencia nos dice que eso rara vez funciona. Habrán errores graves. Si la calidad tiene algún valor para ti, es necesario algún tipo de fase de pruebas de aceptación manuales. Se trata de que encargados de pruebas dedicados que no son parte del equipo machaquen el sistema con ese tipo de pruebas que el equipo de Scrum no pudo imaginar, o no tuvo tiempo de hacer o no contaban con el hardware necesario para implementar. Los encargados de pruebas acceden al sistema en la forma exacta en la que los usuarios finales lo harán, lo que significa que debe hacerse manualmente (asumiendo que tu sistema sea para usuarios humanos).

Así que ¿cómo maximizamos la calidad del código desarrollado por el equipo Scrum? Bueno, hay muchas maneras. He aquí dos que nos funcionan muy bien: 
• Incluir encargados de pruebas en el equipo Scrum - Me parece una buena práctica aunque las empresas consideren que no es necesario.
• Hacer menos cosas en cada Sprint.

El encargado de pruebas es quien da el visto bueno.

Un bonito efecto secundario de esta práctica es que el equipo tiene ahora una persona que está perfectamente preparada para organizar la Demo del Sprint.