Sprint Retrospective: Frmula de mejorar con xito

Con el fin de tener ningn efecto positivo, sus reuniones Sprint Retrospective
deben participar plenamente su equipo y dar resultados tangibles. He aqu una
lista de los componentes que debe tener para asegurar una reunin eficaz
Sprint Retrospective, que se traduce en un progreso real y mejorar con xito a
todos los niveles.
Retrospectivas regulares Sprint son clave para un proceso eficaz de Scrum,
pero muchas veces una retrospectiva se puede convertir en una reunin formal
aburrida que se celebra cada primavera. Los miembros del equipo pasan las
ideas de tiempo generando con un Scrum Master, pero el proceso general se
considera un mal necesario producir otro artefacto "muerto" sin una sola
intencin de mejorar nada.
Una buena reunin Sprint Retrospective conduce a una mejora
verdaderamente tangible en todos los niveles, y los miembros del equipo como
asistir porque pueden ver resultados considerables. `Ve estado presente en
ambos buenos y malos Retrospectivas de primavera, y` ve traducido mis
observaciones en una lista de componentes necesarios para garantizar los
mejores resultados.
Para una exitosa reunin retrospectivo hay que ir a travs de las siguientes
etapas:
Puntos positivos deltas
deltas Comentario
Completado Anlisis Artculos
Anlisis de las causas
La captura de causa raz
Elementos de accin
Persona responsable
Mejora xito
Vamos a discutir cada etapa en ms detalles.
ETAPAS COMUNES
Puntos positivos
Hablando de lo que ha ido bien durante el sprint es comn para todos los
equipos de Scrum, por lo que gan el `t se centran en ello en este artculo. Lo
importante es que no es suficiente para compilar una lista de elementos, `s
necesario recordar las decisiones y procesos eficaces y continuamente
utilizarlos en el futuro.
deltas

Otro escenario comn es que los equipos para crear una lista de elementos que
requieren mejoras.

Frecuentemente se salta ETAPAS

