Interview Questions for Agile (Scrum, Kanban)

Scrum is a lightweight, iterative, and incremental framework for managing complex work, often used for software development but applicable to various projects. It emphasizes teamwork, accountability, and iterative progress towards a well-defined goal. Think of it as a structured approach to tackling a large project by breaking it into smaller, manageable chunks.

The key roles in Scrum are:

• Product Owner: Responsible for maximizing the value of the product. They define the product backlog, prioritize items, and ensure the team builds the right product. Imagine them as the visionary, guiding the project’s direction.
• Scrum Master: Serves the Scrum team and the organization to remove impediments and ensure the team follows Scrum principles. They’re the coach and facilitator, helping the team work efficiently and effectively. Think of them as the team’s advocate and problem solver.
• Development Team: A self-organizing and cross-functional team responsible for delivering the product increment. They are the doers, the ones actually building the product. This team is empowered to decide how best to achieve the sprint goal.

Scrum and Kanban are both Agile frameworks, but they differ significantly in their approach. Scrum is a framework with defined roles, events, and artifacts, creating a highly structured environment. Kanban, on the other hand, is a method that focuses on visualizing workflow and limiting work in progress (WIP). Think of Scrum as a rigid structure and Kanban as a more flexible canvas.

• Structure: Scrum is highly structured with defined roles, events, and artifacts; Kanban is more flexible and adaptable.
• Iteration: Scrum uses sprints (fixed-length iterations); Kanban uses a continuous flow of work.
• Workflow: Scrum focuses on completing a defined set of work within a sprint; Kanban aims to optimize the flow of work through the system.
• Meetings: Scrum has defined meetings (Sprint Planning, Daily Scrum, etc.); Kanban meetings are typically less formalized and as needed.

In essence, Scrum is prescriptive, while Kanban is descriptive. A team might even use both – employing Kanban boards to visualize the flow of work within a Scrum sprint.

Scrum events are time-boxed meetings designed to inspect and adapt the process. They are crucial for maintaining transparency, collaboration, and continuous improvement.

• Sprint Planning: The team collaborates to select items from the product backlog to include in the upcoming sprint. They create the sprint backlog – a plan for how they’ll achieve the sprint goal.
• Daily Scrum: A short daily meeting (typically 15 minutes) where the team synchronizes, identifies impediments, and plans the day’s work. It’s not a status update meeting, but a collaborative planning session.
• Sprint Review: A meeting at the end of the sprint where the team demonstrates the completed work (the increment) to stakeholders and gathers feedback. It is a collaborative presentation and not a performance review.
• Sprint Retrospective: A meeting where the team reflects on the past sprint, identifies what went well and what could be improved, and creates action items for the next sprint. It’s a focused learning session focused on continuous improvement.

Scrum artifacts are physical or digital representations that hold information throughout the development process. They provide transparency and a shared understanding of the work.

• Product Backlog: A prioritized list of all features, requirements, enhancements, and bug fixes for the product. It’s the single source of truth for what needs to be built.
• Sprint Backlog: A plan for the work the team will complete during a single sprint. It’s a breakdown of the selected product backlog items into tasks.
• Increment: The sum of all the work completed during a sprint. This is potentially shippable product functionality. Each increment builds upon the previous one, adding value incrementally to the product.

Impediments, or obstacles hindering progress, are inevitable in any project. In Scrum, they are addressed proactively and transparently.

Here’s a typical approach:

1. Identification: During Daily Scrum or other meetings, team members openly identify impediments blocking their progress.
2. Escalation: The Scrum Master takes ownership of removing impediments by engaging relevant stakeholders (e.g., management, other teams, support staff).
3. Collaboration: The Scrum Master facilitates discussions and collaboration to find solutions.
4. Tracking: Impediments are tracked, and their resolution is monitored to prevent recurrence.
5. Transparency: Impediments and their resolution are transparently communicated to the entire team.

Example: If a developer is blocked by a missing API, the Scrum Master would work to get the API team involved to resolve the issue.

The ‘Definition of Done’ (DoD) is a shared understanding within the team of what constitutes a completed product increment. It outlines the criteria that must be met before a task or user story is considered ‘done’. This ensures consistent quality and prevents incomplete work from creeping into the product.

Example: A DoD might include criteria like:

