muy bien explicado, gracias Jero!!

Hola Jerónimo, Una pregunta, para realizar el examen online, además del PC con conexión a Internet, ¿hace falta algún hardware añadido? Me refiero a webcams que enfoquen tu monitor para demostrar que no haces "trampas" o cosas así? Gracias por tu respuesta y por todo el contenido que creas, es súper útil!!!

Cuando la empresa ya es muy madura ese cargo no es necesario, actualmente estoy en una de las empresas de TI mas grandes de LATAM y el rol no existe, equipos autogestionados entre colaboradores y managers.

que hace un scrum master? NADA!

Hola Jerónimo muy onesta la charla, no existe un equipo donde todos los programadores sean profesionales o avanzados, para eso es el agil couch estilo xp que sea un crack. El logro están es crear un buen equipo, no obligar a un mal equipo a logran un buen producto. Cómo vas a identificar un buen programador para tu equipo si no eres un programador avanzado. Debe aver noveles en el equipo pero el scrum Master debe ser un programador avanzado, se a vendido la idea de que solo debe ser un buen gestor.

Creo que Scrum se vendió como una solución mágica y al Scrum Master como el único valor del equipo. El marco no tiene mucho desperdicio (parafraciando a Ken Beck) me párese una gran herramienta, pero creo que la comunidad Scrum es la que provocó esa cultura, me párese paradójico que digan "creamos productos no sotware" pues entiendo lo de ver el software como un producto pero no debieron desenfocarse. La versión 2020 de scrum toma elementos de XP por qué ya se veía este problema. Ami la la figura del couch XP me párese esencial, ese tipo saca el talento de los novell y genera un crecimiento de las buenas practicas en el equipo. XP dice que el que dirige o toma decisiones por el equipo deve mancharse las manos y meter la mano a la bola de barro, eso sirve para alinear el desarrollo con la empresa con el criterio correcto. Gracias por tus videos me gustan mucho.

Gracias por el video, me ha servido mucho. Entiendo que consideramos que algo está en "DONE" cuando llegamos al paso del "continuous deployment", no? Gracias 🫂

Hola Jerónimo, me gustan mucho tus videos gracias. Me gusta la nueva cultura de scrum versión 2020, creo que se acerca más a XP pero enfocado a mantener una retroalimentación mas clara con los externos al equipo scrum. Me gusta que los Scrum Master puedan ser desarrolladores pero has dicho en varios vídeos que no tiene por qué estar en los Scrum daly, bueno con esta nueva versión me párese que si, ya que es parte de los programadores y si el scrum daly es para enderezar el rumbo del Sprint, quie mejor que el Scrum Master. De lo contrario si es necesario hacer algo drástico el Scrum Master va a ser el último en enterarse.

Hola Jero muy buen video, muy bien explicado tengo tiempo siguiendo y me ha ayudado mucho en mi día a día, te quería hacer una pregunta ¿Actualmente estoy como analista funcional (Proxy PO) relacionado al sector de la construcción en el cual manejo muy bien a nivel de conocimientos del negocio pero me gustaria hacer un cambio y conocer y aprender otros tipos de negocio, que recomendación me podrías dar?

Wow, me quede lelo viendo este video, la verdad que una explicación monumental.

Me distrae esa barba desalineada y verte de tan cerca. Que horror!

Que perfil profesional se debe tener para ser SM?

Osea la certificación del certiprof es una estafa?

Hola Jero. Hoy en día¿ El SM se sigue involucrando solo en proyectos de software, o aplica a múltiples productos? Si fuese un producto tangible por ejemplo¿ La experiencia técnica se limitaría al producto en cuestión ?

Tremenda explicación, una lástima los ruidos de los vecinos, es muy muy molesto.

una vez a la semana, antes de entrar a mi daily !! veo alguno de tus videos! e intento transmitir algun conocimiento al equipo, ! gracias!!

excelente!!! gracias

Trabajo en una empresa de software de 8.000 ingenieros. Usamos Itil 4. el scrum master es para empresas pequeñas nuevas de 30 personas a lo mucho

Jeronimo, tienes algo de Estuarine Mapping , ? necesito entender mas sobre eso

Hola, y si soy una persona que tiene mucho interés en certificarme y ser Scrum Master pero no tengo experiencia previa como tal, cómo podría responder? A menos que en un puesto entry level las preguntas sean distintas

Vengo a proponer una idea. En mi equipo una de las cosas que más me costo aprender y cómo organizar el backlog, por función ? Por release ? Por versión de la app? Es algo que en la práctica me costo mucho aprender y provoco mucho re trabajo en mi equipo. Otra cosa es , cómo definimos realmente lo que es prioridad? Llega un punto de todo software donde parece que todo es importante, que se podría hacer en esos momentos? Y por último algo que también me costo aprender es: cómo dividimos una función en “partes” de manera que sea fácil de construir para los desarrolladores y aporten valor temprano? Sería genial ver un ejemplo práctico de estos , estaría bueno saber de tu parte Jere cómo gestionas estos temas y contar con tu experiencia

