Agile has mutated significantly since the publication of its manifesto. Today, how agile methodologies and iterative development veered away from traditional interpretation.
What is Agile?
Since its release, in the Manifesto for Agile Software Development, Agile has quickly transformed from an adjective to a noun. This is how we went from iterative development with agile methodologies to a poorly defined concept as “Agile”. This mutation in terminology created a great deal of confusion over the topic. Let’s establish some things to be clear:
- Agile is not a methodology
- Agile is not a specific way of developing software
- Agile is not a framework or process
- Agile is not even a noun. Something can be agile; you can’t get Agile by the dozen. Yeah, and drop the capital letter.
Leaving the language rant aside, it is hard to talk about the subject when abandoning the noun. I’ll talk about agile methodologies, agile values, and agile principles. While reading the article, remember that it is not a clearly defined idea but a set of best practices and recommendations. The spirit of agile software development challenges the prescriptive and normative sense that it has developed.
Using the word agile as an adjective makes things a bit more precise. We are not talking about Agile, but about the agile techniques, agile methodologies, agile standups, agile value, and agile principles. Shifting the focus to the adjective brings the concept closer to its original meaning.
That is why agile software development cannot be a defined recipe and why it is so hard to teach. Agile principles reject allegations of authority and experience. As with many productivity and efficiency teachings, agile values should always be adjusted to the context where they are applied. If you expect to buy a canned solution, you will quickly lose the desired agility.
Manifesto for agile software development
The manifesto for agile software development is only 68 words long, so I will put the essence of it here for you, even if it’s linked below. Consider that this page has been up and running since 2001, so its design might surprise you. When boiled down to its kernel, these people wanted to uncover better ways to develop software and help others. Their values are as follows:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
You can easily see that this group of people cherished agility, versatility, and flexibility, not a definite way of developing software, with strict rules and procedures, but a set of guidelines to loosely follow. Think of Pirates of the Caribbean. “The code is more what you’d call ‘guidelines’ than actual rules.”
We’ve talked before about open-source software development and its difference with free software. This type of free, versatile, and collaborative practice might all be part of a generalized spirit that forever grows at the heart of software development and is starting to get contagious, as we saw with open-source design.
Twelve principles of agile software
Don’t run away just yet! I won’t list all the 12 principles of agile software, but I think some of them are worth mentioning at least, just to give you a sense of what this is all about. I’ll include some excerpts here for you:
- Our highest priority is to satisfy the customer.
- Welcome changing requirements.
- Deliver working software frequently.
- Working software is the primary measure of progress.
- Simplicity is essential.
Why do I bring these here? Because I believe that the agile methodologies can be applied to other industries: video games, copywriting, architecture, recruitment, any type of business.
This freedom to work as you see fit is essential to have in mind before studying and adopting one or the other agile methodology.
Agile is dead
Wow, I think that’s the most clickbaity subtitle I ever used, but I have my reasons! They are explained perfectly in Dave Thomas’ talk: Agile is Dead (and I think of myself as original). Thomas is one of the writers of the Manifesto for Agile Software Development. In his talk, he describes the problem of selling Agile as a product and benefitting from selling recipes for success.
Dave Thomas shows how Agile has quickly mutated into a product to be sold and thought of by people who benefit from proclaiming themselves as experts. The thing is, anyone can learn agile principles really fast and without spending a dime. But that wouldn’t be a business, would it?
Thomas calls then to reclaim agility with a what to do simple checklist:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
As for how to do it, he presents a single rule of thumb:
Prepared and advised with all the needed precautions, I think it’s already time to talk about agile methodologies. You have all the tools to judge, mistrust, and take everything I say with a pinch of salt. I love that. That is truly a conversation.
Agile methodologies
We have already stated this, but I’ll say it once more; agile is not a methodology but a set of values and principles. Nevertheless, it’s common to talk about agile methodologies as the techniques and practices that incarnate such values and principles. Let’s discuss some examples.
Scrum
Scrum is a framework utilizing an agile mindset for developing, delivering, and sustaining products. Its name is borrowed from rugby because it emphasizes teamwork. Scrum is a lightweight, iterative, and incremental framework that challenges the typical sequential approach to development.
We’ve talked about multidisciplinary teams before, and scrum thrives on diversity too. A typical scrum team includes a product owner, developers, and a scrum master. But remember, when these types of structures start to get in the way of agility, you should know it’s not for the best.
Scrum has numerous activities in its workflow. Here is a list of examples:
- Sprint
- Sprint planning
- Daily scrum, or standup
- Sprint review
- Sprint retrospective
- Backlog refinement
Extreme programming (XP)
Extreme programming is also a software development methodology that claims to be agile. It aims to improve software quality and responsiveness to changing customer requirements. XP also relies on planning and established feedback loops. As with scrum, there are also a set of practices and activities that have to be accomplished to succeed.
Extreme programming also has a given set of values that overlap with the ones present in the Manifesto for Agile Software Development. These include communication, simplicity, feedback, respect, and courage.
As with scrum, extreme programming is a set of rules, methodologies, and practices that develop on top of the basic agile principles. There are other agile methodologies and approaches, such as Adaptive Software Development (ASD) or Crystal Clear (CC). What I wanted to show you with these two examples is that the choice is yours.
Any recipe followed blindly fails when performing iterative development in a volatile, uncertain, complex, and ambiguous (VUCA) environment. That is not outspoken criticism of agile methodologies but something to think about before implementing them. The next time someone tries to sell you a canned solution for your specific problem try to ask yourself: but how is this making my development any more agile?
At Awkbit we are big fans of agility, efficiency, communication, and innovation; and we tailor each project we tackle. Even as a software factory, we know how important it is to adjust to our client’s needs, adapt to new workflows, and restructure methodologies in favor of agility. Would you like to implement agile methodologies in your workflow? Are you seeking a partner for iterative development?
This article first appeared on the Awkbit blog at Iterative development: working with agile methodologies
