Lo que pienso y me asusta de Scrum

Scrum desde cero | Ceremonias

Avatar
Enrique Estrada

@enriqueestrada

Buenas tardes estimado profesor Alfredo Barrientos

Me ha gustado mucho todo lo que he escuchado de vos. Veo que tenés una gran experiencia en el tema.

Te cuento que por lo menos en mi experiencia en Costa Rica mi país es que Scrum no es otra cosa mas que una fraude . En mis años NUNCA le he visto el lado bueno a Scrum. Todo mundo presume usarlo pero cuando ves el día a día dentro de la organizaciones te das cuenta que no lo usan bien y que son un desastre.

Es como el comunismo, En la letra es una maravilla pero en la practica es un desastre.

Sé que no debo culpar a la metodología, si las cosas son manejadas por humanos hay procesos de aprendizaje y mejora que deben irse implementando poco a poco.

Voy por esta clase y solo veo un mundo ideal donde si se hace todo al pie de la letra todo debería de ser perfecto. Mmmm en teoría sí. Pero no se habla de que pasa cuando las cosas no salen como se quiere y comó esta metodología ayuda a solventar esas crisis más allá de despedir programadores cuando el Scrum Master y el Product Owner no quieren asumir su responsabilidad y para congraciarse con el cliente lo que hace es quitar elementos del equipo y crear una rotación fuerte de personal. Prácticamente con todas las métricas que Scrum puede dar, un programador puede decir que en su primer día de trabajo comenzó su proceso de despido.

Ahora. Si en el día a día un programador entrega mal su codigo y no sigue instrucciones, ahí doy toda la razón para mover a un elemento del equipo. No estoy justificando lo injustificable.

Pero cuando se ofrecen plazos de entrega de producto que no se pueden cumplir y se explota al equipo y si las cosas no salieron a tiempo ahí Yo veo responsabilidad del Srum Master y del Product Owner pero nadie despide a estas personas, los que pagan los platos rotos son los miembros del Development Team

Cómo puede esta metodología ayudar a mejorar estas crisis sin desmembrar al equipo?

El centro de mi critica para lo que vos enseñas es que en la definición de Scrum lo ponen como el arte de hacer el doble del trabajo en la mitad del tiempo. No digo que eso no se pude, pero creo que ese caballo de batalla con el que han promocionado esta metodología le ha hecho MUCHO daño a las organizaciones.

vos decís que en EUA se vive ese mundo ideal donde las cosas se hacen correctamente pero en LA y en mi caso por mí experiencia he visto el desastre que ha causado esta metodología al ser mal aplicada porque ven esto como una forma automatizada de poder producir más y a menos costo monetizando y deshumanizando los procesos.

Lo que me asusta es que en mi experiencia en esta metodología es que solo el development Team es evaluado pero las cabezas de los proyectos No.

Estamos todavía en LA en pañales con esto? Porque la gte corre como loca para certificarse en Scrum como una moda? Puede un Develpment Team tener un Scrum Master y un Product Owner que no sean del área de la tecnología?

Este seria mi comentario y espero haber sido claro y a la vez respetuoso. Mi intención no es la contender, Más bien es la de dar mi punto de vista y contar mi experiencia.

Saludos Cordiales!

Avatar
Alfredo Barrientos

@alfredobarrientos

Estimado Enrique, lamento mucho lo que indicas, iré comentando cada uno de tus párrafos.

Avatar
Alfredo Barrientos

@alfredobarrientos

"Te cuento que por lo menos en mi experiencia en Costa Rica mi país es que Scrum no es otra cosa mas que una fraude . En mis años NUNCA le he visto el lado bueno a Scrum. Todo mundo presume usarlo pero cuando ves el día a día dentro de la organizaciones te das cuenta que no lo usan bien y que son un desastre." Esto ocurre en muchas organizaciones, no sólo en tu país, sino también en Perú. No importa el tamaño de las empresas, grandes o pequeñas. Al final lo peor de todo es que terminan diciendo: "Scrum no sirve", o "Esta metodología no es para esta empresa!!".

Avatar
Alfredo Barrientos

@alfredobarrientos

"Sé que no debo culpar a la metodología, si las cosas son manejadas por humanos hay procesos de aprendizaje y mejora que deben irse implementando poco a poco." En los frameworks de Transformación Ágil (no digital) indican que los primeros cambios se dan a los 6 meses, con mucho esfuerzo y con mucho apoyo de la alta dirección. Has mencionado algo importante: "procesos de aprendizaje". Déjame decirte que he conocido empresas ni su gente (incluida la alta dirección) que simplemente no tienen interés en aprender, si no quieres aprender, entonces no sirve de nada querer aplicarlo.

Avatar
Alfredo Barrientos

@alfredobarrientos

"Voy por esta clase y solo veo un mundo ideal donde si se hace todo al pie de la letra todo debería de ser perfecto. Mmmm en teoría sí. Pero no se habla de que pasa cuando las cosas no salen como se quiere y comó esta metodología ayuda a solventar esas crisis más allá de despedir programadores cuando el Scrum Master y el Product Owner no quieren asumir su responsabilidad y para congraciarse con el cliente lo que hace es quitar elementos del equipo y crear una rotación fuerte de personal. Prácticamente con todas las métricas que Scrum puede dar, un programador puede decir que en su primer día de trabajo comenzó su proceso de despido." Para evitar este tipo de situaciones, se requiere sí o sí el apoyo de la alta dirección o de un Manager que cuide la ejecución del proceso. No culpes al rol del Product Owner, para tal caso responsabiliza o culpa al que tomó tales acciones de no asumir sus responsabilidades. Esto ocurre sin importar la metodología, cambios dados por el Líder Usuario, sin que asuma su responsabilidad, pida disculpas o acepte el cambio de fechas, el cual es lógico. En los primeros meses de adoptar la agilidad, TODOS se mojan: Todos deben trabajar más, esforzarse más, dedicarse más. Si no tienen conciencia de ello, el tema nació muerto.

Avatar
Alfredo Barrientos

@alfredobarrientos

"Pero cuando se ofrecen plazos de entrega de producto que no se pueden cumplir y se explota al equipo y si las cosas no salieron a tiempo ahí Yo veo responsabilidad del Srum Master y del Product Owner pero nadie despide a estas personas, los que pagan los platos rotos son los miembros del Development Team" Independientemente de la metodología o framework, el equipo ayuda o es responsable de la estimación. El proceso de estimación tiene que definir una holgura, y tienes que tener una buena estrategia de ir mejorando esta técnica. Si en esa empresa donde dices los platos rotos los paga el DT, la empresa tiene un serio problema, y tu CIO, CTO, o Gerente de TI no te es de utilidad para defender el proceso o para defender a su equipo, por responsabilidades que no son de ellos.

Ver más comentarios

Avatar

Escribe una respuesta