The developers called themselves the Agile Alliance. They sought an alternative to the existing software development processes that they saw as complicated, unresponsive, and too focused on documentation requirements. So in February of 2001, the Agile Manifesto was created. Rather than an Agile methodology, it’s a set of values and processes.
The Agile Manifesto consists of four fundamental 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.
Value 1: Individuals and interactions
In the past, many software teams would concentrate on having the best possible tools or processes to build their software. The Agile Manifesto recommends that while those things are essential, the people behind the processes are even more so.
No matter how well-studied your process and high-tech your tools are, it’s the team you work with and how you work together that determines success. Any team and their ability to communicate effectively and efficiently is more important than the processes they follow or the tools use.
This isn’t to say that Agile philosophies hinder formalized processes or tools. Both can help provide structure for your team and facilitate collaborations. They come second. In the end, processes and tools are meaningless if your team can’t communicate. Having the right group of folks on your development team is vital to success. The best tools in the wrong hands are useless. Perhaps even more important is how these people communicate with each other. The collaborations between team members are what helps them to work together and solve any problems.
Value 2: Working Software
Developers would spend weeks constructing comprehensive documentation. That was before they even began writing a single line of code. And while documentation is often essential, there reaches the point when you should concentrate on delivering your customers with working software. Ultimately working software is more important than comprehensive documentation. Traditional product development processes often demanded extensive documentation before a single line of code was written.
While this value highlights the importance of delivering software over letting documentation be a bottleneck, it’s valuable to note that documentation in itself is not a terrible thing as long as you don’t overdo it.
The Agile Manifesto places delivery of software to your customers as one of the highest priorities. You can then gather any feedback to help you enhance future releases.
Value 3: Customer Collaboration
Contracts used to be king. In the past, you would draw up contracts with your customers, who would then specify the finished product. As a result, there was often a discrepancy between what the contract said, what the product did, and what the customer required. The Agile philosophy highlights the significance of customer-centric product development practices over product-centric approaches. While contracts have their place in business, a list of the things you’re offering your customer is no replacement for really communicating with them about their needs and where their challenges are.
Conventional product-centric processes allowed contracts to dictate what was delivered at the end, which left much leeway for mismatched expectations. The Agile philosophy encourages building a constant customer feedback loop into development cycles.
Under the Agile philosophy, customer collaboration begins early in the development process and frequently happens all the way through. This ethos of close collaboration with real customers helps product people ensure they’re delivering effective, valuable solutions to customers. When you talk to customers frequently and build feedback into your development process, you reduce risk and eliminate guesswork.
According to the Agile Manifesto, the emphasis should be on continuous development. It would help if you built a feedback loop with your customers to make sure that the product works continuously.
Value 4: Responding to Change
Imagine drawing up a roadmap that would never change. Well, in the past, that’s what occurred.
The trouble with fixed roadmaps is that we don’t live in a static world. Needs and constraints are constantly shifting, and priorities are always changing.
That’s why the Agile Manifesto proposes that a software team should have the capability to pivot and change direction whenever they need to, with an adaptable roadmap that reflects that. A dynamic roadmap can alter from quarter to quarter, sometimes even month to month, and agile teams can keep up with those changes. A benefit of the agile mindset is that it encourages frequent reviewing and retooling of existing plans based on new information that the team is constantly assembling and evaluating. The product roadmap, then, is no longer a static document but a dynamic strategy. Product managers in Agile settings need to learn to present their dynamic roadmaps to stakeholders transparently, revealing the likelihood of change based on new learnings.
In other words, the Agile approach lets a development team adjust its priorities and plans whenever doing so makes strategic sense. These teams do not get stuck in an antiquated plan simply because they have committed to seeing it through.
Agile is NOT:
- a methodology
- a specific way of developing software
- a framework or a process
Instead, it’s much more adaptable than a “framework.” Agile doesn’t do the work or make the determinations; it simply gives member teams a set of values to participate in for better software development.
Agile Is:
- A collection of principles that teams can use for making decisions about how to develop software.
Individuals and Interactions Over Processes and Tools
Conclusion
So, it’s the VALUES of Agile that enable teams to make Agile decisions. And it’s Agile principles that guide teams in an Agile approach to developing software.
Don’t forget that agile is a mindset, not a set of strict rules to follow. These values are up for interpretation and are not solid instructions set in stone. For more information on Agile and building a nearshore development team, speak to a member of the Bydrec team by clicking this link.