Muy bueno tu contenido Jero, yo participo en dailys donde somos 8 personas, la hacemos todos los dias a la misma con 30 minutos de duración, normalmente hacemos un repaso sobre en que esta cada uno con sus tareas asignadas y si alguno se encuentra "trabado" cuando termina la reunión nos quedamos a intentar de ayudarlo. Estaria bueno un video sobre criterios de aceptación. Saludos, desde Argentina.

- Mira jefe, he hecho esto y hemos mejorado la productividad. - Jefe: y tu para que haces nada? Buen reflejo de un pais con futuro xD

he estado en equipos en donde por algún motivo el scrum master no estaría al día siguiente (por ejemplo enfermedad u otros motivos) y de inmediato la daily esos días se suspendía. Incluso en ocasiones , venía otro scrum master de otra célula y por cumplir la daily solo se limitaba a hacer las 3 preguntas. Lo otro, las veces que se realiza la daily scrum, creo importante compartir el sprint goal, nunca se hace. Se podría simplemente poner un print de pantalla con eso y dirigir a daily en torno a eso . Siempre pasa que a la segunda semana del sprint, uno ya anda perdido y tiene que buscar en los correos ese "sprint goal" .

Muchas gracias por tu contenido. No hay recetas mágicas y como comentas en el vídeo el daily scrum puede darte mucha información sobre problemas mucho más profundos sobre el equipo en cuestión. Muy útil. En uno de mis equipos hemos incluido el parking lot para temas que se quieran comentar y que sean importantes, pero sin que entorpezca y eternice el daily scrum. A mí me gustaría diferenciar los tipos de PBIs y diferenciar entre Tareas y subtareas. Muy buen trabajo. Dejo mi like

Excelente video, muchas gracias. Seguiré atento a tus artículos para aprender sobre este tema. saludos

Excelente contenido, super útil y muy bien explicado como siempre 👏

It's a burnout and depression factory. Muy mala experiencia en equipos que hacen scrum. Ridiculo e intuil lo de las estimaciónes con cartas y como bien comentas un montón de gente que hace scrum master solo para ganar pasta sin tener ni idea, que se la pasan publicando en LinkedIn los miles de eventos y conferencias a las que han asistido, alabando las bondades de scrum y al final no hacen más que hacer la vida de los desarrolladores más miserable.

Lo malo del Manifiesto ágil es que es que es tan ambiguo que las empresas lo interpretan como se les da la gana. Y eso mismo lo convierte en algo totalmente infertil. Cuando quieres trabajar con la gente e implementar la filosofía ágil en una empresa, vienen los directivos y te dicen que no les beneficia, que el manifiesto es para enseñar ala gente explotada a no quejarse y que así serán ágiles. Tal como si el director de un hospital le dijese al cirujano por dónde tiene que cortar. Pero es que lo que está mal parido es el manifiesto en sí tan ambiguamente redactado que no sirve para nada más que para generar confusión y tantos entendimientos como cabezas haya.

Muy buen video, me ha encantado!

Muy interesante! Gracias por compartir no solo conocimiento, que ya de por si es valioso, sino también experiencia.

Fantástico resumen, tocando los aspectos más importantes. Por lo general y en mi experiencia, en el sprint planning suele haber dificultades en diferenciar entre el qué y el cómo (donde empieza y acaba cada uno), en definir un buen sprint goal (que no sea excesivamente abstracto o que no sea un Frankenstein de varias cosas, entiendo que derivada de una falta de alineamiento estratégico) y en la división de PBIs. Gracias por tu trabajo. Dejo mi like. Feliz día de Andalucía

Hola jero cómo estás? Muchas gracias por el contenido de tus Videos los vengo siguiendo hace un tiempo y son muy útiles, he conseguido un trabajo como PO en una empresa de tecnología más concretamente en una edtech. Somos un equipo formados por un Scrum máster, tres desarrolladores un tester y yo. Estamos utilizando Scrum como metodología para trabajar y realmente he logrado comprender todos las etapas de este Framework y te quería preguntar con respecto a lo que decís sobre el conocimiento técnico. Me pasa que mi scrum tiene un desarrollo técnico muy alto y yo siento que me quedo atrás en resolver este tipo de problemas, muchas veces no tengo en cuenta cuestiones técnicas (cómo comportamiento de la base de datos o el diagrama de las querys) lo que provoca retrasos en la planificación por que cuando los desarrolladores toman las ticket que cree , se encuentran que le falta contenido o soluciones técnicas. ¿Como podría adquirir este conocimiento? ¿Sería conveniente hacer un curso de programación básico? Quedo atento tu respuesta de agradezco mucho y gracias por tus videos son lo más jeje 🎉

Muy buen video. Estoy formándome para ser un po. Buen día

