Agile Values, Principles and Frameworks

Introduction and Context

Agile is an approach to developing and delivering products in conditions of uncertainty. It emerged partly as a response to sequential development models in which requirements were defined extensively at the beginning, implementation occurred later, and customer feedback arrived near the end. Such models can be appropriate when requirements are stable and change is expensive or dangerous, but they are less effective when customer needs, technology, regulation or market conditions change rapidly.

Agile does not mean working without planning, documentation or management. It means planning and governing work in ways that enable frequent learning, rapid feedback and adaptation. In DevOps, Agile practices provide much of the delivery discipline that connects customer outcomes, software development, testing, operations and continuous improvement.

This chapter explains the Agile Manifesto, its supporting principles and the relationship between values, principles, practices and frameworks. It then compares Scrum, Kanban and Extreme Programming (XP), with attention to roles, events, artifacts, flow, work-in-progress limits and framework selection.

Learning Objectives

By the end of this chapter, a learner should be able to:

• explain the four values and twelve principles of the Agile Manifesto;
• distinguish values, principles, practices and frameworks;
• describe Scrum roles, events and artifacts;
• explain Kanban flow, visualization and work-in-progress limits;
• describe the principal technical practices of Extreme Programming;
• compare Scrum, Kanban and XP in terms of structure, flow and applicability;
• select an appropriate approach for a practical organizational situation; and
• identify common Agile failure modes and appropriate improvements.

1. The Agile Manifesto

In 2001, a group of software practitioners published the Manifesto for Agile Software Development. The Manifesto contains four value statements and twelve principles. It is not a method, certification scheme or prescriptive project plan. It is a compact statement of priorities for developing software under conditions of uncertainty.

1.1 The four values

The Manifesto states that practitioners value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

The phrase “over” does not mean that the item on the right has no value. Processes, tools, documentation, contracts and plans remain important. The intended meaning is that, when a genuine conflict exists, the item on the left should generally receive greater emphasis.

#### Individuals and interactions

Software is created by people who must understand one another, make decisions and resolve ambiguity. A technically sophisticated tool cannot compensate for poor communication or unclear ownership. Agile teams therefore prefer direct collaboration, shared understanding and rapid clarification.

This value does not reject tools. Source-control systems, issue trackers, automated pipelines and collaboration platforms can improve transparency and reliability. The principle is that tools should support human collaboration rather than replace it.

#### Working software

A running, tested increment provides stronger evidence of progress than a collection of plans or partially completed documents. Working software enables customers and users to provide feedback based on something concrete. Documentation remains necessary for support, compliance, architecture and knowledge transfer, but it should be proportionate and useful.

#### Customer collaboration

Customers are not merely recipients who approve a finished product. They contribute domain knowledge, clarify priorities and evaluate increments. Collaboration reduces the risk that a team efficiently builds the wrong solution. Contracts and formal requirements may still be essential, particularly in regulated or outsourced environments, but they should not prevent sensible learning and clarification.

#### Responding to change

Change may result from new customer knowledge, defects, technical discoveries, security threats, legislation or competitive pressure. Agile teams expect some change and organize work so that adaptation is affordable. This does not mean accepting every request immediately; it means making decisions using current evidence rather than treating an outdated plan as more important than reality.

2. The Twelve Agile Principles

The twelve principles provide practical interpretation of the four values:

1. Satisfy customers through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development, when change improves value.
3. Deliver working software frequently, from every few weeks to every few months, preferably more frequently.
4. Business stakeholders and developers should work together regularly throughout the project.
5. Build projects around motivated individuals, provide support and trust them to do the work.
6. The most effective way to communicate within a development team is face-to-face conversation, although modern distributed teams may use rich synchronous and asynchronous collaboration tools.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development, allowing sponsors, developers and users to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective and adjusts its behavior accordingly.

These principles are related. Frequent delivery without technical quality creates fragile software. Self-organization without a clear product goal can create local optimization. Responsiveness without prioritization can produce chaotic scope expansion. Agile is therefore a system of mutually reinforcing practices, not a license to remove discipline.