• Code reviewed and approved
• Unit tests pass
• Integration tests pass
• Automated deployment successful
• Documentation updated

Without a clear DoD, different team members might have varying interpretations of ‘done’, leading to inconsistencies and lower quality.

A Kanban board is a visual representation of workflow. It’s a tool for managing and visualizing work items as they move through different stages of a process.

Typically, a Kanban board consists of columns representing stages of work (e.g., To Do, In Progress, Testing, Done) and cards representing individual tasks or user stories. Team members move cards across the board as they progress through the workflow.

Kanban boards help to:

• Visualize workflow
• Limit work in progress (WIP)
• Identify bottlenecks
• Improve flow and efficiency
• Enhance communication and collaboration

Think of it as a visual roadmap of your work, helping you track progress and identify areas for improvement. It can be a physical whiteboard or a digital tool.

Kanban, at its core, is a visual system for managing workflow. It focuses on visualizing work, limiting work in progress (WIP), and improving flow. Instead of rigid iterations like Scrum, Kanban emphasizes continuous improvement and adaptability.

• Visualize Workflow: Using a Kanban board (physical or digital), all tasks are visible, allowing the team to see the current state of work at a glance. This transparency promotes better understanding and collaboration.
• Limit Work in Progress (WIP): By restricting the number of tasks in progress at any given time, Kanban prevents context switching and improves focus. This leads to faster task completion and reduces bottlenecks.
• Manage Flow: Kanban aims to optimize the flow of work through the system, identifying and addressing bottlenecks to ensure smooth progression. This is achieved through continuous monitoring and improvement.
• Make Process Policies Explicit: Defining clear rules and guidelines for how work progresses through the system helps everyone understand their roles and responsibilities.
• Implement Feedback Loops: Regularly reviewing the Kanban board and processes allows for quick identification of areas for improvement, leading to ongoing optimization.
• Improve Collaboratively, Evolve Experimentally: Continuous improvement is achieved through collaboration and experimentation. The team regularly discusses ways to enhance the process, testing changes and iterating based on the results.

For example, imagine a customer service team using a Kanban board with columns like ‘To Do’, ‘In Progress’, ‘Testing’, and ‘Done’. They limit the number of support tickets in ‘In Progress’ to prevent agents from becoming overwhelmed. This visual system provides transparency into the workload and enables better resource allocation.

Measuring the effectiveness of a Scrum team goes beyond simply delivering features. We need to assess performance across various dimensions, focusing on both velocity and quality.

• Velocity: This measures the amount of work a team completes in a sprint. While useful for forecasting, it’s crucial to avoid using it as the sole performance indicator, as velocity can be artificially inflated.
• Sprint Burndown/Burnup Charts: These visualize the progress of a sprint, highlighting potential roadblocks or issues that need addressing. Deviations from the plan should be investigated.
• Cycle Time and Lead Time: Cycle time tracks how long it takes to complete a single task, while lead time encompasses the entire process from request to delivery. Shorter cycle and lead times indicate improved efficiency.
• Defect Rate: The number of defects found after a sprint indicates the quality of the work delivered. A high defect rate suggests potential process improvements are needed.
• Team Happiness and Collaboration: A highly effective team is one that enjoys working together and is motivated. Regular feedback sessions and retrospective meetings are crucial for assessing morale and identifying potential issues.
• Meeting Efficiency: Time spent in meetings should be productive and yield clear outcomes. Teams should constantly evaluate if their meetings are delivering value.

For instance, a team consistently exceeding its velocity but with a high defect rate needs to prioritize quality improvements over speed. Conversely, a team with low velocity but high quality might benefit from identifying and removing process bottlenecks.

Scope creep, the uncontrolled expansion of project requirements, is a common challenge in Agile projects. The key is proactive management and clear communication.

• Define a Clear Product Backlog: The product backlog should be meticulously prioritized and contain well-defined user stories with acceptance criteria. This provides a clear baseline for scope.
• Prioritize ruthlessly: Regularly review the backlog and ensure that only the highest priority items are included in each sprint. Use techniques like MoSCoW (Must have, Should have, Could have, Won’t have) to categorize requirements.
• Change Management Process: Implement a formal process for managing changes to the scope. New requirements should be evaluated, prioritized, and potentially added to the backlog, but this should always involve discussing the impact on timelines and resources.
• Transparency and Communication: Keep the stakeholders informed about any scope changes and their impact on the project. This helps maintain alignment and prevent misunderstandings.
• Regular Stakeholder Meetings: Consistent communication with stakeholders ensures everyone is on the same page and prevents uncontrolled feature additions.

