Guillem Hernandez Sola

Cuando facilito cursos certificados de Scrum por Scrum.org, los participantes tienen muchas preguntas. Esto es tan cierto en los cursos online de hoy como en los del viejo mundo de la capacitación presencial. Algunas de las preguntas más frecuentes comienzan con "En Scrum, quién es responsable de ..." La pregunta luego termina de varias formas, como ... refinamiento el product backlog ... actualizando el progreso (ya sea Gantt, Burndown, el JIRA,.... ) ... tomando notas durante una revisión de sprint ... realizando una divertida retrospectiva pinta y colorea ... cumpliendo el objetivo del sprint ... etcétera. Cuando me hacen estas preguntas, casi puedo desconectar la segunda mitad de la pregunta. Realmente no importa cómo alguien termina una pregunta que comienza con "Quién es responsable de ..." porque en Scrum, la respuesta es casi siempre la misma: el Scrum Team. El Product Owner, el Scrum Master y los Developers. El Scrum Team, todo el Scrum Team, es responsable ... de todo. Claro, podemos decir que el Product Owner es responsable de manejar el Product Backlog. Pero imagina un equipo cuyo Product Owner no escribe un Product Backlog. Alguien de ese equipo debería pensar: "Sabes, todo esto iría mucho mejor si tuviéramos un Product Backlog de las próximas cosas en las que estaremos trabajando". Y ese miembro del equipo podría hacer que suceda, puede programar una reunión, documentar lo que creen que está por venir o cualquier otra cantidad de acciones. Sin embargo, esa persona no debe alejarse del problema pensando: "No es mi problema". La mayoría de las acciones en Scrum se consideran mejor como una responsabilidad compartida. Es el trabajo de todos asegurarse de que esas cosas sucedan. Es responsabilidad del Scrum Team. Es cierto que a veces podemos reducirlo a una sola persona y decir que el Scrum Master realiza la retrospectiva y el Product Owner se asegura de que el equipo tenga un Product Backlog. A menudo se dice que estas personas son responsables. Deben asegurarse de que los conceptos básicos de Scrum (una retrospectiva divertida, una inspección del Incremento) sucedan o existan. Pero incluso si decimos que una persona es responsable, eso no elimina la responsabilidad de los demás en el equipo. Compartir la responsabilidad incluso cuando una persona es responsable ayudará a su equipo a tener éxito con Agile.

Inspeccionar y adaptar bien podría ser el lema no oficial del movimiento ágil y en especial del marco de trabajo Scrum. Lo escuchas en todas partes.

Uno de los beneficios de estar en un equipo son las amistades que puedes hacer con tus compañeros de equipo.

Os voy a comentar las fuentes más fiables que he encontrado para preparar el assessment PAL-EBM de Scrum.org

