What Is Agile? A Philosophy That Develops Through Practice

Originally conceived for software development teams, Agile is now the premier project management approach for industries and companies all over the world. The appeal lies in its simplicity and flexibility: Agile’s lack of prescriptive practices makes it highly adoptable. And yet, when guiding Agile transformations in several companies, I’ve found this flexibility also results in misconceptions about what it means to be Agile. Many companies prioritize adhering to Agile-derived frameworks over understanding the philosophy itself.

Instead, project managers and coaches assembling and guiding Agile teams should begin by training them in adopting an Agile mindset, essentially internalizing the philosophy’s core values and principles. Only then should they combine, customize, or omit practices from Agile frameworks based on what best serves project requirements.

By tracing Agile’s historical development and tying its founding principles to the specific needs of companies and teams, this article can help project managers create an optimal future for Agile transformations. As the following cases demonstrate, Agile shouldn’t be thought of strictly as a project management approach, but rather a product development philosophy continuously evolving in practice.

Agile Antecedents

First compiled in 2001, the “Manifesto for Agile Software Development,” a succinct collection of four core values and 12 principles, was a radical response to linear, process-heavy approaches laden with rules and reams of documentation. But the history of Agile originated decades before with a method for streamlining industrial manufacturing.

An antecedent of the philosophy for its focus on iterative improvement, the Plan-Do-Study-Act model was developed in the 1930s by Bell Labs physicist and statistician Walter Shewhart. After World War II, his protege, W. Edwards Deming, applied it to train managers at Toyota. The method was integral to the development of the Toyota Production System, the chief source of Lean thinking with its efficient build-measure-learn loop.

In the 1970s, the concept was further developed when Barry Boehm proposed the Wideband Delphi technique, using an iterative process to accurately and objectively estimate the labor and time required to develop software.

With the proliferation of personal computers in the mid-1980s, it became clear that software as a product and service would become the cornerstone of the way people do business. As professionals began paying serious attention to incremental, iterative approaches to software engineering, Agile surpassed Waterfall processes as the superior development and management approach.

Researchers found that manufacturers who were innovating more quickly than their competitors were employing a multidisciplinary, team-oriented method to move a product through its life cycle. This is widely regarded as Jeff Sutherland’s inspiration for inventing the Scrum framework in 1993, which allowed him to complete ostensibly impossible projects on schedule and under budget, with minimal bugs.

Agile values in theory—emerging from these antecedents—have been borne out in my use of Agile in practice, with an emphasis on iterative development, collaborative teamwork, and accurate estimation.

What Is Agile in Theory?

As companies continue to adopt Agile ways of working, they risk making it more prescriptive than the philosophy’s framers ever intended. In my experience, leaders wishing to adopt Agile focus too much on the frameworks—or sets of specific practices and their associated nomenclature—and not enough on the values and principles.

As practitioners who are advanced in imparting Agile principles well know, every organization seeking to undergo an Agile transformation has to find and adapt approaches that suit them. I facilitate this learning process by showing teams how to follow the values and principles of the manifesto and then drawing inspiration from the frameworks, such as Scrum, Kanban, and Extreme Programming (XP), to implement them in practice.

The tenets of the manifesto are by now second nature to Agile project managers:

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

The caveat that follows these tenets in the manifesto, however, often gets overlooked: “That is, while there is value in the items on the right, we value the items on the left more.” Many Agile practitioners end up disregarding the values on the right and focusing only on what’s on the left. The result? The opposite of blindly following process-heavy frameworks: no process at all, which is equally problematic.

Striking the proper balance between the items on the right and left has become the key to how I guide Agile transformations. It’s also exemplified by the management approaches at Apple, Google, Amazon, Facebook, and Netflix, none of which have subscribed to a singular Agile framework. They’ve embodied the principles of the manifesto first and foremost, while following or changing parts of different frameworks based on what has worked best for them; as a result, they have adapted to market changes and are able to deliver new products quickly.

What Is Agile in Practice?

In the following overview, I’ve modified the original phrasing of the manifesto’s values. Changes to the semantics help clarify how I apply Agile values in practice.

In the first value, I replace the term “individuals” with “people” because being agile means being team-oriented. As for the second, it’s obvious that software has to be “working,” so the focus is now on successful and timely “delivery.” The third value is simply “collaboration,” as it applies equally to colleagues working together and teams working with clients. Finally, “frameworks” replaces “following a plan,” because this forestalls the misunderstanding that planning should be abandoned altogether.

People Over Processes

Agile transformations are difficult, primarily because most businesses are so accustomed to following processes strictly. Completing a certain number of steps with a certain set of tools, instead of developing an innovative product, becomes the end goal.

I’ve been dismayed to see this mentality give rise to a profitable “Agile industry.” As Agile founders Ward Cunningham and Jon Kern explain, many businesses sell software they claim will help companies “go Agile.” But going Agile means adopting a philosophy, not using software and following the program it prescribes.

Achieving the right balance is not about eliminating procedures, but rather finding the ones that best support each team’s development objectives. For one of my clients, a large enterprise tech organization, I implemented Disciplined Agile, an approach developed at IBM. It combines many practices from multiple frameworks, including Scrum and Kanban. It utilizes iterative development but is a little more process-heavy than traditional Agile, especially in the beginning phase, because it’s intended to fill gaps left by Scrum. Disciplined Agile worked for this client because the organization was very process-oriented. It allowed me to meet the teams halfway, get their buy-in, and persuade them to adopt a Scrum workflow.

I incorporated backlog refinement meetings, review meetings, and daily scrums to facilitate intra- and interteam collaboration. Backlog refinement is part of the Scrum Guide, but refinement meetings are not. I added these to enable healthy conversation about why we planned to implement specific features in upcoming sprints, which is helpful for Agile novices. I also chose the nomenclature “milestones”—a term used in Waterfall project management—because it was more familiar to the client. Reviews and daily scrum interactions are conventional elements from the Scrum Guide, but I made them more structured in terms of the schedule, duration, and flow.

Additionally, whereas a strict adherence to Scrum would have each person fully dedicated to one of the roles listed in the Scrum Guide, there were people on my client’s teams whose skill sets didn’t fit neatly into one role. Using the Disciplined Agile method allowed me to divide the responsibilities of these positions among multiple team members and create a process that played to the strengths of the people involved.

Software Delivery Over Documentation

Another reason I prefer customized Scrum or Kanban workflows over strict compliance with any one framework is that they give me the opportunity to add the minimum viable product (MVP) into the plan as an objective. Derived from Lean, the practice of creating an MVP is consistent with iterative development and has become a popular technique among Agile practitioners. It allows a team to deliver high-quality software and other goods to users efficiently and then refine them based on feedback. Applying it as part of a hybrid approach largely based on Scrum or Kanban has enhanced my teams’ abilities to create products that meet customers’ needs.

I’m currently working with a US-based startup and employing this method in building a cryptocurrency marketplace for NFTs. We’re focusing on creating the MVP, so we’re only writing the minimal documentation needed for now. While this approach is effective for a wide range of products, it’s especially useful for cryptocurrency and NFTs, which are in a new, experimental category that’s changing quickly. Instead of drafting complete specs and features, and having to change them repeatedly before the release, we can devote that time to incorporating user feedback to enhance our marketplace development.

Collaboration Over Contracts

The aforementioned large enterprise tech organization relied heavily on contracts for a lot of fixed-cost projects. The contracts outlined the methods they would use to complete the work, as well as the specific individuals who would be responsible for each task. Once signed, the contracts could not be changed without a lengthy request process.

