How can you avoid common myths about Scrum Framework?

Scrum is often referred to as a framework rather than a process or methodology. This distinction is important because it reflects the flexibility and adaptability that Scrum offers in contrast to more rigid and prescriptive approaches like traditional processes or methodologies. A process or methodology tends to offer a more detailed and standardized set of procedures, practices, and guidelines. It often assumes a one-size-fits-all approach and may not encourage the same level of adaptability and continuous improvement that Scrum emphasizes.

Scrum is evolutionary. It adapts as per need of organisation ans need of teams. Flexibility is the key here. Scrum myths can be overcomed by emphasizing scrum values and agile principles after certain intervals. In daily routines teams overlooked them and later blame goes to framework that its not working for us.

The Key pillars are the ceremonies that happen in Scrum lifecycle. Most of the companies I have worked with, keep skipping one or the other key ceremony as per the need. If you don't maintain the decorum of these ceremonies, scrum would never feel a success to you or the organization.

I agree the fact that it’s should be flexible and adaptable as the conditions differs in every cases but the Agile is more a mindset with set of manifesto of agile principles which should implemented for better performance and productivity.

From Scrum guide 2020 this framework tries to shift from software products to other industries. It starts from changing the terminology. For example every Sprint the Scrum Team should create a valuable increment which is replaced by potentially releasable one. However, The main thing about using this framework is not about the industry. It’s about using this framework in an inappropriate way. Remember Scrum is immutable so that use it just like it is.

It started with the IT industry , but the scope now is wider. Start with understanding the principle and tailor the Scrum to your domain.I think all areas need collaboration, calibrate the work volume and deliver value.

This is the biggest and most common myth. During an agile transformation of the organization, you will hear it many times. Scrum initially started being applied in software development, but in reality, Scrum is a flexible framework that can be adapted and utilized in a wide range of industries and projects beyond software development. It's based on principles like transparency, inspection, and adaptation, which are not exclusive to software development. Scrum emphasizes regular feedback, collaboration, open communication, and continuous improvement. As we understand, the above can be applied everywhere because all of this is a mindset.

Indeed Scrum is not only for the software world. Scrum is a framework within which people can address complex adaptive problems. In the real world, climate change, world financial crisis etc. can be good examples of complex problems. Currently there are many vehicle manufacturers in the Automotive sector who have been using scrum framework. And it’s true that scrum is not tied to any technology or tool but rather it focuses on delivering values.

Scrum works well in contexts where deliverables need to be frequently produced on a regular cadence. While Scrum was developed in the context of software development, it's certainly not limited to that domain. When teams of people need to work together to produce something, Scrum can be very useful to help coordinate activities and keep momentum going. It's important to note that not all contexts are structured this way. When the situations are inherently reactionary, urgent, sensitive, exploratory, or broad, an alternative framework, such as Kanban, may be a better fit.

The product backlog refinement is not a Scrum event but a continuous activity. It can be organized as meeting, informal conversation, experiment... Besides from that I find it difficult to explain the difference between an event and a meeting. Event sounds more exciting, right ;)?

Interestingly enough, the Daily Scrum should be mostly by and for the developers in the Scrum Team. If this is really lived, it automatically changes its character from a progress update meeting to an interactive event where impediments on the way to the Sprint Goal are discussed. As a Scrum Master, I always like best when that happens and when my presence is, ideally, not relevant.

Why is daily meetings a myth. What is the problem statement? Scrum builds on agile mindset and values. The first value of the Agile Manifesto: Individuals and interactions over processes and tools In Scrum Guide: "Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum." "Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings." "The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work." Apart from events, there are meetings too, be it daily or not.

We should have a clear distinction between a “Meeting” and “Ceremony”. Meeting can be skipped not the Ceremony. And Daily Scrum Call (DSC) is one of those ceremonies. It’s a short planning session where we agree on a plan that needs to be followed on that specific day. If DSC is misconstrued as a meeting that may allow people to take it like any other meeting and they may consider skipping it by sharing their status on Email/Chat. Which eventually kills the idea of Scrum/Agile. Other than DSC, which is a ceremony, no need for daily meeting.

While Scrum does define specific roles and responsibilities, it is important to note that the framework is designed to be flexible and adaptable to different contexts. While the roles of Product Owner and Scrum Master are well-defined within Scrum, there is room for variation and customization based on the needs of the team and the organization. For example: - Each team and organization has unique circumstances and requirements - In smaller teams or organizations, individuals might take on multiple roles. -Depending on the project's complexity, the team might introduce additional roles to address specific needs. -Hybrid models that combine Scrum with other frameworks or methodologies.

