(s6-1) Retrospectivas en tu entorno

¿Qué forma de aprendizaje usan en los ambientes laborales y personales que los que participas?

Contá un ejemplo, evaluando su efectividad (se logran mejoras) y eficiencia (el tiempo y esfuerzo dedicado en relación a los resultados obtenidos.

5 puntos

Anuncios
Publicado en Sin categoría
21 comments on “(s6-1) Retrospectivas en tu entorno
  1. Julián dice:

    Delegación de Actividades

    Cuando llegan personas nuevas, los jefes o supervisores no dan la bienvenida o capacitación correspondiente al nuevo trabajador, delegando estas tareas a otro empleado. Esto hace que algunas funciones no se hagan con las normas y procedimientos definidos por la empresa y se deja mas a la subjetividad del empleado encargado.

    Trabajo y Recompensa:

    Cuando se cumplen las metas y los objetivos planteados, se suele dar beneficios (como por ejemplo bonos, dinero, comisiones, dia de descanso). Pero esto tiene cosas buenas, pero mas cosas malas, ya que fomenta la competencia entre compañeros. Puede que aumente la productividad del negocio, los tiempos y demás, pero internamente se generan conflictos entre compañeros.

  2. En mi entorno laboral, las retrospectivas constan de dos reuniones semanales en las que se encuentra y participa la mayor parte del equipo y en las que se aprovecha para ajustar detalles, poner al tanto a todos de las novedades o problemas surgidos, mostrar avances, plantear dudas y elevar oportunidades de mejora. Estas reuniones son de carácter mas bien informal. Su efectividad es relativa ya que al ser informal, en ciertas ocasiones, existen puntos importantes que se tratan muy en el aire y se pierden, dando paso a confusiones o pequeños malos entendidos que pueden retrasar la ejecución de algunas tareas.

  3. Leandro Esteban Gallippi dice:

    En mi trabajo se utiliza una ERP para indicar los tiempos estimados para cada una de las tareas y luego el encargado de la tarea incluye los tiempos reales de la realización de esta. Al final de cada proyecto se comparan los tiempos reales con los estimados como para poder utilizar esta medición en futuras estimaciones. En cuanto a eficiencia, la realidad es que demanda tiempo y esfuerzo tener que estar pendiente del ERP todo el tiempo, pero el método de aprendizaje resulta bastante efectivo para poder ir reduciendo cada vez más la cota de error entre tiempos estimados y reales.

  4. En mi entorno laboral utilizamos una técnica, que es la que se llevo a cabo en la clase, que es la de los 5why’s. Básicamente es una técnica interrogativa que se pregunta ‘por qué?’ hasta 5 veces para deteerminar la causa raiz de alguna situación en particular. Realmente es bastante efectiva y se llegan a buenas conclusiones. En relación al esfuerzo que se dedica para llevarla a cabo es poco en relación al beneficio que se obtiene de ella.

  5. Uriel Kusnesov dice:

    En mi entorno laboral durante un proyecto largo que tuvimos, se hacian reuniones de retrospectiva luego de cada sprint y luego al final del proyecto de desarrollo (luego hubo uno de soporte) una retrospectiva mas larga con varios representantes del cliente.
    En las retro de cada sprint se dedicaba una media hora a que cada uno pudiera decir que problemas tuvo y entre todos propongamos solucion. No era algo muy formal, pero quedaba claro cuales eran los problemas del proyecto ya que habia coincidencias entre los miembros del equipo sobre ciertos problemas.
    El esfuerzo que tomaba no era mucho pero la relacion con el beneficio no fue buena, ya que habia lecciones aprendidas y se identificaban los problemas y posibles soluciones pero no quedaba un responsable claro para tomar acciones que tampoco estaban del todo definidas.
    Por esto es que varios de los problemas continuaron a lo largo del proyecto y volvieron a salir a la luz en le retrospectiva final.

  6. Ezequiel Reyes dice:

    En primer lugar en mi entorno laboral, se lleva a cabo una reunión diaria que toma entre 15 y 20 minutos al comienzo del día dentro del equipo, en esa reunión se informa sobre las tareas en las que se estuvo trabajando el día anterior, se fijan tareas del mismo día y se da una mano cuando alguno tuvo un problema en alguna US. En ese sentido me parece muy efectiva la daily a pesar de que tome un tiempo todos los días.
    Por otro lado también contamos con capacitaciones en herramientas nuevas, y reuniones mensuales de retro donde se ven los números de las estimaciones vs hs trabajadas, retrabajo y etc, allí sacamos puntos en los que hay que mejorar, puntos en los que mejoramos respecto a la retro anterior y un panorama mas grande de los proyectos actuales.
    Me parecen también bastante efectivas porque se desarrollan acciones en los puntos a mejorar y por lo gral se logra reforzar los puntos flojos que se tuvo en el mes.
    Por el lado de las capacitaciones, en algunas se sacan provecho y en otras no tanto, dependiendo siempre de “la cancha” que tiene aquel que da la capacitación en cuanto a la transmisión de ideas.

  7. frossi85 dice:

    Use Restrospective en varias empresas. En Globant hacíamos retrospectiva al final de cada sprint. Ahi se hablaban de varias cosas como la diferencia entre las estimaciones que hicimos y los tiempos reales, si hicimos algunos features que luego fueron descartados, problemas con definiciones funcionales y problemas humanos dentro del equipo. Al final se repasaban los puntos y se los anotaba en una lista asignándole un owner. No se dedicaba mucho tiempo a estas reuniones pero el resultado a veces no era el esperado por falta de tiempo para ejecutar esas acciones y cuando eran problemas humanos por lo general la gente no tenia autocrítica.
    En otra empresa, hacíamos retrospectives mayormente cuando había un downtime en la plataforma, entendíamos primero por que sucedió downtime y luego hacíamos brainstorming para proponer mejoras para que eso no pase. Al final armábamos un plan de acción y lo ejecutabamos.
    En ambos casos siempre se aprendía luego de las retrospectivas, pero no quería decir que que corrigieran ya que había cuestiones de tiempos en el proyecto o humanas que eran difíciles de cambiar.

  8. Fernando Cortes dice:

    En mi trabajo, en el proyecto que estoy actualmente, estamos trabajando con sprints de dos semanas.
    Los miércoles se hace la demo con el cliente de lo avanzado y se hace la planning del nuevo sprint.
    Al otro día se realiza la retro del sprint, la cual consiste en revisar los items anotados de las retros anteriores para debatir si fueron solucionados, mejorados o no fueron alcanzados ni abordados.
    Luego se procede a hacer un keep-fix-try, donde cada miembro del equipo toma unos cuantos post-it y procede a anotar las acciones que cree que deben hacerse saber al grupo. Se divide un pizarron en tres columnas (keep, fix y try) y de a uno a la vez los miembros del equipo vamos pegando los post-it en la columna correspondiente y explicando las razones del post-it.
    Al finalizar, el facilitador (en nuestro caso el PL, Scrum Master) toma nota de cada uno de los issues que surgieron, sobre todo las cosas a mejorar y las deja accesibles a todo el grupo para que las tengamos en cuenta en el próximo sprint (publicándolas en Trello por ejemplo).
    En mi opinión creo que tiene sentido la retro porque se debaten temas que nos afectan a todos y al éxito del proyecto. Creo que es el espacio indicado para hablarlos porque durante el sprint los miembros del equipo pueden no compartir la oficina, tener actividades extras, estar también en otros proyectos… Pero creo que debe durar entre 30 y 45 minutos. Por lo que debe estar bien organizada antes de ser realizada para no perder tiempo, ya que concurren todos los miembros del equipo.

  9. Mart dice:

    En un proyecto realizado en equipo se hacían reuniones cada dos semanas, al finalizar el sprint, donde el grupo realizaba una retrospectiva. Al finalizar el proyecto se realizó una reunión especial extra para evaluar todas las lecciones aprendidas.

    En cada una de estas reuniones se expresaba todos los inconvenientes y también soluciones encontradas a los mismos, tratando de aportar experiencia a lo vivido por el grupo.

    El tiempo dedicado fue medianamente corto, pero su aprovechamiento fue muy fructífero, ya que dejó aprendizajes de utilidad para el equipo de trabajo, ya sea para próximos sprints o para otros proyectos a encarar.

    Saludos,
    Mart.-

  10. Hoy en día estoy trabajando en un proyecto donde solo somos dos desarrolladores y un QA, por lo que las reuniones de retrospectivas son bastante informales, es por eso que pedí estar en una de uno de los otros proyectos.

    En este proyecto realizan iteraciones de 1 semana, dado que es un proyecto corto y necesitan actuar rápido. Es por eso que todos los viernes, antes de la planning, realizan una reunión de retrospectiva donde analizan si los compromisos de la reunión anterior fueron cumplidos y si realmente significaron una mejora al modo de trabajo. Luego tratan de identificar cuáles fueron las principales trabas del sprint y que creen que deben mejorar enseguida. Priorizan los puntos enunciados y analizan cuáles creen que son los más urgentes y pueden tomar.

    Suelen ser reuniones bien cortas, ya que el equipo es chico y sus iteraciones son cortas.

  11. Guido Laghi dice:

    En mi trabajo somos 4 personas. No había retrospectivas formalizadas, sin embargo empezamos a hacerlas desde hace 2 meses. Encontramos un espacio planificado y disponible para proponer mejoras y señalar problemas.

    El tiempo invertido es de 30 minutos aproximadamente.
    La efectividad o mejoras conseguidas aun no está del todo claro, pero entiendo que con el pasar del tiempo se van a ir consiguiendo.

    En todas las reuniones dedicadas a este tema, siempre hubo buena predisposición, interés y como dije previamente, encontramos un espacio especial para señalar e identificar items para pulir.

    La forma es que las estamos orientando es usando 3 categorias. Keep, Fix. Try. Luego agrupando coincidencias y posteriormente profundizando cada una para buscar coincidencias o diferencias y planes de acciones de ser necesarios.

  12. En mi trabajo en este momento somos pocos en el área de desarrollo y la empresa está reestructurando algunos sectores. Nuestras retrospectivas suelen estar orientadas a nuestra posición frente a los líderes de otras áreas (algunos incorporados recientemente), como está siendo la comunicación con ellos, y los resultados obtenidos durante la semana (desarrollamos sofware para uso interno de la empresa).

    Las retrospectivas son más bien informales, pero surgieron naturalmente por necesidad del equipo volviéndose una costumbre todos los Viernes, por lo que el intercambio de ideas suele ser bastante fluido. La participación es optativa, aunque suelen participar todos, el tiempo dedicado normalmente no supera los 30 minutos.

    Las ideas surgidas y acciones a tomar, suelen quedar anotadas en la pizarra para tener presente durante la semana.

  13. Hacemos retrospectivas de sprint. Es una reunión donde el equipo discute qué mejorar. Igual que las otras reuniones de Scrum, hay un ScrumMaster responsable de que la reunión se haga y la facilita.
    Los propósitos, básicamente, son:
    – Intentar pensar honestamente como fue el último Sprint discutiendo varios puntos, como nuestras habilidades, relaciones, procesos, ambiente de trabajo, etc.
    – Descubrir qué cosas del sprint anterior se pueden o deberían mejorar
    – Mejorar el procesos
    Las reuniones ayudan a adaptar el uso de Scrum y también a analizar como está progresando el equipo. Comparamos el estado actual del equipo con el estado deseado, identificamos diferencias y qué cambios deberían hacerse para mejorar. Realmente se logran mejoras.
    Se hacen al finalizar el sprint, cuya duración puede variar, pero suele ser de unas dos semanas. La reunión en sí dura una hora.

  14. En mi trabajo hacemos retrospective todos los Miércoles cada 15 días y a continuación la planning. Al día siguiente se procede a realizar la review meeting entre el equipo de desarrollo, el funcional, testing y la dirección del proyecto.

    En las retrospective se hace mucho encapié en cómo estuvo el sprint de cada uno, qué dificultades tuvo y si se recibió suficiente “input” por parte del equipo funcional. También se corta rápidamente a los desarrolladores que comienzan a relatar las acciones técnicas que realizaron durante el sprint pasado.

    Se hace mucho énfasis en la comunicación y se toman acciones correctiva en el próximo sprint de ser necesario, las ideas principales quedan documentadas en un documento de word de google compartido y las reuniones suelden durar 30 min.

  15. Matías S. Manzano dice:

    En el proyecto en el que me encuentro trabajando ahora no usa metodologías ágiles, sino es mas bien un proyecto orientado a PMI, y lo que usamos como posible punto de mejora son reuniones con el equipo de trabajo, donde se revisa el gannt y los compromisos, y cada quien habla sobre lo que estuvo trabajando y con que problemas se topó, si pudo resolverlos o no y cuanto tiempo lo demoró. A raíz de eso surgen varias sugerencias por parte del resto del equipo que muchas veces nos ha servido para adoptar algún enfoque que mejore la productividad o el trabajo en equipo. Sirve además para afianzar al equipo y que cada quien este en contacto con lo que está haciendo la otra persona. El tiempo insumido es de 1 día (8 horas) al mes. En cuanto a la productividad del acto, podría ser mejor si se redujera un poco el tiempo perdido por practicas viciosas de las reuniones, pero en líneas generales logra un efecto positivo de cambio.

  16. Sebastian Rial dice:

    En donde trabajo somos pocos y las retrospectivas se basan en pensar en los items que no se cumplieron y cuales fueron las causas. En forma divergente se planteaban las diferentes causas posibles y luego se concreta cuales fueron realmente principales y se las anota.

  17. Juan Manuel Agüero dice:

    En los ambientes laborales que participo, usamos retrospectivas de sprint y de proyectos.

    Como los sprints suelen ser semanales, las retrospectivas de sprint son los viernes a última hora. En general tratamos de que siempre se hagan y usamos técnicas variadas. Pero si estamos con muy poco tiempo lo que hacemos es una “fast retro” con una tabla de “mas delta”. Donde en una columna ponemos lo que hicimos bien y queremos que continue, y en la otra columna ponemos lo que tenemos que mejorar.

    Las retro de equipo las hacemos cuando finaliza un proyecto. Esto nos sirvió muchísimo para no repetir errores, y para aprender de lo que hicimos bien.

  18. nicolascoco85 dice:

    Les cuento que los sábados trabajo ad honorem para una parroquia humilde del barrio de la boca, durante el año utilizamos esta técnica para poder determinar el curso de acción de la casa y como decimos nosotros este en sintonia, el colegio, la parroquia, el oratorio y el centro profesional, para ello hacemos asambleas comunitarias entre todos los que quieran participar para compartir lo que detectamos que puede estar necesitando la gente que se acerca a nosotros y de alguna manera poder actuar en conjunto. Para nosotros es casi vital tener una de estas a comienzo del año y otra a fin del mismo para poder evaluar y mejorar para los años siguientes.

  19. pablonazareno dice:

    En mi trabajo las retrospectiva son forzadas. No salen del grupo sino por que el manager las pide y la hacemos. Pero realmente no sale nada útil de ahí.
    Pero si me gustaría compartir los resultados de este cuatrimestre en otra materia de taller que cada 15 días (luego de cada entrega parcial) hacíamos una retrospectiva.
    Utilizábamos la puntos de “que estuvo bien” “que estuvo mal” y “que vamos a cambiar”. Se anotaban los item de cada grupo y se hacia incapie sobre 1 de cada uno para actual.
    Eso mejoro mucho la eficacia del grupo, ya no llegábamos tan ajustados con las fechas y el trabajo salia mas fluido.
    Una cosa que me pareció muy importante fue la predisposición y voluntad de los miembros con respecto a lo que se plateaba y resolvia en estas reuniones. Que como comente al principio. Si no sale del equipo no tiene sentido.

  20. En mi trabajo no suelen hacer retrospectivas, como comenté en la actividad S4-1. Si realizamos retrospectivas en los proyectos personales. Pasadas las 2 semanas de iteración, nos juntamos con todo el equipo de trabajo. Tratamos de focalizarnos en que hicimos bien y qué hicimos mal durante el sprint.. Buscamos las causas de los errores de manera informal. Y armamos un documento con tres columnas, fix, try and keep para que las ideas no queden volando.

  21. Ariel Barreiro dice:

    Trabajo de forma independiente y normalmente en equipos chicos. Siempre hacemos reuniones post-proyectos y tratamos de generar procedimientos que ayuden a mejorar la productividad en nuevos proyectos. El trabajar con distintos clientes también me permite llevar cosas útiles de uno al otro y utilizar mucho de lo aprendido para una mejora personal.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: