I've been hearing the word "Agile" bandied around a lot over the past couple years. The word is often attached to all sorts of ideals, goals, processes, etc. in ways I wonder if even make sense? Software, consulting & business goals are sold on the word "agile." I myself have used it casually in a number of inconsistent ways abusing its meaning even more. I figured it was time to revisit what "Agile" actually is & was initially intended to mean.

Twelve Priciples of the Agile Manifesto

I can't think of a better source for the original meaning of "Agile" than the Agile Manisfeto itself, so I'm going to take each of the twelve manifesto points and see if I can grasp their real meaning.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

There are very few customers that are going to be overly impressed that you've perfected your internal processes if you never actually deliver any features. The whole point of adopting the Agile culture is that features get out to customers fast with the least amount of internal futzing necessary. The faster a feature can go from development to production, the better.

Another benefit of getting features in front of customers fast is that you can better assess what works & what doesn't early on. This doesn't mean delivering bad or broken things constantly, it means having a well streamlined delivery process that incorporates testing & quality control without hassle.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

When the delivery process is easy & not overburdened by slow process it becomes much easier to make changes. Alternatively, when projects are broken into smaller, more discrete tasks, each task can be easier to change. Large monolithic & heavily intertwined projects are complex & difficult to change especially late in the game. Work small, deliver quickly & be ready for changes as necessary.

This doesn't mean be directionless - it means be flexible. If it takes 3 years to build machine X & it's found out that actually machine Y is needed 2.5 yrs in then there becomes a real problem with large, complicated, monolithic mechanisms. However if, after 2.5 yrs, it is discovered that the machine needs rubber wheels instead of metal ones but everyone is still interested in using the machine then that becomes a much easier change to make.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Again, customers aren't interested in your process if they never see any new features. Delivering small but desireable changes quickly becomes more important than large changes with uncertain value after a very long time (in which time the original need has already disappeared).

Also, small changes are much easier to find & fix than large changes. Things that were developed just days ago are easier to recall than things that were developed weeks or months ago & are now buried in a mountain of other changes.

Business people and developers must work together daily throughout the project.

The most brilliant engineer in the world could develop the most amazing thing technically but if it doesn't serve any purpose that anyone actually wants it becomes worthless. Developers require the insight of those that interact with the customer to understand how to build something the customer actually wants so the business can flourish.

