It’s been 11 years since I wrote about the notion of being "Agile" without a name. My feelings about the topic haven’t changed since then. I still believe it’s more important to be an effective software developer than one that has been labeled "agile" according to some specific agile methodology.
The Agile Manifesto suggests valuing "Individuals and interactions over processes and tools". I like it. But how can a consulting organization make money without well-marketed processes and tools? I understand the predicament and the financial forces that lead to agile software development schools of thought with certifications and documented practices and training courses.
Values and Principles
I’ve worked in organizations whose values were well aligned with those in the Agile Manifesto. However, I never heard them use the word "agile" to describe their software development practices.
One organization, in particular, operated in a very technologically competitive and fast-moving market. Tt was a risky market. A software mistake could cost the company vast sums of money in a very short period of time. They had hundreds of software developers. And yet they had no software architects to enforce discipline and they had no organizational best practices or coding guidelines.
Some developers wrote unit tests, some didn’t. Some developers used underscores before private variables and some didn’t. I saw source code files with at least 5 coding styles in a single file. There were seldom any planning sessions. Retrospectives happened sporadically. There was little to no software documentation.
Some small groups of developers might decide to use agile techniques like Kanban or Scrum. If an agile practice served that purpose for an individual or group, at least for a while, then they were free to use it. Or not. It depended on the effectiveness of the practice.
Most experienced software developers would consider this a recipe for disaster. Chaos. How could it ever work?
Effectively Free
It may be surprising, but it worked because of the principles outlines in the Agile Manifesto. Individuals interacted constantly and the interactions were free to evolve in whatever direction was most productive. And the interactions were constantly evolving.
Developers sat next to customers and those interactions were also constantly evolving. No user stories. No requirements documentation. Everyone understood that task completion estimates were just a wild guess. Stuff happens. The organization adjusted (frequently) and moved on.
Continuous integration and continuous testing helped provide some stability to the chaos. Even so, the unit test coverage was spotty. There were multiple levels of tests, both automated and manual. They even did continuous testing of runtime behavior in production systems. Testing happened everywhere and yet no one was required to test if they didn’t think it was effective use of their time. Of course, these were smart developers so many of them felt some form of testing was beneficial.
This was an environment where if you weren’t effective then you typically did not have that job for very long. But effectiveness didn’t mean being perfect or never having a bug in your code. In this context, effectiveness was a balance between development speed and quality. Sometimes speed will lead to mistakes, but speed was highly valued. So was quality. The organization recognized and supported this tradeoff and constantly worked to learn from the inevitable mistakes without casting blame on individuals. This was a complex software development environment. A mistake was almost never something that could be attributed to a single developer or even a single group within the organization.
Continuous Change
Responding to change. I was surprised how effective software development anarchy was for that purpose. It worked, but it wasn’t something a consultant could bottle up and label with a name and sell it. It wasn’t a thing that could be named. It changed constantly. It flowed. It was agile.