What Is Agile?

Digital technologies are becoming part of more areas of life. They bring new services and opportunities, as well as new perspectives in internet and telecommunications. Yet an online store, CRM system, mobile application, messenger or other digital platform will not meet users' needs through technical work alone. The overall approach—and even the philosophy behind the work—also matters.

Agile emerged in software development as one such approach. Its principles can also be useful elsewhere. What does this philosophy mean, and where can it help?

What is Agile? A short history

A mechanical translation of the word does not fully explain the concept. “Agile” and “flexible” can both be translated using the same word in other languages, yet the emphasis differs. Flexibility can describe a physical property; agility also suggests mental adaptability, responsiveness and the ability to change direction.

Together, these meanings provide a fuller picture. The original article refers to D. Blinov's 2021 discussion of the history of the Agile Manifesto to explain the background. The manifesto sets out values and principles for developing software.

As software projects grew in scale, writing a complete and unchanging technical specification became increasingly difficult. Customers themselves did not always know precisely what they needed at the outset. Agile addresses work in which understanding and requirements develop during the project.

The Agile Manifesto: four values and twelve principles

The 2001 manifesto describes priorities for software development and collaboration with customers. Its four values put greater emphasis on:

• People and their interactions than on processes and tools.
• Working software than on extensive documentation alone.
• Collaboration with the customer than on negotiating contractual details alone.
• Responding to change than on rigidly following the initial plan.

The other side of each comparison still has value. The point is to keep the people and the problem being solved at the centre of the work, rather than treating the development process as an end in itself.

Twelve principles

1. Make satisfying the customer through useful deliveries the highest priority.
2. Be prepared to accommodate changing requirements, including later in development.
3. Deliver working increments frequently.
4. Keep business representatives and developers working together throughout the project.
5. Give motivated professionals the environment and support they need, and trust their work.
6. Use direct communication to improve shared understanding.
7. Judge progress primarily by working software.
8. Maintain a sustainable pace for sponsors, developers and users.
9. Pay continuing attention to technical quality and good design.
10. Keep things simple and avoid unnecessary work.
11. Allow effective, self-organising teams to develop requirements, architecture and solutions.
12. Regularly examine how the team can work more effectively and adjust accordingly.

These principles support iterative work: delivery takes place alongside analysis of results and adjustment of the next steps. A useful comparison is the PDCA cycle:

1. Plan: decide what to do.
2. Do: carry out the work.
3. Check: assess the result.
4. Act: make necessary changes and begin the next cycle.

In this sense, Agile is an adaptable approach to solving problems around the customer and their requirements. Businesses seeking to improve service can consider how these principles apply to their own circumstances.

Agile philosophy and management

Discussions often ask whether Agile is a methodology or a philosophy. It is useful to distinguish the broad philosophy from the specific methods and practices used to implement it. The approaches considered here are Scrum, Kanban, Extreme Programming (XP), DSDM and Feature Driven Development (FDD).

Scrum

The name comes from rugby and the importance of coordinated teamwork. The original article discusses the work of Japanese researchers Hirotaka Takeuchi and Ikujiro Nonaka, followed by Jeff Sutherland's application of Scrum to software development in the 1990s. It also refers readers to Sutherland's book on the method and its use in large organisations.

Several concepts help organise the work:

• Product Backlog: the ordered work needed for the product.
• Sprint Backlog: the work selected and planned for a sprint.
• Sprint Goal: the objective that gives that work a shared direction.
• Burndown chart: a possible visual aid for tracking remaining work; it is a supporting technique rather than the whole method.

Responsibilities and working arrangements must be clear. The Product Owner is accountable for product value and ordering the backlog, with the authority to make relevant product decisions. Developers create the increment. The Scrum Master helps the team and organisation use Scrum effectively and address obstacles.

A small team, clear priorities, timeboxed sprints, short daily coordination, reviews of the working result and reflection after each cycle all support this approach. The daily Scrum is timeboxed to fifteen minutes. Scrum is one way to apply Agile thinking, rather than its only possible form.