On the other hand, businesses that promise the world without any regard for the reality of building such things lose all reputation & quickly dissolve. Promises are not a profitable item (at least not long-term - the world is full of suckers, but that's a whole other discussion of ethics). Business owners need to be communicating with their developers to determine if what the customer wants is realistic. If it is not realistic then the business owner & developer need to work together to figure out what can be delivered that the customer will actually like.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Smart people can produce smart outcomes given the right environment. Smart people who are constantly boxed into a mold they do not fit into become frustrated, bitter & eventually leave. Produce environments where people are able to grow to be the best they can be at what they enjoy doing the most. It's at that point that they will be the most productive.

When people are doing what they enjoy they are far more motived to do a good job & produce something of high quality. Trust them to do well in their own environment & give them the tools to succeed.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I have mixed feelings about this. I'm not entirely sure I buy that face-to-face conversation is the most efficient method. Often face-to-face conversation leads to tangents, miscommunications, forgotten conversation points, etc. Chat & email provide context, referrence & unmistakable information. The message still needs to be articulated well, but that is the case in conversation too. With text-based communication the context can be immediately related to the thing being said & a history of the conversation is stored for later reference.

Another aspect of non-face-to-face communication that I appreciate is the ability to be asynchronous. When dealing with people in alternate timezones are those who have busy schedules it can be an absolute nightmare trying to coordinate face-to-face time. I don't see how that becomes more efficient. I know there will be many who disagree with this sentiment, but that's my opinion.

Working software is the primary measure of progress.

This seems fairly obvious. If software doesn't work then it's not useful. But what does "working" mean in this context? I believe "working" software is software that is not only functional, but deployable, maintainable, efficient & monitored. There is plenty of functional software out there that I'd consider very, very broken. If a piece of software stops working & becomes impossible to troubleshoot or fix easily or if it stops working without anyone noticing then I would consider the software to be faulty - it doesn't really work.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Here's one that seems to either conflict with the idea that Agile should promote the absense of oppressive process as well as being a concept that is abused for the introduction of ever more mis-placed process. Here's what I think it means...

Certain amounts of process (rules) allow things to work more predictably & effectively. We utilize this constantly in the technical field with the concept of protocols. Protocols are consistent processes for organizing data in a way that is predictable & repeatable. We also follow process everyday when we drive on roads in cars with other people. Without that defined process we'd have chaos.

Process also encompasses the concept of pipelines & tooling that takes the repetitive tedium as well as the guesswork out of delivering useful features to the customer. Solid processes can be understood & followed by everyone in predictable ways. People aren't confronted with the fear of figuring out what to do next when there are good processes in place to define what comes next.
Process removes errors as more & more repetitive parts of a well defined process become automated, tested & repeated. Processes can be tested & monitored. They can provide predictable results that can be measured thus providing for more accurate understandings about how long things will take.

However, process can also be oppressive & incredibly inefficient. Processes that impose unnecessary requirements, steps or oversight slow the ability to produce results & hamper innovation or creativity. Process shouldn't be used as a way of replacing trust or allowing for individual improvements. There should only be as much process as is necessary to remove burdens on productivity. It's an aspect of the environment which should be constantly reviewed & tuned.

Continuous attention to technical excellence and good design enhances agility.

Agile & it's processes should encourage the constant improvement of the product. Retrospectives on deliveries or issues are an important way to identify what is working well so it can be expanded & what is not working well so it can be addressed. If something is found to be inefficient it should be considered for redesign whether it be algorithms, processes, architecture or even culture. As these things are reviewed & improved the whole mechanism becomes more refined.

Simplicity--the art of maximizing the amount of work not done--is essential.

This is very apropos in the context of process as discussed above. Focus energy on simplifying processes to the point they are removing tedious work rather than adding burden. Free up time & energy so it can be redirected to more interesting tasks.

Architecting infrastructures & software from the perspective of simplicity first produces a result that is far easier to understand, troubleshoot, improve & automate. Complex & overly clever architectures lead to confusion, surprises & hidden inefficiencies.

Complexity often also produces drag on the process of delivering useful features quickly. Developers get bogged down in figuring out how the complexity works or adapting another feature to fit within a complex system instead of seeing the results of their work quickly. Removing useless or problematic peices of complex systems comes with far more risk & uncertainty which ultimately produces more tedious work.

The best architectures, requirements, and designs emerge from self-organizing teams.

Self-organizing teams are inherrently groups of people with a common interest & thus a strong motivation to succeed. This requires a level of maturity & discipline in individuals to be part of these teams. They each have to care their own weight in order for the team to ultimately succeed. However, the whole concept of self-organizing implies that inefficienct or incompatible members are organized out of the team when necessary. The team works like an organism that has a desire to survive & flourish.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I addressed this concept earlier in the "Continuous attention to technical excellence and good design enhances agility" principle. The process of retrospective examination allows teams to identify where they are both succeeding & lacking then learn from its findings. Successes are continued or even expanded while inefficiencies are reviewed & addressed. The process is a feedback loop that continuously improves the health of the team & it's output.

Retrospective

I suspect the above considerations will result in opposing opinions that will be valid. I suspect I will end up changing my own opinions on some of my understandings as I review them again or hear compelling arguments that convince me otherwise. That's fine & I welcome that! In the end I've been reminded of what the term "Agile" really is intended to mean & I can better identify when it's being misunderstood or even abused. It's my hope that others who use or are exposed to this term consider its actual meaning as well.