3. Values, Principles, Practices and Frameworks

A useful distinction is:

• Values express what an organization considers important.
• Principles describe general ways of applying those values.
• Practices are observable techniques, such as a daily coordination meeting, automated testing or visualizing work on a board.
• Frameworks provide a structured set of roles, events, rules and artifacts for organizing practices.

Scrum, Kanban and XP are not interchangeable labels. Scrum is a lightweight management and product-development framework. Kanban is a method for improving flow through visualization, explicit policies and limits on work in progress. XP is an Agile software-development approach with strong engineering practices. Organizations often combine them, but combinations should be deliberate rather than a collection of fashionable terms.

4. Scrum

Scrum is designed for complex product development in which a team needs a regular inspection-and-adaptation cycle. Work is organized into timeboxed iterations called Sprints, normally one month or less. The current Scrum Guide describes Scrum as a framework within which people can address complex adaptive problems while delivering products of the highest possible value.

4.1 Scrum accountabilities

Scrum uses three accountabilities:

• Product Owner: maximizes product value and is accountable for effective Product Backlog management. This includes communicating the Product Goal, creating and ordering backlog items, and ensuring that the backlog is transparent and understood.
• Scrum Master: establishes Scrum, helps the team understand its theory and practice, coaches self-management, removes impediments where appropriate and supports effective Scrum events.
• Developers: create the usable Increment each Sprint. Developers plan the work, uphold the Definition of Done, adapt their plan daily and hold one another accountable as professionals.

The three accountabilities form one Scrum Team. The team is intended to be cross-functional and self-managing. The Scrum Master is not simply a meeting administrator, and the Product Owner is not a traditional project manager who assigns every task.

4.2 Scrum events

Scrum includes a Sprint and four formal events within it:

• Sprint: a fixed-length period during which a usable Increment is created. The team establishes a Sprint Goal and plans work for the Sprint.
• Sprint Planning: the team discusses why the Sprint is valuable, what can be delivered and how the selected work will be accomplished.
• Daily Scrum: a short event for Developers to inspect progress toward the Sprint Goal and adapt their plan. It is not necessarily a status report to management.
• Sprint Review: stakeholders and the Scrum Team inspect the outcome and discuss future adaptations to the Product Backlog.
• Sprint Retrospective: the team examines people, interactions, process and tools, then identifies useful improvements.

The events create a cadence for transparency, inspection and adaptation. They do not guarantee agility if participants merely attend meetings without using evidence to make decisions.

4.3 Scrum artifacts and commitments

Scrum has three artifacts:

The Definition of Done is a shared quality standard. An item that does not meet it is not part of the Increment, even if coding appears complete. The Definition of Done may include code review, automated tests, security checks, documentation, deployment readiness and operational monitoring.

Scrum does not prescribe a particular estimation technique, project chart or ticketing tool. Story points, task boards and burndown charts may be used, but they are optional practices rather than the essence of Scrum.

5. Kanban

Kanban is a method for managing and improving the flow of knowledge work. Its central idea is to make work visible, establish explicit policies, limit work in progress (WIP), manage flow and improve continuously. Kanban can be introduced into an existing process without requiring fixed iterations or a new set of formal roles.

5.1 Visualizing work

A Kanban board represents the workflow. A simple software board might contain columns such as:

Ready → Development → Code Review → Testing → Ready for Deployment → Done

Each card represents a work item. The board should reflect the actual workflow, not an idealized process. Policies should explain, for example, what “Ready for Development” means, who may move a card and what quality conditions apply before an item enters “Done.”

5.2 Work-in-progress limits

A WIP limit restricts the number of items allowed in a workflow state or group of states. If the Testing column has a limit of three and already contains three items, developers should normally help testing, resolve defects or improve the process rather than start a fourth feature.

WIP limits reduce multitasking and expose bottlenecks. They do not mean that people must remain idle; they encourage the team to finish existing work and restore flow. A limit should be treated as a policy to inspect and improve, not as an arbitrary performance target.

