I know you are thinking, "Not another Agile 101 article!" We were, too. There are many resources that describe what agile is, talk about the history of the concept, and go into depth about why it is important. This article is not any of those things—rather, we would like you to forget everything you've been told; everything you've learned, read, or otherwise acquired via misuse of the term or misdeed in implementing it.
Before we unpack the word agile, we want to set some context. In February 2001, the Agile Manifesto was written by 17 people who represented a variety of different software development methods. While they all represented different areas, they had one thing in common—they felt a need to find an alternative to the heavyweight software development process that was most common at the time. It was this meeting, as well as the follow-up rallying cry by the industry, that brought agile into the forefront today.
However, because of the proliferation of information around "agile" on the internet and the tendency for companies to move towards certain methodologies over others, there is often a default thought that agile must equate with the methodology of Scrum. At Red Hat, we view this a lot simpler than that. Instead of immediately diving into methodologies and how to do things, we ask our associates to focus on the first sentence of the manifesto...
"We are uncovering better ways of developing software by doing it and helping others do it."
...and stop there—everything that comes after is subject to your own experiences and is generally based on your personal circumstances.
Here's what those words mean.
Uncovering better ways
This casually refers to the ideal that continuously improving is paramount above all other processes. Yes, this means having a perspective on what is going well or not going well. But, it is far simpler than that. It refers to the simple act of getting better at what you do as time goes on, and that includes your people, technical tooling, and workflow processes.
Developing software by doing it
There isn't much hidden behind these words, although we often associate this with the concept of teams who are able to digest requirements, make decisions on the fly, and work self-directedly to achieve an outcome for their customers. The key point here is that it isn't conceptual—you are spending your time experimenting with what works for your customers vs. having a conversation ad nauseam about what is possible before beginning work.
Helping others do it
Finally, this brings in the human element of agile—the part where teams are encouraged to talk, share, teach each other, fail safely together, and be kind to everyone while they are working in what amounts to be a stressful industry with many deadlines—hopefully encouraging folks to love their jobs.
While it may be hard to ignore the juxtaposition between the original intent of the manifesto vs. what agile looks like today, there is a strong growing sense of bringing it back to the basics. The best way to do so is to not get bogged down by the multitude of ways to get work done, but rather focus on the spirit and intent of the original words written in 2001.
3 Comments