Agile Methodology

The Agile movement was born in 2001 during a meeting of 17 forward-thinking developers at a retreat in Utah. The philosophy and principles established during the retreat formed the basis of Agile and subsequent Agile methodologies that were developed from their initial work.

Since the publication of the original document, “The Manifesto for Agile Software Development”, Agile methodology has had a profound transformative effect on not just software development but organizations across nearly every field. The values of lean product creation, iterative discovery, change-focused development, and collaborative work performed across all corporate and social groupings have formed the basis of new, advanced business and product models worldwide.

This guide to Agile Methodology will serve as an overview to introduce the core principles of Agile. We will start with a definition oofagileMethodology as proposed in the 2001 Manifesto, and continue by describing some of the most well-known offshoots that have sprung from agile. Finally, we will discuss some of the most popular Agile methods and tools.

What is Agile?

Agile is an approach to work (initially software development) that can be thought of as a commitment to continuous change and improvements.

Agile values

Agile is succinctly described in the following values, which were written in 2001 by the original Agile Manifesto team:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Looking at these principles, it is easy to see that Agile is defined by what it is not as well as what it is. The four values depicted above all have the common thread of prizing iterative discovery and collaboration over rigid deliverables. By focusing on these elements, Agile teams can not only create better products with less waste, but they can also allow room for discovery, all while keeping functional releases flowing to the end customer.
Agile vs. Waterfall development
Agile’s founders proposed a major departure from the software industry’s traditional work methods. At the time (ca. 2001), software was largely created as a single project-based effort to produce a digital product based on specific specifications set months in advance. The vision for the product was determined by a group of consultants, executives, and administrators who would then form a list of requirements to be given to management teams. The management teams would then delegate the work of coding, compiling, testing, and building out the requested software, to be performed over a set period within a set budget.

Developers referred to this system as the “waterfall” methodology because software requirements and deliverables were all dictated from the top of the company down to the core development workers.

The original Agile collaborators rejected this form of software development for several reasons. Foremost, waterfall was too inflexible to respond to customer demands that could change during development. Secondly, waterfall product design meant that all innovations were supposed to be devised before the project was ever started. This rigid framework leaves little room for the discovery of new feature possibilities until after the release is finished. Further, the software may not work as intended, so discovering this mid-development in a waterfall project meant costly delays.

Agile’s founders proposed, instead, a method of creating software that was open to discovery, innovation, and iteration. Rather than expecting an entire piece of feature-complete software to be delivered at a certain date, functional builds could be released incrementally. This reduces time-to-market and allows for development to be budgeted for in phases, as opposed to all at once.

Most importantly, Agile development acknowledges that the product as-originally-imagined may not be capable of delivering the expected level of value to customers and the company itself. Working in build phases allows for new ideas to be added or product strategies to be changed, allowing development to respond in ways waterfall cannot.

Agile principles

To overcome the shortcomings of waterfall, the Agile philosophy encourages ideas to be sourced from everywhere in the company. Also important is for product development cycles to be focused on iterative changes, delivered frequently, as opposed to major product releases that took months or years to create a functional build.

In place of traditional “waterfall” management-driven development cycles, the group proposed the following working methods which were radical at the time:

• When creating new software, start with simple concepts and ideas rather than exhaustive deliverablesDevelop a working proof-of-concept prototype that exemplifies the potential for the concept to deliver value to customers and internal stakeholders.
• Make business people and developer teams collaborate to determine ways to advance, improve, and evolve the working prototype into more-robust versions.
• Make time and space daily for direct conversations between individuals and team members so that progress is followed and new opportunities to improve the product are discovered. This can take the form of quick stand-up meetings or longer scrum meetings.
• Deliver new working versions of software frequently, continuously integrating and deploying the new changes in the live production environment. Each changed version represents an improved version of the previous.
• Reflect on the outcome of each working period (a “sprint”), and use lessons learned to improve later development.
• Give the customer a voice in the process, either through direct surveying or through indirect data signals, in order to continue improving the product

Agile and Lean manufacturing

Agile absorbs many lessons from lean manufacturing, a philosophy pioneered during the growth of advanced industrialized manufacturing in the latter half of the 20th century. Lean manufacturing eliminates unnecessary steps in product creation while improving the pace of production. These methods were famously put to use by the Japanese motor company Toyota, forming the Toyota Production System (TPS).

Key lessons for Agile learned from lean include:

• Create the most efficient process possible.
• Eliminate waste (Muda) by combining processes and removing those that do not result in a better product.
• Rigorously measure results so that products have consistent quality and consistent manufacturing cycles.
• Let workers contribute to improving processes, and rely on key personnel to drive quality, speed, and efficiency goals.
• Identify steps in the process that contribute to delays or poor quality, and address these “flow” issues so that a smooth, efficient process creates consistent products on a reliable basis.

What is Agile Methodology?

Agile methodology is a set of working methods that all reflect the Agile ideals first codified in 2001. As such, there are actually multiple methodologies that can be included under the umbrella of “Agile Methodology”. These make up the most popular Agile methods, which are each described in further detail below.

Agile methodology is defined by the following traits:

• Teams are built from subject matter experts from different areas of the organization (cross-functional teams).
• Cross-functional teams are responsible for building prototype versions of software/product concepts based on innovative ideas sourced from the team itself as well as customer feedback and product strategy teams.
• The software product is then revised during a short “sprint” to add more functionality, features, improvements, and fixes.
• Ideas for changing and improving the product are sourced from across the company Discussions on these matters take place frequently.
• Cross-functional teams discuss work progress, challenges, priorities, and new emerging opportunities during short daily “stand up” meetings.
• Once a sprint has been completed, the changes created during the sprint are incorporated into the current version of the product.
• Quality controls are introduced throughout the process, including regular testing and the incorporation of customer feedback. Issues with a specific release are discovered and (ideally) dealt with prior to the integration and delivery of the new release.
• At the conclusion of each sprint, the cross-functional team takes time to reflect on the results as well as how the process went. New goals and milestones are likely to be set based on what was learned.
• New sprints are organized for cross-functional teams to take on, which will add new features, improvements, and fixes.