A common flow relationship is known as Little’s Law:

Here, L is average WIP, λ is average throughput, and W is average cycle time. The relationship assumes a stable system over the period considered, with consistent definitions of the system boundary and completed work. Units must be consistent: if throughput is items per day and cycle time is days, average WIP is items. For example, if a team completes an average of 8 items per week and average cycle time is 1.5 weeks, average WIP is:

The equation describes an observed relationship; it does not by itself prove that increasing WIP will increase throughput. In a congested system, increasing WIP commonly increases waiting and cycle time instead.

5.3 Flow measures

Useful Kanban measures include:

• Lead time: elapsed time from a customer request or commitment point to delivery.
• Cycle time: elapsed time from the start of active work to completion.
• Throughput: number of work items completed in a specified period.
• WIP: work started but not yet completed.
• Flow efficiency: a local measure comparing active processing time with total elapsed time. It must be defined carefully because waiting and processing categories vary between organizations.

Measures should support learning, not individual punishment. Using throughput to rank people encourages gaming, splitting work into artificially small items and avoidance of difficult work.

5.4 Kanban roles and cadence

Kanban does not require a universal set of roles equivalent to Product Owner or Scrum Master. Existing responsibilities may be retained, and organizations can define service-delivery roles suited to their context. Replenishment meetings select work for entry; delivery reviews inspect outcomes; operations reviews examine system-level performance; and improvement meetings identify experiments. The exact cadence may be adapted to demand and risk.

6. Extreme Programming

Extreme Programming, or XP, is an Agile approach especially concerned with software quality, rapid feedback and close customer involvement. It “turns up” effective engineering and collaboration practices to reduce technical risk.

Important XP practices include:

• Small releases: deliver valuable functionality frequently.
• The planning game: customers and developers collaborate to select and estimate work.
• Test-driven development (TDD): write an automated test for a small behavior, implement enough code to pass it, then refactor.
• Continuous integration: integrate and test changes frequently.
• Pair programming: two developers work together at one workstation or through an equivalent collaborative arrangement.
• Collective code ownership: the whole team is responsible for the codebase.
• Refactoring: improve internal structure without changing externally observable behavior.
• Simple design: implement the simplest design that satisfies current, understood requirements.
• Sustainable pace: avoid a process that depends on chronic overtime.
• On-site or readily available customer collaboration: obtain rapid clarification and feedback.

XP is not merely “writing tests.” Its practices reinforce one another. TDD is more effective when code is designed for testability; continuous integration is more useful when builds and tests are automated; collective ownership requires coding standards and communication.

XP may be used with Scrum or Kanban. For example, a team may use Scrum for product planning and Sprint events, Kanban for managing the development workflow, and XP practices for engineering quality. Such a combination should preserve clear policies and avoid confusing different purposes.

7. Comparative Analysis

The approaches differ in emphasis rather than forming mutually exclusive categories. Scrum answers, “How can a product team organize empirical work around a regular cadence?” Kanban answers, “How can work flow more predictably through a system?” XP answers, “How can software be built with rapid feedback and technical excellence?”

8. Selecting an Appropriate Framework

Selection should begin with the problem rather than the brand name of a framework. Consider the following questions:

1. Is work arriving unpredictably, or can it be grouped into meaningful product increments?
2. Does the team need a fixed inspection cadence for stakeholders?
3. Is the principal difficulty prioritization, workflow congestion, technical quality or all three?
4. Can the team release frequently and obtain customer feedback?
5. Are regulatory, safety or contractual obligations likely to require additional documentation and approvals?
6. Does the organization have the authority and capability to change its workflow?
7. Are the product goal, ownership and decision rights clear?

Typical selection patterns

Scrum may be appropriate when a stable, cross-functional product team works on a product with a changing backlog and benefits from regular reviews and retrospectives. It is often suitable for a new product where stakeholder feedback must be deliberately scheduled.

