What is Scrum?
Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices. Scrum has been used from simple projects to changing the way entire enterprises do their business.

Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development. Learn more... For an overview audio of Scrum, click here. For a video of Scrum, quality, and enterprise competitiveness, click here. For an description of Scrum in the Financial Times : The London Financial Times interviews Ken Schwaber and Ian Shimmings of Conchango about Scrum.

Scrum VSTS - Scrum Tutorials and Tool
Learn more about Scrum through a multimedia kit, or download a Scrum kit for Microsoft VSTS. Both are provided through the hard work of Conchango. Also available is eScrum, built by Microsoft also for use with the VSTS platform.

Scrum Alliance
The home of the Certified ScrumMasters organization, offering training, gatherings, information, and materials regarding Scrum, including frequent articles..
ScrumMaster Certification

To acquire the formal Scrum methodology, Scrum Project Management software, and training - or to find a Certified ScrumMaster to help you implement Scrum, go to ScrumAlliance. To learn iterative, incremental development the agile way using Scrum, the next ScrumMaster Certification classes that I teach :

When
Where
Registration

Video de scrum aplicado a las empresas

http://video.google.com/videoplay?docid=-7230144396191025011&q=Google+Tech+Talks&hl=en

La dificil tarea de planificar

Unos de las tareas mas difíciles (si no la mas difícil) a la que nos enfrentamos al abordar el desarrollo de software es realizar la planificación del trabajo a realizar. Para muchos proyectos necesitamos realizar una planificación bastante detallada ya sea para presentar un presupuesto a un cliente o si es una aplicación interna para estimar las fechas de entrega. También hay que tener en cuenta que este plan los vamos a tener que ir revisando Sprint a Sprint para adaptarnos a los cambios que nos encontremos por el camino.

Un buen recurso donde podemos aprender como planificar proyectos si utilizamos Scrum es el libro Agile Estimating and Planning, cubre todos los pasos necesarios para realizar la estimación, la planificación y el seguimiento de los proyectos.

El libro se divide en en siete partes:

Parte I: Realiza una introducción al propósito de la planificación y a la planificación ágil en particular.

Parte II: En esta parte se adentra en estimar el tamaño del trabajo a realizar. Nos proporciona dos medidas para calcular el tamaño, los puntos de historia y los días ideales.

Parte III: Una vez estimado el tamaño tenemos que priorizar las historias para saber en que orden se van a desarrollar.

Parte IV: Lo siguiente es decidir la longitud de las iteraciones y calcular la velocidad para calcular cuanto vamos a tardar en recorrer el tamaño estimado y en base a esto decidir las fechas de entrega. También nos explica a usar los buffers como herramienta para manejar la incertidumbre.

Parte V: Una vez comenzado el proyecto tenemos que realizar un seguimiento del proyecto comparándolo con lo planeado y adaptar el plan si fuera necesario.

Parte VI: Porque la planificación ágil funciona.

Parte VII: Un ejemplo practico donde se pone en acción todo lo visto anteriormente.

En definitiva un libro muy recomendable donde se expone de manera clara y practica todo lo necesario para poder planificar nuestros proyectos si utilizamos Scrum.

Scrum aplicado a la implantacion de ERPs

En uno los proyectos de gestión de la implantación de ERPs en los que estoy envuelto ahora estoy viviendo un pequeño infierno.Requerimientos que se tomaron hace escasamente tres semanas han sido cambiados por el cliente radicalmente, y más de una vez, desde el momento en que revisó el documento donde el implantador había documentado su análisis.

Lógicamente éste se ha rebotado y ya ha empezado a hablar de ampliaciones en el proyecto, algo que ha erizado el pelo de mi cliente. Nosotros en medio e intentando reconducir la situación... (sí ya se, otro proyecto que es igual)Y es que el proceso de toma de requerimientos, su transformación en un diseño/modelo para la configuración posterior del ERP en general está muy mal resuelto por monolítico y poco ágil.