Kanban

Kanban places particular emphasis on making work visible and managing its flow. It does not prescribe the same accountabilities or sprint structure as Scrum. Where Scrum is often introduced through its defined structure, Kanban can be understood through the balance between incoming work and available capacity.

A visible workflow can show tasks moving through stages such as:

• Planned.
• In development.
• In testing.
• Done.

This visibility helps reveal queues, delays and uneven workloads. Similar boards appear in CRM systems, where a sale, purchase or approval can be seen at its current stage. A Gantt chart is another way to visualise work, although it represents scheduling and dependencies rather than the same flow model. No board by itself eliminates interruptions: the team must use the information to manage the work.

Extreme Programming (XP)

XP shortens feedback cycles in software development. Pair programming is one example: one developer writes code while another actively reviews and discusses it. Testing small pieces of work and correcting problems promptly helps the team discover mistakes before they spread.

The source article refers to Kent Beck's work on test-driven development. Practices discussed include:

• Using shared coding standards across the team.
• Writing a test before the implementation in a test-driven cycle.
• Listening carefully between developers and customers so that questions and misunderstandings are resolved.
• Planning the next step after reviewing the previous one and adjusting the current plan when necessary.

These practices help a team work with changing requirements and focus on a useful result for the customer.

DSDM

DSDM stands for Dynamic Systems Development Method. It considers preparation, the project itself and work after delivery, beginning with business goals and available resources. The article presents a historical nine-point account of its ideas:

1. Actively involve customers and users.
2. Give the development team authority to make appropriate decisions without repeated management approvals.
3. Deliver a solution fit for its purpose on time, instead of pursuing endless perfection.
4. Resolve critical functional issues promptly and deliver useful functionality.
5. Use customer feedback to improve the result.
6. Keep changes reversible where possible.
7. Establish the main requirements before detailed work begins.
8. Integrate testing throughout development.
9. Maintain close cooperation between everyone involved.

These ideas overlap with the other approaches described above. The original article refers to Jennifer Stapleton's book on DSDM for further background. This historical summary should be distinguished from the wording and structure of later versions of the framework.

Feature Driven Development (FDD)

FDD organises development around features. It predates the Agile Manifesto but shares an emphasis on incremental delivery. Its main activities are:

1. Develop an overall model and identify the problems the product must solve.
2. Build a feature list from those needs.
3. Plan work by feature.
4. Design by feature.
5. Build by feature.

FDD gives explicit attention to modelling the system. This is a difference in emphasis, not a reason to dismiss the value of other approaches.

Advantages of Agile

A major advantage is the ability to respond to change. Digital products operate in a changing environment, and frequent feedback can help teams adapt. Small teams with clear decision-making authority and close communication often find this easier to organise.

• Regular stakeholder involvement reduces the risk of misunderstandings and delayed feedback.
• Short delivery cycles make progress more visible and can improve planning.
• Problems and unmet expectations can be addressed as they are discovered.
• Attention stays on useful outcomes and business value, rather than activity for its own sake.

Limitations and implementation difficulties

Large organisations with complicated approval chains can struggle to respond quickly. If every small change must pass through marketing, a brand manager, a PR director, senior management and a monthly board meeting, changing the team's terminology will not remove the underlying delay.

Close collaboration and customer participation require deliberate effort. Distributed teams need suitable communication and working agreements; remote work changes how this is organised, rather than making Agile inherently impossible.

Another concern is that continual adjustment might prevent a product from ever being considered finished. Clear business goals, acceptance criteria, priorities and release decisions help control that risk. Iteration should produce useful deliveries, not become an excuse for endless polishing.

Agile ideas are also discussed outside IT, including engineering, equipment and consumer products. The original article uses the Britax B-Agile pushchair as an illustration of adaptability; the product name or design alone does not establish which development method its manufacturer used. The broader lesson is to choose practices that fit the work, maintain feedback and measure the value of the result.