Kanban may be appropriate for support, maintenance, operations, infrastructure or service teams handling variable demand and urgent work. It is also useful when an organization wants to improve an existing process without immediately introducing fixed iterations.

XP practices may be appropriate when defects, integration failures, technical debt or slow feedback are major constraints. XP is particularly valuable when the team can automate tests and builds and can work closely with a customer representative.

Many DevOps teams use a hybrid arrangement: a product team uses Scrum for product-level planning, a Kanban board for daily flow, and XP engineering practices in the delivery pipeline. The hybrid should be evaluated by outcomes such as shorter lead time, improved reliability, higher quality and better customer value—not by the number of practices adopted.

9. Illustrative Case: A Digital Service Team

Background

A fictional public-service organization is developing an online appointment system. The team includes six developers, a service designer, a tester, an operations engineer and a business representative. Users need to book, change and cancel appointments. Regulations require audit records, accessibility compliance and protection of personal information.

Problem

The team initially used a sequential plan. Requirements changed after service staff and users tested prototypes. Large batches reached testing simultaneously, producing long queues and late defect discovery. Releases occurred every four months, and operations often learned about configuration requirements near the release date.

Analysis

The problem was not simply that the team lacked a particular framework. It had several interacting causes:

• work items were too large;
• development and testing were treated as separate phases;
• WIP was not limited;
• customer feedback arrived late;
• automated regression testing was weak; and
• deployment and audit requirements were not included in the completion standard.

Approach and solution

The team selected Scrum as its product-management framework, using two-week Sprints and a clear Product Goal. It introduced a Product Owner from the service organization and a Scrum Master to coach the process. A Kanban-style board made the workflow visible, with explicit limits for development, review and testing.

The team also adopted selected XP practices: automated unit and acceptance tests, continuous integration, pair programming for high-risk changes, refactoring and small releases to a production-like environment. The Definition of Done included code review, automated tests, accessibility checks, security review where applicable, audit logging and operational monitoring.

The team used Sprint Reviews with service staff and representative users. Retrospectives focused on one or two measurable improvements rather than a long list of complaints. Urgent production incidents were handled through an explicit policy rather than by silently interrupting every Sprint.

Outcome

After several delivery cycles, the organization observed smaller work items, earlier discovery of defects and fewer items waiting for testing. Stakeholders changed priorities based on actual demonstrations rather than assumptions. The case does not claim that a particular framework automatically caused success; the improvement resulted from combining clear product ownership, visible flow, limited WIP, technical quality and regular feedback.

Learning points

1. Framework selection should follow the nature of the work and the principal constraint.
2. Scrum events are valuable only when they produce inspection and adaptation.
3. Kanban limits help expose bottlenecks but do not replace technical improvement.
4. XP practices make frequent delivery safer by shortening technical feedback loops.
5. Compliance requirements can be integrated into the Definition of Done rather than postponed until release time.

10. Challenges, Limitations and Governance

Agile theatre

Agile theatre occurs when an organization adopts visible ceremonies, job titles or boards without adopting transparency, collaboration or adaptation. A daily meeting does not create agility if impediments remain hidden and decisions are made elsewhere.

Misunderstanding velocity

Velocity is an internal planning signal used by some Scrum teams to understand the amount of work completed per Sprint. It is not a universal productivity measure and should not be compared across teams. Story points are relative estimates, not units of business value or hours of labor. Management pressure to increase velocity can distort estimates and damage trust.

Excessive multitasking

Starting more work can create the appearance of activity while increasing queues, handoffs and cycle time. Teams should prefer finishing valuable work, reducing dependencies and addressing bottlenecks.

Inadequate technical quality

Agile does not justify skipping testing, security, architecture or documentation that users and maintainers need. Sustainable agility depends on technical excellence. In DevOps, automated testing, version control, infrastructure as code, observability and controlled deployment can make feedback faster and safer.

Compliance and ethical responsibility