In practice, if a new requirement emerges during a sprint, the team should assess its importance and impact. If it’s high priority, it could be added to the backlog for future sprints after discussing the potential adjustments needed to the sprint goal. If it’s low priority, it can be deferred or rejected altogether.

Several Agile metrics help track progress and identify areas for improvement. The choice of metrics depends on the specific project and context, but some common ones include:

• Velocity: Story points completed per sprint.
• Cycle Time: Time taken to complete a single task.
• Lead Time: Time from request to delivery.
• Throughput: Number of tasks completed per unit of time.
• Defect Rate: Number of defects per unit of work.
• Code Churn: Amount of code changed or added.
• Test Coverage: Percentage of code covered by automated tests.
• Customer Satisfaction: Measured through feedback surveys or direct interaction.

These metrics should be used to understand trends rather than focusing solely on individual numbers. For example, a consistently decreasing cycle time indicates improved efficiency, while an increasing defect rate might signal a need for better testing practices.

Agile estimation is crucial for planning and forecasting. I’ve extensive experience with story points and T-shirt sizing.

• Story Points: A relative estimation technique where team members assign points to user stories based on their complexity, effort, and uncertainty. Fibonacci sequence (1, 2, 3, 5, 8, 13…) is often used. This fosters a shared understanding of the work involved. We use planning poker as a collaborative estimation technique.
• T-Shirt Sizing: A simpler, quicker method assigning sizes (XS, S, M, L, XL, XXL) to user stories based on relative size. It is less precise than story points but sufficient for certain projects or early stages.

In practice, I’ve found that a combination of both techniques can be effective. We might use T-shirt sizing for initial rough estimation and then refine with story points as we gain a better understanding of the requirements. The key is consistency and team agreement on the scale.

The Sprint Retrospective is a crucial event in Scrum, focusing on continuous improvement. I facilitate them using a structured approach:

• Set the Stage: Create a safe and respectful environment where everyone feels comfortable sharing their thoughts and opinions.
• Gather Data: Use techniques like questionnaires, surveys, or a simple discussion to gather information about the sprint. What went well? What could be improved? What did we learn?
• Analyze Data and Identify Themes: Organize the feedback into key themes or patterns to focus the discussion.
• Generate Solutions and Action Items: Brainstorm potential solutions for identified issues. Assign owners and deadlines for action items to ensure accountability.
• Close the Retrospective: Summarize the key takeaways and action items. Communicate the decisions and their rationale to the team.

I always emphasize that the retrospective is about continuous improvement, not blame. The goal is to identify areas for improvement and collaboratively create solutions. I typically use visual aids like sticky notes and a whiteboard to make the process engaging and productive.

CI/CD (Continuous Integration and Continuous Delivery) is a set of practices that automates the process of software development, testing, and deployment. It is highly beneficial in an Agile environment.

• Continuous Integration (CI): Developers integrate code changes into a shared repository frequently (ideally multiple times a day). Automated builds and tests are triggered with each integration to quickly detect and fix integration issues. This minimizes the risk of large integration problems later in the development cycle.
• Continuous Delivery (CD): Extends CI by automating the release process. Once code passes automated tests and meets quality standards, it’s automatically deployed to a staging or production environment. This allows for faster releases and quicker feedback from users.

In an Agile context, CI/CD allows for faster feedback loops, quicker response to user needs, and reduced risk. It promotes frequent, smaller releases, aligning perfectly with the iterative nature of Agile development. A well-implemented CI/CD pipeline greatly improves development efficiency and reduces time-to-market.

Managing dependencies between Agile teams requires proactive communication and collaboration. Think of it like a well-orchestrated symphony – each section (team) plays its part, but they need to be in sync. We can’t have the violins playing their crescendo while the trumpets are still on their introduction.

• Dependency Mapping: First, we visually map out the dependencies. A simple dependency matrix or a Kanban board showing inter-team relationships can work wonders. This clearly shows which team relies on the output of another.

