Agile is people, the rest is commentary.
Agile is "just" four principles. Simple, right?
You may have heard of this new idea called "Agile", where you prioritize people over processes etc etc etc. I occasionally saw it on Twitter, before I quit that hellsite, after which I kinda lost track of it. But I recently started clout-mining LinkedIn and now see see a lot more posts about Agile. I think it's almost mainstream!
Like any idea that picks up steam, people are now disagreeing on how to actually do Agile. There's Scrum, and Kanban, and SAFe, plus techniques like mob programming and planning poker. Other people argue that all this praxis is missing the point of Agile. As one person puts it:1
The Agile Mainfesto is 73 words. Gobs and gobs of software has been written to "do agile". Every software shop I've encountered in the last decade has told me they use an agile software development process. Being an "Agile coach" is an entire career. But the whole manifesto is just not all that. The entire body reads as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
That's it. Focus on relationships with people, and actually solving problems.
I see this sentiment all over the net: everybody is making Agile too complicated; just follow the principles and do your best.
Now for something unrelated
I grew up an Orthodox Jew, meaning I followed all of the rules laid out in the Torah.2 There's a famous story about those rules:
A non-Jew came to Rabbi Hillel3 and asked for him to explain the whole Torah while standing on one foot. Hillel stood on one foot and said "what is hateful to you, do not do to your neighbor. That is the whole Torah, the rest is commentary."
So simple!
Here's the thing though. A full copy of the Torah (with English translations) costs 40 bucks and weighs 4 pounds. But many of its commandments have contextual ambiguities. For example, the Torah says that the punishment for stealing something is (generally) you pay double the value stolen. Well, what if you steal an item that was already stolen? Who do you pay and how much? The rabbis hashed out these kinds of questions over the course of 400 years, eventually producing the Mishnah, a collected 63 volumes of commentaries on the Torah. It costs 500 dollars and weighs 42 pounds.
Except the Mishnah isn't comprehensive, either. What if the second thief returns the item to the owner, and the owner doesn't tell the courts and extracts an extra 2x value payment from the first thief? How should they be punished? The next 300 years of Mishnah analysis are codified in the Gemara, a full copy of which costs 2000 dollars and weighs 300 pounds.
That's a lot of commentary
The real world is complicated and when you get into the specifics, things get messy fast. Take the Agile principle of "individuals and interactions over processes and tools":
- What if you can't fully rely on your individuals, and don't have the capacity or resources to change that?
- What if you're working with a major language barrier in the team, and misunderstandings can be mitigated with processes?
- What about processes with proven track records? Should we force opposed individuals to use version control?
- If we're in a large company, should we standardize our tech stack, even if it makes people unhappy?
- How do we handle work that needs to be timed with other work, like coordinating with other departments or companies?
The Agile philosophy can handwave away any internal contradictions with "there is value in the items on the right", so you still need processes and tools. But that still leaves the present problem: what do you do in the specific circumstance of unreliable individuals and a language barrier? "People over process" isn't enough of an answer.
So you hash out the specifics. You come up with Scrum and sprint planning and retrospectives to deal with your particular situation, to make the Four Principles work in the real world. Over time different people in different situations come up with different things, and then you end up with a morass of incompatible and contradictory ideas. It took 73 volumes to understand the Torah's one principle. Agile has four.
Agile is people, the rest is commentary.
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.