Los marcos como Scrum son fantásticos para resolver problemas comerciales y las empresas continúan haciendo la transición a la agilidad para lograr los objetivos. Pero pueden surgir problemas si se olvida que Agile es solo una metodología, un medio para lograr un objetivo, no el objetivo en sí. Hay millones de artículos sobre las trampas (y el temor) asociados con la decisión de la gerencia de "volverse ágil" repentinamente. Refleja la ilusión de que se trata de una implementación simple, como cambiar de proveedor de material de oficina, en lugar de un marco que requiere un cambio significativo de mentalidad y en la cultura de la organización. La típica frase siempre es “Amazon lo está haciendo”, "Netflix lo hace" o "Spotify lo hace también". Buenos indicadores de que la empresa no ha definido claramente el "¿por qué?" es una de las primeras preguntas que hago cuando trabajo con una empresa en transición a ágil o cuando imparto una clase certificada de Scrum. A menudo obtengo respuestas como: Queremos adaptarnos rápidamente al cambio Queremos realizar mejoras continuas Queremos realizar releases con más regularidad Estos parecen grandes objetivos y se alinean con los resultados que esperamos de una metodología ágil. Pero incluso las metas que suenan nobles pueden causar problemas y frustraciones cuando las persigue sin definirlas adecuadamente. ¿Cómo sabe que ha elegido el objetivo correcto? Digamos que mi amigo me dice que quiere ganar $ 100,000 adicionales en los próximos 12 meses. Probablemente lo alentaría a probar este objetivo para ver si es lo que realmente quiere. Los cinco porqués es un enfoque bien conocido para descubrir la causa raíz subyacente de un problema y también funciona bien para descubrir las motivaciones subyacentes para perseguir un objetivo. Si le pregunto a mi amigo por qué quiere los $ 100,000, puede responder que es para mejorar su estado, o tal vez dice que quiere remodelar completamente su casa. Si aplicamos otro por qué, podemos descubrir una capa más profunda de lo que es importante para él sobre estas cosas. Entonces podría decir que el estatus es importante para él, para demostrarles a sus padres que tiene éxito. O quiere remodelar para estar emocionado de volver a casa al final del día. A medida que continúa explicando por qué algo es importante, puede comenzar a revisar el objetivo original y preguntar: ¿Es el correcto y está definido con suficiente claridad? Por ejemplo, tal vez mi amigo no necesite $ 100,000 para demostrarles a sus padres que tiene éxito, tal vez solo necesite un coach de vida para darse cuenta de que es lo suficientemente bueno. Y quizás todo lo que necesita para disfrutar de volver a casa al final del día es que un mejor amigo lo reciba. Una buena meta también necesita buenas pautas Después de un poco de discusión, mi amigo decide que definitivamente quiere dinero contante y sonante. ¿Cómo debería lograr esto? Podría robar un banco. O adquirir el dinero a través de una estafa de criptomonedas al estilo Josef Ajram. ¿Debería considerar esas opciones? Bueno, dado que mi amigo no es un genio criminal, hay muchas posibilidades de que lo atrapen y pierda la libertad. También es una persona realmente decente, por lo que la idea de cometer un crimen probablemente le molestaría. Claramente, reconocemos que además de elegir el objetivo correcto, también necesita pautas sobre cómo lograr ese objetivo (por ejemplo, no infringir la ley) y no comprometer las cosas que son importantes para él, como su libertad y sus valores. Cuando tiene el objetivo correcto, pero la ejecución incorrecta Conocí a un vicepresidente senior que quería usar Scrum para mejorar la colaboración. Ese es un objetivo perfecto para este tipo de marco de trabajo. Sin embargo, también creía que la colaboración solo se podría lograr si el equipo trabajaba físicamente en el mismo espacio. Como resultado, trasladó a todos a una sala pequeña y estrecha e insistió en que todo el trabajo y las discusiones se llevaran a cabo allí, con todo el equipo involucrado. Esto no solo era incómodo; también significó que un miembro que anteriormente había pasado unos días trabajando desde casa ahora tenía un viaje diario de ida y vuelta de tres horas. La moral y la calidad del trabajo comenzaron a sufrir. Cuando entré para ver por qué Scrum no funcionaba para ellos, comencé preguntándole por qué quería mejorar la colaboración. Me dijo que quería que los miembros del equipo tuvieran: Comprender en qué estaban trabajando otras personas, identificar brechas o ver dónde los miembros tenían exceso de trabajo para que pudieran ayudarse entre sí. Discutir con confianza y rapidez las soluciones a los problemas Comunicarse entre sí de una manera simple y clara. Y nos dimos cuenta de que ninguna de esas cosas requería que alguien se sentara físicamente al lado de otra persona. Al analizar la situación de nuevo, el vicepresidente se dio cuenta de que "colaboración" no significaba proximidad, y pudimos volver a examinar las diferentes formas en que podían trabajar para lograr los objetivos reales. Cuando olvidas el por qué, es fácil dividirse Trabajé con un Scrum Master que era nuevo en un equipo. Cuando descubrió que habían modificado algunas de las reglas, en su opinión, no estaban haciendo Scrum correctamente. Como Scrum Master, sintió que era su papel corregir al equipo y asegurarse de que todos estuvieran haciendo Scrum de la manera correcta. Para hacer esto, duplicó las reglas, destacando los errores del equipo y aconsejando lo que deberían hacer en su lugar. Pero cuanto más presionó, más gente la rechazó y se convirtió en un ambiente tóxico de interminables desacuerdos. Le pregunté por qué era tan importante hacer cumplir esas formas de trabajo. Ella me respondió: "Porque así es como solía trabajar con mi equipo anterior y tuvimos mucho éxito". Le pedí que describiera cómo era estar en ese equipo y que compartiera por qué pensaba que trabajaban tan bien juntos. “Hicimos clic. Nos animábamos el uno al otro incluso cuando cometíamos errores. Conocíamos las fortalezas de los demás, nunca nos preocupamos por pisar los dedos de los pies, realmente nos sentimos libres de entrar y hacer nuestro mejor trabajo " En ningún momento dijo: "Porque siguieron perfectamente el marco de Scrum". Cuando dimos un paso atrás, vimos que su rigor sobre las reglas estaba provocando tensión, desconfianza y disminución de la productividad. Su objetivo general era ser un equipo ágil de alto rendimiento, pero sus acciones a corto plazo estaban directamente en conflicto. En lugar de centrarse en las cosas que su equipo hacía de forma diferente, empezó a fijarse en el objetivo que todos compartían, ser ese gran equipo ágil, y decidió centrarse en lo que estaba funcionando bien y crear una buena relación, en lugar de intentar arreglar todo lo que tenía. el pensamiento estaba roto. Ponga a prueba las metas y asegúrese de que las pautas sean claras Si tu organización está pasando a ser ágil, anima a los gerentes a poner a prueba esos objetivos cuando sea posible. Descubre que es realmente importante. Elimina la ambigüedad de lo que desea lograr como equipo, de modo que puedas ser creativo con tu enfoque en lugar de limitarte a reglas arbitrarias. Y considera el costo que estás dispuesto a pagar. ¿Es importante la moral del equipo? ¿Es mejor atraer a menos clientes con promesas realistas, entregar de manera más confiable y generar más negocios repetidos? Con los equipos deportivos, el éxito a menudo se relacionaba con los muchos pases desinteresados ​​realizados por los miembros del equipo, con la forma en que los individuos anteponen el éxito del equipo a la gloria individual. Veo que sucede lo mismo con equipos ágiles exitosos. Un equipo con el que trabajé estaba entregando a tiempo, pero se hizo evidente que el UX estaba sobrecargado de trabajo. En lugar de considerar su propia capacidad individual al planificar y seleccionar tareas, los miembros comenzaron a pensar en la capacidad del equipo. Decidieron que si una persona estaba luchando, todos estaban luchando. Un desarrollador abandonó algunos de sus propios elementos del Backlog pendientes para dedicar un tiempo a aprender a diseñar e intentar ayudar. El equipo disminuyó la velocity a corto plazo, pero a largo plazo comenzaron a entregar más, ya que tenían habilidades más desarrolladas. Si simplemente se hubieran centrado en ofrecer tantas funcionalidades como fuera posible en cada iteración, es posible que este progreso a largo plazo nunca hubiera sucedido. Me encantaría conocer tu experiencia. ¿Están los objetivos claramente definidos y comprendidos? ¿O alguna vez has sentido que se estaba siguiendo un plan de negocios basado en palabras de moda? ¿Qué has encontrado que funciona bien al usar Scrum y es ágil para resolver un problema de negocio o lograr un objetivo?