Es muy complicado, por no decir imposible, clavar en un documento los requerimientos del cliente - siempre hay matices o situaciones y que se les acaban ocurriendo cuando acaban viendo el sistema en funcionamiento. Históricamente se han utilizado prototipos que aunque mejoran la situación no acaban de resolverla.Para romper este enfoque en cascada echo mucho de menos el poder aplicar en las implantaciones de ERPs una metodología como scrum, donde los requerimientos se van cerrando por el (y al) cliente a medida que el producto se va desarrollando y perfeccionando por el equipo.

Pero a ver quien convence a un cliente de que el proyecto de implantación de su ERP no tiene una planificación con un alcance cerrado y conocido de antemano, aunque esa planificación siempre se incumpla.Este es un tema, scrum aplicado a la implantación de sistemas de información, que me gustaría desarrollar en algún post.

Aqui te mostramos un video de lo complicado que se puede tornar la toma de requerimientos:

http://www.youtube.com/watch?v=glnrQ2fymSg

DESARROLLO INNOVADOR CON SCRUM

SCRUM está en la línea de los módelos ágiles de gestión de los que ya hablé hace algunos meses. Algunas de sus principales asunciones son:
los productos y por tanto sus especificaciones están en constante evolución y en un entorno de incertidumbre,
lo que determina el éxito de un producto es incorporarle valor para sus usuarios,
la rápidez y la flexibilidad en la evolución de los productos son un valor diferenciador muy importante
SCRUM se está utilizando actualmente en empresas referentes de nuestro sector como Google, y tanto para pequeños como para grandes proyectos.
El libro insiste en que ninguna metodología es la mejor para el 100% de los casos, sino que depende del proyecto, del producto, de la empresa, … En mi opinión, tampoco es necesario aplicar una metodología concreta 100%, sino que pueden aprovecharse las ventajas de cada una para determinadas tareas, por ejemplo, estabilización de aplicaciones.
¿En qué puede traducirse esto en nuestro ámbito de trabajo? Pues, por ejemplo en:
Formación de equipos multidisciplinares, en los que intervengan los clientes, desarrolladores y usuarios
Especificación continúa y flexible
Solapamiento de fases del modelo en cascada
Generación de más versiones de producto, con menos delta de funcionalidad entre ellas, pero que vayan aportando un valor importante
Feed-back rápido de las funcionalidades que se van desarrollando por parte de los usuarios
Flexibilidad en la identificación de las prioridades a desarrollar en cada momento
Creación de equipos autogestionados y automotivados de profesionales brillantes
Para terminar, os incluyo un diagrama con el flujo de actividades típico que propone SCRUM. Creo que algunas ideas las vamos incorporando (como las reuniones de sprint, que corresponderían con reuniones de seguimiento).

FUNCIONA SCRUM

