Nowadays, most companies claim to “be Agile”. But, once you start working there, you discover that only means they added the typical Agile/Scrum meetings to their pre-existing meetings.
What Agile is supposed to be
While “Agile” was created in February of 2021, the principles behind it were already around for (at least) several decades.
If you want to know where Agile comes from, and I highly suggest you do, read about W. Edwards Deming, The Toyota Production System, and Taiichi Ohno. You’ll learn about how Toyota rebuilt itself after World War II, to become highly efficient and known for quality.
You’ll be able to track most Agile/Scrum ideas back to these manufacturing principles and practices from the 1940s.
- Small size for units of work (user stories)
- Fast feedback (two/three week “sprints”)
- Continual improvement (retrospectives)
- Frequent quality checks (unit tests)
- Poka Yoke (make it difficult to do something incorrect – Test-Driven Development)
- Kanban boards
- Eliminating waste in the work process
In software development, Agile and Scrum are supposed to help us create the most user value possible, for the work we put in.
We should always be working on the highest-priority features. We should work in small increments, get feedback quickly, and ensure we are maintaining quality throughout the whole process – not just at the end.
If we notice any ways to improve our process, we should change the process, check if the change was an improvement or not, and look for the next way to improve our process.
This is what Agile is supposed to be – a way for us to create more valuable software faster.
How most companies implement Agile/Scrum
Unfortunately, most of the “Agile” companies I’ve worked at have focused on the “letter of the law” and not the “spirit of the law”.
They have daily standups. But, if someone brings up blocking issues, nothing gets done about them. No one listens to what their co-workers report on, so there are still issues when people make changes that breaks someone else’s work.
They have retrospectives, but never change anything in their process. Any problems brought up are met with, “Well, we can’t fix that”, or put on the backlog as a “tech task” that will never be worked on. So, the development process never improves.
One of the basic principles of Agile/Scrum is that your process should adapt to your company’s, and project’s, needs. There is not “one way” to be agile. But that’s how most people act. You’re forced to follow someone’s interpretation of what they read in a book or blog post.
My personal view is, if your development process hasn’t noticeably changed in the last six months, then your company is not “Agile”.
Does “Bad Agile” matter to you?
Many people don’t care if they work with a bad process or a good process. They seem to have the attitude that they show up to work, do what they’re told to do, and collect their paycheck.
There are some positives to that attitude. Life is less stressful when someone else takes responsibility for the process. You also don’t have to worry about suggesting a change, having it fail, and being blamed for it during your next annual review with your boss.
But, for some people, work is frustrating when the process is bad, everyone knows it’s bad, but no one is willing to change it. You go to work every day, knowing you could do better. Knowing that you don’t need to be repeatedly blocked by the same solvable problems.
It’s often difficult to get people to change – even when the change is an improvement. I now follow the saying, “If you can’t change your job (make your current job better), then you can change your job (get a new job, at a different company)”.
Ultimately, you need to find out what kind of work environment is best for you and try to find a job with that environment.
Return to “Life as a programmer outside Silicon Valley” index