Transforming Cultures: The 4 Agile Values Explained

In the field of Development Operations worldwide, “Agile” is more than an industry buzzword. Since the advent of the Agile Manifesto, majority of software companies have adopted Agile as a way of life. The Waterfall practice has failed software development teams and the zeitgeist indicates that Agile development isn’t just another fleeting trend or catchphrase; needless to say, the DevOps sphere may be careening towards a pure Agile orientation.

Notwithstanding the promise of an Agile culture, many organizations are lured into the pitfall that transforming the organization into an Agile environment is just a Sunday picnic. Agile adoption is a project in itself, and it takes volumes of introspection and self-assessment to determine if your own organization is ripe for Agile.

For starters, this article briefly discusses the four values that fortify the pillars of an Agile organization. Is your company or department Agile-ready? You be the judge.

The Four Agile Values

1. Individuals and Interactions over Processes and Tools

An organization that espouses an Agile culture holds paramount the value of collaboration and teamwork over unbending adherence to processes and tools. Because an Agile organization takes pride in the competence of its people, the establishment of well-defined processes and selection of sophisticated tools always come second-fiddle. The best tools won’t help up the performance of a bunch of inept people.

Agile teams are self-organized, and don’t follow a rigid team structure. They are cross-functional and are not limited by the functional roles they had when they used to be part of a traditional organizational hierarchy. An Agile team thrives on empowerment, not on control; on leadership, and not on management.

2. Working Software over Comprehensive Documentation

The Agile way of developing software swiftly grew popular as a response to the inflexible nature of the Waterfall approach. Most of the time, it takes months before the customer gets to see the product; and if by horrid hap the software turns out to be a dud, by then it’s too late to recoup the investments that went to the  creation of the product.

The benefit of a software that is developed in an Agile environment is that the customer can see small pieces of a “working” software at a regular interval called “sprints.” Sprint length can vary across Agile organizations, but most of the time, it’s usually 2 weeks.

The working software is always the best litmus test for the performance of a software project instead of voluminous documentation and complex technical diagrams. Take note, however, that the Agile way only recommends LESS but not NO documentation. Documentation is indispensable; it may not be top priority, but it should certainly be present in any Agile project being undertaken.

3. Customer Collaboration over Contract Negotiation

Because Agile is essentially change-driven, the emphasis is placed on how teams work together and how the team members respond to abrupt turns brought about by the a shift in both technical and non-technical directions. The goal of an Agile project is to satisfy the needs of the customer; it encourages constant communication between the customer and the development team.

Contract matters, but not as much as the people working on the project.

4. Responding to Change over Following a Plan

 Truth be told, more than 60 percent of software requirements change during the course of its development. For this, the development team must be responsive to changes when a shift in direction occurs. Often times, because of limitations set by the contract and communication channels intrinsic to the organization, by the time a project is done; when the budget is depleted; when time allotted for it is used up, the customer is unhappy to find that the software turned out to be remote to what they wanted in the first place.

The Agile way places heavy importance on incorporating customer feedback throughout the project. Humphrey’s Law states that customers don’t what they want until they see a working software. When feedback is solicited and integrated early in the development process, the easier and earlier it is to deliver a working software that resonates with the voice of the customers.