Agile Software
Agile Manifesto and Priorities in Software Development
People and results over processes and documents. These values motivated seventeen leading professionals to gather in 2001 to discuss effective principles for agile software development and to create the symbolic Agile Manifesto. Despite using different methods and even competing on certain projects, this group shared a common goal: to “debureaucratize” processes for faster development.
While enforcing rigid methodologies was slowing things down, they “swam against the current” by shortening paths—shocking traditionalists and corporate bureaucrats.
Before diving deeper into this topic, it’s important to note that the movement behind the Agile Manifesto is not against methodologies, but in favor of their balanced use. After all, methods (any methods) are tools designed to facilitate and speed up processes to achieve the best results.
However, each project has its own unique characteristics and needs, not to mention that these can change over time due to new technologies, additional demands, and so on. Consequently, if methodologies are followed rigidly without considering a project’s variables, they can become inefficient in certain situations.
This is something seen in many large corporations—not just in software development, but in marketing, management, and beyond. In the pursuit of efficiency through “rule-following,” teams lose sight of the purpose behind methodologies and become less effective, to the detriment of the project.
Can you see that the problem doesn’t lie in the methods themselves, but in why they’re used and how priorities are defined? The thinkers behind the Agile Manifesto identified this inversion of values: teams were developing just to follow processes, instead of using processes to deliver real development. In this case, the order of priorities changes the outcome—because the tasks will differ depending on whether the goal is to complete process steps or to build working software with agility.
In the Manifesto for Agile Software Development, available online, the authors outline four core values that place results over bureaucracy:
Let’s break these down:
Processes only make sense if they help individuals do their work and speed up task completion. Likewise, interactions that exist only to follow protocol end up slowing things down. That’s why it’s important to question the actual need for each procedure or intermediary between those doing the work and the clients.
System documentation is important for guiding users, but it only matters if the software actually works. In other words, there’s no point creating extensive documentation if you don’t have the time or resources to focus on the core objective: delivering the system.
A client deserves to be treated as more than just a contract. Even when the client is a company, there’s still a human being making requests, asking questions, and interacting with your team. So consider their needs—and if you can’t meet them due to contract limitations, respond thoughtfully and try to offer alternatives.
Flexibility to solve problems and make changes must be prioritized over sticking to a rigid plan. If the client changes their mind mid-project, what’s the impact on timelines, tasks, and investment? Asking these kinds of questions is key to building a plan that’s “disaster-proof.” At Visie, for example, we like to break large projects into groups of smaller deliveries throughout development, allowing for changes without major disruptions.
The Agile Manifesto also includes twelve principles of agile software that its creators follow—and we recommend them for your business too. In next week’s article, we’ll describe each one and draw parallels with the day-to-day reality of a company and its dev team. Don’t miss it!
By Joana Kerr
© 2024 Visie
All rights reserved.