Los comentarios deltas
Incrementos deben presentarse en forma de hechos objetivos - y no conjeturas
o suposiciones subjetivas - es importante revisar la lista de deltas antes de
seguir adelante y asegurarse de que son realmente manifestaciones de un
problema real.
Por ejemplo, como parte de una retrospectiva de Sprint que asist, uno de los
deltas era un miembro del equipo mencionar que un desarrollador de una
aplicacin para el equipo integrado con no era parte del equipo Scrum. Cuando
empec a investigar lo que los resultados negativos fueron presumibles del
desarrollador no estar en el equipo, result que el verdadero problema era con
una funcionalidad publicada roto, y no con el desarrollador.
Esta observacin identifica el punto verdadero dolor de cabeza y el equipo
tiene la oportunidad de corregirlo. Si un anlisis de causa raz se lleva a cabo
con el problema real (que es "la funcionalidad publicada se rompe") y no con
una suposicin subjetiva ( "un desarrollador no es una parte de nuestro
equipo"), las posibilidades para corregir de manera rpida y crecer con xito
inmensamente.
Completado Anlisis Artculos
Otra etapa muy importante de una buena reunin Sprint retrospectivo es
analizar lo que se ha hecho desde el anterior Sprint Retrospective - no slo de
revisin que los puntos de accin de la retrospectiva anterior se ha
completado, sino tambin para analizar lo siguiente:
la realizacin de un elemento de accin particular, ha ayudado a corregir la
correspondiente causa de origen?
Ha Correccin de una raz-causa particular ayudado a evitar la repeticin de
este tipo de "deltas" en el futuro?
No siempre es posible descubrir la causa raz correcta en el primer intento. Lo
mismo ocurre con la correccin que - a veces se necesita ms de un intento
para definir el curso de accin ms eficaz.
Esta etapa ayuda a definir el grado de eficiencia cualquier solucin dada es y
decidir si se debe utilizar en el futuro o no. A menudo, los nuevos "puntos
extra" o "deltas" pueden ser aadidos a la lista durante la fase de anlisis.
Anlisis Causa Raz
El equipo debe revisar cada artculo delta para identificar las verdaderas
causas profundas de los artculos. Si hay muchos "deltas" que tiene sentido

para dar prioridad a ellos y tratar slo los ms crticos. Sin embargo, si hay
tiempo deben ser analizados todos los deltas. Bsicamente, cualquier tcnica
de anlisis de las causas puede ser utilizado, siempre que ayuda a identificar la
causa raz y es posible que a menudo varios "deltas" pueden tener la misma
causa.
La captura de causa raz

Esta etapa es la continuacin lgica de la anterior. Todava no he decidido

insistir en tener que en cada reunin retrospectivo, pero recomiendo
encarecidamente para capturar y guardar las ms importantes causas
profundas que usted el `VE definidos. Le ayudar a simplificar el "Anlisis de
Elementos completados" para la prxima etapa retrospectiva.
Elementos de accin
Esta parte de la reunin se dedica a la lluvia de ideas. Deje que su equipo
piensa en todas las formas de corregir la causa raz usted `ve sin tapar, a
continuacin, elegir la mejor y la solucin ms adecuada. Pero no hay que
olvidar que esta parte puede requerir la aprobacin de la direccin.
Persona responsable
Sus reuniones Sprint Retrospective siempre deben asignar a una persona
responsable de cada elemento. Esta persona ser el propietario del elemento,
impulsar su aplicacin y asegurar su terminacin oportuna. Deje que los
miembros de su equipo de voluntarios para los elementos de accin. Sin
embargo, no he decidido recomiendo designar ms de una persona que se
encargue de un elemento de accin. responsabilidad compartida no siempre
funciona bien, y dos o ms personas responsables de un elemento muy a
menudo significa que nadie es realmente responsable de la misma.
Mejora xito
Que tiene incorporados todos estos elementos en una reunin Sprint
Retrospective que se asegurar de que su equipo de captura:
Puntos positivos;
deltas reales y especficas (elementos para mejorar);
Sobre sus causas profundas;
Y los puntos de accin con la persona responsable designada.
Se llevar slo unos pocos encuentros para que usted note un progreso real
cuando se inicia la realizacin de sus Retrospectivas Sprint de acuerdo con esta
estructura. Los miembros del equipo podrn disfrutar de asistir al ver lo til y
eficaz los Retrospectivas son, adems de las mejoras generales.

Hay muchas maneras de hacer una retrospectiva de Sprint ms interesante y

para involucrar a su equipo. Hemos de tener en cuenta que una reunin de
Sprint Retrospective debe resultar en una mejora exitosa. Y, por supuesto, lo
mejor es que usted no espere hasta el sprint planeada reunin retrospectiva, si
hay un problema que necesita para corregir inmediatamente.
En mi prximo post `m va a discutir la planificacin de Sprint en Scrum, as que
estad atentos para ms!

2. En perspicaz libro de Doug DeCarlo eXtreme Gestin de Proyectos, que

identifica formas innovadoras para agilizar los procesos y simplificar el enfoque
de un equipo. gestin de proyectos giles, Scrum y en particular, pueden llegar
a ser abrumadora consumida por la metodologa, la jerga y reglas. Esto es justo
lo contrario de lo que se pretenda originalmente para proyectos giles de
plomo.
Al ser un facilitador gil y lder incluye las siguientes funciones y
responsabilidades principales:
Proporcionar orientacin
Motivar al equipo para entregar el proyecto a tiempoeliminar los obstculos
Proporcionar comunicaciones oportunas y eficaces
Es la parte de comunicaciones de nuestro papel que es tan importante. Vamos
a echar un proyecto Scrum por ejemplo.
Un scrum rpida Walkabout
Inicialmente, el alcance de un proyecto Scrum se define por el plan Scrum que
incluye una definicin de cada uno de los elementos del backlog producto
(caractersticas). Los elementos ms importantes de los clientes y de alto valor
comercial deben ser priorizados para ser implementado por primera vez y
desglosado en tareas en una sesin de planificacin de Sprint que es
impulsado principalmente por el dueo del producto. Una persona con el rol de
ScrumMaster designada facilita y gua al equipo

El equipo se rene frecuentemente (a diario) Scrums con la intencin de

discutir el progreso, eliminar los obstculos con el fin de reducir el riesgo y
ponerse de acuerdo sobre las horas de trabajo para completar restante. A la
finalizacin de cada ciclo de sprint, los resultados de la carrera son presentados
y discutidos en una reunin de revisin del sprint que participen todas las
partes interesadas, incluyendo al cliente. El proyecto debe ser dejado en un
estado probado, trabajando. El equipo decidir si lanzar o para continuar con el
siguiente ciclo de sprint.

Scrum no suele permitir nuevas solicitudes de funciones que se aadan sin

quitar otra todava-a-ser ejecutados por caractersticas, por lo que no debera
ser un riesgo mnimo de requisitos que se arrastra horario de impacto y costo.

ltimas palabras famosas

Con esta breve introduccin, el ScrumMaster es la clave para dirigir y facilitar

el equipo que requiere una comunicacin efectiva.

La comunicacin con el equipo y las partes interesadas

Desde una gua para la Direccin de Proyectos del Conocimiento (PMBOK
Guide) se refiere a la comunicacin como un 90% de papel de un jefe de
proyecto, el mismo compromiso debe debe solicitar ScrumMasters.

Cunto es suficiente la comunicacin? administradores de software no tienen

tiempo para comunicarse y directores de proyectos tienden a inundar el equipo
con demasiada informacin intil y forma de acogida demasiadas reuniones. En
contraste, la metodologa gil le gusta a dictar poca o ninguna documentacin
a la vez que mantener reuniones al mnimo. Esto no quiere decir que no hay un
montn de tiempo en la preparacin por el ScrumMaster.

En mi experiencia, muy centrado y comunicacin simple puede recorrer un

largo camino para asegurar que todos estn informados y que el equipo sabe
exactamente en qu concentrarse.

No es el papel de la comunicacin de todos modos? Vamos a definir

herramientas de comunicacin simples que pueden ser utilizados para la
priorizacin cartera de productos y para el seguimiento del estado del proyecto
Scrum ...

Definicin de los elementos de la Pila de Producto

Antes de entrar en la plantilla de hoja de clculo, recientemente he aprendido
sobre el poder de los mapas mentales en el artculo escrito por Claire Moss, en
la revista Better Software. Por qu perder el tiempo con adherencias en la
pared cuando se puede crear y ajustar elementos del backlog del producto con
las partes interesadas mediante la proyeccin de un mapa mental de estar
dibujo en la pared?

No puedo pensar en una mejor manera de identificar a los ricos de la

necesidad de la agradable para ricos. La mejor parte? Hay un montn de
potentes aplicaciones de software de visualizacin mapa mental disponibles
por un costo mnimo (o sin costo alguno). No slo son los mapas mentales una
gran herramienta para el intercambio de ideas, que sirven como activos
digitales para su proyecto, sin pasar horas transcribir crpticas notas de papel.

Estado del proyecto simplificado

Para hacer efectiva la comunicacin, la informacin debe ser concisa,
comprensible y aplicable. Y ah es donde ayudan a las herramientas de
software de gestin de proyectos. Cuando estoy llevando mltiples proyectos
giles y necesito para realizar un seguimiento, costes adicionales, las
dependencias y el uso de los recursos compartidos, recurro a LiquidPlanner. S
que hay muchas herramientas por ah, pero esta solucin basada en la web se
ha convertido en la Salesforce.com para ScrumMasters y gestores de
proyectos. Por otro lado, si ests trabajando con un solo proyecto a la vez, una
simple hoja de clculo puede servir como una herramienta de comunicacin
para rastrear grandes elementos clave de la mayora de cualquier proyecto.

He definido una sola hoja de hoja de clculo para realizar un seguimiento de

estado de un sprint proyecto. En aras de la simplicidad, asumiremos un sprint
semanal de cinco das hbiles:

La informacin sobre el estado del proyecto se hace un seguimiento y se

mantiene en pestaas individuales de hoja de clculo y se proyecta en la pared
y se actualiza en tiempo real con el equipo en las reuniones diarias del equipo
de proyecto. La hoja de trabajo se divide en secciones (A a F):

A. Hay dos partes. La celda superior identifica el nmero de sprint y el menor

conjunto de ventas muestran los elementos del backlog del producto
terminados, activos y an no iniciadas. Esta es llenada en la planificacin del
sprint.

tiempo disponible de B. El equipo del proyecto se resume en la planificacin del

sprint para todo el sprint en horas hombre.

C. Durante la planificacin del sprint, los elementos del backlog del producto
activo se divide en tareas a realizar. Los miembros del equipo deben recurrir al
pquer Sprint para estimar las horas para completar el trabajo. el total de
horas de cada individuo no deben exceder las horas disponibles. De lo
contrario, el trabajo no se ha subdividido adecuadamente los recursos
disponibles.

D. Todos los das del sprint, una nueva columna se rellena resume el total de
horas que quedan para cada tarea se complete.

E. Hay dos grficos que reflejan el progreso diario de horas de trabajo para
completar restante. El grfico de la izquierda da una visin de cada tarea (los
bloques de color ms grandes indican la mayor parte del trabajo restante). El
grfico de la derecha muestra las horas que quedan agregados programada
versus real. Los tres das restantes valores reales se trazaron como 0 debido al
hecho de que esos das estn en el futuro.

F. Por ltimo, si hay algunas notas especiales para iniciar la sesin, les entra
aqu. Este es un buen lugar para indicar riesgos, limitaciones o recursos que se
necesitan atencin.

Una palabra final

La cosa ms fcil de hacer es simplemente copiar y pegar esta hoja de clculo
y enviarlo despus de sus reuniones de proyectos diarios al equipo y luego tal
vez para el equipo ampliado y las partes interesadas despus de la revisin del
sprint. Un consejo que fuertemente sugerira es poner de relieve cules son las
tareas ms alta prioridad de cada miembro del equipo para el da.

Por qu hacer la planificacin de proyectos y seguimiento de proyectos

complicados? Si desea una copia de la hoja de clculo de usar, slo en contacto
conmigo en leadingswmaniacs.com.

3. Es obvio que la metodologa gil para proyectos de desarrollo de software ha

recibido mucha atencin en los ltimos aos. Se ha convertido de hecho en una
metodologa de desarrollo preferido tanto para lograr la eficiencia y para
obtener productos utilizables y las caractersticas en las manos de los usuarios
de forma rpida.

Soy un gran defensor de la metodologa gil para sus beneficios cuando sea
adoptada e implementada dentro de lmites razonables. Sin importar el sabor
particular de desarrollo gil abraz (como Scrum, Extreme Programming, etc.),
hay desafos - especialmente para los equipos y las organizaciones que tratan
de implementar un marco de desarrollo gil por primera vez. Hay una gran
cantidad de informacin fcilmente disponible por ah en relacin con diversas
metodologas giles. Hay herramientas de formacin bien establecidos y
recursos para ayudar a los equipos orientar a tomar-en este esfuerzo.
S, es esencial tener un buen conocimiento de la metodologa gil particular
que se est implementando. Tambin es fundamental para cumplir con los
pasos preparatorios de desarrollar habilidades entre el equipo de desarrollo de
software, as como el equipo de gestin de proyectos. Sin embargo, el aspecto
ms importante para lograr el xito del proyecto, finalmente, tiene que ver con
cmo se gestiona, mantiene y fomenta el equipo gil. Una cosa es tener
conocimiento de las reglas del juego, pero es totalmente otra para perfeccionar
el enfoque gil como profesionales. El director del proyecto, junto con los
gerentes funcionales puede hacer una gran diferencia al fomentar una
"mentalidad gil" ms all del contexto inmediato de las tareas del proyecto
del da a da.
Cualquiera que haya tratado con el desarrollo gil sabe que slo hay amplias
reglas de la metodologa. No hay una talla nica para todos,
independientemente del tipo de desarrollo gil siguieron. Cada equipo, cada
proyecto y cada organizacin es diferente - y se puede necesitar ajustes

apropiados para hacer que funcione de manera eficiente en cualquier situacin

particular.
Dado el nfasis en la auto-organizacin y los equipos autosostenibles que se
ocupan de todas las fases del SDLC dentro de un entorno de tiempo en caja, el
xito del proyecto depende del nivel de madurez que el equipo tiene en cuanto
a la prctica de una mentalidad gil.
stos son algunos de los aspectos de la disposicin gil el equipo necesita
cultivar para optimizar su forma de pensar. PMs pueden desempear un papel
vital en ayudar a los equipos de proyectos giles maduran.
1. El nivel de comodidad con el manejo de la ambigedad y la evolucin de los
conocimientos
2. nivel de logro que el rendimiento del equipo en lugar de la contribucin
individual
3. La disciplina de auto-gobierno como un equipo
4. Comprensin del objetivo ms amplio del proyecto
5. Disposicin para pedir ayuda y escalar los problemas sin vacilacin ni
demora
Problema de la ambigedad y el conocimiento en evolucin
Con la metodologa gil, el equipo y el PM a menudo tienen que manejar de
manera eficiente el proceso de captar la evolucin del conocimiento especialmente en lo que se endurecen los requisitos al comienzo del proyecto /
sprint. El equipo tiene que conseguir progresivamente mejor a hacer frente a la
ambigedad y la informacin incompleta travs de la interaccin constante con
los grupos de inters (o el dueo del producto). El jefe de proyecto puede
reforzar un enfoque positivo y progresivo haciendo hincapi en el hecho de que
frente a la incertidumbre es una parte del proceso, y ayudando a las tareas del
plan de equipo adecuadamente. En este proceso, los objetivos del proyecto no
se vean comprometidos mientras que todava hay un esfuerzo concertado para
ejercer una razonable flexibilidad para permitir que el equipo sea gil.
El concepto de xito de medicin
En proyectos giles, el viejo clich de edad "no hay un" yo "en equipo" necesita
ser practicado con sinceridad! A veces es un reto difcil que la mayora se dan
cuenta, especialmente para aquellos que la transicin a los equipos giles de
situaciones en las que se destacaron en gran medida a travs de las
contribuciones individuales. El PM tiene la responsabilidad de hacer que los
equipos no slo se dan cuenta de que el xito del equipo es la nica cosa que
importa, sino tambin fomentar una mentalidad donde el equipo cree en s
mismo con confianza para lograr un objetivo colectivo. El seguimiento del
progreso del proyecto por el PM puede volver a insistir en el enfoque de equipo.
Disciplina de auto-gobierno

Esto es una cosa difcil para el PM para controlar por completo. No puede haber
muchos factores sutiles que van a hacer un equipo de xito en la consecucin
del nivel de disciplina que necesitan para organizarse, incluyendo la calidad de
las interacciones, la co-localizacin, qumica personal, infraestructura de
comunicaciones, apoyo tecnolgico, etc. El PM puede aliviar este reto, en cierta
medida, facilitando lo que el equipo necesita de los grupos de inters o la alta
direccin. La PM tambin puede imponer expectativas razonables y claras en
cuanto a lo que el equipo necesita para entregar mediante el aprovechamiento
de su capacidad para organizarse. La conclusin es que el SPM pueden ayudar
a los equipos a mejorar en gobernarse a s mismos.
La motivacin y la conciencia de la meta ms grande
A menudo es ms fcil para que los equipos quedan consumidos por las tareas
diarias y metas casi a trmino, y es, de hecho, se espera de ellos. Sin embargo,
tambin es igualmente importante para el equipo para mantener la motivacin
porque entienden el contexto ms amplio del proyecto y el objetivo final /
producto que estn trabajando hacia. Los directores del proyecto, junto con los
dueos del producto pueden facilitar un entorno donde el equipo se mantiene
informado del impacto funcional y de negocio / econmica del proyecto en el
largo plazo. Esto tambin proporciona un marco eficaz para apreciar el esfuerzo
y el xito del equipo durante el proyecto. Esta informacin "cuadro grande"
puede subrayar la importancia del xito del proyecto y motivar positivamente
al equipo.
El pedir ayuda oportuna y escalada equipos giles eficaces se enorgullecen de
la capacidad de auto-gobernar y resolver los problemas a medida que se
presenten. De hecho, el director del proyecto est comprometido a trabajar
estrechamente con el equipo para capturar las necesidades puntuales de
escalada de problemas para mitigar los riesgos y minimizar el impacto adverso
sobre el proyecto. Sin embargo, los equipos giles necesitan estar en sintona
con la evaluacin de situaciones en las que hacer una eleccin entre invertir
ms tiempo para abordar los problemas, y burbujear el tema hasta la PM para
la escalada. El PMS puede ayudar a los equipos afilan este instinto por el
equilibrio entre la flexibilidad y la independencia del equipo tiene que abordar
los problemas con la mnima intervencin, y activamente tratndolo como una
cuestin de proyecto cuando sea necesario para mitigar los riesgos ms
grandes.
La gestin de proyectos giles requiere muchos componentes, y todos los
interesados inmediatos tienen responsabilidades especficas dentro de la
metodologa gil elegido con el fin de tener xito. Ms all de todas las reglas
de juego y "debera" requisitos, el mantenimiento y el fomento de una
mentalidad gil dentro del equipo es extremadamente crtica. Esto puede
distinguir "grandes" equipos de equipos "buenos" y los directores de proyectos
puede tener gran influencia en la conformacin de un equipo gil para tener
mucho xito.