8.2 Agile, DevSecOps & Operational Change Control

Agile Frameworks, Scrum & DevOps

The landscape of project management in technology has dramatically shifted away from rigid, predictive methodologies toward highly adaptive, iterative approaches. The CompTIA Project+ exam heavily emphasizes understanding these modern delivery models. This section explores the Agile mindset, the highly structured Scrum framework, and the transformative cultural and technical movement known as DevOps, which fundamentally changes how software is built and delivered.

The Agile Mindset and Frameworks

Agile is not a single methodology; it is a mindset guided by the values and principles of the Agile Manifesto. 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 an Agile environment, the scope is expected to evolve. The project team delivers work in small, functional increments, allowing for rapid feedback and course correction.

While Agile provides the philosophy, several specific frameworks put it into practice. Kanban focuses on continuous flow and limiting work in progress. Lean emphasizes eliminating waste. However, for the Project+ exam, Scrum is the most critical framework to master.

Demystifying Scrum

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. It relies on specific roles, events (ceremonies), and artifacts to create a predictable cadence for iterative delivery.

Scrum Roles

The Scrum team is small, cross-functional, and self-managing. There is no "project manager" role in Scrum in the traditional sense; instead, responsibilities are distributed among three specific roles:

1. The Product Owner: This individual represents the voice of the customer and the business. They are accountable for maximizing product value and for effective Product Backlog management. Work may be delegated, but accountability remains with the Product Owner; they order work and communicate the Product Goal.
2. The Scrum Master: This is a servant-leader role. The Scrum Master does not manage the team; they manage the Scrum process. They help everyone understand Scrum, facilitate as needed, and cause impediments that hinder the team's progress to be removed.
3. The Developers (Development Team): The professionals who do the actual work of building the product increment. They are self-managing and decide how to accomplish the work they forecast and select for the Sprint.

Scrum Events (Ceremonies)

Scrum organizes work into fixed-length iterations called Sprints, each lasting one month or less. During a sprint, the team focuses exclusively on a defined set of goals.

1. Sprint Planning: At the start of the sprint, the team collaborates to select items from the Product Backlog that they forecast they can complete during the Sprint. This selection forms the Sprint Backlog.
2. Daily Scrum (Standup): A 15-minute daily meeting where the development team synchronizes activities. The Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog, using whatever structure produces an actionable plan for the next day.
3. Sprint Review: Held at the end of the sprint, the team demonstrates the working product increment to stakeholders to gather feedback and adapt the Product Backlog if necessary.
4. Sprint Retrospective: After the review, the internal team meets to reflect on the sprint process itself. They discuss what went well, what didn't, and identify improvements for the next sprint.

Scrum Artifacts

1. Product Backlog: An ordered, dynamic list of everything that is known to be needed in the product. It is owned by the Product Owner.
2. Sprint Backlog: The subset of Product Backlog items selected for the current sprint, plus a plan for delivering them.
3. Increment: The sum of all completed Product Backlog items at the end of a sprint. It must be in a usable condition and meet the team's Definition of Done.

The DevOps Culture and Practices

Historically, software development (Dev) and IT operations (Ops) operated in silos. Developers focused on building new features rapidly, while Operations focused on maintaining stability and uptime. This often led to conflict, with code that worked in development breaking when deployed to production. DevOps is a cultural and technical movement designed to break down these silos.

DevOps promotes collaboration, communication, and integration between software developers and IT operations professionals. The goal is to shorten the systems development life cycle and provide continuous delivery with high software quality. It achieves this through a cultural shift emphasizing shared responsibility and heavy reliance on automation.

Continuous Integration and Continuous Deployment (CI/CD)

The technical heart of DevOps is the CI/CD pipeline, a series of automated steps that deliver software seamlessly.

• Continuous Integration (CI): Developers frequently merge their code changes into a central repository (like Git). Every merge triggers an automated build and automated testing. This ensures that new code does not break the existing application and allows teams to detect bugs rapidly.
• Continuous Delivery / Continuous Deployment (CD): Following successful CI, the code is prepared for release. In Continuous Delivery, the code is ready to be deployed to production, but a human must click a button to authorize it. In Continuous Deployment, every change that passes all stages of the production pipeline is released to customers automatically, with no human intervention.

Why DevOps Matters for Project Managers

A project manager leading a DevOps-oriented team must adapt their approach. The focus shifts from massive, rigid project plans to facilitating a smooth flow of value. PMs in this environment must understand automation tools, champion cross-functional collaboration, and manage risks associated with rapid, automated deployments. The traditional boundaries of "project phases" blur as development, testing, and deployment become continuous, interconnected activities.

Exam Trap: Remember that the Scrum Master is not the boss of the developers. If an exam question asks who assigns tasks to developers during a sprint, the answer is the developers themselves (self-organization). The Scrum Master facilitates the process.

DevSecOps, SAFe, and XP

DevSecOps makes security a shared, continuous responsibility by adding threat analysis, code and dependency scanning, secrets controls, security tests, and policy checks to delivery rather than waiting for a final review. Scaled Agile Framework (SAFe) coordinates strategy, planning, and delivery across many Agile teams. Extreme Programming (XP) emphasizes rapid feedback and engineering practices such as pair programming, test-first development, refactoring, simple design, and frequent integration.

Operational IT Change Control

Project change control decides whether the project plan or deliverable should change. Operational change control protects live services while an authorized technical change is released.

For infrastructure, perform and document the risk assessment, then schedule an approved downtime or maintenance window, notify customers and support teams, define a tested rollback plan, and run validation checks after implementation. For software, trace the change to defined requirements, assess risk, perform appropriate automated and manual tests, obtain approval, notify affected customers, and release through the controlled path.

Cloud and on-premises changes share these controls but allocate responsibility differently. On premises, the organization controls more of the hardware and window. In cloud services, provider maintenance, service APIs, regions, shared-responsibility boundaries, and managed-service limitations affect timing and rollback.

Separate development and testing from beta or staging and production. Staging should resemble production closely enough for meaningful validation without exposing live data or users unnecessarily. In a tiered architecture, verify each tier and the interfaces between them. A CI/CD pipeline may automate build, test, approval evidence, and deployment, but automation does not remove authorization, customer notification, monitoring, or rollback requirements.

A complete change closes only after validation confirms the intended result, monitoring finds no unacceptable effect, the implementation record is updated, and affected stakeholders receive the deployment outcome.