Class Notes - The Agile Practice of Continuously Identifying Problems, Impediments, and Risks

Dr. Darnell’s Class Notes

Amberton University

MGT6525 Agile Value Delivery

Summer (2023). Week 7:

Competency: The Agile practice of continuous identification of problems, impediments, and risks.

Introduction

The Agile practice of continuously identifying problems, impediments, and risks is a cornerstone of its iterative, responsive nature. This approach enables teams to pivot quickly, improve constantly, and ensure that projects do not derail.

Since its conception, agile project management and its affiliated practices have transformed the landscape of software development and other fields. The Agile Manifesto, formulated in 2001, emphasizes values like individuals and interactions, customer collaboration, and the ability to respond to change (Beck et al., 2001). An essential aspect of implementing this approach is continuously identifying problems, impediments, and risks. This practice is integral to Agile's iterative, adaptive nature, supporting its responsiveness to change and fostering an environment of ongoing improvement.

In traditional project management, problems and risks are typically identified and addressed during particular stages, often leading to the issues becoming substantial before they are dealt with. Agile practices, in contrast, allow for the ongoing detection and resolution of such issues, enabling teams to pivot quickly and mitigate the risk of project derailment. This continual improvement involves daily standup meetings, retrospectives, explicit risk management, visual management, and continuous integration.

While not all frameworks explicitly mention "continuous identification of problems, impediments, and risks,” the concept is implicit in Agile's nature and is present in various ways in different practices:

• Daily Scrum (Scrum): In this daily meeting, team members report what they did the previous day, what they plan to do today, and any obstacles or impediments that could block their work. This allows the team to identify and address problems and risks constantly.
• Retrospectives (Scrum, Extreme Programming, and others): At the end of each sprint or iteration, the team holds a retrospective to reflect on what went well and what didn't. They then make plans to improve their processes for the next iteration. This regular reflection helps the team continuously identify and address problems.
• Risk Management (Crystal, Scrum): Many Agile frameworks advocate for regular risk assessment and management. Crystal, for instance, includes a "risk list" as one of its key artifacts. In Scrum, the Product Owner is typically responsible for identifying and managing external risks, while the Scrum Master helps the team deal with internal risks and impediments.
• Visual Management (Kanban): Kanban teams use visual boards to manage their work, making it easy to see bottlenecks, blocked tasks, and other issues as soon as they arise.
• Inspect and Adapt (Scrum): This is a fundamental principle in Scrum, where the team and stakeholders regularly inspect the product being developed and how well the team is working, intending to identify potential issues and make improvements.
• Continuous Integration (Extreme Programming): By integrating and testing code several times daily, teams can identify and fix problems as soon as they occur rather than letting them build up into more significant issues.
• DevOps Practices: While not an Agile methodology per se, Devops shares the Agile principles of iterative development and quick feedback cycles, and it plays a critical role in the continuous identification and resolution of problems, impediments, and risks.

Remember, the ultimate goal of Agile is to deliver working software quickly and respond to changes efficiently. The continuous identification and resolution of problems, impediments, and risks is crucial to achieving this goal.

Further Elaboration

The following explores the Agile practices noted above, which contribute to an effective system of identifying and addressing problems, impediments, and risks. We'll discuss how these practices foster transparency, encourage problem-solving, and help create self-organizing teams that adapt to change and consistently deliver value to the customer.

Daily Scrum / Standup /Team Sync

In Scrum, a popular Agile framework, Daily Scrum meetings are essential to the process. The Daily Scrum, also known as the daily stand-up or team sync, is a 15-minute event for the Developers of the Scrum Team. It's designed to be held at the same location and time daily to reduce scheduling complexity (Schwaber & Sutherland, 2020).

According to the Scrum Guide, during the meeting, the Developers plan work for the next 24 hours. This optimizes team collaboration and efficiency and helps meet the Sprint Goal. The Developers can select whatever structure and techniques they want for the Daily Scrum as long as it focuses on progress toward the Sprint Goal (Schwaber & Sutherland, 2020).

While it's common for the Developers to discuss what work was done yesterday, what work will be done today, and what obstacles impede progress, this format is not mandated in the 2020 Scrum Guide. The objective is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a key inspect and adapt event crucial to promoting transparency and quick problem-solving. It allows the Developers to inspect their work, synchronize their activities, and create a plan for the next 24 hours, addressing any issues hindering their progress.