Agile teams remain accountable for privacy, accessibility, security, safety, records management and contractual obligations. Product Owners and technical leaders should ensure that acceptance criteria and the Definition of Done include relevant controls. Personal data should not be exposed in test environments without appropriate protection. Teams should also consider algorithmic bias, accessibility barriers and the effects of automation on vulnerable users.

Governance should provide necessary oversight without requiring every decision to pass through a slow central committee. Lightweight evidence—such as test results, change records, security findings and release approvals—can support accountability while preserving delivery flow.

11. Contemporary DevOps Connections

Agile development and DevOps are complementary but not identical. Agile emphasizes iterative product development and feedback; DevOps extends collaboration and automation across development, security, operations and service delivery.

A modern team may connect Agile practices to:

• continuous integration and automated verification;
• continuous delivery with approval controls where needed;
• infrastructure as code and repeatable environments;
• monitoring, logging and tracing;
• feature flags and controlled experimentation;
• incident learning and blameless post-incident reviews; and
• product analytics that reveal whether delivered features produce value.

AI-assisted coding and testing may increase speed, but they do not remove the need for human review, secure handling of proprietary data, license awareness, testing, explainability where decisions affect people and accountability for production outcomes. AI should be treated as an assistive capability within an Agile feedback system, not as a substitute for product ownership or professional judgment.

Best Practices

• Start with a clear customer or user outcome.
• Make work, policies and quality criteria visible.
• Keep work items small enough to obtain feedback quickly.
• Limit WIP and focus on finishing.
• Automate repeatable tests and integration checks.
• Include security, accessibility, operations and compliance in “done.”
• Establish a regular learning cadence through reviews and retrospectives.
• Measure flow and outcomes rather than individual busyness.
• Select only the practices that address a real constraint.
• Adapt the process using evidence, not fashion.

Chapter Summary

Agile is a disciplined approach to delivering value under uncertainty. Its four values prioritize people and communication, working software, customer collaboration and responsiveness to change. The twelve principles translate those values into frequent delivery, close collaboration, sustainable pace, technical excellence, simplicity, self-organization and continuous reflection.

Scrum provides a structured empirical framework based on a Product Owner, Scrum Master, Developers, Sprints, formal events and three artifacts with associated commitments. Kanban improves flow by visualizing work, establishing explicit policies and limiting WIP; Little’s Law relates average WIP, throughput and cycle time under stable-system assumptions. XP emphasizes engineering discipline through practices such as test-driven development, continuous integration, pair programming, refactoring and small releases.

No framework is universally best. Scrum is useful when a team benefits from a regular product cadence, Kanban is useful when demand and flow are central concerns, and XP is useful when technical quality and rapid feedback are major constraints. Hybrid use can be effective when each practice has a clear purpose. Successful Agile and DevOps adoption depends less on ceremonies than on transparency, effective feedback, technical quality, responsible governance and continuous improvement.

Key Terms

Agile Manifesto: A statement of four values and twelve principles for Agile software development.

Agile value: A broad priority that guides decisions and behavior.

Agile principle: A general guideline explaining how an Agile value can be applied.

Artifact: A visible, inspectable object used to represent work or progress.

Backlog: An ordered list of work, opportunities or improvements.

Cycle time: Elapsed time from the start of active work to completion.

Definition of Done: A shared quality standard that determines when work is complete.

Empirical process: An approach based on transparency, inspection and adaptation.

Extreme Programming (XP): An Agile approach emphasizing customer feedback and disciplined engineering practices.

Increment: A usable, valuable addition to a product.

Kanban: A method for managing and improving the flow of knowledge work.

Lead time: Elapsed time from a defined request or commitment point to delivery.

Product Owner: Scrum accountability responsible for maximizing product value and managing the Product Backlog.

Scrum Master: Scrum accountability responsible for helping the team understand and use Scrum effectively.

Sprint: A fixed-length Scrum cycle in which a usable Increment is created.

Throughput: The number of work items completed during a specified period.

Value: A benefit delivered to customers, users, the organization or other stakeholders.