The 2020 version of the Scrum guide does not talk about roles, but about accountabilities: PO, SM and developers (not development team any more). There is only one team in Scrum, the Scrum Team (which consists of PO, SM, and Devs).

Scrum has 3 main roles: scrum master, product owner and the team. Teams should be full of generalists rather than specialists to have minimum or no handovers, this will improve the deliverables, it is better to have people who knows bit of everything rather then specialists.

Scrum outcomes are better when these are distinct roles, but I do believe the Scrum Master and the Product Owner do have to be separate roles. It's too big of a conflict to manage a scrum process when one needs to manage the Product priorities and backlog.

Scrum is one framework that has roles that can be played out by anyone in the team. A dev can become a product owner or a scrum master based on necessities. Scrum promotes fence skills and encourages self sufficiency within the team.

Most of the times, it is difficult to implement scrum as not everyone on the team is aware of all the processes, terminologies, roles and responsibilities. So the team has to be first educated and everyone has to be on the same page before we can even start to implement scrum. Once the team has had a couple of iterations/sprints, things start to slowly smoothen up.

In my perspective, it’s not just about following the ceremonies and roles; it's about adopting a new way of thinking and working; it's a profound shift in how teams and organizations work. It challenges you to be transparent about your work, inspect your processes, adapt to change, collaborate effectively, empower team members, and put customers at the heart of what you do. Implementing Scrum, It's a journey, a continuous process that requires a whole lot of pragmatism, commitment, courage, and discipline. So, it's not a walk in the sunshine, but it can be as satisfying as finding the last slice of the Albanian Byrek in the oven at 2 AM once you've figured it out.

Depends on several factors such as transformation lead by experienced coaches, buy-in from leadership, appetite for change, right kind of enablement & skilled folks in critical roles of Product Owners & Scrum Masters. If the above things done right with collaboration across then the implementation becomes easy. If people lack knowledge of what it takes to transform, applying Scrum as fancy fix and jump on the wagons with namesake activities will kill the purpose. It's critical to ensure the foundations are done right.

Though Scrum is one of the simple as well as light weight framework of agile methodology. But it is not easy to implement. It requires mindset where every member of team must know about the scrum values and principles and scrum master helps team and organization to understand all the scrum terminology. Scrum helps team to be more self organised. Implementing scrum is not few days work, it is a journey which embrace mindset, principles,values, atifacts and role. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

The idea that Scrum is easy to implement can be misleading for several reasons. Scrum requires a significant shift in mindset, not just for the development team but for the entire organization. Adopting an Agile mindset means embracing iterative development, continuous feedback, and a willingness to adapt. Changing established practices and ingrained behaviors can be a substantial challenge. Also you need to have changes to the organizational culture, roles changes and new process ( sprints). The journey to implementing Scrum is a continuous process of learning, adapting, and improving, leading to more successful and agile project outcomes.

Another myth about scrum is it does not provide career growth opportunities. This is not true, remaining in scrum team you always keep evolving. Collaboration, communication and courage to build next opportunity also evolved in scrum framework. It gives more independence to work on innovation and learning if you plan wisely.

Many people think that team will work in Agile once they work in that mode for 6-8 months and that is not true. Leadership has to constantly guide and find ways to improve the team’s adoption of scrum and nudge them back when they move away from it. It is easier to fall back to old ways if not consciously monitored.

A core principle of Agile is "people over process." Teams that are implementing Scrum need to make this central to their team culture and a touch-point for their decisions. One of the appealing aspects of Scrum is how much rich and detailed information exists to help teams get started. It can be easy to become over-zealous over the HOW of Scrum that you overlook the WHY of Scrum.

The biggest myth is tailoring of the Scrum framework. One thing I keep hearing a lot is that we did Scrum and it doesn’t work. We even tried to tailor it to our team. Scrum framework is unique in a way that you can build upon the framework to become more Agile but don’t tailor the core of it. The scrum guide says: “Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.” You can be agile without Scrum but you aren't using scrum without its core.

Lo importante es entender a qué hace referencia el término "agilidad", salir de la comparación con "hacer las cosas rápido". Entender que el por qué y el para qué. Agilidad para responder al cambio y a qué cambio nos referimos y por qué es importante esto en diferentes entornos. A qué? Al cambio. Para qué? Combatir entornos cambiantes, complejos y de alta incertidumbre, esto se puede entender abordando VUCA y BANI por ejemplo.