What are the types of Agile Methods?

There are many popular versions and offshoots of Agile as well as methods that predated the Agile Manifesto but share its values. They include Scrum, Lean, Kanban, Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), and Crystal.

Scrum

Scrum focuses on the use of aggressive sprints to complete iterative Agile improvements. Scrum teams coordinate to get major work done during the course of sprints, and each sprint is planned so that significant work can be accomplished without compromising the quality and integrity of the release.

Scrum is notable for introducing the roles of “Scrum Master” and “Product Owner”, both of which have oversight for seeing that all the small processes add up to desirable results. Also important is the concept of a “Product Backlog”, which represents opportune features, improvements, and fixes to introduce in the next sprint.

Scrum methodology has been proven to scale to multiple teams across very large organizations with 800+ people. See how Digital.ai Agility, formerly VersionOne, supports scrum sprint planning by making it easier to manage your product backlog.

Lean

Lean manufacturing, described in part above, prioritizes the creation of continual, consistent value through a predictable “flow” of work. It emphasizes the speed and efficiency of development workflow and relies on rapid and reliable feedback between programmers and customers. Lean uses the idea of work product being “pulled” via customer request. It focuses decision-making authority and ability on individuals and small teams since research shows this to be faster and more efficient than the hierarchical flow of control.

Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.

Kanban

Kanban is a method for managing production that is closely entwined within the history of lean. The kanban method primarily makes use of a “kanban board” that tracks the current volume of work items and the stages of work through which they have progressed. A kanban board uses sticky notes (or a virtual equivalent) to track the number of current work items at each stage of the process. Once a work item has been completed, the sticky note is moved to the next stage of the process.

Kanban emphasizes flow by visualizing the current volume of work items and the progress they are at within the development cycle. When many work items get bottled up in a single stage, it is a sign to immediately tackle the amount of work-in-progress (WIP) so that the sprint or task group can be ushered towards completion. The elimination of WIP can also serve as a signal to “pull” new work items from the backlog since there is now a new capacity.

Extreme Programming (XP)

Extreme Programming, or “XP” was created in the late 90s by Agile Manifesto collaborator Kent Beck. Like Agile, it promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.

The original XP recipe is based on four simple values: simplicity, communication, feedback, and courage. It also functions through twelve critical supporting practices:

• Planning game
• Small releases
• Customer acceptance tests
• Simple design
• Pair programming
• Test-driven development
• Refactoring
• Continuous integration
• Collective code ownership
• Coding standards
• Metaphor
• Sustainable pace

Feature Driven Development (FDD)

Feature Driven Development (FDD) is a variant of Agile methodology that describes specific, very short phases of work, which are to be accomplished separately per feature. These include domain walkthrough, design, design inspection, code, code inspection, and promotion to build.

The primary concept of FDD is that the intended future state of the product can be depicted using models and that working on features helps build out a holistic product model represented by things that are “useful in the eyes of the client”.

FDD recommends specific programmer practices such as “regular builds” and “component/class ownership”. FDD’s proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams.

Dynamic Systems Development Method (DSDM)

DSDM is another early ancestor to Agile, first described in 1994. The seeds of DSDM’s creation came from rapid application development (RAD), which aimed to standardize software delivery frameworks. After the advent of Agile, DSDM further evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile process and iterative software development projects.

DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

DSDM prioritizes certain deliverables using a time-box model, and items that fall lower on priority are pre-selected to be moved aside in order to meet time-box deadlines.

Crystal

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Several of the key tenets of crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile process methodologies, crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.

Crystal is actually comprised of a family of agile methodologies such as crystal clear, crystal yellow, crystal orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project ‘s unique characteristics.

The Benefits of the Agile Methodology

Agile methods can all have their own unique strengths and purposes, but the following benefits tend to be mutual all of them:

• Working versions of software are delivered relatively quickly and frequently
• The quality and integrity of a build is understood early in the process
• Dependencies and delivery process bottlenecks are minimized
• Products reflect the current state of demands as understood from signals indicated by customers, competitors, and the market as a whole
• Innovations can be introduced at any stage of the product lifecycle
• Collaborative input is sourced from all teams, rather than from top advisors/administrators/consultants who then issue orders to the bottom
• Risks are reduced compared to development cycles that don’t emphasize functional builds
• Emphasis is placed on customer satisfaction and team morale; if neither are happy, then it is understood that the products and processes aren’t meeting needs
• Work is made more manageable and predictable while introducing flexibilities that can accommodate disruptions or sudden shifts in strategy

Top tools to use with Agile methods

Some of the most-recommended tools for Agile methods include:

• Agile Planning Software: Provides kanban and other tools for managing product backlog portfolios and planning sprints.
• Release Orchestration Software: Allows for the assignment of work items while also providing release orchestration and automation capabilities.
• Release Deployment Software: Simplifies and automates the process of deploying new releases to the operating environment, including cloud and container-based ones.
• Continuous Testing Software: Enables efficient and automated testing throughout the development process, lowering risks and costs while hastening delivery.
• Business Intelligence and Analytics Solutions: Create a single source of truth that adds transparency to release timelines, change-related risks, and opportunities to improve the quality and value delivery of releases.