Discuta argumentando con hechos (repaso coaching) y citando fuentes, desde cualquiera de estas dos posturas: Desde una posición radicalmente en contra de Scrum o radicalmente a favor de Scrum (5 puntos)
Responda al último comentario que exista parándose en la posición siempre contraria al mismo.
Soy uno de los siete fundadores de FDV Solutions. Como CEO de la compañía, ejecuto la estrategia general de FDV Solutions y la supervisión de las distintas áreas de negocios y gerentes que me reportan: Ventas y Marketing, Operaciones, Administración y Finanzas, y Recursos Humanos. Además tengo un rol activo en las distintas acciones institucionales de la empresa, siendo representante de la misma en diversas cámaras e instituciones, como la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI). Soy graduado en la Carrera de Ingeniería en Informática, y cuento además, con un posgrado en comercialización para ingenieros del Instituto tecnológico de Buenos Aires (ITBA). Actualmente estoy finalizando un máster en Ciencias Cognitivas de la Universidad de Buenos Aires y soy docente universitario en dicha casa de estudios. Soy también Fundador de Proyecto Nahual (www.nahual.com.ar), una iniciativa que busca la inclusión social y la inserción laboral a partir de la capacitación tecnológica en programación y testing de software. Participo además activamente de la Comisión de Inclusión de CESSI.
Administración y Control de Proyectos II 
Scrum es sin duda la mejor opción a la hora de seleccionar que metodología utilizar. Esto se debe a que provee entregas incrementarles que permiten validar el producto y obtener priorizar las cosas que tienen mas valor. Además todo el equipo se mantiene informado en las daily’s meetings. Cabe la pena mencionar que las retrospectivas y luego de cada sprint proveen en tiempo y forma las acciones correctivas necesarias para cumplir los objetivos (http://es.wikipedia.org/wiki/Scrum).
En suma a esto Scrum es una metodología aplicable a cualquier tipo de proyecto. (http://www.mountaingoatsoftware.com/blog/using-scrum-to-plan-your-wedding)
Partiendo desde el punto de que scrum no es una metodología, sino un framework su éxito depende de como se lo utilice, scrum no garantiza desde ningún punto de vista el éxito del proyecto.
Mucha de la teoría en la que se basa scrum no funciona en la realidad. La daily meeting dice tener a todo el equipo informado del trabajo que realizan en el día a día y predecir con anterioridad posibles problemas o retrasos, pero sin embargo esto en la realidad no sucede, las personas suelen no interesarse en que dice el otro. Algo parecido ocurre con la retrospectivas, dado que comúnmente después de la reunión no se toman las acciones necesarias para corregir el problema planteado y todo sigue funcionando de la misma manera.
En informática es muy factible que los proyectos terminen fuera de presupuesto, o fuera de tiempo o ambas, si scrum fuese tan bueno esto no ocurriria. Solo el 15% de los proyectos de software se consideran exitoso siendo hoy scrum la forma de trabajo más usada.
El principal fuerte de scrum es adaptarse rápidamente a los cambios, lo cual es curioso porque la principal causa de fracaso de los proyectos se debe a los requerimientos cambiantes.
http://www.alejandrobarros.com/content/view/691759/Comportamiento-de-proyectos-TI-Estan-en-deuda.html
Lo cierto es que mucho depende de quien realice la estadística. Si buscamos datos reales, el propio Dr. Dobb’s publica en su revista en el año 2007 una estadística muy favorable a las prácticas ágiles como scrum.
http://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-newsletter-1107/204200877
Ahí puede verse que para los entrevistados que utilizaron tanto tecnologías ágiles como tradicionales el mayor porcentaje de proyectos exitosos es para la primera.
Como se puede ver en el manifiesto ágil, la metodología es rápida para administrar cambios, se centra en el equipo de desarrollo y en el software funcional. Es de público conocimiento que los cambios y el software funcional son dos elementos esenciales hoy en día.
Manifiesto: http://agilemanifesto.org/iso/es/
Es por esto que Scrum es la mejor metodología.
PD: No quiero ofender a nadie, sólo acato el enunciado. No me importa que metodología jane.
Por mas que uno se refiera a Scrum como un marco de trabajo ágil, y no una metodología, Scrum se perfila como la alternativa más completa para la realización de proyectos complejos. Aunque al principio sólo se aplicaba a proyectos de desarrollo de software, hoy en día se aplica a cualquiera, incluso a las más complicadas e innovadoras con las mismas garantías de éxito. Sus posibilidades son infinitas y, sin embargo, el método de trabajo es absolutamente simple.
Como se puede ver en el siguiente articulo http://www.proyectosagiles.org/beneficios-de-scrum los beneficios que ofrece esta metodologia son numerosos y contemplan la mayoria de las areas de conocimientos involucradas en los proyectos:
Gestion regular de las expectativas del cliente
Resultados anticipados
Felxibilidad y adaptacion
Retorno de la inversion
Mitigacion de Riesgos
Productividad y Calidad
Alineamiento entre cliente y equipo
Equipo motivado
Scrum como marco que rige sólo sobre un proyecto no aporta seguridad ni solidez al producto, en metodologías tradicionales (como RUP) el cliente conoce el plan, los tiempos, los lineamientos de calidad, costos y tiempos con antelación y nitidez, lo cual permite tomar decisiones menos riesgosas.
Scrum es un modelo empírico que en ciertos casos, con grandes clientes y grandes proyectos, no es suficiente respaldo para el producto.
Para el éxito del producto se necesita tener una buena proyección de los costos, la calidad y consecuencias del proyecto y esto scrum no lo cumple, éste confía y delega toda esta responsabilidad solamente en la capacidad del equipo de trabajo (lo deja librado a la subjetividad, al mero compromiso incondicional del mismo).
En el siguiente se exponen características necesarias para que un proyecto bajo la metodología scrum funcione y no termine con «deuda técnica», es decir perjudicando la calidad y el prestigio ante el cliente: http://www.proyectosagiles.org/calidad-agilidad-cuarto-encuentro-agil-barcelona; en el mismo se menciona CMMI en el siguiente link se encuentran publicadas cifras que respaldan su solidez.
“Adiós para siempre a los productos que tardan meses en ver la luz por primera vez”, esa parece la mejor definición de Scrum como estrategia para la creación de productos, una técnica usada en empresas de la talla de Amazon, Spotify, Ericsson y Adobe, y que de poco, fue incluso migrando de empresas tecnológicas a ganar terreno en otros rubros e industrias.
La metodología Scrum se reduce a una forma de crear productos o servicios en contextos complejos y dinámicos con una premisa: hacerlo en un período de tiempo más corto que el que manejan las metodologías tradicionales. Incluso, nace como respuesta a los proyectos de meses o años de duración y opta por la flexibilidad y la inmediatez como parte misma del proceso. Fuente:
http://pulsosocial.com/2014/03/07/scrum-el-adios-para-siempre-productos-eternos-que-tardan-meses-en-ver-la-luz/
Desde 2005, la empresa VersionOne, lleva realizando cada año una encuesta a un gran muestreo de empresas, preguntándoles sobre ciertos aspectos relacionados agilidad.
Este año los resultados se han recogido sobre 3925 respuestas, un 65% de las cuales provienen de empresas en Norte América y un 21% de Europa.
Resumiendo algunos resultados de la encuesta:
¿Qué metodología ágil se usa más?
Scrum sigue destacando como lo más utilizado para llegar a la agilidad (56% de los encuestados).
Y lo que más gracia me hace (aunque no sé si reír o llorar), es que aparece que el 3% de los encuestados dicen que no saben qué metodología están utilizando
¿Cómo escalar la agilidad?
El 69% de los encuestados opta por utilizar Scrum de Scrums (69%), seguido de métodos internos (25%).
Fuente:
http://www.javiergarzas.com/2015/04/estado-de-la-agilidad-9th-state-of-agile-survey.html
Scrum aventaja a metodologías tradicionales al lograr buenos resultados en los entregables en menos tiempo, acordando con los dueños del producto la funcionalidad necesaria para cada una de las entregas y priorizando de acuerdo a las necesidades de cada momento del proyecto el desarrollo de las soluciones. Este tipo de flexibilidad no puede ser lograda cuando todo debe ser planificado de antemano.
Esto mantiene la solución abierta y con la posibilidad de ser receptiva respecto de los cambios que pueden darse en la medida que el negocio lo requiera. De esta forma se minimiza el impacto ante la concreción de potenciales riesgos (que son menores que los riesgos que se corren al utilizar metodologías no ágiles).
En proyectos encarados por Empresas Emergentes, las metodologías ágiles y el Lean Thinking dejó de ser una moda para convertirse en una forma de trabajo necesaria para mantener los costos al mínimo al desarrollar sólo lo que sirva para ganar en términos de funcionalidad, no generando desechos, ni desarrollando cosas que no aporten al beneficio inmediato propuesto por el producto.
Fuentes sobre Scrum y Lean Thinking: https://msdn.microsoft.com/es-es/library/jj161049.aspx
Tuve la mala suerte de que el comentario anterior fue a favor de Scrum 😦 Voy a intentar argumentar en contra aunque me cuesta demasiado:
Scrum es costoso en términos de recursos: realizar todas las reuniones que requiere Scrum involucra muchas personas (todo el equipo) durante mucho tiempo.
La Daily Meeting todos los días puede que dure poco tiempo – si el equipo es pequeño y las cosas no se van por las ramas – pero no se tiene en cuenta el tiempo que lleva prepararlas. Es frecuente que se demore hasta que todos se reúnan frente al pizarrón o cualquiera que fuera el lugar de encuentro, atrasando el horario de comienzo y poniendo a los asistentes puntuales en espera. También suele suceder que por alguna razón se deba cambiar el horario de una daily y hasta que todo el equipo se ponga de acuerdo pueden tardarse horas, generando nuevamente una pérdida de tiempo. Otro factor que hace perder tiempo suceder cuando se tiene que lidiar con conexiones lentas al intentar hacer dailies remotas por Skype..
En cuanto a las Planning Meetings, suelen ser largas (a veces varios días) y también involucran muchas personas, lo cual las hacen tediosas y aburridas, desviando la atención de los asistentes. Esto incluso puede impactar en malas estimaciones. Todo esto al menos una vez por Sprint!!!
Y las Retros? Medio día (con suerte) de charlas y no son bien facilitadas pueden resultar en otra gran perdida de tiempo.
Fuentes:
https://lostechies.com/jimmybogard/2012/09/12/why-im-done-with-scrum/
http://www.quora.com/What-are-the-disadvantages-of-agile-software-development
http://www.my-project-management-expert.com/the-advantages-and-disadvantages-of-agile-scrum-software-development.html
El trabajar con scrum genera mucho sobre trabajo. Esto es porque tiene demasiadas meetings (daily, sprint planing, retro, etc), Todo el tiempo usado en esas meeting podría sea aprobechado para trabajar en el proyecto.
Para hacer que las tareas se puedan ejecutar en un sprint muchas veces tienen que ser reducidas, separadas o recortadas. Lo que genera que no se tenga en la mente el objetivo final, lo que puede generar re trabajos, lo que es mas perdida de tiempo.
referencia: https://agilepainrelief.com/notesfromatooluser/2015/06/daily-scrum-is-a-waste-of-time.html#.VZdxxDgziko