The Scrum Master, while not a mandatory participant, can attend this meeting and ensures that the Developers are conducting the Daily Scrum but does not interfere with their ownership of the event. They can also help by facilitating the meeting if requested or needed and ensuring that it remains within its time box and focuses on the appropriate topics.

Through this practice, the Scrum framework promotes a culture of collaboration, accountability, and continuous planning to increase the likelihood of achieving the Sprint Goal.

Retrospectives (Scrum, Extreme Programming, and others):

At the end of each sprint or iteration, the team holds a retrospective to reflect on what went well and what didn't. They then make plans to improve their processes for the next iteration. This regular reflection helps the team continuously identify and address problems.

In many Agile methodologies, such as Scrum and Extreme Programming (XP), retrospectives are an essential practice. The Scrum Master or team coach typically facilitates them, but everyone from the team is encouraged to participate openly and honestly (Schwaber & Sutherland, 2020).

Retrospectives serve as a dedicated time for teams to reflect on their work with the objective of continuous improvement. These meetings involve reflecting on what went well and what could be improved and then developing action plans to improve the next iteration (Derby & Larsen, 2006).

The purpose of retrospectives includes:

• Reflecting on the Past: Teams analyze the recently completed Sprint or iteration, discussing successes, challenges, learned lessons, and areas for improvement.
• Identifying Risks and Issues: Retrospectives allow teams to identify any risks, impediments, or bottlenecks that affect their progress. This could include technical challenges, team dynamics, process inefficiencies, or external influences.
• Creating an Improvement Plan: After identifying successes and areas for improvement, teams collaborate to form a plan addressing the issues and enhancing their processes for the upcoming Sprint. These plans are actionable, specific, and often assigned to team members to take responsibility.
• Fostering Team Collaboration and Trust: Retrospectives are a team activity fostering open communication, collaboration, and mutual trust. When done well, they help create a safe space where everyone feels comfortable sharing their thoughts and ideas, leading to a more cohesive and effective team.

Teams often use structured formats to conduct effective retrospectives that encourage complete and constructive feedback. Typical stages of a retrospective include setting the stage, gathering data, generating insights, deciding what to do, and closing the retrospective.

Agile teams foster a culture of transparency, inspection, and adaptation through this practice, allowing them to identify and address problems, risks, and inefficiencies continuously.

By providing a dedicated space and time for reflection and discussion, retrospectives create a mechanism for continuous problems, impediments, and risk identification. This aligns with the Agile principle: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" (Beck et al., 2001), helping teams improve their processes, stay adaptable, and manage potential risks effectively.

However, retrospectives do more than identify problems, impediments, and risks; they also foster problem-solving and continuous improvement. Once the issues are identified, teams collaboratively decide on actions to address them in the upcoming sprint. By assigning ownership and tracking these actions, teams ensure that they actively work towards mitigating identified problems and risks, thereby enhancing their effectiveness and agility over time.

Agile Risk Management

Risk management in Agile methodologies is an ongoing process that involves identifying, categorizing, prioritizing, and mitigating potential project threats. By continuously managing risk, Agile teams can proactively address issues that could negatively impact the project's progress or success.

Different Agile frameworks handle risk management in varying ways. For example, Crystal, a family of Agile methodologies developed by Alistair Cockburn, incorporates a "risk list" as a key artifact. The risk list is a living document that records identified risks, their severity, and mitigation strategies. It serves as a visual and accessible reminder for the team to continually consider and address project risks throughout each iteration (Cockburn, 2004).

In Scrum, one of the most popular Agile frameworks, risk management tasks are divided among different roles. The Product Owner is primarily responsible for managing external risks. These could include changes in market demands, customer needs, company strategy, or technology that could impact the product. The Product Owner needs to communicate these risks to the team and stakeholders and adjust the product backlog accordingly to mitigate potential impacts.

On the other hand, the Scrum Master helps the team deal with internal risks and impediments. These could be team-related issues like conflicts, skill gaps, productivity blocks, or project-related like technical debt, architecture problems, or tooling issues. The Scrum Master's role is to facilitate the removal of these obstacles, keeping the team's progress toward the Sprint Goal as smooth as possible (Schwaber & Sutherland, 2020).

In the Scaled Agile Framework (SAFe), risk management is explicitly addressed through the use of a Risk Management Cycle and Risk Backlog. During Program Increment (PI) planning sessions, teams identify risks and create a management plan. These risks are then documented and managed via the Risk Backlog (Scaled Agile, Inc., 2021). Additionally, a structured risk management cycle is part of each PI. This involves:

1. Identifying Risks: Teams actively search for potential risks throughout the PI.
2. Analyzing Risks: Teams assess identified risks' potential impact and likelihood.
3. Synthesizing and Prioritizing Risks: Risks are then categorized and prioritized.
4. Implementing Risk Responses: Based on prioritization, teams implement suitable risk mitigation strategies.
5. Evaluating Risk Response: The effectiveness of the risk responses is evaluated.

Risks are categorized as one of three types in SAFe: business, technical, or compliance. This helps teams design an appropriate mitigation strategy (Scaled Agile, Inc., 2021).

Large Scale Scrum (LeSS): does not have specific guidelines for risk management; however, it adopts and scales essential Scrum elements and practices that inherently address risks.

In LeSS, managing risks involves maximizing transparency, improving product definition, reducing cycle time, and focusing on customer value. By having cross-functional teams and promoting continuous integration and delivery, many risks related to dependencies, integration, and delivery delays are naturally mitigated (Larman & Vodde, 2016).

By following Scrum's empirical process control theory (transparency, inspection, adaptation), LeSS encourages teams to continuously identify, inspect, and adapt to risks throughout the product development process.

Disciplined Agile Delivery (DAD) is a hybrid Agile approach to enterprise IT solution delivery. It has all the elements of Scrum, Agile Modeling, Lean software development, and Extreme programming. DAD is a part of the Disciplined Agile (DA) toolkit, which provides a more flexible approach to the workflow and extends its Agile and Lean strategies to provide a robust, end-to-end streamlined delivery process.

In terms of risk management, DAD provides explicit and robust guidance. Like other Agile methodologies, risk management is ongoing throughout the project's lifecycle. The DAD framework encourages proactive risk mitigation through active stakeholder participation, early and frequent feedback, prioritized requirements, and iterative development (Ambler & Lines, 2012).

In DAD, risk management is made explicit through various practices such as:

• Lookahead Modeling and Planning: This practice involves looking ahead to upcoming work to foresee and mitigate risks early.
• Proactive Experimentation: Teams are encouraged to experiment early with new technologies, techniques, and strategies, thus mitigating the risk associated with them.
• Regular Coordination Meetings: Regular coordination meetings help identify and address risks related to dependencies and integration between different teams.
• Regular Reflection and Improvement: Teams are encouraged to regularly reflect on their performance and make necessary improvements to mitigate identified risks.
• Risk Value Lifecycle: This lifecycle involves identifying, estimating, exploring, and managing risks throughout the project’s lifecycle.

This systematic approach to risk management in DAD allows teams to identify potential issues early, react efficiently, and minimize the overall impact of the risks on the project outcome.

It's important to note that Agile risk management is an ongoing process, not a one-time event. Risks are continuously identified, assessed, and prioritized throughout the project lifecycle. Then, proactive steps are taken to mitigate the most significant risks. This constant loop of identifying and addressing risks aligns with the Agile core principle of embracing change and maintaining flexibility.

Continuous Risk Management in Agile

Agile methodologies, at their core, are centered around adaptability and continuous improvement. Risk management in Agile reflects these principles, positioning itself as an ongoing process rather than a one-off activity. The dimensions of continuous risk management are listed below:

• Continuous Identification: Agile teams actively look for risks in every iteration or Sprint. This identification is not confined to the beginning of the project but occurs continuously throughout the lifecycle. As the team members work on their tasks, they stay alert to any factors threatening the project's timeline, quality, budget, or objectives. Regular events like daily stand-ups, Sprint planning, and retrospectives are key moments for this activity.
• Continuous Assessment: Once risks are identified, they must be assessed for their potential impact and probability. This is not a static evaluation—risks might evolve, and new information might change the initial assessment. Therefore, similar to identification, assessment is also a continuous activity in Agile risk management. Tools like risk matrices or risk burndown charts can be used to visualize and track this information.
• Continuous Prioritization: Risks are prioritized based on their potential impact and likelihood after assessment. This helps the team focus their efforts on what is most significant. However, as the project evolves, so does the risk landscape. A low-priority risk in one Sprint might become more critical in the next. Therefore, Agile teams regularly revisit their risk priorities and adjust their focus as necessary.
• Continuous Mitigation: Once the most significant risks are identified and prioritized, Agile teams take proactive steps to mitigate them. This could involve preventative actions to lower the likelihood of the risk, contingent actions to reduce the impact if the risk does occur, or even acceptance if the risk is small enough. The critical aspect is that these strategies are implemented immediately and reviewed regularly.

