Agile Religion

Well, you read it right, "Religion". Giving some credit to Juval Lowy, who loves to call Agile: That voodoo metastasized religion; for lots of organizations Agile is just another cool thing that they should do to attract talent and they always emphasize on being an agile shop! and "Talent" also doesn't exactly know what Agile is, but as long as there are Sprints and Stand-ups they claim to know Agile.

tldr:

• This is not a course on Agile or how to "become" Agile.
• How AI (LLMs), Bard or ChatGPT, can't be the source of truth
• Why Agile is failing for some companies
• All projects can't be nails for the Agile hammer

So What is Agile?

When you ask this from ChatGPT, it will give you this:

At its core, Agile values:

1. Adaptability: Emphasizes the ability to respond to change quickly and effectively, even late in the development process.
2. Collaboration: Encourages close collaboration between cross-functional teams, stakeholders, and customers throughout the project's lifecycle.
3. Iterative Development: Divides work into smaller increments or iterations, allowing for continuous improvement and frequent reassessment.
4. Customer Satisfaction: Prioritizes delivering value to the customer by focusing on their needs and incorporating their feedback into the development process.

Which is pretty good but not precise.
When you ask it (AI), what is the origin of Agile:

The Agile methodology has its roots in the software development industry (which is wrong). It emerged as a response to the traditional heavyweight, sequential approach to software development known as the Waterfall model. (almost correct)

Now when we ask you or your company, here is the response:

Yes! we have 2 weeks sprints, Daily Stand-ups and Sprint Demos!. There is a Product Owner and we have a backlog, we are totally agile!

Well now it is getting to look like Religion. This is Exactly what happens to a religion when the time of its glory is passed, and people only remember the ceremonies and not the reason why those ceremonies exist!

Speaking of Ceremonies, Sprint Demo, Sprint Planning, Stand-ups, Product Owner ... all of these are Scrum ceremonies, which has nothing to do with Agile!

you can be an Agile company without any of scrum ceremonies! (to quote myself, AFShin 😄 )

The origin of agile is from Car Manufacturing, to be more specific Toyota Production System (TPS).
According to wikipedia,

The main objectives of the TPS are to design out overburden (muri) and inconsistency (mura), and to eliminate waste (muda).

The waste that needed to be minimized are:

1. Waste of overproduction (largest waste)
2. Waste of time on hand (waiting)
3. Waste of transportation
4. Waste of processing itself
5. Waste of excess inventory
6. Waste of movement
7. Waste of making defective products
8. Waste of underutilized workers

and this also depends on the concept of Just-in-time:

"Making only what is needed, only when it is needed, and only in the amount that is needed"

You are not Agile!

There is a lot here to unpack. One important realization that you should have by now is that Software Development in Agile is regarded as a Manufacturing Process. Instead of Cars, in case of Toyota, we are manufacturing Software. It should also be clear that Agile is not the only great way of manufacturing, more on this down below.

As you also see, there is no mention of Sprints! or Product Owner. The goal is to increase efficiency by reducing waste and increasing automation. Having a Scrum Master, doesn't make your team Agile.

Every Religion says you should love one another as if we are the members of one family, Baha'u'llah says:

Earth is but one country and Mankind its citizens.

To be reminded of that principle, some are going to church. Now, going to church once a week (or any other cadence) doesn't make you a Christian, Loving One Another would make you a Christian, a Muslim, or a Baha'i.

Agile Manifesto

Now that you know a little bit of the origins of Agile, you should read Agile Manifesto: https://agilemanifesto.org. it is not long, just 2 pages. The Values that the 17 people signing it came up with are:

and they defined 12 principles. The first 2 are one of the most important ones (to me):

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.

Another important item is not how many tickets you are closing per sprint, it is:

Working software is the primary measure of progress.

How can you welcome change in requirements in later stages?

There is a complete Design and Architecture phase that is (for the most part) outside of Agile process.
You MUST have a design up front, the cost of change up front is so much cheaper than changing software (paying back those technical debts) later, after manufacturing process has started, and needs to be corrected.
You might ask, what if the business changes the requirements, the answer is: you should Design for change. Think about Ebay and Amazon, They are just selling things, however, if Amazon wanted to start getting items auctioned, what needs to change? how difficult that would be? that is a change in requirement, isn't it?
Yet, when looked at from a wider field of view, the nature of the business is still the same. In this case amazon is not going to open a Mediterranean restaurant. Only the section about price needs to change. Which if the design has been right, only a couple of sections need to change and the rest of the system will adapt to the change.

This is getting long and I have 2 more things to say. if you want to hear more about Design, or have a question, please let me know in the comments.

Agile is not for everything

This leads to the next point, not everything should be Agile. For example, a Software Company (manufacturer) also needs billing and accounting. Can you do Just in time billing: Make money only when it is needed, and only in the amount that is needed (Just-in-time)? Anyone that has owned a business knows, not every month is the same, sometimes your business is not as great for a whole year. Farmers with a bad weather might lose the whole crop, and there goes all the potential money!
Waterfall also is a great project management and product delivery tool. There are roads, bridges, and lots of other successful companies and projects that are not run strictly with Agile.

Can you Risk Deadlines over Quality?

And one last thing, which I think is the most important one in terms of building your vision for agile is something called: Andon Cord.
Traditionally it used to be an actual Cord, but it could be a button now, and even these days softwares can do it and it can be automated.
The idea here is that anyone could stop the production line due to quality issues or a problem with process. the question is: Is your company prepared to do this? can you stop pushing code to repo, delay the deployment and say the code is not ready? can your company escape from "Fix it later" mentality?

Netflix takes this to another level, and unleashes Chaos Monkey to production environment. On top of people, they have created a software that makes problem for their other softwares, and sometimes brings an entire region (think cloud regions) down, and does all this in production environment, and yet when you watch "The Good Place" you don't notice a thing!

Coda

I hope you are uneasy with somethings mentioned in this post, That's a great thing. That's how we learn and grow. If you decide to have a dialog and leave a comment, make sure to read the "About" page for the rules of engagement. Hopefully you are not considering ChatGPT, Bard, or any other AI a Source of Truth. As an Engineer and Architect we should think for ourselves, be honest and own our decisions; That is if we want to grow.