• Regular Communication: Daily stand-ups, or perhaps weekly synchronization meetings between dependent teams, are crucial. These meetings help to identify potential roadblocks early on.

• Joint Planning: Teams should collaboratively plan their sprints to align on deliverables and timelines. This might involve including representatives from dependent teams in sprint planning sessions.

• Integrated Backlogs: If feasible, integrate the backlogs of dependent teams. This enables a holistic view of the overall project progress and dependencies.

• Shared Definition of Done: Ensuring all teams have a shared understanding of the ‘Definition of Done’ prevents misunderstandings and delays caused by differing quality standards.

• Use of Tools: Project management tools such as Jira or Azure DevOps can be instrumental in tracking dependencies, progress, and communication across teams.

For example, in a project involving a front-end and back-end team, the front-end team’s progress is dependent on the back-end team delivering the APIs. Regular communication and clearly defined API specifications are vital to avoid delays.

I have extensive experience with SAFe (Scaled Agile Framework) and LeSS (Large-Scale Scrum). SAFe, with its defined roles and layers, is best suited for large organizations with numerous teams requiring a highly structured approach. I’ve used it in projects involving hundreds of developers, where its rigor in planning and governance is essential. It offers a comprehensive framework, but can sometimes feel overly complex and bureaucratic.

LeSS, on the other hand, is leaner and more focused on empowering teams. It emphasizes simplicity and encourages decentralized decision-making. I’ve applied LeSS in smaller-scale projects, where its emphasis on collaboration and self-organization helped foster a more agile and responsive environment. It’s more adaptive but requires a high degree of trust and self-management within the teams.

The choice between SAFe and LeSS depends greatly on the organizational context, project size, and the team’s maturity level. In some cases, a hybrid approach blending elements of both frameworks might be the most effective solution.

In one project, a disagreement arose between a designer and a developer regarding the usability of a particular feature. The designer felt the user interface was intuitive, while the developer argued it was overly complex and would be difficult to implement. This conflict threatened to derail the sprint.

To resolve this, I facilitated a collaborative session where both team members were encouraged to express their viewpoints without interruption. We used a structured approach: first, understanding the root cause of the conflict (differing perspectives on user experience and technical feasibility). Then, we explored alternative solutions that addressed both the design and development aspects. We established clear criteria for evaluating these alternatives, focusing on user experience, technical feasibility, and development time. Through open discussion and compromise, we arrived at a solution that satisfied both parties – a modified design that simplified the interface while maintaining the core functionality.

The key takeaway was emphasizing active listening and collaborative problem-solving. The success of this resolution stemmed from fostering a respectful environment where differing perspectives were valued, not dismissed. The resulting solution was stronger because it incorporated the insights of both the designer and the developer.

Task prioritization in Kanban is typically achieved using a combination of techniques that reflect business value and urgency. It’s not about rigid sprints like Scrum but a continuous flow.

• Value-based Prioritization: We assign priority based on the business value each task delivers. The tasks with the highest business impact are placed at the top of the backlog.

• Urgency/Risk: Tasks with tight deadlines or significant risks are prioritized higher to ensure timely completion and minimize potential negative impacts.

• Cost of Delay: This technique helps quantify the negative consequences of delaying a task, and this quantification is used to prioritize tasks.

• Weighted Scoring: Assigning numerical weights to different factors (value, urgency, risk, etc.) can provide a more objective prioritization framework. This method helps when many factors need to be considered.

• MoSCoW Method: Categorizing tasks as Must have, Should have, Could have, and Won’t have, provides a clear prioritization structure. This helps focus on essential tasks first.

The specific method used depends on the project’s context and team preferences, but it’s crucial to maintain transparency and ensure the entire team agrees on the prioritization scheme. Regular backlog refinement meetings are essential for reviewing and adjusting priorities.

I have extensive experience using Jira, Trello, and Azure DevOps. Jira is a powerful, feature-rich tool ideal for managing complex projects and tracking detailed information. Its customization options are vast, allowing for tailoring to specific project needs. However, it can be overwhelming for simpler projects.

Trello’s visual Kanban boards make it excellent for visualizing workflows and tracking progress, especially in smaller teams. Its ease of use and intuitive interface make it a good choice for teams new to Agile or those preferring a simpler approach. However, its features for managing complex projects and reporting are less comprehensive compared to Jira.

