What are the most common challenges in using the Scrum framework?

Deliver workable software at the end of each Sprint: In theory this sounds great, but the reality is different. Being working with this model for many years, I must say it is not always possible and it is difficult to achieve if you are working with big organisations where there are too many dependencies on other teams, business units, stakeholders and vendors. The sprint length is ideally between 2-3 weeks. But not every time we have something fully developed, tested and ready to be deployed in production environment. This sprint length could work for small startups and teams, not for big companies.

Agile approaches to work expose problems, but won't fix them on their own. If your adoption of Scrum highlights a lack of clarity, talk as a team about ways to better define scope. I'm a big fan of articulating a lightweight definition of done and definition of success for each task. This is work that the entire team should shoulder; not just the Product Owner or Scrum Master.

Unfortunately too many organizations want the "benefit" from Scrum as a Framework, without accepting its necessary "concessions" (or for some Mangers, not Leaders, "sacrifices" to their unlimited powers). In fact, without a truly empowered Product Owner (replaced by the so called proxi-PO, too often the BA) who TRULY OWNS a Product/Service end-to-end, the Organization will lack not only from a Vision, but won't allow the whole Scrum team to Focus & Commit on the Product and Sprint Goal, missing Openness and Transparency, with no reason to show Courage when the "Product Backlog" is actually just a list of deliverables to be "Done" by a fixed date. This is unfortunately a very common approach of "doing mechanical Scrum" without BEING Agile.

Uno de los desafíos más importantes de Scrum es asumir la frecuencia corta de iteración de lo que se está haciendo, antes se verificaban los avances cada 3 meses, ahora cada 15-7 días. El otro problema es que por principio no admite especialistas, todos tienen que saber sacar el trabajo, esto no es real, imaginemos un rol de DBA y queda claro. Pero el principal problema es cultural: Scrum cuestiona las relaciones de poder. En muchas empresas hay personas con puestos "ganados" que no están dispuestas a hacer las cosas de otra manera. Y que tienen mando e influencia sobre las personas que "sacan" el trabajo. El Scrum Master no tiene opciones para cambiar ese status quo. Finalmente el responsable de los fracasos es el SM y vuelta atrás.

Length of Daily Call: Some teams are good at ending calls in less than 15 mins, they are to the point and precise. But some teams end up talking for more than 30 mins every day. Scrum Master can coach and try to train team members, but there is also a limit. Some team members think they need to talk more to be listened and miss the entire point of 15 mins Daily Call principles. This meeting is not to go in detailed technical discussions. It's not a space to share personal diary. The purpose of this call is not to update everyone in detail what you did yesterday and will do today. In some cases, it is not useful for entire team members to be there and keep listening for long conversations. This leads to loss of productivity and focus.

Si se parte desde cero en Scrum, hay que observar muy bien el nivel técnico de los desarrolladores, una falencia en lo humano se puede reconducir, falta de conocimientos en lo técnico no, en el corto plazo. Se necesita un equipo equilibrado en los saberes y en la experiencia, muy difícilmente todos puedan hacer todo como indica la teoría de Scrum. Muchos equipos se niegan a calcular el tiempo de dearrollo, argumentando que en Scrum no se hace, esto no es así, el tiempo es dinero y compromiso con el cliente. Otro error a evitar es hacer equivalencias fáciles, tipo un punto=una hora. No es así. El planning poker, bien entendido, es la mejor manera de calcular y fijarse objetivos. Finalmente, sin confianza mutua no hay retrospectiva que sirva.