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.

Avatar
Alfredo Barrientos

@alfredobarrientos

"Cómo puede esta metodología ayudar a mejorar estas crisis sin desmembrar al equipo?" Es un tema de cultura y de mindset, sino cambian ello, de nada sirve seguir los conceptos y prácticas.

Avatar
Alfredo Barrientos

@alfredobarrientos

"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." Yo no creo que el problema sea ese, el problema es que los líderes no abrazan correctamente el cambio, y esperan que todo se acomode sólo. A esos líderes les falta un cambio de mentalidad, urgente!!

Avatar
Alfredo Barrientos

@alfredobarrientos

"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." Como dije, la culpa no tiene la metodología, la tiene el implementador. Ahora importante comentar que en todo NO puedes aplicar Scrum, sino más bien en proyectos complejos (Framework Cynefin).

Avatar
Alfredo Barrientos

@alfredobarrientos

"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." Eso está mal, todos deberían ser evaluados, el Scrum Master y el Product Owner de todas maneras!!

Avatar
Alfredo Barrientos

@alfredobarrientos

"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?" No diría que es un tema geográfico, he visto empresas que SI han alcanzado una madurez ágil. El PO no debería ser de tecnología, el Scrum Master podría no serlo, pero en mi experiencia preferiría que lo sea. El Dev Team debe ser un ingeniero de software, ingeniero de sistemas de información o uno de ciencias de la computación, o carreras SUPER afines, para trabajar en ello. Comprender bien la diferencia entre las carreras. Ver: http://www.tendenciasti.com/2018/05/02/a-que-profesional-de-ingenieria-debo-contratar/

Avatar
Alfredo Barrientos

@alfredobarrientos

Gracias por tus comentarios Enrique!! Un fuerte abrazo!!

Avatar
RENE ALEXANDER RIOS GUTIERREZ

@renealexanderriosgutierrez

lo del comunismo es letra maravillosa pero al igual que el scrum se debe a los actores que participan (solo las hormigas pueden hacer y hacen un perfecto comunismo... no existe el individualismo y es una jerarquia simple... me sali de tema...)

creo que el scrum master no tiene la culpa... claro que a menos sea uno integrado con el que diseña el sistema (estamos hablando de sistema no? oO?) si fuera asi de hecho tiene que saber de programacion y hasta podria decir que tiene que saber mas que los programadores... esa gente te falta el respeto y tienes que ponerles en fila india xD

a lo que yo si creo que scrum te ayuda... pero debe estar a cargo de la persona idonea... pon a una gente que SABE sacar proyectos antes de los 90's y le das scrum estos veran que le serviria... la metodologia jamas anticipara errores de diseño... no a menos que sea algo por el estilo de sacar un certificado iso 9001... ahi para certificarte te obligan a que se presente un trabajo funcional... al menos ahi te da garantia de que uno sabe...

recomendacion: se mejor profesional de lo que son los scrum master que te tocaron (si bien la experiencia te cae del cielo... la mucha experiencia se busca) y ahi aprende bien scrum xD

Avatar

Escribe una respuesta