En un caso hipotético hablemos de que los pilares y los valores de Scrum se implementen en un proceso o en una empresa, ¿qué va a pasar? pus que así no sea SCRUM va a generar valor en lo que hacemos. Los pilares y lo valores son el corazón de SCRUM y serán el corazón de quien lo aplique en lo que sea.

Master Jero, muchísimas gracias, por compartir estos valiosísimos tips, un abrazo.🥳🎉

Soy Scrum Master desde hace muchos años y en las entrevistas a diversos perfiles de SM he preguntado abiertamente por alguna forma de promover los pilares de Scrum y NINGÚN candidato sabía los pilares de Scrum. Diferenciar quien sabe solo las mecánicas frente a las bases y propósito de Scrum es crucial, pero ya os digo, limitará muchisimo el funnel de candidatos, ya de por sí bajo en mi experiencia. Es una profesión muy bonita y enriquecedora Gracias Jero por compartir tu experiencia

Excelente

Excelente!! Muchas gracias Jero!

Excelente vídeo... me gustaría de tu ayuda para intentar crear 4 historias de usuario para el siguiente ejemplo: Elaboración de una campaña de publicidad online para convertir a los usuarios de la versión gratuita de una app en usuarios de pago. La app consiste en una tabla de ejercicios orientada hacia la pérdida de peso. En la versión de pago hay tres categorías de ejercicios (pectorales, abdominales y extremidades), cronificados a lo largo de 30 días combinados con recomendaciones generales sobre la dieta más recomendable. La versión de pago incluye un análisis personalizado según los datos que le introduzca un usuario y un lector de códigos de barras que aporta información sobre las calorías de cada alimento.

Me ha recordado a hace unos años cuando alguien me recomendaba usar waterfall para los proyectos serios y Agile para los pequeños y más informales.

Buen video! Como todo en la vida, sube y baja.. Al rato esas mismas empresas se dan cuenta que si les daban valor y re-contratan, saludos!

Gracias, Jerónimo, sin duda es genial que estés creando este tipo de contenidos nuevamente. Eres uno de mis 2 o 3 referentes en la materia.

Un líder una de sus funciones es crear a otros líderes, un SCRUM Máster es parecido, debe crear a más SCRUM Máster. Cuando en tu equipo ya son SCRUM, debes ir a otro equipo. El trabajo fue completado.

He venido mirando algunos de tus videos y me han venido pareciendo interesante, pero en esta ocasión difiero un poco, el SM ni en la teoria ni en la práctica puede desaparecer, y el SM que piense que debe tender a desaparecer pues ha interpretado la guía de manera errónea. La Guía menciona que Scrum se basa en el empirismo y pensamiento Lean. Por tanto, las oportunidades de mejora son infinitas en un equipo compuesto por humanos. También especifica que el SM es el responsable de lograr la efectividad en el Scrum Team, algo que tampoco termina. Así que, toca leer la guía nuevamente y hacer otro video.

Que hartazgo de escuchar este tipo de sandeces. Parece que ser SM es equivalente a ser un mártir.que debemos sacrificarnos por el buen común. Pues no. No somos lemures. Como parte de nuestro trabajo empoderar al equipo, pero siempre habrá áreas de mejora, experimentos que implementar... Que desaparezcan ellos 😜

Que razón tienes diciendo que sin los valores scrum no funciona. Y que difícil es que la empresa y los equipos den importancia a estos valores y no a las reuniones sin darles sentido

Como cada uno de sus videos todo muy claro y aplicado a situaciones muy actuales y reales. Excelente video y gracias por compartirlo

Gran trabajo. Hay una fuerte tendencia basada prácticamente en un instinto de supervivencia de buscar hacerse necesario en una empresa. Normalmente hay mucha cultura de la medalla. Quizás desde mi ignorancia me equivoque, pero en mi opinión el valor que aporta un scrum master se ve reflejado indirectamente. Ayudar a que la música suene bien sin tocar ningún instrumento a veces es difícil de entender en muchas organizaciones. Un placer oirte y ver la notificación de que has subido video. Seguiremos por aquí dando feedback y apoyando. Seguro que hay mucho trabajo y esfuerzo detrás de cada video y cada publicación del blog, pero para mi han sido y son de una inmensa ayuda para seguir trabajando día a día con algo tan "hard & disruptive" como es scrum. Gracias

Este tipo de videos son fundamentales. Super útil. Una recomendación a modonde lluvida de ideas: sería genial un video que abordase el papel y la responsabilidad de los desarrolladores más allá de picar código justificando por qué es importante. Parece que todo lo que no sea escribir código es desperdicio. Y, por otro lado, aspectos que caen en el ámbito de los desarrolladores y no debe venir cerrado por parte del PO o de los SHs. Muchas veces el "qué" se amplia tanto que el "cómo" queda reducido casi a cero. Gracias por tu esfuerzo y trabajo