As a successful Black man, I have a built-in responsibility to my community. Whether I want it or not, it’s just there. Being a successful Black man in technology, somehow makes that responsibility more pronounced.
Because of this, there have been many times when friends, family, or acquaintances have asked me to give guidance or counsel to some teenager or pre-teen about some poor choices that they’re consistently making.
Of course the expectation is for me to be an example of what can actually be accomplished. These kids need to see that there are more choices than gangs, sports, hip hop, trappin’ (drugs), and various other street enterprises (pimpin’, hustlin’, etc.). That there really are many ways to earn a successful living in this world.
As I have these conversations, one thing becomes immediately clear in 100% of the cases: the youngsters these days have no grasp of the value of a free education.
For clarification, yes I did say 100% of the cases and yes I did add bold highlighting to emphasize the fact that I found this to be true in 100% of the cases.
So my path is set: I have to show these misguided youngsters that their ancestors and countless others fought and at times had to give their very lives so that future generations could have the right to a free education.
They have to be shown just how much bullshit our ancestors and fair-minded White people had to suffer through so that their dumb asses could go to school. They need to understand why someone would fight so hard for something like this. They need to know what our ancestors understood that they do not.
Once we bridge that gap, it’s easier to get them to see why I make the following statement…
Pissing away your free education isn’t funny and it isn’t cute. It will never be the “modern-hip-cool-thing-to-do” in any context. It has been and at all times will be one of the most disrespectful things you can do to yourself, your community, and all those that came before you.
It always boils down to the fact that since they’ve always had it and never had to fight for it to get it, they simply don’t view access to free education in the proper context that motivates them to appreciate it and take full advantage of it. They need the historical context in order to properly shape their perspectives.
When it comes to Agile, I find the same dynamic at play here. A lot of these muhfukkas that go around tryna shit on Agile really don’t understand just how valuable it is, why it exists, or how fukked up things were before it came along.
Just like those youngsters that I described above, most software makers today have never programmed in a world without Agile. They’ve always had access to it and all that it has spawned for their entire programming lives. Since they don’t know what the world was like before it and since they aren’t the one’s that actually had to change the world to get it, they don’t view it in the proper historical context to appreciate it.
Hell, most of these lames don’t even know what Agile is in the first place. They have some vague notion that it’s something that allegedly “makes you go fast”. The majority of the time when I talk to someone about Agile, they immediately substitute in the word “scrum” instead. SMH.
So let’s rewind the clock a lil bit and let me educate you ignorant muhfukkas. I’d like to take a minute, just sit right there. I’ll tell you about how Agile saved our industry like a breath of fresh air.
The industry of software development was in serious trouble. To give you an idea of just how much trouble, here is an excerpt from the Standish report on the state of software development projects from the year 1994–2000.
The Standish Group categorizes projects into three resolution types:
You can easily see that even by the year 2000, 62% of software projects either failed outright or was delivered late, with fewer features, for more money. And that was considered an improvement!
In the end, who suffered most from these failures? Our employers did. You know, those that paid us for our services. They were not getting what they were paying for. Actually, they were losing money hand over fist. This was not good for us.
Sure there were some successful projects here and there and of course those projects grabbed all of the headlines. To the uninitiated, getting in on this “computer” stuff was the thing to do. That is, until they started trying to purchase their own custom software. That’s when the shit hit the fan and it was revealed just how precarious the entire situation was.
Trust me when I tell you that shit got real. The whole thing was bleak. Extremely bleak. Something was dreadfully wrong.
But what was wrong? Were the programming languages just not up to par with the modern demands of software creation? Were we all just idiots? What was the problem exactly?
To understand why everything was all fukked up, you need to first understand this…
Creating software professionally requires exactly two components. You must have the business and you must have the software makers (development). The business pays the software ninjas to build software systems that add value to the business.
The problem with creating successful software systems professionally was two fold really. Each side (business and development) had a share in the blame.
The first problem was with development and this is what started it all. As indicated by the numbers, software projects were losing a ton of money for the business.
As a result, the business had lost trust in the software ninjas. There was a huge divide between business and development.
You need to really grasp what was going on here. The people that paid us didn’t trust us.
But software still needed to be developed. These systems still needed to be built. The business still relied on the software ninjas that they couldn’t trust. So they introduced processes to control us. They were tired of wasting their hard earned money on this shit and I don’t blame them.
As a quick tangent, why do you think QA departments exist in software companies? Because we as software ninjas did such a horrible job at our jobs that entire departments needed to be invented just to make sure that we were on top of our shit.
Even with all this, things were still fukked up. Furthermore, things weren’t getting any better. They were getting worse.
As mentioned, the business needed to take control of this out-of-hand situation and so they introduced process.
This in itself was problematic, because they didn’t (and still don’t) understand what we do. They tried to control us the way they control output in a factory or an assembly line even though software creation just doesn’t work that way. But they had to do something.
So along came the dreaded waterfall model of software creation. All this did was exacerbate the problem. We literally went from the proverbial frying pan into the fire.
There were many, many problems with this model, but to sum them all up we can say that this process was too heavy, too rigid, and almost always resulted in systems being delivered even more late, and even more over-budget than they were before.
Again, shit was getting worse and worse. It was hard out here on these software streets.
If you’re familiar with the history of the United States, try to imagine that now. There were a group of rebels that had enough of the status quo and decided to fight against it.
In so doing, they created a nation. A nation free from the ills and oppression of what had come before it. A nation that has changed the world forever.
But why were they there? Because something needed to be done and the Founding Fathers knew that this problem had to be fixed from the inside. It was up to us to right this ship. The business simply didn’t (and still doesn’t) know enough about what we do in order to properly guide how we should do it.
”We need to heal the divide between business and development”.
The Founding Fathers knew that in order to heal the divide, they needed to create trust. In order to create that trust, they knew our methods needed to be transparent. Nothing should be hidden from the business. Even if they can’t understand it all on our terms, they need immediate access to it.
Contrary to the notion that Agile “makes you go faster”, the truth is that Agile is simply a methodology that builds trust. It builds that trust by telling the truth a lot sooner.
But still, what is Agile? What did the Founding Fathers actually do? What did they come up with? And how is what they came up with “Agile”?
What the Founding Fathers did, was extract from their collective consciouses what they knew about how to really build software and put it in a formal, coherent form for the rest of us to learn from and follow.
The first thing needed, was a clean and clear break up with the waterfall methodologies. In no uncertain terms, the Founding Fathers let their experience in doing this shit for real rule the day.
They came up with the following words that are our Declaration of Independence from waterfall and any other process similar to it.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
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.
One day, I’ll devote an entire post just to this Declaration of Independence. For now, suffice it to say that those words, and those words alone are what define Agile and what separates it from all other methodologies that came before it.
If I might be so bold as to paraphrase… Agile is an approach to developing software that stresses interaction between humans to produce software that works as intended that can swiftly respond to changes that are collaboratively discovered.
As the United States Constitution delineates the frame of government, so too does the Constitution of the Agile nation present the frame for governing software development.
These 12 Articles of Constitution (aka the 12 Agile Principles) elaborate upon and add substance to what’s written in the Declaration of Independence. In other words, the Declaration of Independence can be viewed as an interface and the Articles of Constitution as an abstract base class that implements the spirit of that interface through a series of 12 abstract methods.
The Constitution establishes a framework of software government that addresses the core issues head on. It exposes a clear outline detailing the way to build software correctly and thereby establishing trust between business and development.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Just as the federal government of the United States set about to limit its own power in judicial and other proceedings, and reserve some powers to the states and the public, so too does the Constitution of Agile Software Development limit itself.
The Agile manifesto never tells you how to do any of the things that it describes. It (wonderfully) tells you the things that must exist in order to be Agile, but it’s pretty much left up to you to decide how you want to get those things done.
Remember earlier when I likened the Constitution to an abstract base class that implemented the spirit of the Declaration of Independence with a bunch of abstract methods? Well that is exactly what happens when a system wants to be labeled as Agile.
Since the new system wants to be in the Agile family of methodologies, the Constitution must be its superclass. And because all of the methods on the Constitution are abstract, the new system must implement all 12 principles. Then and only then can that new system be used as an Agile methodology.
This is important because the specific implementation details of what works for one organization may not necessarily work for another. Each group of people is unique and the methodology must work for them too.
Let’s try an example. Take the 4th Article.
Business people and developers must work together daily throughout the project.
One of the ways that scrum implements this is the daily standup. All of the stakeholders can be present, but only the pigs can talk. During this standup, each pig will respond to the following questions.
For some organizations though, they may have overly sensitive developers with very fragile egos and they may feel trepidation and angst about being “put on the spot” and having to explain what they’re up to.
The daily standup would not be a good fit for this company, so maybe the way they implement this requirement is to have a slack or a hipchat channel with a summary of work done yesterday and work expected to be completed today. This could be shown for the team and not mention any individual developer.
Another organization may have overly egotistical developers and use the daily standup to brag and boast about how much shit they got done and how far ahead of everyone they are (when they’re probably just some Chump Coder variant).
That group would have to figure out how to implement the 4th Article in a way that works best for them and their culture.
This is why the Constitution doesn’t tell you how to go about doing these things. It’s goal was to tell you that you indeed must have them. How is best left to you.
Given the Constitution, you should be able to assess any methodology claiming to be Agile and determine if it fits the bill or not. You don’t have to take their word for it. Examine it to ascertain if it conforms to both the technical and management practices that Agile demands.
The world of software development hasn’t healed to the point that the Founding Fathers wanted, but it’s damned sure a lot better than it was. The Agile methodologies are a major contributor to that.
So now you should know more of the historical context of why Agile was introduced to the world. You still may not appreciate it, but at least now you know its intent and how it has impacted your life as a software ninja.
If you wanna hate on Agile, that’s your right but at least hate on it for the right reasons. Make sure you’re attacking it and not some half-baked bastardization that’s unjustly riding under the Agile umbrella.
This joint is already too long so I won’t go into much more detail about Agile consisting of both management practices and technical practices. But I do plan to write about that as its own topic soon.
Before I end this piece though, I want to make something really clear. The Founding Fathers recognized what the root causes were for the horrible state of the software industry at that time.
What they did, was have the courage to accept accountability for the role developers played in the fukk up and had the strength to tell the business flat out that “this bullshit you’re burdening us with in response ain’t working either”.
Just as the Founding Fathers of the United States merely wanted freedom from tyranny and oppression and didn’t have grand plans to set the world ablaze, neither did the Founding Fathers of modern software development expect to change the face of software creation forever.
Even though they did indeed change the world forever, that was a side effect (and a damned good one I might add). What they sincerely wanted, was for the business to trust us again.