Agile Development: Power in the Principle
The word “agile” as applied to the creation and management of software development processes has been a buzz-word for several years now. But what does it actually mean? Why do we use the word “agile”?
Today I participated in a CppCon course titled, “System Architecture and Design Using Modern C++”. During the first day of the course, we spent a few minutes talking about “agile methodologies” and how they relate to “real-world” software development. Many participants presented opinions and made some bold statements for and against agile in certain situations. These various opinions sparked some good conversation, and all of it forced me to think about whether or not I really understand what “agile” means.
I’m sure that over the next two days of the course we will refer back to the word “agile”, so I want to make sure I have a firm understanding of what “agile” means and how we should be using it. As such, I’ve done some research, given it some thought, and would like to share what I believe to be the fundamentals we should all understand when we use the word “agile” as it relates to software development.
What is “Agile”?
Let’s go back to basics on this one by looking at a simple dictionary definition:
agile (adj.) - quick, smart, and clever; able to move and adapt easily; nimble
Using this definition, when we say something is agile, we mean it can easily adapt to changing environments and move quickly. In this sense, “agile” doesn’t tell us how something achieves these qualities. It just tells us what these qualities are.
Agile Principles
We can expand on this generic definition of “agile” even further by looking specifically into the domain of software. The origins of agile software development point back to the Agile Manifesto. This manifesto defines 12 principles that influence how agile developers and managers make decisions and act on them. These principles expand on what agile means as it relates to software, but they still don’t explicitly say how you should apply those principles. Instead they give reasons why adhering to these principles is advantageous.
In other words, the principles of the manifesto provide a convincing description of the mindset we should have in order to create processes that allow us to rapidly develop software. It is then our responsibility to apply that mindset to a physical process.
Agile in Software Development
Given all this background information, we can produce a concise definition for agile software development:
Agile Software Development involves using systematic processes for building software based on customer-centric principles that focus on providing meaningful value quickly and adapting to changing environments.
And that’s it. Just by looking at the basic definition of “agile” and the Agile Manifesto, we can derive expectations about what an implementation of these principles would look like. No elaborate trainings. No special certifications.
However, notice that even with this expanded definition, we still don’t have anything that concretely describes how agile development is done. The definition above says that agile software development is about processes, and although it describes what qualities those processes should have, it doesn’t go into detail about exactly how work needs to be done to conform with this definition.
Agile Processes
This is where the trainings and certifications come in! Turns out there are many applications of agile principles out there that are represented by processes. Some of these include:
- Scrum
- Kanban
- Scaled Agile Framework (SAFe)
Scrum and Kanban are fairly well-known. I have some experience with SAFe and have found it to work nicely for organizations that have lots of teams that all need to work together to deliver complex, high-value products. This 5-minute overview of SAFe is a great place to start to understand how the framework works and how it can scale to support agile development across multiple teams in an organization.
Each of these processes differ in how they implement agile principles, but in the end they are all just implementations. Following one of these processes does not make a team agile. What makes a team agile is a paradigm shift. Teams must adopt the agile mindset to fully realize the power in the process.
Agile in the Real World
So how do we do it? We’ve seen the benefits, and many of us are following the processes currently. But how do we adopt such a mindset on our teams? There really isn’t a silver bullet, but a great place to start is to ask ourselves and our teams a simple question:
How can I help?
The bottom line is we will never be agile if we don’t interact with others. Agile is all about relationships. This can sometimes be hard for us as software developers. We like to sit in the comfort of our cubes and focus on writing the next greatest line of code. In reality, building great software is a complex process of understanding requirements, designing a solution, implementing it, and testing and analyzing the results. Notice that in this very simple cycle, three out of the four steps cannot be done properly without involving other people. Now imagine how many more interactions with others there would be in a more complicated cycle!
By focusing first on understanding needs, we begin to shift our way of thinking into a more service-oriented perspective that gives us the motivation to create high-value solutions that address stakeholder concerns.
At the End of the Day
Agile is a set of principles. A mindset. A new way of thinking. It helps us develop effective relationships with stakeholders and team members so that we can deliver value quicker than the competition. We can use these principles to create organized processes that increase efficiency and facilitate communication amongst team members so that we can better understand and address stakeholder needs.
Remember: the power is in the principle, not in the process.