¿En Realidad Funciona?La premisa básica de scrum, y en gran medida de los métodos ágiles, es que si el colaborador está comprometido con el equipo de trabajo, y el jefe confía en ellos, entonces el equipo invierte el tiempo en producir algo, en lugar de estar justificando el avance o falta del mismo. Esto reduce la necesidad de reuniones y reportes de situación. Básicamente, se parece mucho a las tareas universitarias, en las que el profesor dice qué hay que hacer y cuando hay que entregarlo. Al principio, todos los involucrados, y en especial el equipo de trabajo, se sentirán extraños, pues no hay una estructura centralizada de control. Pero en el momento en que el equipo se organiza, la falta de control central se vuelve la principal ventaja del método.
Es muy difícil otorgarle al equipo de trabajo el control que requiere scrum. La técnica es aventurada, y existe un riesgo de toparse con límites reales, que puedan llegar a cancelar el proyecto. Una falla puede tener mucho impacto en los miembros del equipo de trabajo por los niveles de envolvimiento personal con el proyecto.
Lo Que No FuncionaA continuación comparto una lista de las trampas más comunes de una implementación primeriza de scrum en una organización con métodos tradicionales, y que en mi experiencia son señales claras de que no se está trabajando de acuerdo al principio inicial de scrum de autorregulación.• La junta scrum no es un reporte de avance. Los participantes del equipo deben ver la junta scrum como una oportunidad para resolver sus problemas inmediatos. Una clara señal de que las juntas no están funcionando como deberían es que los integrantes del equipo miran al dueño del scrum y le relatan sus actividades, como en un reporte de situación, en lugar de hablar entre ellos o solicitar la intervención del dueño del scrum en algún asunto relacionado con las áreas periféricas de la organización. • No se contemplan todas las actividades necesarias en el sprint. Esto es, se viola el principio del sashimi, siempre tener un producto entregable para el usuario final. Es muy común que en los primeros sprints se olviden algunas actividades, típicamente las que se podrían clasificar de poco ágiles o poco sexy, como mantener los documentos o los manuales de usuario. Es normal, pero también es importante que se corrija el rumbo una vez detectado esto. Una actividad no puede considerarse completa sin estos productos adicionales. El dueño del scrum debiera desincentivar que un miembro del equipo cambie de actividad antes de terminarla por completo.• Interferir con el equipo de trabajo durante el scrum. Es muy tentador para el dueño del producto acercarse al equipo para solicitar un pequeño cambio. Y es también muy fácil para el equipo aceptarlo – al fin y al cabo, estamos siendo ágiles, ¿o no? El dueño del scrum debe combatir estas intervenciones para mantener al equipo centrado en entregar la funcionalidad en tiempo y en forma.
Referencias• www.controlchaos.com • Ken Schwaber. Agile Project Management with Scrum.

2004, Microsoft Press

SCRUM EN LAS EMPRESAS

¿Por qué no aplicar Scrum en toda la empresa considerando a la organización en su conjunto, como un todo sistémicamente relacionado?
¿Por qué acomodar la empresa a la "forma" del modelo?: Sea la forma de Scrum o de DSDM o de CMMI. ¿Por qué no considerar a las formas como lo que son, y emplear los fondos de conocimiento que hay tras ellas para componer un modo de trabajo apropiado a las características de la empresa y de sus proyectos?
Scrum puede "implantarse" (forma) o "institucionalizarse" (fondo); y proporciona mayores cotas de agilidad cuanto más ágil es la empresa en su conjunto.
Poner un ScrumMaster en el departamento de programación de una empresa con visión y cultura apuntando en otra dirección, o sencillamente sin visión; con un área de RR.HH. no alineada hacia una gestión de personal ágil (gestión del conocimiento); con un departamento de marketing o de producto sin implicación en roles de propietario de producto; con áreas administrativas y comerciales trabajando sobre patrones de contratos de planificaciones cerradas... es una combinación peligrosa que suele producir empresas fragmentadas.
Más que aplicar una "forma" para el área de desarrollo se trata de gestionar la empresa en su conjunto desde los principios de agilidad. Es más una tarea de "Scrum Manager" que de "Scrum Master".
¿Por qué no trabaja el departamento de marketing en un campo de scrum?. ¿Por qué los directivos de la empresa no tratan la estrategia de la organización en un campo de scrum?. ¿Por qué no es ágil toda la empresa?.
Las siguientes son las líneas directrices de esta visión de "gestión scrum" en cuyo desarrollo colaboro con Claudia (buena amiga y consultora de procesos de software) y que compartimos aquí con todos a los que os puedan resultar útiles.
El fondo de esta gestión scrum es la síntesis de conocimiento producida por la resolución dialéctica de las iniciativas de procesos (CMMI, ISO, PMI) y de agilidad. De ésta toma el modelo de Campo de Scrum como entorno para el desarrollo de los proyectos.No emplea prácticas de áreas de procesos o patrones ágiles de forma cerrada.Sobre la base de los entornos de trabajo definidos a finales de los 80 como Campos de Scrum, plantea principios que ayudan a la gestión para determinar la forma más apropiada a su organización y su proyecto.


http://www.navegapolis.net/content/view/613/