| Table of Contents: Learn Agile & Scrum in 2 Hours | |
| Previous Chapter: About Learn Agile & Scrum in 2 Hours | Next Chapter: Agile Process |
Introduction
Agile is all about flexibility and continuous improvement. While the Agile Manifesto was written in 2001, the ideas behind Agile—like working in small steps and adapting as you go—have been around for decades.
What makes Agile different from traditional project management (like waterfall) is its approach to change. Instead of seeing change as a disruption, Agile teams expect it, plan for it, and even welcome it.
Rather than spending months (or years) mapping out every detail before getting started, Agile teams plan just enough to move forward, adjusting as they learn more. This is called “just-in-time planning,” and it keeps projects from getting bogged down by rigid structures.
Agile frameworks—such as Scrum—work in short, focused cycles, usually called sprints, where teams regularly review progress and make improvements. The goal isn’t to follow a process but to deliver something valuable as quickly and efficiently as possible.
| What Does That Mean? |
| Just in Time (JIT) Planning: An iterative approach where stakeholders and teams work together to complete a project, planning just enough—a few steps ahead. Sprint: Timeboxed intervals of work (typically two weeks) characteristic of the Agile Scrum framework. |
What Is Agile?
Agile is a flexible, iterative approach to project management and product development that prioritizes adaptability, collaboration, and continuous value delivery. Agile frameworks help teams break work into short, focused cycles called sprints, typically lasting two to four weeks, allowing for faster feedback and incremental improvements.
Instead of waiting months (or even years) to see results, Agile teams deliver progress in small, usable increments. At the end of each sprint, the team releases a working feature or product update—something customers can use, test, and provide feedback on. This ongoing feedback loop helps teams refine priorities, adjust scope, and pivot direction when needed, ensuring the project stays aligned with real-world customer needs.
But Agile isn’t just about speed—it’s about adaptability. Teams can quickly respond to change, continuously improve their work, and keep customers engaged throughout the process.
More than just a process, Agile is a mindset and philosophy—one that values collaboration, feedback, and flexibility over rigid plans, heavy documentation, and fixed contracts. It’s about delivering what truly matters, not just ticking boxes.
Figure 1: The Agile Scrum Process and Iterative Sprints
| What Does That Mean? |
| Agile: A project management and product development philosophy that emphasizes iterative progress, adaptability, and continuous value delivery. Agile Framework: A structured approach that applies Agile principles through defined roles, workflows, and practices to help teams deliver value efficiently. Examples include Scrum, Kanban, Extreme Programming (XP), and Lean. |
The Issues with Traditional Project Management
What’s wrong with traditional project management, or waterfall? Those methods involve planning, estimating, and documenting a complete solution up front—before any of the actual build work begins. Once the work does begin, tasks are actioned in a series of sequential stages.
Just like a waterfall cascading from one tier to the next, it can never repeat the previous step. Not without a lot of costly variations, anyway!
While this sequential process seems logical and straightforward, it can cause major issues during digital and software development projects. We’ll explore these issues next.
| What Does That Mean? |
| Waterfall: The traditional linear project delivery framework. It involves planning, estimating, and documenting a complete solution up front. Its cascading process is like a waterfall, hence the term. |
Figure 2: Typical Waterfall Process
Problems with Waterfall Projects
What’s the problem with this seemingly logical approach? Due to its sequential nature, in waterfall projects, everything is typically planned up-front. But as the poets write, the best laid plans of mice and men often go awry.
Reality intervenes, causing unexpected changes, and customers often change their minds, or perhaps they didn’t really know what they wanted in the first place. Waterfall doesn’t accommodate for this “on the journey” flexibility—it’s not designed for that.
As a result, waterfall projects typically suffer from the following:
- Unpredictable requirements: It’s nearly impossible to define all requirements upfront. By the time documentation is written, it’s often outdated.
- Delayed value delivery: Nothing usable is delivered until the very end. If the project gets canceled midway, all that work amounts to nothing.
- Risk accumulation: Risks build up over time instead of being addressed iteratively, making them harder to manage.
- Rigidity: Changes are seen as disruptions rather than opportunities, leading to friction between customers and teams and ultimately impacting quality.
Because modern software environments (and many other fields) evolve so rapidly, waterfall’s linear nature can struggle to keep pace, often leaving teams with outdated requirements or unsatisfactory products.
That said, waterfall is still widely used—and sometimes even required—in places where altering the plan mid-project is prohibitively complex or costly. We’ll explore these scenarios in the section, “When Isn’t Agile Suitable?” on page 148, to show how waterfall continues to be the standard in certain contexts.
Agile Manifesto
By the late 1990s, many software professionals were frustrated with the rigid, heavily documented, and sequential nature of the waterfall method—the dominant approach in large-scale software projects.
Waterfall’s step-by-step structure left little room for change, yet software development is naturally dynamic. Customers often refined their needs mid-project, market conditions shifted, and new technologies emerged.
A group of 17 software practitioners, already experimenting with more flexible approaches, gathered in 2001 to define a shared philosophy. Their goal was to prioritize collaboration, adaptability, and customer satisfaction over rigid documentation and process-heavy management.
Instead of a strict methodology, they outlined a set of values and principles to guide software teams, publishing them as the Agile Manifesto (Beck, et al. 2001).
The impact was enormous. Agile became the dominant approach to software development, influencing not just software teams but project management, product development, and even business operations. Over twenty years since the Manifesto was published, Agile adoption surged to 86% among software development teams, according to consultancy Digital.ai (Digital.ai 2021).
If you read the Agile Manifesto, two things stand out:
- It’s remarkably concise. In just 68 words, it defines four key values and twelve supporting principles.
- It’s based on values, not rigid rules. This flexibility is a key reason why Agile has flourished—it’s a mindset as much as a methodology.
| What Does That Mean? |
| Agile Manifesto: A foundational document for software development expressing the core values and principles that inform Agile ways of working created in 2001 by 17 software experts. |
Agile Values
Agile values shape the culture, mindset, and work practices of Agile teams. Instead of rigidly following bureaucratic processes that may or may not produce meaningful results, Agile teams prioritize delivering value to customers in a flexible and adaptive way.
The Agile Manifesto defines four core values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
It’s important to note that the items on the right still have value. Agile doesn’t eliminate planning, documentation, or contracts—but it prioritizes people, adaptability, and working solutions over rigid adherence to rules.
These values are central to Agile’s success. Agile isn’t just a bunch of frameworks like Scrum and the Scale Agile Framework (SAFe)—it’s a mindset that helps teams navigate an ever-changing, complex world. By emphasizing collaboration, continuous improvement, and customer feedback, Agile provides a flexible alternative to traditional, plan-driven project management.
| Insight: Adopting Agile Values |
| Teams who adopt Agile values often feel more empowered, engaged, and passionate about their work, as they have more autonomy, ownership, and alignment with the project vision and goals. According to consultancy JCURV, 71% of employees in Agile organizations with 1,001–5,000 staff feel empowered by their leadership, and that number rises to 86% for organizations with over 20,000 employees (JCURV 2020). |
| What Does That Mean? |
| Agile Values: The core beliefs that guide Agile philosophy, such as prioritizing 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. |
Individuals and Interactions over Processes and Tools
Figure 3: Individuals and Interactions over Processes and Tools
Agile emphasizes the importance of teamwork and collaboration over rigid processes and tools. Unlike traditional methods that often result in bureaucratic behaviors, such as slavish adherence to process—even if this results in terrible outcomes! —Agile recognizes that engaging with people is more important. By valuing individuals and interactions over processes and tools, Agile fosters an environment where innovation is not only encouraged, it thrives.
Working Software over Comprehensive Documentation
Figure 4: Working Software over Comprehensive Documentation
Agile prioritizes delivering functional software that meets customer needs over creating extensive documentation. This doesn’t mean documentation is unnecessary, but it should be limited to what is useful and necessary. In software development projects, minimal manuals or guides are usually all that are needed, though some projects still require comprehensive user guides or training materials. While Agile reduces the emphasis on detailed specifications compared to waterfall, documents like test specifications remain essential to ensure quality standards. The main goal is to avoid excessive and quickly outdated documentation.
Table 2: Do’s and Don’ts of Agile Documentation
| Do’s | Don’ts |
| Focus on delivering functional software | Produce excessive documentation that doesn’t add value |
| Create documentation when necessary and useful | Prioritize detailed specs over actual working software |
| Ensure user documentation is clear and minimal | Create large, complex manuals if the software is intuitive |
| Maintain essential documentation for quality standards | Skip necessary documentation for testing and delivery |
Customer Collaboration over Contract Negotiation
Figure 5: Customer Collaboration over Contract Negotiation
Traditional project management often relies on contract negotiation, which means fixing scope, schedule, and budget up front. It can create an antagonistic relationship, where everyone tries to do the minimum expected of them under the contract in an attempt to maximize their own benefit, chiefly financial. As you can imagine, this doesn’t lead to great results.
Agile, however, emphasizes customer value over contract negotiation. It does so by making customer collaboration, regular communication, feedback, and alignment key focuses. This creates a partnership arrangement where everyone benefits by working together to create the best possible products and often creating mutually beneficial long-term relationships.
| What Does That Mean? |
| Customer Value: The benefit a product delivers to its users. In other words, how well does the software (or solution) meet customer needs and solve their problems? |
Responding to Change over Following a Plan
Figure 6: Responding to Change over Following a Plan
Agile emphasizes adapting quickly and flexibly to change rather than sticking to a detailed plan. To be Agile, you must be pragmatic—change is inevitable! By planning only as much as necessary (just-in-time planning), teams can adjust to change when it occurs, whether it’s from evolving requirements or an unexpected change in circumstances.
Agile projects do involve planning, but it’s an ongoing process. Agile plans are living documents that evolve with stakeholder needs and feedback. They focus on the immediate future and are frequently revised based on each sprint’s outcomes.
Agile’s Principles-Based Approach
The Agile Manifesto advocates a principles-based approach. This makes it very flexible and responsive to customer needs. In contrast, traditional approaches provide best practices: steps, processes, competencies, and knowledge areas that project managers are expected to master to effectively deliver projects.
These best practices—which have been accumulated by generations of project managers—are assumed to achieve good outcomes. However, understanding how to apply these best practices effectively can take decades to master. Even worse, these traditional methods assume that the best practices are suitable for all scenarios or that the project manager using them is experienced enough to understand where they need to be adapted.
However, projects are rarely one-size-fits-all—and highly experienced project managers don’t grow on trees! This isn’t just true for software development, it’s true of many projects. A principles-based approach, such as Agile, allows for creativity, collaboration, and experimentation, as well as continuous improvement and learning.
A principles-based approach enables the project team and stakeholders to work together to deliver the best possible solution rather than following a predetermined plan or specification—and as it’s a team-based approach it doesn’t rely on a single, brilliant individual to orchestrate it, such as the Scrum Master.
Here are the two most common traditional approaches:
Table 3: Project Management Methods
| Process-Based Approaches | Knowledge-Area Based Approaches |
| A process-based approach, such as Projects in Controlled Environments (PRINCE2), prescribes a set of sequential steps and activities that must be followed for project management regardless of the context or the nature of the project. In PRINCE2, this process is orchestrated by the project manager. | A knowledge-area based approach, such as the Project Management Institute (PMI)’s Project Management Body of Knowledge (PMBOK), defines a set of domains and competencies that project managers need to master to successfully deliver projects—but leaves it up to the project manager to figure out how to do so. As in PRINCE2, in PMBOK, this process is orchestrated by the project manager. |
Agile’s Twelve Principles
The Agile Manifesto identifies twelve guiding principles that build on and expand the concepts embodied in the Agile values. These principles will help you understand how to “operationalize” the Agile values in your work. Embrace them as part of your Agile journey from being a newcomer to becoming a skilled team player in a high-performing Agile team.
The twelve principles are listed on the following page and can also be found on the Agile Manifesto website.
| What Does That Mean? |
| Agile Principles: Guiding principles that build on and expand the concepts embodied in the Agile values, facilitating the development of an Agile mindset and work practices. |
Agile’s twelve principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a Development Team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architecture, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Frameworks
Agile is an overarching set of values and principles—a guiding philosophy for working more collaboratively, efficiently, iteratively, and flexibly on projects to deliver better outcomes. But how do you actually “do” Agile? Like traditional project methodologies such as PMBOK, the Agile Manifesto is fantastic at telling you what and why—but not so much how to apply it.
That brings us to Agile frameworks. Frameworks are a set of practices and tools that help teams and enterprises apply Agile values and principles in their projects. Agile frameworks provide advice on how to plan, execute, and deliver products or services in a way that aligns with the spirit and intention of the Agile values and principles. They’re customizable to suit different situations and needs, and they provide the essential “how” that’s missing from a high-level manifesto.
The most commonly used Agile frameworks are Scrum, Kanban, Scaled Agile Framework (SAFe), and Scrumban—a combination of Scrum and Kanban. Scrum is by far the most common Agile framework at the team level: according to consultancy Digital.ai, Scrum is used by 63% of Agile users (Digital.ai 2023).
Figure 7: Kanban, Scrum, and Scrumban
| What Does That Mean? |
| Kanban: An Agile framework that emphasizes lean principles such as continuous delivery, a pull-based workflow system, limiting work in progress, and visualizing workflow with a Kanban board. Scrum: An iterative and lightweight Agile software development framework. It focuses on small teams of people working together with highly specified roles to address complex problems, incrementally deliver value, and continuously improve. Scrumban: A hybrid Agile framework that blends the structure and discipline of Scrum with the flexibility and flow of Kanban. |
Table 4: Comparing the Most Popular Agile Team Frameworks: Scrum, Kanban, and Scrumban
| Feature | Scrum | Kanban | Scrumban |
| Approach | Iterative and incremental | Continuous flow | Hybrid of Scrum and Kanban |
| Roles | Product Owner, Scrum Master, Development Team | No fixed roles | Scrum roles with Kanban workflow |
| Workflow | Time-boxed sprints (usually 2-4 weeks) | Continuous delivery, pull-based system | Uses Scrum iterations with Kanban flow and WIP limits |
| Planning | Sprint planning at the start of each sprint | Planning is continuous, done as needed | Combines Sprint Planning with continuous planning |
| Meetings | Daily stand-ups, Sprint Reviews, Retrospectives | Meetings as needed; no specific meetings mandated | Daily stand-ups, reviews Retrospectives as needed |
| Focus | Delivering a potentially shippable product increment | Visualizing and managing workflow, limiting WIP | Delivering value through continuous improvement |
| Best For | Complex projects needing defined roles and structure | Projects requiring flexibility and continuous delivery | Teams needing a balance of structure and flexibility |
