Scrum is a popular agile framework that helps teams deliver value to customers in an iterative and incremental way. However, Scrum is not a one-size-fits-all solution, and teams may need to adapt it to suit their specific context, goals, and challenges. In this article, you will learn how to customize Scrum to fit your team's needs, without losing its core principles and benefits.
Scrum is based on empirical process control, which means that teams inspect and adapt their work based on feedback and data. This allows teams to respond to changing requirements, customer needs, and market conditions. However, Scrum also provides a set of roles, events, artifacts, and rules that define how teams should work together. These elements are designed to create transparency, alignment, and collaboration among team members and stakeholders. However, not every team may find these elements optimal or relevant for their situation. For example, some teams may work in different time zones, have different skill sets, or face different regulatory constraints. Therefore, customizing Scrum can help teams find the best way to apply the agile values and principles to their context.
Let's make a clear distinction between "customizing Scrum" (deprecated), "Configuring Scrum" (essential) and "Adding Engineering Practices" (essential). If you change Scrum itself, what you're doing is no longer Scrum. Some changes might be improvements - or improvements in the specific context, but the vast majority of changes I've seen are ignorant. Scrum gives you two nested PDSA cycles and almost everything in Scrum is to support these. Do you REALLY want to break that? There are a few legitimate changes, say converting once per sprint events into continuous activities. But take care. And by all means, configure things like sprint length, Daily Scrum timing etc. to the needs of the context.
I think the proper word here should be"CONFIGURING not CUSTOMIZING" If you customize Scrum, then you're no longer doing Scrum. The best approach is to seek a professional who is an expert in agile transformation, these change agents are trained to help organizations adopt scrum, its processes, practices and principles.
It involves adapting framework while still adhering to its core principles and that can be done by Adjusting Sprint Length, tailoring roles and responsibilities, modifying artefacts, continuous improvement, transparency and collaboration.
Customizing Scrum to fit your team's needs involves adapting its practices, ceremonies, roles, and artifacts to align with your unique context while preserving its core principles. This may entail tailoring the frequency and format of ceremonies, adjusting roles to better suit your team's structure, modifying artifacts to reflect your workflow and priorities, and experimenting with different timeframes or integrating with other agile practices like Kanban or DevOps. Encouraging a culture of continuous improvement, empowering team autonomy, and iterating on your approach over time are key to creating a more tailored and effective agile framework that supports your team's goals and objectives.
It's a lightweight framework. Simply ask your team "What else do we need to do to get things delivered whilst at the same time keep our end users happy?"
Customizing Scrum does not mean disregarding its core elements or creating new ones; rather, it involves changing or altering some components of Scrum to better suit the team's needs, while preserving the essence and purpose of Scrum. To customize Scrum, teams should start by identifying the problem or opportunity they want to address. Then, assess how they are currently using Scrum and identify the gaps or issues they face. Next, define what they want to accomplish by customizing Scrum and how they will measure it. After that, propose and implement a change to one or more aspects of Scrum that will help them achieve their desired outcome. Following this, observe and collect data on the impact of their change and compare it with their baseline and expectations. Finally, review their findings and decide whether to keep, modify, or discard their change. Document and share their learnings with other teams and stakeholders. Repeat this process as needed until they find the optimal way to use Scrum for their context.
1. Observe your team individually 2. Listen to their voices 3. Analyze your data, who did what at which speed, team strength and weakness 4. Experiment, test your theory and process and collect feedback and data some more And repeat these 4 steps over and over again
I feel all teams should always start with Scrum as prescribed in the Scrum Guide. As teams get accustomed to ways of working & related processes, they will start identifying things that work well and ones which don't. I tend to call this 'Try & Fail' method, where you try out the process with the team and get feedback. Based on feedback & suggestions from the team, change things that are detrimental and incorporate improvements as the team adapts to this 'newer' process. In the long term, probably the team would move away from Scrum by the book to a Scrum that works for them.
Scrum framework does not give an all-inclusive, prescriptive approach, instead, offers a guideline (Scrum Guide) with its core elements (theory, values, roles, events, artifacts) to be applied to solve complex problems. I think you can add value to your team and customers with use of best practices, tools and techniques (for example on prioritization of Product Backlog, refinement of user stories, generating Product Vision, crafting Definition of Done) that do not interfere with agile mindset, core elements, theory and values of Scrum. In the end, your purpose is presenting a working increment of your product to your customers/consumers at the end of each Sprint.
There is no predefined formula to build an adaptive solution, and skilled one needs to tailor the project framework to achieve it. For example, the scrum team can conduct each event differently and may not stick to one call. Delegate, reacquire, or cross-train the scrum role as feasible. Commit to scrum artifacts that add value to the client's business. You can extend Scrum to dependent teams (non-scrum teams who may or may not know Scrum) on the fly in an easy way to adhere. A framework like Scrum customization requires experienced and skilled expertise. Do not try with a na?ve one.
Customizing Scrum to fit the team's needs is a common practice, as every team has unique dynamics, challenges, and requirements. Some teams find shorter sprints (like one week) more suitable for rapid iterations, while others might opt for longer sprints (like three weeks) for more substantial increments. While Scrum defines certain ceremonies like Sprint Planning, Daily Standups, Sprint Review, and Sprint Retrospective, by tailoring and fine-tuning these ceremonies, you can optimize Scrum to better suit the team's needs. The key to successful customization is to stay true to the core principles and values of Scrum while adapting the practices to suit the team's unique context and challenges.
Scrum offers some flexibility and options for teams to customize some of its elements, as long as they do not compromise its core values and principles. For instance, teams can select the duration of their sprints, which are the time-boxed iterations in which they deliver a potentially releasable increment of value. The default sprint length is one month, but teams can choose shorter or longer sprints depending on their product, customer, and market needs. Additionally, teams can choose how and when they refine their product backlog, which is the ordered list of requirements and features that they want to deliver. Furthermore, teams can decide on their definition of done, which is the shared understanding of what criteria a product increment must meet to be considered done and potentially releasable. Lastly, teams can choose their roles and responsibilities, which are the functions and expectations of each team member and stakeholder. However, teams should ensure that any customization does not hinder the Scrum values and principles and that it fosters self-organization, collaboration, and accountability.
There are many options a. Sprint Length: Are your projects quick or long and complex? Change how long your sprints are to match. b. Meetings: Do your daily meetings help or waste time? Change how often you meet or how you run meetings. c. Roles: Does your team need a specific person in charge of the product, or can you share the responsibility? Decide based on your team's structure and the project's complexity.
1. Customize the meetings in a way that makes people very productive. ?????? 2. Customize the tools that will generate a significant amount of data over a period so that the organization can evaluate and rethink. ??????? 3. Customize the culture in a way that every single person is respected and becomes inclusive in the process journey. ??????
I think not to have daily meetings is not an option. Let’s imagine the scenario: how else would the team members raise red flags?
Teams should be careful what to change and what not to. I feel the core of Scrum should not be disturbed unless proven 'utterly' wrong.
scrum tiene una estructura , ceremonias que sí son obligatorias, pero el contexto,la cultura, el tipo de proyecto es en base a lo que quiere lograr el equipo scrum. Por ejemplo , es obligatorio tener spring, pero lo personalizas , basados en los recursos tiempo y carga laboral de equipo.
While Scrum allows some room for customization, there are some elements that teams should not change or omit, as they are essential for Scrum to work effectively and deliver value. For example, it is important to uphold the Scrum values of commitment, courage, focus, openness, and respect - which help teams build trust, transparency, and collaboration. Additionally, the Scrum principles of empiricism, self-organization, collaboration, time-boxing, and value-driven delivery should be followed in order to inspect and adapt their work based on feedback and data. Teams should also not skip or alter the Scrum events such as the sprint planning, the daily scrum, the sprint review, and the sprint retrospective - which help create transparency, alignment, and learning. Finally, teams should not ignore or modify the Scrum artifacts like the product backlog, the sprint backlog, and the product increment - which help create visibility, accountability, and quality for their work.
Well, throw away the backlogs and you're done - not only with scrum :) I find most principles or ceremonies are just good organization but for some they might be hard to stick to and that is a slippery slope to assumptions, lack of transparency and lower quality of delivery.
It's important to adhere to agile principles when customizing. Customizations should not affect the 4 main ceremonies, but the way they are conducted can be customized.
While Scrum might be a very good way to start for a team, if - by following the agile principles and self management - they decide to customize things so to make them create better value ... they should be able to change anything they want. You could argue that they aren't doing "Scrum" anymore if they ditch some ceremony ... but they can still be very agile !
los roles del equipo. SM, P.O y desarrolladores , deben tener claro sus funciones, las ceremonias, spring reuniones de feedback, etc.
Customizing Scrum can help teams find the best way to use the agile framework for their context, but it can also create some challenges and risks. For example, customizing Scrum can lead to confusion, inconsistency, or inefficiency among teams and stakeholders, especially if they work on the same or related products or projects. Therefore, teams should balance customization and consistency in Scrum by following these tips: Communicating and collaborating with other teams and stakeholders affected by their changes, aligning and integrating their customization with the overall vision, strategy, and goals of their product or organization, and experimenting and evaluating their customization with a scientific and data-driven approach. They should also seek feedback from others, learn from their experiences and best practices, ensure that their changes do not create conflicts or dependencies with other teams or systems, deliver value to customers and users, define clear hypotheses, measures, and criteria for their changes, test them in small and fast cycles, monitor and analyze results and outcomes of their changes, and validate them with customers and users.
Asegúrate de que cualquier personalización promueva la transparencia, la inspección y la adaptación. Además, deberías revisar regularmente la efectividad de tu versión personalizada de Scrum y estar dispuesto a hacer ajustes según sea necesario. Usa herramientas tecnológicas que faciliten el workflow del equipo de trabajo y su personalización, tal como Jira o Trello.
Establish some standards and practices to go by, no matter what but be in the continuous cycle of learning and adapting. This will not only help keeping the scrum customizable but convey very transparently to the team the practices to follow.
dentro de los principios de scrum exite la comunucación y visualizacion con las partes interesadas, la visión board , como la documentación debe ser accesible
As an agile methodologies expert, I can add my two cents here are: 1. Adapting roles, events, and artifacts to fit team dynamics and project needs. 2. Experimenting with practices while preserving core Scrum principles. 3. Facilitating continuous improvement through regular retrospectives and feedback loops. 4. Integrating additional tools and techniques to enhance collaboration and productivity. 5. Collaborating with stakeholders to ensure alignment with organizational goals and values. 6. Providing guidance and expertise to support effective customization efforts.
Scrum reste un framework très léger et peu prescriptif. En réalité, - Vous avez une équipe scrum avec un Product Owner, un Scrum Master et des Développeurs (comprendre personnes en chargent de créer, pas forcément développeurs Python) qui construise un produit - Vous définissez des objectifs à atteindre à fréquence régulière (entre 1 et 4 semaines) - Vous inspectez l'objectif à atteindre chaque jour pour adapter votre plan, vous inspectez au moins une fois avec vos utilisateurs et clients vos réalisations selon votre fréquence choisi et vous inspectez votre fa?on de travailler a cette même fréquence en équipe... Vous faites du Scrum. Estimation, Story Point, Poker Planning, Burndown, Vélocité, ... Tout ceci n'est pas Scrum
In some occasions I have helped teams implement Scrum without having the formal roles of PO & SM defined. Yet, scrum mastering & product ownership were taken up by a committee of volunteers. It's about the behaviour, not about the title.
It could be a good idea to switch from Scrum to Kanban, if you have more and more daily business tasks instead of change activities. Other good idea to improve your Scrum is to establish OKRs. We use them to create our EPICs (our key results) for the next quarter.
Customize Scrum by adapting ceremonies, roles, and artifacts to suit team dynamics and project requirements. Experiment with adjusting sprint length, refining the definition of done, or introducing additional ceremonies like backlog grooming. Encourage continuous improvement by soliciting feedback from team members and stakeholders. Tailor metrics and reporting mechanisms to reflect the team's unique goals and challenges. Strive for a flexible approach that maintains the core principles of Scrum while accommodating the specific needs and circumstances of the team.