By adhering to this ongoing process of identifying, assessing, prioritizing, and mitigating risks, Agile teams can avoid potential problems, handle them before they become critical, and remain flexible in the face of change. This iterative approach aligns perfectly with Agile's flexibility, adaptability, and continuous improvement principles, fostering a proactive and responsive project environment.

Visual Management in Kanban

Visual management is a critical component of the Kanban methodology, originating from the Japanese Toyota Production System. Kanban is focused on creating visual workflows that allow teams to manage their work more efficiently. This is typically done through a Kanban board, a visual tool that depicts work at various stages of the process (Anderson, 2010).

The Kanban board is divided into different columns, each representing a different stage in the workflow. Each task or work item is represented as a card that moves from one column to the next as it progresses through the stages. This makes the workflow transparent and gives everyone a clear and real-time overview of the status of the work.

In the context of continuous identification of problems, impediments, and risks, Kanban offers several benefits:

• Spotting Bottlenecks: A visual workflow lets teams immediately see where work is piling up, indicating a bottleneck. These bottlenecks might slow down the entire process; identifying them early allows teams to address the root cause and improve the flow.
• Identifying Blocked Tasks: Impeded or blocked tasks are often visually differentiated (for example, using colors or tags). This makes it easy to identify issues that are preventing tasks from moving forward, allowing the team to resolve these issues promptly.
• Managing Work in Progress (WIP): Kanban teams use WIP limits to control the amount of work at any stage at one time. If a column exceeds its WIP limit, it's a signal that a problem might need addressing before new work can enter that stage.
• Flow Efficiency: By visualizing the work process, teams can track how long tasks stay in each column (cycle time) and identify any delays or inefficiencies in the process.
• Promoting Collaborative Problem-Solving: A shared, visual representation of work promotes a collaborative approach to problem-solving. When issues are identified, the team can collectively decide how to resolve them.

In essence, the Kanban board is a powerful tool for visual management, providing immediate insight into the status and health of the workflow. It aids in the continuous identification and resolution of problems, impediments, and risks, fostering a culture of transparency, communication, and continuous improvement.

Inspect and Adapt:

Inspect and Adapt is where the team and stakeholders regularly inspect the product being developed and how well the team is working, intending to identify potential issues and make improvements.

Inspect and Adapt is a core principle in Agile frameworks such as Scrum and the Scaled Agile Framework (SAFe). It encapsulates the idea that teams should regularly evaluate their product and processes and make necessary adjustments to optimize quality and productivity. This iterative approach allows teams to respond to change effectively and continuously improve over time (Schwaber & Sutherland, 2020; Scaled Agile, Inc., 2021). The dimensions of an Inspect and Adapt philosophy are described below:

• Product Inspection: In the context of product development, "inspect and adapt" involves regular reviews of the product or deliverables. In Scrum, for instance, the Sprint Review meeting allows the Scrum Team and stakeholders to inspect the product development increment during the Sprint. They evaluate its alignment with customer needs and expectations, verify that it meets the “Done” definition, and gather feedback for future enhancements. This ongoing inspection helps detect any quality issues, deviations from requirements, or misalignments with stakeholder expectations.
• Process Inspection: Inspect and Adapt also applies to the team’s work. The Agile methodology encourages teams to regularly review their performance, collaboration, and processes, identifying inefficiencies or issues. In Scrum, this happens during the Sprint Retrospective, where the team reflects on the past Sprint, discussing what went well and what could be improved. They then agree on a set of actions to improve their working methods in the next Sprint.
• Adaptation: The adaptation phase follows inspection. It involves making necessary adjustments based on the insights gathered during the inspection. This could include changes to the product backlog based on stakeholder feedback, development process modifications, or team dynamics alterations. By continually adapting, Agile teams stay flexible and responsive, ensuring that their product and processes evolve in alignment with changing conditions and insights.
• Continuous Improvement: Inspect and Adapt underpins the concept of Kaizen, or continuous improvement, in Agile methodologies. By regularly inspecting and adapting their product and processes, teams foster a culture of continual learning and improvement. They become better equipped to handle uncertainties, adapt to changes, and enhance their performance over time.