Part of the transformation I led prioritized collaboration over these rigid agreements. The plan we implemented replaced the contracts with one-page documents. Each stated that we agreed to use Agile to work collaboratively—with our customers, as well as our teammates and colleagues from different teams—between designated start and end dates. Whatever came out of the collaboration would be the result. I didn’t include specifics about what the finished products might be. Because we were requesting customer feedback and incorporating it into our product development, removing specifications from our plan document made us more receptive to their responses and incentivized them to work with us more actively.

To get management on board, I asked them to let me lead a proof of concept with one small team working with one small client, who had expressed concerns that development times were too long, even before any required changes compounded the issue. By having this customer collaborate directly with our product owner, we were able to make changes mid-development and reduce delivery times significantly.

These results persuaded management to let me roll out the plan to more teams. Overall, the streamlined contract and our Agile workflow decreased the time required to develop and take product features to market.

Adaptability Over Frameworks

Another client of mine, a health tech company, also failed to strike a balance in terms of recognizing the importance of both sides of an Agile value, namely responding to change over following a plan. In this case, however, it had made the opposite of the mistake my enterprise tech client had: Instead of following a process too rigidly, it had over-indexed on flexibility while largely neglecting process. The engineers rarely knew what they should be working on because there was no prioritization or schedule. They lost time and productivity trying to figure that out each day and completed less-important tasks before more crucial ones.

I proposed the implementation of Scrum to the CEO and CTO, explaining that sprints would force the engineers to be disciplined and plan in two-week increments, as opposed to deciding what to work on every day. Also, I advised that they hire a product owner, which would fix the team’s lack of product accountability. I asked the executives to give me three or four months to work with their teams before they could expect to see results.

Having gotten their approval, I first introduced Agile values and principles, then trained the team on the product backlog and the different techniques for arranging it, including crafting epics and user stories, and creating subtasks. The techniques and meetings that we included in our workflow are deviations from traditional Scrum in that they do not appear in the Scrum Guide. I integrated them into the plan because the epics, stories, and subtasks resonated with the teams during training and the meetings promoted productive discussions.

I also included the concept of velocity, a late addition to XP that measures the total-of-effort estimates for all user stories in each product iteration. However, I used the term “capacity,” which I prefer because it emphasizes how much work team members can pick up rather than how fast they can complete tasks.

For estimation, I started with T-shirt sizing, a technique that measures projects and tasks as small, medium, and large; as the team progressed, I switched to story points, a more traditional estimation technique. Story points are often misused by teams uninitiated in Agile, who try to convert them into work hours or days, excessively focusing on time frames and judging people based on their ability to meet deadlines.

T-shirt sizing is more abstract, making it easier for teams to avoid this pitfall. However, it’s also less precise. So once the team understood how to estimate in relative terms, I transitioned them to the more sophisticated technique.

By the time the team had completed two sprints, senior management was able to see their employees working more productively and communicating more effectively. Developers were engaging with stakeholders and executive management for the first time. They had met the customer support team and had gained an understanding of how the features they’d implemented were improving users’ lives.

This approach soon led to an increase in the quality of the company’s software and a reduction in delivery time for new features from months to weeks.

What Is the Future of Agile?

The COVID-19 pandemic created a new reality in which teams could no longer be co-located, which was the preferred way to work within Agile when it was conceived. However, the idea that it must remain this way is a myth: As remote work has become commonplace, it’s become clear that close communication is entirely possible with videoconferencing software. The teams I’m working with now are fully distributed, and I’m delivering training remotely. Some teams are even opting to work asynchronously, using tools such as Notion and Loom, as well as Slack plugins like Standuply.

The distributed model of collaboration is the new world of work, with agility at its center. The work-life balance afforded to remote teams has a positive impact on morale and mental wellness, which boosts productivity and quality; it puts people over processes and is flexible and adaptable, making it quintessentially Agile.

Agile coaches, Scrum masters, and project managers should return to the philosophy’s roots and present it as the manifesto’s framers did: a flexible and dynamic set of development and delivery guidelines. They should teach executives and team leaders that, while they can take inspiration from project management, they’re not really managing anything in Agile—they’re guiding teams and freeing them to do their best work.