{"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/Q4XsFY3eIdg.jpg?itok=Z09feOCa","video_url":"https://www.youtube.com/watch?v=Q4XsFY3eIdg&feature=youtu.be","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Evidence-Based Management (EBM) es un enfoque empírico que ayuda a las organizaciones a mejorar continuamente los resultados de los clientes, las capacidades organizativas y los resultados comerciales en condiciones de incertidumbre. Proporciona un marco para que las organizaciones mejoren su capacidad de ofrecer valor en un mundo incierto, buscando un camino hacia los objetivos estratégicos. Usando experimentación intencional y evidencia (medidas), la EBM permite a las organizaciones mejorar sistemáticamente su desempeño a lo largo plazo y refinar sus objetivos con base en mejor información. Al medir las condiciones actuales, establecer objetivos de rendimiento, formar pequeños experimentos rápidos para las mejoras, medir el efecto del experimento e inspeccionar y adaptar los objetivos y los próximos pasos, la EBM ayuda a las organizaciones a tener en cuenta la mejor evidencia disponible para tomar decisiones sobre las formas de mejorar. Este video define que es EBM, sus conceptos y su aplicación.

En esta sesión, Jeff Gothelf, autor de best-sellers como Lean UX, Sense & Respond y Forever Employable, responde a preguntas sobre como integrar Scrum y UX (sesión en inglés).

En esta sesión, Guillem Hernández, PST de Scrum.org responde a dudas sobre como hacer Scrum más atractivo para los desarrolladores.

En esta sesión "pregunta a un experto", José Casal, Kanban Trainer y PST de Scrum.org con una larga experiencia, aclara aspectos como...

Estoy muy contento de que comentarios que he visto y recibido sobre la nueva Guía Scrum 2020.