The Continuous Loop of Inspection and Adaptation in Agile Methodologies

The "Inspect and Adapt" principle in Agile methodologies forms a continuous feedback loop that enables teams to maintain high product quality, efficiency, and responsiveness to change. This principle is deeply ingrained in Agile practices such as Scrum and the Scaled Agile Framework (SAFe), reinforcing Agile development's iterative and incremental nature (Schwaber & Sutherland, 2020; Scaled Agile, Inc., 2021).

Regular and frequent inspection provides visibility into the product's development status and the team's working methods. This transparency allows for the early identification of problems, bottlenecks, or risks and opportunities for improvement. Product inspection ensures that the output aligns with customer requirements and expectations. It also quickly uncovers any deviations or quality issues, allowing for timely corrective actions.

Meanwhile, process inspection evaluates the effectiveness and efficiency of the team's practices and interactions. By reflecting on their work, the team can identify strengths to leverage and weaknesses to address. They can spot friction, redundancy, or miscommunication and figure out how to enhance their working methods.

Adaptation is the responsive action taken after inspection. It involves adjusting the course based on the insights gained from the inspection. For the product, this might mean refining features, reprioritizing the backlog, or making design changes to better meet customer needs. For the team, adaptation could involve revising workflows, improving communication channels, or adopting new tools or techniques to increase productivity and collaboration.

This continuous loop of inspection and adaptation ensures that Agile teams remain nimble and effective. They can adapt their product and processes according to evolving customer needs, business contexts, or technological advancements while also fostering a culture of continuous learning and improvement.

The "Inspect and Adapt" principle embodies the Agile commitment to delivering value and embracing change. By integrating this principle into their routines, Agile teams ensure they're always moving towards optimal performance and product excellence. The Inspect and Adapt principle promotes transparency, adaptation, and continuous improvement in Agile teams, fostering an open learning environment, flexible to changes, and focused on delivering high-quality products that meet customer needs.

Continuous Integration (Extreme Programming): By integrating and testing code several times a day, teams can identify and fix problems as soon as they occur rather than letting them build up into more significant issues.

Continuous Integration (CI) is a software development practice that originated from Extreme Programming (XP), though it is now widely adopted across various Agile methodologies. It involves integrating work frequently, usually multiple times daily, to detect and resolve integration issues as early as possible (Beck, 2000; Fowler, 2006).

Here's how continuous integration aids in the continuous identification of problems, impediments, and risks:

• Early Detection of Integration Issues: In traditional development models, integration was often performed at the end of the development cycle. This led to the infamous 'integration hell' where numerous conflicting changes had to be reconciled simultaneously. With CI, since code is integrated frequently, conflicts between different parts of the codebase are detected and addressed immediately, preventing them from escalating into more complex problems.
• Prompt Bug Fixing: In CI, every integration is verified by an automated build and test process. This ensures that bugs and other quality issues are identified quickly. When a defect is found, it's typically easier to fix because developers can still remember what they were working on and thinking about when they wrote the buggy code.
• Reducing Risk: CI reduces the risk of late-stage integration problems and ensures that the software is always in a releasable state. This promotes transparency and predictability, which are critical for managing stakeholder expectations.
• Enhancing Code Quality: The practice of CI encourages developers to write modular, less complex code, which is easier to integrate and test. This results in higher overall code quality and less technical debt.
• Facilitating Collaboration: CI fosters a culture of shared responsibility for the codebase. It promotes close collaboration among developers, testers, and operations, breaking down silos and encouraging shared ownership of code quality and stability.

Continuous Integration, therefore, plays a significant role in Agile practices, particularly in the continuous identification and resolution of software development problems. By integrating and testing frequently, Agile teams can maintain a high-quality, reliable codebase and effectively manage risks associated with integration.

DevOps and Continuous Problem Identification

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) with the goal of shortening the system development lifecycle and providing continuous delivery with high software quality. DevOps can be seen as an extension of Agile methodologies that focuses on the end-to-end software delivery pipeline.

In the context of continuous problem identification, DevOps introduces several practices and principles:

• Continuous Integration and Continuous Delivery (CI/CD): Building on the practice of Continuous Integration, DevOps extends this to Continuous Delivery, ensuring that the software can be reliably released at any time. This involves automating the building, testing, and deployment processes to accelerate release cycles, reduce manual errors, and enable fast feedback on potential problems.
• Infrastructure as Code (IaC): DevOps teams treat infrastructure setup and management as a codebase that is versioned and reviewed like application code. This enables consistency, repeatability, and the ability to roll back changes, thereby reducing risks associated with manual configuration or inconsistency across environments.
• Monitoring and Logging: DevOps emphasizes real-time monitoring of application performance and user behavior and detailed logging of system events. This enables teams to quickly identify and troubleshoot issues, reducing downtime and improving user experience.
• Post-Mortems and Blameless Culture: When incidents occur, DevOps teams conduct post-mortem analyses to identify the root cause and learn from the failure. The culture encourages learning from mistakes rather than blaming individuals, fostering an environment where problems are openly discussed and addressed.
• Security Integration (DevSecOps): In practice, sometimes called DevSecOps, security practices are integrated into the DevOps process. Security checks and controls are automated and incorporated into the pipeline, helping to identify and mitigate security risks early and throughout the lifecycle.

By integrating these practices, DevOps enables continuous identification and resolution of problems, enhancing software quality, reliability, and security. It promotes a culture of collaboration, learning, and continuous improvement that aligns well with the Agile principles.

Summary

We've explored the Agile practice of continuous identification of problems, impediments, and risks. This is central to Agile methodologies as it supports adaptability, flexibility, and continuous improvement principles.

Several Agile practices facilitate continuous problem identification:

Daily Scrum: Daily standup meetings allow team members to share their progress and discuss any issues or impediments, promoting transparency and immediate problem-solving.

Retrospectives: Agile teams hold retrospectives at the end of each sprint or iteration to reflect on their performance and identify areas for improvement. This helps them continuously address issues and refine their working processes.

Agile Risk Management: Risk management in Agile methodologies is an ongoing process that involves identifying, categorizing, prioritizing, and mitigating potential project threats. Continuous Risk Management in Agile: Agile teams can proactively address issues that could negatively impact the project's progress or success by continuously managing risk.

Visual Management (Kanban): Kanban teams use visual boards to manage their work. This visualization aids in quickly spotting bottlenecks, blocked tasks, and other problems.

Inspect and Adapt: Core to Scrum and SAFe, this principle involves the regular examination of the product and the team's performance to identify potential issues, followed by changes to improve. This embodies the continuous improvement philosophy of Agile.

Continuous Integration (Extreme Programming): By integrating and testing code several times daily, teams can promptly detect and fix problems, preventing them from becoming more significant issues.

DevOps and Continuous Problem Identification: DevOps can be seen as an extension of Agile methodologies that focuses on the end-to-end software delivery pipeline. DevOps enables continuous identification and resolution of problems, enhancing software quality, reliability, and security.

Agile frameworks like Crystal maintain a "risk list," while Scrum assigns the task of managing risks to the Product Owner and Scrum Master. The DAD and SAFe methodologies scale Agile principles for larger teams and projects, offering advanced risk management practices.

We also touched on DevOps, a set of practices that bridge software development and IT operations for continuously delivering high-quality software. DevOps integrates continuous integration and delivery, infrastructure as code, real-time monitoring, blameless post-mortems, and integrated security practices to identify and mitigate issues continuously.

The Agile practice of continuously identifying problems, impediments, and risks is pivotal in maintaining high product quality, promoting a culture of learning and improvement, and ensuring responsiveness to change.

References

Ambler, S., & Lines, M. (2012). Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise. IBM Press.

Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley.

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., ... & Kern, J. (2001). Manifesto for Agile Software Development. Agile Alliance.

Cockburn, A. (2004). Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley.

Derby, E., & Larsen, D. (2006). Agile retrospectives: making good teams great. Pragmatic Bookshelf.

Fowler, M. (2006). Continuous Integration. MartinFowler.com. Retrieved from https://martinfowler.com/articles/continuousIntegration.html

Kim, G., Debois, P., Willis, J., & Humble, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution.

Puppet Labs. (2015). 2015 State of DevOps Report. Puppet Labs. Retrieved from https://puppet.com/resources/white-paper/2015-state-of-devops-report

Scaled Agile, Inc. (2021). SAFe 5.0 Reference Guide: Scaled Agile Framework for Lean Enterprises. Scaled Agile, Inc.

Schwaber, K., & Sutherland, J. (2017). The Scrum Guide. Scrum Guides.

Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum Guides.