SCRUM BUT sucks!
Que Scrum But es correcto? que Scrum debe ser modelado de acuerdo a la organización? No quieres cambiar, entonces recortas y adaptas.
Que especialistas de procesos estudien y re-diseñen SCRUM y lo mutilen con prácticas de procesos obsoletos? que la organización se centre en el proceso modelado y no haya aprendido de las personas trabajando? No es válido!!!.
Scrum sin expertos en Agile es nefasto, mucho más que cualquier otro modelo. Scrum como un proceso bien definido no te llevará hacia Agile. Necesitas Champions con experiencia que lideren a los teams.
SCRUM sin Agile es cualquier cosa, menos SCRUM.
Por favor, al menos utiliza algunos criterios fuera de tus antiguos paradigma, intenta, intenta, intenta... aunque igualmente lo siento, muy probablemente no podrás.
Haz algún Scrum Test, lo más básico pero ei honesto al responder, con la verdad, no con lo que crees que debería ser .... intenta pensar distinto sin miedo.
Ten en cuenta algunas estadísticas:
- el 70% de los equipos reciben buenas especificaciones en general
- solo un bajo porcentaje intentan trabajar con historias pobremente especificadas, o con enormes documentos de requerimientos o sin ellos.
- casi el 80% de los equipos practicantes de Scrum utilizan iteraciones fijas de 4 semanas o menos (Fijas, no un día más para terminar testing. Fijas, no la review la haremos en unos días cuando logramos terminar unas features... ah pero sin testing)
Testing Issues
- solo un 2% de los equipos no han incluído testers a su proceso de desarrollo Scrum
- un 27 % prueban las features cuando las mismas están completadas,
- bueno si se agregó un nivel más de testing para la integración de las features
- malo si se esperó a tener la feature completa para hacer testing
- solo un 20% pasó las pruebas de aceptación
- malo si solo un 20% de los equipos hacen Sprint Review
- malo si solo el 20% de los equipos logra pasar OK las Sprint Review
- solo un 6% despliega su software luego de cada Sprint
- el 74% de los equipos cuentan con Product Owners que en general tienen un product backlog claro y previamente estimado por el equipo, antes de las Sprint Planning, con un roadmap del release con fechas realistas basadas en la velocidad de los equipos. Adicionalmente suelen trabajar como entes motivadores del equipo.
Product Backlog issues
- el 89% de los equipos trabaja con un único Product Backlog, claramente especificado y priorizado antes de las Sprint Planning, sus burdown chart releases están actualizados de acuerdo a la velocidad los equipos y es posible medir el ROI basado en ingresos reales, costos por puntos de historia o alguna otra métrica Agile.
- el 56% de los equipos no son interrumpidos por Project Leaders, Managers o Product Owners y están compuestos necesariamente solo por roles Scrum
Tags : scrum scrum but statitics
Javosantillan
Seo Construction
I like to make cool and creative designs. My design stash is always full of refreshing ideas. Feel free to take a look around my Vcard.
- Javosantillan
- Februari 24, 1989
- 1220 Manado Trans Sulawesi
- contact@example.com
- +123 456 789 111
Publicar un comentario