Azure DevOps provides a comprehensive suite of tools, including Agile planning, code management, CI/CD, and test management. It integrates seamlessly with other Microsoft services, making it a strong choice for organizations heavily invested in the Microsoft ecosystem. Its richness can also lead to a steeper learning curve.

The choice of tool depends on project complexity, team size, and organizational context. My approach is to select the tool that best fits the project’s specific needs and team’s capabilities.

In Scrum, velocity is a measure of how much work a team can consistently complete within a sprint. It’s typically expressed as story points or hours. Think of it like the team’s ‘pace’ – how much ground they can cover in a given timeframe.

Velocity isn’t a fixed number; it fluctuates depending on various factors, such as team composition, task complexity, and unforeseen issues. It’s crucial to track velocity over several sprints to establish a baseline and to predict future sprint capacity more accurately.

Calculating velocity involves summing the story points (or hours) of the completed items in a sprint. Over time, you can use the average velocity to estimate the amount of work a team can realistically handle in future sprints. This helps in sprint planning and capacity forecasting. However, always remember that velocity is a prediction, not a rigid target; external factors can influence it.

Risk identification and mitigation in Agile projects is an ongoing process, not a one-time event. It’s like navigating a ship – you constantly monitor the horizon for potential hazards and adapt your course accordingly.

• Risk Brainstorming: Regularly conduct risk brainstorming sessions with the team. Encourage open discussion and document all identified risks, no matter how small they may seem.

• Risk Prioritization: Prioritize risks based on their likelihood and potential impact. A risk matrix can be useful for this. High-priority risks need immediate attention.

• Mitigation Strategies: Develop strategies to mitigate each identified risk. These could include contingency planning, assigning additional resources, or adjusting the scope. This is a proactive approach – don’t just hope problems will go away!

• Risk Monitoring: Regularly review and monitor identified risks. Check for new risks and assess whether existing mitigation strategies are still effective. Adjust as needed.

• Risk Log: Maintain a risk log that documents all identified risks, their likelihood, impact, mitigation strategies, and status. This serves as a central repository of information for the team.

For instance, if a critical dependency on a third-party library is identified, the mitigation strategy could involve testing alternative libraries, contacting the library provider, or developing an internal solution as a fallback. Continuous monitoring of the risk’s status ensures the team is prepared to react to any changes.

Agile methodologies, such as Scrum and Kanban, offer numerous benefits, primarily centered around increased flexibility, collaboration, and faster time to market. They enable organizations to respond quickly to changing requirements and deliver value incrementally.

• Faster Time to Market: By delivering working software in short iterations (sprints in Scrum), Agile allows for quicker feedback and faster release cycles. Imagine a software company launching a new feature every two weeks instead of every six months – that’s the power of Agile.
• Improved Quality: Continuous testing and integration throughout the development lifecycle leads to higher quality software. Early and frequent feedback minimizes the risk of major defects later in the process.
• Enhanced Collaboration: Agile emphasizes teamwork and communication. Daily stand-up meetings, sprint reviews, and retrospectives foster a collaborative environment, leading to better problem-solving and a more engaged team.
• Increased Customer Satisfaction: Regular feedback loops allow for continuous adaptation to customer needs. This ensures the final product aligns closely with user expectations, leading to greater satisfaction.
• Reduced Risk: Incremental development and frequent testing minimize the risk of large-scale project failures. If a problem is identified early, it can be addressed quickly and effectively.

For example, a startup developing a mobile app might use Agile to test different features with early adopters, gathering feedback and iterating based on their responses. This iterative process allows them to adjust their product strategy based on real user needs, leading to a more successful product launch.

Implementing Agile methodologies can present several challenges, often stemming from cultural resistance, inadequate training, or a lack of management support. Successfully navigating these challenges requires careful planning and execution.

• Resistance to Change: Switching from traditional waterfall methodologies requires a significant cultural shift. Teams accustomed to rigid processes may resist the flexibility and iterative nature of Agile.
• Lack of Management Support: Agile requires a commitment from leadership to embrace the principles of transparency, collaboration, and empowerment. Without this support, Agile initiatives can struggle to gain traction.
• Inadequate Training: Agile frameworks require specific skills and knowledge. Insufficient training can hinder teams from effectively implementing and utilizing Agile practices.
• Difficulty Estimating and Planning: Agile’s iterative nature can make long-term planning challenging. Accurately estimating the time and resources required for future iterations can be difficult, particularly in the early stages of a project.
• Scope Creep: The flexibility of Agile can lead to scope creep if not managed effectively. Clearly defined acceptance criteria and prioritizing features are crucial to prevent this.