Work in progress (WIP): Work that has started but has not yet been completed.

WIP limit: A policy restricting the amount of simultaneous work in a workflow state or system.

Review Questions

Short Answer Questions

1. What is the meaning of the word “over” in the four Agile value statements?
2. Name the three Scrum accountabilities and briefly state the purpose of each.
3. What problem is a Kanban WIP limit intended to address?
4. Define the Definition of Done.
5. Name four engineering practices associated with Extreme Programming.

Long Answer Questions

1. Explain the relationship between Agile values, principles, practices and frameworks.
2. Describe Scrum events and explain how they support transparency, inspection and adaptation.
3. Explain how Kanban visualizes and improves flow, including the importance of explicit policies.
4. Compare Scrum, Kanban and XP in terms of structure, roles, cadence, WIP and technical practices.
5. Discuss why technical excellence and sustainable pace are necessary for long-term agility.

Analytical / Application Questions

1. A service desk receives unpredictable requests, urgent incidents and occasional improvement work. Recommend an approach and justify your selection using flow, WIP and governance considerations.
2. A product team holds all Scrum events but releases infrequently, has serious regression defects and pressures developers to increase velocity. Diagnose the problems and propose a practical improvement plan.
3. A regulated organization wants frequent delivery but must maintain audit records, accessibility evidence and security controls. Design a Scrum–Kanban–XP combination that preserves both agility and responsible governance.

Multiple Choice Questions with Answers

Question 1

Which statement best expresses the Agile value concerning working software?

A. Documentation should never be produced.

B. Working software provides stronger evidence of progress than documentation alone.

C. All software must be released directly to customers every day.

D. Planning is unnecessary once coding begins.

Correct Answer: B. Working software provides stronger evidence of progress than documentation alone.

Question 2

Who is accountable in Scrum for maximizing product value and managing the Product Backlog?

A. The Scrum Master

B. The Developers collectively

C. The Product Owner

D. The project sponsor exclusively

Correct Answer: C. The Product Owner

Question 3

What is the primary purpose of a Kanban WIP limit?

A. To ensure every worker has an equal number of tasks

B. To restrict unfinished work and expose bottlenecks

C. To require fixed-length iterations

D. To replace all quality standards

Correct Answer: B. To restrict unfinished work and expose bottlenecks

Question 4

Which Scrum event is primarily used to inspect the outcome with stakeholders and discuss future adaptation?

A. Daily Scrum

B. Sprint Planning

C. Sprint Review

D. Sprint Retrospective

Correct Answer: C. Sprint Review

Question 5

Which practice is strongly associated with Extreme Programming?

A. Test-driven development

B. Annual requirements freezing

C. Sequential handoff to a separate testing department

D. Prohibiting refactoring

Correct Answer: A. Test-driven development

Question 6

In the relationship L = λW, what does λ represent?

A. Average work in progress

B. Average throughput

C. Average cycle time

D. The number of workflow columns

Correct Answer: B. Average throughput

Question 7

A team averages 6 completed items per week and an average cycle time of 2 weeks. Under stable-system assumptions, what is its average WIP?

A. 3 items

B. 8 items

C. 12 items

D. 18 items

Correct Answer: C. 12 items

Question 8

Which approach is most directly centered on continuous flow and managing work through a visual system?

A. Kanban

B. Scrum

C. Extreme Programming

D. Waterfall

Correct Answer: A. Kanban

Question 9

What does the Definition of Done provide in Scrum?

A. A forecast of annual revenue

B. A shared quality standard for a completed Increment

C. A list of every possible future feature

D. A mandatory estimate in hours for each task

Correct Answer: B. A shared quality standard for a completed Increment

Question 10

A team has frequent integration failures and slow feedback from testing. Which response best reflects XP?

A. Increase batch size to reduce the number of releases

B. Adopt continuous integration and automated tests

C. Remove code review to speed development

D. Delay testing until the end of the project

Correct Answer: B. Adopt continuous integration and automated tests