For instance, a large enterprise transitioning to Agile might encounter resistance from project managers used to the control afforded by traditional methodologies. Overcoming this requires providing thorough training, demonstrating the benefits of Agile through pilot projects, and actively addressing concerns from stakeholders.

Adapting Agile practices to different organizational cultures requires a tailored approach that considers existing norms and values. It’s about finding a balance between adhering to Agile principles and respecting the unique characteristics of the organization.

• Gradual Implementation: Start with a pilot project in a receptive team to demonstrate the benefits of Agile before scaling it across the organization. This allows for incremental change and reduces resistance.
• Cultural Sensitivity: Consider the organization’s communication style, decision-making processes, and risk tolerance when choosing Agile frameworks and implementing practices. For example, a highly hierarchical organization might benefit from a modified Scrum approach that incorporates more formal reporting structures.
• Training and Coaching: Provide thorough training on chosen Agile frameworks and techniques to equip team members with the necessary skills. Ongoing coaching and mentoring can support the team throughout the transition.
• Leadership Buy-in: Secure leadership support and commitment. Leaders need to champion Agile principles and demonstrate their commitment to the change.
• Continuous Improvement: Regularly review and adjust Agile practices based on feedback from the team and stakeholders. Agile is not a one-size-fits-all solution, and continuous improvement is crucial for success.

Imagine adapting Agile to a highly collaborative and innovative startup versus a large, established corporation. The startup might easily embrace Scrum’s self-organizing teams, while the corporation might require a more structured approach with clearly defined roles and responsibilities.

In an Agile environment, the Product Owner and Project Manager have distinct, yet complementary roles. While both contribute to the success of the project, their responsibilities and perspectives differ significantly.

• Product Owner: The Product Owner is responsible for defining and prioritizing the product backlog—a prioritized list of features and functionalities. They represent the customer’s voice and ensure the team builds the right product. They are focused on the what – what needs to be built.
• Project Manager: The Project Manager focuses on the how – how the product will be built. They are responsible for removing impediments, managing risks, and ensuring the team has the resources they need to complete the sprint. They often handle administrative tasks, planning, and coordinating resources.

Think of it this way: the Product Owner is the visionary, deciding what features are important and their order of priority. The Project Manager is the facilitator, ensuring the team has the resources and support to deliver those features efficiently.

Addressing a team member consistently missing deadlines requires a systematic approach focused on understanding the root cause and implementing supportive solutions.

1. Open Communication: Initiate a private conversation with the team member to understand the reasons behind the missed deadlines. Are there skill gaps? Are they overwhelmed with workload? Are there external factors affecting their performance?
2. Collaboration and Support: Work collaboratively to identify solutions. This could involve providing additional training, adjusting workload, reassigning tasks, or providing mentoring support.
3. Process Improvement: Evaluate the team’s workflow to identify any bottlenecks or inefficiencies. Are there unnecessary steps? Could task estimations be improved?
4. Clear Expectations and Goals: Ensure that the team member understands the expectations for deadlines and the consequences of consistently missing them. Setting SMART (Specific, Measurable, Achievable, Relevant, Time-bound) goals can help.
5. Performance Management: If the problem persists despite efforts to support the team member, formal performance management steps may be necessary. This may involve documenting performance issues and implementing corrective actions.

The key is to focus on finding a solution that addresses the underlying issue, rather than simply punishing the individual. A supportive approach is more likely to lead to positive change and improved performance.

The Agile Manifesto is a foundational document that outlines the values and principles behind Agile software development. It prioritizes individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

In essence, the Agile Manifesto emphasizes the importance of flexibility, collaboration, and delivering value quickly. It recognizes that while processes and tools are important, they should not overshadow the core values of building working software that meets customer needs. It encourages teams to embrace change and adapt to evolving requirements throughout the development lifecycle.

The four core values are concisely stated as:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These values serve as guiding principles for Agile teams, helping them to prioritize what truly matters in software development – delivering value to the customer.